The Atomic Host platform is now replaced by CoreOS. Users of Atomic Host are encouraged to join the CoreOS community on the Fedora CoreOS communication channels.
The documentation contained below and throughout this site has been retained for historical purposes, but can no longer be guaranteed to be accurate.
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.
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
dockercommand line tool contacts thedockerdaemon process via a socket file/var/run/docker.sockowned by groupdocker. One must be member of that group in order to contact thedocker -dprocess.
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.