Docker Kata 006

It’s LinuxCon this week in Berlin, so let’s have a little bit of fun with this week’s Docker Kata 006. As much as I wanted to attend, things have been pleasantly hectic in New York with my day job @Contino and the exciting news that we’ve achieved APN Advanced Partner Status! Go us!

As a result, I’ve been watching from afar and enjoying the keynote, updates, and presentations given by all the talented speakers at LinuxCon Europe. But for now, save those links for later. Let’s take a look at one of the more interesting pieces of news coming out of the conference: InfraKit. What does it mean for you?

The Mission

As per usual, first some history. If you recall, we learned at this year’s DockerCon that Docker’s mission and roadmap centers around their goal to:

to build tools of mass innovation, starting with a programmable layer for the Internet that enables developers and IT operations teams to build and run distributed applications

To that end Docker Inc. has been building and contributing the software plumbing toolkits used to power their vision, back to the community as a set of loosely coupled tools. If that sounds familiar, it’s because it follows the basics of Unix Philosophy, ideals that originated with Ken Thompson’s early conjectures on how to design small-scale and capable operating systems with robust and straightforward service interfaces. Doug McIlroy, a very smart fellow who invented Unix pipes, elaborated on Ken’s original ideas and described the following characteristics:

— Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

— Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.

— Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.

— Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

Now there’s some debate across the internet on whether or not Solomon and company are accomplishing that goal, but in general I feel that (heated, sometimes!) discussion of standards and the evolution of the ecosystem serves to benefit the ultimate endpoints in the ecosystem: us, the users.

The Ecosystem

Now, in order to understand the present and relevance place of InfraKit, let’s consider the evolution of the last few years. We’ve seen a number of technologies roll out out of Docker and into the ecosystem: libcontainer, libnetwork, and runc created the foundations of the Docker container vision. This year at OSCON we were introduced into HyperKit, VPNKit, and DataKit; tool that gave us the internals we needed to run Docker natively on Mac and Windows.

Most recently, we’ve gotten to play with SwarmKit as you’ve seen in Docker Kata 002 and 005. This allowed us to orchestrate containers with built-in security, and gave us functionality seen in Kubernetes and their container Platform as a Service (Paas). SwarmKit plays a central role in the ability to create highly available applications that work across a raft protocol based, gossip network of managers and workers.

InfraKit!

Born out of Docker’s work on Cloud Service Providers (CSPs) such as Amazon Web Services (AWS) and the Microsoft Azure platform, Docker realized that they needed a standard and consistent way to manage infrastructure state across any number of physical, virtualized resources and cloud providers. This might sound a lot like BOSH to some of you, a comparison that occurred to me early on.

For anyone that’s ever worked on a sizable piece of infrastructure that spanned one or several CSPs, you’ve undoubtedly realized that each provider has specific and unique implementations on how they handle their cloud software and API interfaces. Once you’ve figured out how to abstract a cloud provider’s API into a general compute “utility,” there’s still further challenges ahead to detect, heal, and repair that infrastructure as time goes on.

There are many familiar and consistent motifs in dealing with these problems. The creation of low-level primitives to abstract resource management. Distributed monitoring and repair of resources. Declarative description of end state.

What do these motifs mean for us in practice? I’d argue the following:

Given sufficiently large system with many moving pieces, there is a requirement to create self-aware and self-healing infrastructure in order to support distributed systems at scale.

This is important because as the application begins to take center stage as an immutable, auditable, and traceable artifact that is deployed into a distributed system, the underlying technical architecture must be sound. InfraKit takes these requirements and breaks down our need for automation into API-like pluggable components that allow us to create:

• declarative infrastructure state
• active monitoring
• automatic reconciliation of that state.

These traits become challenging when your infrastructure needs to conform to a specific but changing state as specified by an operator. You may experience the requirement of state as a feature of security (ensuring ports are closed), a method of access control (which services have access to a specific API), or in ensuring idempotence (allowing for continual and blue-green deployment of resources.)

Let’s explore how InfraKit handles these questions.

InfraKit, Inside

Using components called plugins, InfraKit is at the core a set of collaborating processes. Implemented as servers running over HTTP and communicating through unix sockets, plugins define an interface that provide the behavior of three types of primitives: groups, instances and flavors.

Groups

In order to managing computing clusters, we use the “groups” primitive to abstract the setup of many machines into either exactly similar, or mostly similar configuration.

$ ./infrakit/group -h
Group server

Usage:
  ./infrakit/group [flags]
  ./infrakit/group [command]

Available Commands:
  version     print build version information

Flags:
      --listen string            listen address (unix or tcp) for the control endpoint (default "unix:///run/infrakit/plugins/group.sock")
      --log int                  Logging level. 0 is least verbose. Max is 5 (default 4)
      --poll-interval duration   Group polling interval (default 10s)

Use "./infrakit/group [command] --help" for more information about a command.

Instances

Instances are individual members of a group, which doesn’t necessarily have to be a physical server. Included in the toolkit as examples for Vagrant and Terraform.

$ ./infrakit/cli instance -h
Access instance plugin

Usage:
  ./infrakit/cli instance [command]

Available Commands:
  describe    describe the instances
  destroy     destroy the resource
  provision   provision the resource instance
  validate    validate input

Flags:
      --name string   Name of plugin

Global Flags:
      --dir string   Dir path for plugin discovery (default "/run/infrakit/plugins")
      --log int      Logging level. 0 is least verbose. Max is 5 (default 4)

Use "./infrakit/cli instance [command] --help" for more information about a command.

Flavors

Flavors remind me a bit of auto-scaling groups (ASGs), in that they create a description of a group of resources that is responsible for configuration and layer 7 level-type application health checks of an instance.

$ ./infrakit/cli flavor -h
Access flavor plugin

Usage:
  ./infrakit/cli flavor [command]

Available Commands:
  healthy     checks for health
  prepare     prepare the provision data
  validate    validate input

Flags:
      --name string   Name of plugin

Global Flags:
      --dir string   Dir path for plugin discovery (default "/run/infrakit/plugins")
      --log int      Logging level. 0 is least verbose. Max is 5 (default 4)

Use "./infrakit/cli flavor [command] --help" for more information about a command.

Monitoring and Reconciliation

Central to InfraKit is the goal is to help builders create more resilient systems. Group plugins will potentially allow us to manage cluster size and health, while the Instance plugin monitors the state of physical and virtual resources, with the flavor plugins checking application-specific configuration as related to the health of a resource.

We can observe an example infrastructure diagram from the announcement post:

We can see here three types of groups defined: stateless cattle, unique pet instances, and a group of InfraKit manager instances. Each group is monitored for prescribed state and is reconciled independently of the other groups.

This following diagram shows the current state of InfraKit in the ecosystem, though it’s highly likely that it will become part of Docker engine in the future.

What that means for adopters and cross-compatibility remains to be seen.

In particular, Docker is setting their sights on creating a cohesive framework for managing infrastructure resources from nodes to networks, load balancers and storage. Over the next few months we should begin seeing blog posts and deep dives into the technology in order to determine its impact on on-premises and Cloud infrastructure provisioning and management.

For the time being, I’ll be checking out the quick tutorial, and taking a look at swarm and Terraform plugins in order to get started with these technologies, and I recommend you try the same!

Hope you’ve enjoyed this dive into InfraKit, and hope to see lots of great blog work popping up exploring this tool.

Thanks for reading, and as ever — click the heart below if this helped!