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.
This is the first part of a series of posts about containers’ images. In this first part we’re going to focus on skopeo.
Back in March, I published a post about skopeo, a new tiny binary to help people interact with Docker registries. Its job has been limited to inspect (skopeo is greek for looking for, observe) images on remote registries as opposed to docker inspect, which is working for locally pulled images.
As part of the effort to continually improve the developer experience and make getting started easier, the ADB now supports client binary downloads. These downloads are facilitated by a new feature in ‘vagrant-service-manger’, the install-cli command.
The vagrant-service-manager plugin enables easier access to the features and services provided by the Atomic Developer Bundle (ADB). More information can be found in the README of 'vagrant-service-manager’ repo.
The install-cli command was released as part of 'vagrant-service-manager’ version 1.2.0. This command installs the client binary for services provided by the ADB. Today it can download client binaries for docker and OpenShift. This feature allows developers to know they have the best client for use with the ADB services they are using.
Last week, the CentOS Atomic SIG released an updated version of CentOS Atomic Host (tree version 7.20160707), featuring updated versions of docker and the atomic run tool.
CentOS Atomic Host includes these core component versions:
CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. Check out the CentOS wiki for download links and installation instructions, or read on to learn more about what’s new in this release.
CentOS Atomic Host now ships with runC, a lightweight client wrapper around libcontainer for spawning and running containers according to the Open Container Initiative specification. In this release, the host’s atomic run tool makes use of runC to manage system services running in containers. While it’s possible to run system containers with docker, there are certain system components that present chicken-and-egg scenarios, such as flannel, on which docker itself depends.
runC-based containers can be pushed and pulled from standard docker registries, but are composed slightly differently than standard docker containers, as described in this post from Mrunal Patel, and this Dockercon 2016 talk from Phil Estes.
For more information on the system container feature in atomic, check out the man page for the atomic install command and this blog post from Giuseppe Scrivano.
Elsewhere on the OCI front, users who wish to run systemd inside of their containers can do so more simply with this new atomic host release, thanks to a pair of OCI hooks that enable users to run systemd in docker and OCI compatible runtimes such as runc without requiring the --privileged flag, and to display journal information from these containers using the host’s journalctl command.
Also new in CentOS Atomic Host is an updated version of OSTree, the project that provides for atomic system upgrades for Atomic Hosts. The new OSTree version adds support for the ostree admin unlock command, which mounts a writable overlayfs, allowing users to install rpms on their otherwise immutable atomic hosts. These overlaid packages can be made either to persist between reboots or not, but the overlay will be discarded following an ostree upgrade. For more information on this feature, check out Jonathan Lebon’s blog post on hacking and extending atomic hosts.
For a more permanent package overlay option, there’s a brand-new package layering capability available, which Jonathan also covers in his post. However, this capability is not yet included in the main CentOS Atomic Host release.
To facilitate the testing of this and other new atomic host features, the SIG is now producing a Continuous atomic host tree, which combines a base of CentOS packages with an overlay of certain continuously-built packages pulled from upstream git sources. The packages are built using a project called rpmdistro-gitoverlay that runs as a Jenkins job within the CentOS CI infrastructure.
Switching to the Continuous release involves adding a new remote entry to an existing atomic host, rebasing to the continuous tree, and rebooting into the new tree:
# ostree remote add --set=gpg-verify=false centos-atomic-continuous https://ci.centos.org/artifacts/sig-atomic/rdgo/centos-continuous/ostree/repo/
# rpm-ostree rebase centos-atomic-continuous:centos-atomic-host/7/x86_64/devel/continuous
# systemctl reboot
Many of the features that make Atomic Host great are due to the immutability of
/usr. Things like atomic upgrades and rollbacks and efficient storage of files
in an object store all require immutability. However, this immutability is also
what can irritate people the most when they first start using Atomic Host.
There is no yum or dnf to install programs. We are at the mercy of the
content provider.
The answer of course is to use containers. Keep a pet
SPC container around
that will allow you to do all the configuration and hacking you need, all in the
comfort of your favourite editor.
But if you’re hacking on the Atomic Host itself, containers can only take you so far. What if you want to change the version of docker on the host? Or install a new package? Or modify an installed Python script for debugging?
I recently answered an email asking about –selinux-enabled in the docker daemon, I thought others might wonder about this, so I wrote this blog.
I’m currently researching the topic of
--selinux-enabledin docker and what it is doing when set to TRUE.From what I’m seeing, it simply will set context and labels to the services (docker daemon) when SELinux is enabled on the system and not using OverlayFS.
But I’m wondering if that is even correct, and if so, what else is happening when setting
--selinux-enabledto TRUE.
`--selinux-enabled on the docker daemon causes it to set SELinux labels on the containers. Docker reads the contexts file /etc/selinux/targeted/contexts/lxc_contexts for the default context to run containers.