Kubernetes exposes DNS for service discovery, but the DNS server itself must be configured after you install Kubernetes. In the future it will be integrated into kubernetes as part of the platform (see PR11599) but for now you have to setup and run the SkyDNS container yourself.

I have seen some tutorials on how to get skydns working, but almost all of them are rather involved. However, if you just want a simple setup on a single node for testing then it is actually rather easy to get skydns set up.

I recently was tasked with testing a change in the upstream ostree code on an Atomic Host.

Well, since Atomic hosts use ostree as their distribution model, that means I couldn’t just get an RPM and install it that way. (I could have just copied over the compiled binary, but where is the fun in that?)

My task list was as follows:

1. build ostree from source
2. package ostree into an RPM
3. create an custom ostree compose
4. rebase an existing Atomic host to the custom compose

As someone who hadn’t really accomplished any of these tasks before, I had to reach out for some help on multiple occasions, but I got through it all and hopefully this guide will help you along the way.

Docker image metadata can be arbitrarily extended using the LABEL directive in a Dockerfile. This is a great way to annotate an image and enable automation:

• How to run or install an image
• Who built an image
• URLs for documentation or other support information

We’ve been encouraging the docker community to standardize these LABELs in an open source way through the Container Application Generic Labels repository. Recent pull requests added a new vendor directory for software companies (or FOSS projects) to document metadata that is specific to their particular needs.

As a point of reference, Red Hat released their LABEL metadata and image naming policy to the community. This might be a useful reference for other folks building their own metadata.

Have metadata for your project? Just submit a pull request to help create documentation about metadata your tooling or application depends on. Have questions? Ask on the atomic-devel mailing list, or create an issue in the GitHub repository.

A single Atomic Host is a fine place to run your containers, but these hosts are much more fun when bunched into clusters, a task that we can manage with the help of Kubernetes.

There are a lot of great guides for setting up a kubernetes cluster, but my favorite involves ansible and vagrant, and lives in the kubernetes contrib repository on Github.

This install method can be used with the libvirt, virtualbox or openstack vagrant providers. You can also use the ansible scripts on their own, if vagrant isn’t your thing.

Next week, on Tuesday, September 22nd, the Fedora Cloud and CentOS Atomic special interest groups will be dabbling in test day fusion to put each projects’ Atomic Host Images through their paces.

On the Fedora side, we’ll be testing images based on the upcoming Fedora 23. On the CentOS side, we’ll test images from our latest release, as well as one or more development images featuring newer components atop the CentOS 7 base.

It’s been a while when we announced move of atomic-reactor under Project Atomic.

Since the name is so cryptic, one could wonder about the purpose of the tool. Let’s go through a simple example…

What problem is atomic-reactor trying to solve?

Imagine Bob, a software engineer who would like to ship company’s products as containers. Bob’s company has already pretty complex infrastructure with build system, source code management, product deployment and delivery.

So Bob starts the work on integrating docker into company’s infrastructure.

Bob knows it’s so easy to build a docker image:

$ docker build --tag=product-X .

Docker 1.8 fixes a long term problem with handling of command line options. It introduces the docker daemon command which segregates the global options from the daemon options.

Docker daemon is a background server side process that manages images and containers. It is a child of the init system e.g systemd and can be started using systemd unit files. For the purpose of this article we will using linux distribution fedora.

A system administrator can execute systemctl start docker to start the docker daemon.

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:

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:

One of the issues with containers built “The Right Way” (TM) (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.