July 20–24, 2015
Portland, OR

CoreOS DNA on Debian

Patrick Galbraith (Hewlett Packard)
5:00pm–5:40pm Wednesday, 07/22/2015
Tags: Linux, Devops
Average rating: *****
(5.00, 1 rating)

Prerequisite Knowledge

Basic Unix systems administration and DevOps experience.


Recently, the Advanced Technology Group at HP embarked on a project to demonstrate a clustered Docker solution. The goal was to build a proof-of-concept that used exciting new technologies on top of Debian, the Linux distribution of choice used for HP Helion. Our group decided that CoreOS was an emerging Linux distribution that used a promising architecture, and that we would build CoreOS components, or as we thought of it “CoreOS DNA”, on top of Debian.

The components we used for a clustered Docker solution for our POC were:

  • Docker: a platform for building, shipping, and running of distributed applications using containers. Containers are an operating system-level virtualization built into the Linux kernel that allow applications to run self-contained and eliminate the historical frustration of dependency hell.
  • Etcd: a simple, highly available, durable, and distributed (using Raft) key/value store, written in Go, that allows simple values pertaining to a given machine or subsystem that other components can utilize to work in conjunction with. Its API is simple HTTP/JSON.
  • Fleet: a rudimentary scheduler for Docker, designed to be very low-level and a foundation for higher-order orchestration. Fleet is written in Go, runs on a single machine, and uses etcd to discover information about services and containers on other machines. Fleet is the interface that uses systemd across machines to control the state of Docker containers, in essence providing a distributed system functionality.
  • systemd: Not necessarily a component, but an innate standard with newer versions of Linux funamentally crucial for the cluster to work. This is a system of daemons, libraries, and utilities that replace upstart and init scripts. Systemd uses the concept of unit files that define which process to run, how to run it, and ensures that there are no conflicts with the process. The version of Debian we built our POC on included systemd by default.

Using HP’s Public Cloud, built from OpenStack, we constructed a compute virtual machine image using Ansible to deploy the virtual machine, as well as install and configure each of these components to work in a five-node cluster.

This talk will cover exactly how we did this, including:

How we used Ansible to:

  • Orchestrate and deploy HP cloud instances
  • Build the VM images to contain the software needed for a clustered Docker including Docker, Etcd, and Fleet
  • Configure the lauched images required for etcd to properly run as a cluster.
  • Configure Fleet to properly interact when etcd as well as systemd

Fleet usage:

  • How systemd unit files are loaded into the cluster
  • Discuss each unit file for the ELK Stack demo application and what comprises a unit file
  • Demonstrate the cluster re-launching a container when another has failed

ELK Stack Demo application:

  • Overview of ELKStack and how the components, being distinct containers, work together.
  • Demonstrate the Demo application generating log entries, and show traffic being generated with Kibana

This talk will conclude with a question and answer session.

Photo of Patrick Galbraith

Patrick Galbraith

Hewlett Packard

Patrick Galbraith is a principal engineer at HP as a member of the Advanced Technology Group. He is the author or two recent books: Developing Web Applications with Apache, MySQL, memcached, and Perl (Wiley), and Expert PHP and MySQL (Wiley). In his “spare time”, he also maintains DBD::mysql, Ansible Modules for HP Switches, and generally tinkers with new technologies. Patrick lives up in the sticks of New Hampshire with his wife and children, as well as his Kubota tractor.