Introducing Docker-specific distributions

One of the benefits of running services with Docker is that the server distribution no longer matters. If your application needs CentOS tools, it can run in a container based on CentOS. The same is true for Ubuntu. In fact, services running in containers based on different distributions can run side-by-side without issue. This has led to a push for very thin, Docker-specific distributions.

These distributions have one purpose: to run Docker containers. As such, they are very small and very limited in what comes out of the box. This a huge benefit to cloud wranglers everywhere. Fewer tools mean fewer updates and more uptime. It also means that the host OS has a much smaller attack surface, giving you greater security.

Their focus on Docker is a great strength, but it can also be a weakness. You may find yourself up against a wall if you need something specific on your host that is not available. On the positive side, many tools that might not be available in the default install can be run from a container.

CoreOS

CoreOS ( https://coreos.com ) was one of the first Docker-specific distributions. They have since started their own container project called rkt, but still include Docker. It is supported on all major cloud providers including Amazon EC2, Microsoft Azure, and GCE and can be installed locally in bare-metal or in a local cloud environment.

CoreOS uses the same system that Google uses on their Chromebooks to manage updates. If the updates cause a problem, they can be easily rolled back to the previous version. This can help you maintain stable and reliable services.

CoreOS is designed to update the system automatically which is very unique. The idea is that automatically updating the OS is the best way to maintain the security of the infrastructure. This process can be configured, by default, to ensure that only one host in a CoreOS cluster is rebooting at a time. It can also be configured to only update during maintenance windows or turned off completely. Before you decide to turn it off manually, remember that a properly configured orchestration system will keep services up and running even when the hosts they are running is on reboot.

CoreOS includes Docker but does not enable it. The following example from the CoreOS documentation shows how to enable Docker on boot. This is done by creating a new systemd unit file through cloud-init. On AWS, this is placed in the user data instance configuration:

#cloud-config 
 
coreos: 
  units: 
    - name: docker-tcp.socket 
      command: start 
      enable: true 
      content: | 
        [Unit] 
        Description=Docker Socket for the API 
 
        [Socket] 
        ListenStream=2375 
        BindIPv6Only=both 
        Service=docker.service 
 
        [Install] 
        WantedBy=sockets.target 

CoreOS uses a default core user. Users can be added through the cloud-config file:

#cloud-config 
users: 
  - name: "demo" 
    passwd: "$6$HpqJOCs8XahT$mSgRYAn..." 
    groups: 
    - "sudo" 
    - "docker" 

As SSH key can also be added with the ssh-authorized-keys option in the users block. You can add any number of keys to each user:

#cloud-config 
users: 
  - default 
  - name: "demo" 
    ssh-authorized-keys: 
    - "ssh-rsa AAAAB3Nz..." 

CoreOS also supports sssd for authentication against LDAP and Active Directory (AD). Like Docker, it is enabled through cloud-config:

#cloud-config 
coreos: 
  units: 
  - name "sssd.service" 
    command: "start" 
    enable: true 

The sssd configuration is in /etc/sssd/sssd.conf. Like the rest of CoreOS, the configuration can be added to cloud-config:

#cloud-config 
write_files: 
  - path: "/etc/sssd/sssd.conf" 
    permissions: "0644" 
    owner: "root" 
    content: | 
      config_file_version = 2 
      ... 

Note

Full configuration of sssd is beyond the scope of this book. Full documentation is at the following website: https://jhrozek.fedorapeople.org/sssd/1.13.1/man/sssd.conf.5.html

RancherOS

Rancher ( http://rancher.com ) was designed from the ground up to run Docker containers. It supports multiple orchestration tools including Kubernetes, Mesos, and Docker Swarm. There are ISOs available for installation to hardware and images for Amazon EC2, GCE, or OpenStack. You can even install RancherOS on Raspberry Pi!

RancherOS is so unique; even the system tools run in Docker. Because of this, the admin can choose a console that fits what they're comfortable with. Supported consoles are CentOS, Debian, Fedora, Ubuntu, or the default BusyBox-based console.

Rancher provides a very nice web interface for managing containers and clusters. It also makes it easy to run multiple environments including multiple orchestration suites. Rancher will be covered in more detail in Chapter 7, Using Simpler Orchestration Tools - Fleet and Cattle.

The cloud-init package is used to configure RancherOS. You can configure it to start containers on boot, format persistent disks, or do all sorts of other cool things. One thing it cannot do is add additional users. The idea is that there is very little reason to log in to the host once Docker is installed and configured. However, you can add SSH keys to the default rancher user to allow unique logins for different users:

#cloud-config 
ssh_authorized_keys: 
  - ssh-rsa AAAAB3Nz... 

If you need to add options to Docker, set them with cloud-init:

#cloud-config 
rancher: 
  docker: 
    args: [daemon, ...] 

Project Atomic / RHEL Atomic

Project Atomic ( http://projectatomic.io ) grew out of the Fedora Project but now supports CentOS, Fedora, and RHEL. Images are available for Linux KVM and Xen-based virtualization platforms as well as Amazon EC2 and bare-metal installation.

It uses OSTree and rpm-OSTree to provide atomic updates. In other words, every package is updated at the same time, in one chunk. You do not have to worry that one package might have failed updates and left the system with an older package. It also provides for easy rollback in case the updates cause problems.

Project Atomic comes pre-installed with Docker and Kubernetes. (Kubernetes is covered in detail in Chapter 5, Deploying and Managing Services with Kubernetes.) This makes it an ideal base for Kubernetes-based clusters. The addition of SELinux adds an extra level of security in case one of the running containers is compromised.

Deployment on almost any local cloud system or EC2 is made easier by the use of cloud-init. The cloud-init package lets you configure your Atomic hosts automatically on boot, instantly growing your Kubernetes cluster.

You can use cloud-init to set the password and enable SSH logins for the default user:

#cloud-config 
password: c00l-pa$$word 
ssh_pwauth: True 

You can also add SSH keys to the default user's authorized_keys file:

#cloud-config 
ssh_authorized_keys: 
  - ssh-rsa AAAAB3Nz... 
  - ssh-rsa AAAAB3Nz... 

Note

The name of the default user depends on which version of Atomic you use. For Fedora, the username is fedora, for CentOS it is centos, and for RHEL it is cloud-user.