Over the past several weeks, teams within the CentOS and Fedora projects have been establishing the processes needed to produce “Atomic Host” variants of their respective distributions. If you haven’t already done so, you can check out the latest pre-release Fedora Atomic and CentOS Atomic images.

Now, consuming an OS that partakes in the hotness of atomic system and application management while consisting of pre-built packages from a distribution you already know and trust is the point of Project Atomic, but you still might want to take the reins and produce your own Atomic updates or add new RPMs of your choosing.

If so, you can, without too much trouble, compose and host your own updated or changed atomic updates right from your Atomic host, or from any other sort of Docker host. Here’s how that works:

Composing and hosting atomic updates

First, start with a Docker host (I’m using an instance of the CentOS Atomic alpha, but you can use whatever you want) and clone my byo-atomic repo.

I’m not sure why, but when I performed this operation from the CentOS Atomic alpha image, I had to run my docker build command below with the --privileged argument in order for the rpm-ostree compose tree bit to work.

# git clone --recursive https://github.com/jasonbrooks/byo-atomic.git
# sudo docker build --rm -t $USER/atomicrepo byo-atomic/.
# sudo docker run -ti -p 80:80 $USER/atomicrepo bash

Once inside the container:

For CentOS 7:

# cd /byo-atomic/sig-atomic-buildscripts
# git checkout master
# git pull

If you’d like to add some more packages to your tree, add them in the file centos-atomic-cloud-docker-host.json before proceeding with the compose command:

# rpm-ostree compose tree --repo=/srv/rpm-ostree/repo centos-atomic-cloud-docker-host.json

The CentOS sig-atomic-buildscripts repo currently includes some key packages built in and hosted from the CentOS Community Build System. The CBS repos rebuild every 10 minutes, so if your rpm-ostree fails out w/ a repository not found sort of error, wait a few minutes and run the command again.

The compose step will take some time to complete. When it’s done, you can run the following command to start up a web server in the container.

# sh /run-apache.sh

Now, you should be able to visit $YOURHOSTIP/repo and see your new rpm-ostree repo.

For Fedora 21:

The master branch of the fedora-atomic repo contains the definitions required to compose a rawhide-based Fedora Atomic host. If you’d rather compose a f21-based Fedora Atomic host, you’ll need to:

# cd /byo-atomic/fedora-atomic
# git checkout f21
# git pull

If you’d like to add some more packages to your tree, add them in the file fedora-atomic-docker-host.json before proceeding with the compose command:

# rpm-ostree compose tree --repo=/srv/rpm-ostree/repo fedora-atomic-docker-host.json

The compose step will take some time to complete. When it’s done, you can run the following command to start up a web server in the container.

# sh /run-apache.sh

Now, you should be able to visit $YOURHOSTIP/repo and see your new rpm-ostree repo.

To configure an Atomic host to receive updates from your build machine, edit (as root) the file /etc/ostree/remotes.d/centos-atomic.conf or sudo vi /etc/ostree/remotes.d/fedora-atomic.conf and add a section like this:

[remote "centos-atomic-host"]
url=http://$YOURHOSTIP/repo
branches=centos/7/x86_64/cloud-docker-host;
gpg-verify=false

[remote "fedora-atomic-host"]
url=http://$YOURHOSTIP/repo
branches=fedora-atomic/21/x86_64/docker-host;
gpg-verify=false

With your repo configured, you can check for updates with the command sudo rpm-ostree upgrade, followed by a reboot. Don’t like the changes? You can rollback with rpm-ostree rollback, followed by another reboot.

Till Next Time

If you run into trouble following this walkthrough, I’ll be happy to help you get up and running or get pointed in the right direction. Ping me at jbrooks in #atomic on freenode irc or @jasonbrooks on Twitter. Also, be sure to check out the Project Atomic Q&A site.

Colin Walters [recently announced] (https://lists.projectatomic.io/projectatomic-archives/atomic/2014-October/msg00000.html) a new cloud image for Atomic that includes support for cloud-init and Kubernetes. Supporting cloud-init is a great move but running this image locally with KVM needs a different set up than previous images. Here’s a walk through to get started with this latest image and the Fedora Atomic Cloud releases. This was the first time I needed to work with cloud-init, and there was a bit of a learning curve. There are a few different examples floating around the web and none of them seemed to work quite right.

I’ve tried out a lot of different software applications in my time, so I’ve come to appreciate projects and products that make it easy to get up and running quickly and without the need for assembling a whole labful of equipment.

In this vein, the various components that comprise oVirt, the open source virtualization management project, can be piled onto a single piece of hardware in form that works well enough to credibly kick the project’s tires.

An Atomic host is a minimal system that is designed to run containers. On an Atomic host, you don’t install additional software via the traditional package management tools. The software running on the host is provided by composed upstream RPM content.

Because of this, everything running on an Atomic host should be running inside a container. In this article we are going to show you how to deploy both libvirtd and libvirtd-client onto a Atomic host and how you can deploy virtual machines with that configuration.

Scenario 1: libvirtd in a container

A libvirt installation on a single node, like a laptop, has become rather trivial theses days. Users can, for example, issue a reasonably simple yum command and install a KVM environment that only needs a few tweaks to become runnable. That simplification has masked the primary components of KVM like libvirtd, libvirt-client, virsh, and qemu. The basic Atomic deployment has none of these.

On a running Atomic system that you can boot into, you have two options for rollback. By default, atomic keeps the previously booted os tree; it will be available as a secondary bootloader entry. The first option is, while on a physical console, hold down shift to access the syslinux boot menu. While logged into a running system, atomic rollback will swap the bootloader order to the previous tree. The second option is, while logged into a running system, type atomic rollback which will swap the bootloader order to the previous tree.

There may be a time when you have an issue with the Atomic host and need to enter rescue mode to fix an issue. In this article, we will explore how to do just that.

Dockermania has been running wild, and it seems as though there’s an advocate for swapping in the containerization technology wherever we once turned to virtual machines. While Docker won’t (yet) fit the bill in all of these cases, containers are great for trying out new or updated Web applications on your local machine.

Rather than tax your speedy but space-constrained notebook SSD with a library of different virtual machines, you can stack up a series of containers on a single VM.

When WordPress hit its big 4.0 release earlier this month, I fired up an instance of the new Fedora 21 Atomic image alpha on my notebook to check out the new WordPress release, in Dockerized form.

I saw on the docker-dev list someone was asking about Fedora documentation that described how you add a user to the docker group. The user wanted to allow his users to do docker search to try to find images that they could use.

From the Docker installation documentation regarding Fedora:

Granting rights to users to use Docker

Fedora 19 and 20 shipped with Docker 0.11. The package has already been updated to 1.0 in Fedora 20. If you are still using the 0.11 version you will need to grant rights to users of Docker.

The docker command line tool contacts the docker daemon process via a socket file /var/run/docker.sock owned by group docker. One must be member of that group in order to contact the docker -d process.

Luckily this documentation is somewhat wrong, you still need to add users to the docker group in order for them to use docker from a non-root account. I would hope that all Distributions have this policy.

When compared to dynamic sites based on WordPress or Drupal, staticly generated blog and Web sites (like this one) can go a long way toward simplifying deployment and maintenance. There’s no database or server-side code to maintain, and, when paired with a service like Github or Gitlab, you can accept posts or other contributions from anyone, via pull request.

However, while simplifying certain areas, static sites introduce a bit more complexity in other areas. Among the handful of Middleman-based static sites that our team at Red Hat help maintain, we’ve seen the specter of "it works on my laptop" arise.

With Middleman, authors preview content on their local machine, using Middleman’s built-in development server. There isn’t much setup required to run this development server, but when the same Middleman code runs on different machines, with different operating systems, and different assortments of Ruby gems, things don’t always work as expected.

Enter Docker, which makes it easy to enforce a common application environment for users on different machines. Here’s how I’m using Docker to write and preview this post:

First, I’ll make sure that git and docker are installed on my Fedora 20 notebook, and I’ll add myself to the docker group on my machine.

sudo yum install -y git docker-io

sudo usermod -a -G docker $USER

For the group add to take effect, you must log out and back in, or run su - $USER before continuing.

Then, I’ll cruise over to Github, make a fork of the Project Atomic Web site repo, and clone my new repo:

git clone git@github.com:jasonbrooks/atomic-site.git && cd atomic-site

There’s a script named docker.sh in the repository that builds and runs a Docker container for running local development version of the projectatomic.io site.

I have a couple of modifications for the script and Dockerfile, which make it easier to viewing changes to the site as I write.

First, in the Dockerfile included in the repo, I change the FROM line to FROM fedora:20, which is the official Fedora image. If you’d prefer a CentOS image, you can change this line to FROM centos:centos7. If you do, you’ll also need to add tar and patch to the list of packages to install in line 5.

I also remove line 11, ADD source /tmp/source, because rather than roll the site source into my image, I’m going to point to the source directory in my checkout of the site. This way, I can add and edit posts without rebuilding the image.

Next, I edit the docker.sh script included in the repo such that the docker run command reads:

docker run -p 4567:4567 -v "$(pwd)"/source:/tmp/source:ro middleman

Finally, I modify the SELinux context of my checked-out source directory to allow my Docker container to read it: chcon -Rt svirt_sandbox_file_t source/ To build and run the container, simply run: sh docker.sh After a short time (shorter, naturally, if you have an image already cached on your machine), the Middleman development server will be running on your machine at http://0.0.0.0:4567.

When you add to or edit the posts and other files within the source directory in your checked-out repo, you can refresh the page in your browser to see your changes.

I see people rushing to set up Web sites and PaaS Servers that allow random people to upload Docker container images, and I feel like I am the voice in the wilderness. Remember, containers do not contain!

Containers Do Not Contain

As I stated in my posts on OpenSource.com, not all of the operating system is namespaced. Parts that are not namespaced can potentially allow containers to attack each other, or the host, or at the very least will allow leakage of information into the containers.

The Fedora Project holds regular Test Days to help put releases or individual components through their paces. This week, Fedora’s Test Day will focus on Cockpit, which will be part of the Fedora Atomic Host in Fedora 21.

If you’d like to participate, be sure to look over the Test Day on the Fedora wiki and check out the prerequisites, test cases, and how to file results and bugs.

Note that the test day runs all day, and you should be able to find help in the #fedora-test-day channel on Freenode. (New to IRC? See the Fedora guide on IRC.)

Questions? Ask on the cockpit-devel mailing list.