Big news, fans of all things Atomic – the CentOS Project’s Atomic SIG has released an updated CentOS Atomic Host system tree and image set, which includes Kubernetes v1:
Project News
Introducing the “fedora-tools” Image for Fedora Atomic Host
Borrowing from the Red Hat Developer Blog entry, here’s an introduction the “fedora-tools” image for Fedora Atomic Host.
When Red Hat’s performance team first started experimenting with Atomic, it became clear that our needs for low-level debug capabilities were at odds with the stated goal of Atomic to maintain a very small footprint. If you consider your current production environment, most standard builds do not include full debug capabilities, so this is nothing new. What is new, is that on Red Hat Enterprise Linux (RHEL) you could easily install any debug/tracing/analysis utility, but on Atomic:
Using a Super Privileged Container to Troubleshoot Container Problems
One of the issues with containers built The Right Way
™ (e.g., minimal containers that only provide the application code) is figuring out what’s going on inside the container. If you ship just application code, you run the risk of turning your container into a proverbial black box. Atomic hosts can provide a one way view of all of the operations inside a container, if you can find the right tool. Rather than adding more tools to your application container, folks like Dan Walsh have been working on super privileged containers to manage the host, such as the Cockpit container.
I was recently introduced to Sysdig for inspecting running process and activity on a Linux system. It’s a fairly nifty tool that understands Docker containers, and the authors have made sure that sysdig can be run in a container. This made it very simple to install on my laptop and start investigating.
Running a Containerized Cockpit UI from Cloud-init
Fedora 22’s Atomic Host dropped most of packages for the web-based server UI, cockpit, from its system tree in favor of a containerized deployment approach. Matt Micene blogged about running cockpit-in-a-container with systemd, but people have expressed interest in learning how to start this container automatically, with cloud-init.
cloud-init and cockpit
Referencing the sample cockpitws.service file from Matt’s post, and using cloud-init’s cloud-config-write-files functionality, I started out with this service file:
Deploy Kubernetes with a Single Command Using Atomicapp
Kubernetes, the open source orchestration system for Docker containers, is a fast-moving project that can be somewhat complicated to install and configure, especially if you’re just getting started with it.
Fortunately, the project maintains some really well-done getting started guides, the simplest of which steps you through running Kubernetes, in Docker containers, on a single host.
The up-and-running part of the walkthrough amounts to issuing just three docker run commands:
# docker run --net=host -d gcr.io/google_containers/etcd:2.0.9 /usr/local/bin/etcd --addr=127.0.0.1:4001 --bind-addr=0.0.0.0:4001 --data-dir=/var/etcd/data
# docker run --net=host -d -v /var/run/docker.sock:/var/run/docker.sock gcr.io/google_containers/hyperkube:v0.21.2 /hyperkube kubelet --api_servers=http://localhost:8080 --v=2 --address=0.0.0.0 --enable_server --hostname_override=127.0.0.1 --config=/etc/kubernetes/manifests
# docker run -d --net=host --privileged gcr.io/google_containers/hyperkube:v0.21.2 /hyperkube proxy --master=http://127.0.0.1:8080 --v=2
Now, this isn’t as simple as rattling off a single command from memory, but we can’t have everything…
…or can we?
Through the magic of a couple tools we’ve been working on here at Project Atomic, we can get up and running with the upstream kubernetes project’s containerized install method using a single command like this:
# atomic run jasonbrooks/kubernetes-atomicapp