Julian C. Dunn, product manager at Chef, presented at Config Management Camp about how configuration management needs to adapt to a containerized world, while Gareth Rushgrove, software engineer at Puppet Labs, talked about the future of configuration management, and how the emerging and future technologies will still need to have configuration management into account.

Configuration Management in a Containerized World

Julian C. Dunn affirmed that containers are only going to be used more and more, and configuration management needs to evolve and adapt quite dramatically:

Docker is optimized for developer experience. Containers could be used before but needed a lot of expertise. Unless a tool is adopted by devs and ops it will not be successful.

Containers are here to stay, you better get used to them.

Dunn listed the top three reasons for Docker success:

• Instant productivity, it allows a quick start.
• Developing is like shipping, developers do not like anything more than shipping.
• Portable artifact format, it can be run across any host.

There is a lot of controversy about what is going to be the format. CoreOS is is trying to grab some share of the container ecosystem with Rocket and the new App Container specification.

About building and deployment of containers, Dunn showed how Chef can build Docker containers, using the knife container plugin. Containers still need to go through testing, deployment, i.e. in Kubernetes, and run. It is also important to consider gathering metrics, managing inventory, resource allocation, service discovery and a controlled mutability.

According to Dunn, the next step for containers is fleet management, crossing the machine boundary, something that configuration management has not done yet.

The Future of Configuration Management (And How to Stop It)

Gareth Rushgrove defines configuration management as a discipline. Any input to the infrastructure is configuration, and configuration management is about managing those inputs over time, and scale.

The configuration management process became its own technical discipline sometime in the late 1960s when the Department of Defense developed a series of military standards, the "Military Handbook: Configuration Management Guidance", covering identification, control, status accounting, verification and audit, something still valid today.

Configuration management verifies that a system is identified and documented in sufficient detail and that it performs as intended. Configuration management is not files, services, packages, users and groups, it just happens to do that too.

The breath of infrastructure we manage is only increasing.

In the near future configuration management will handle:

• Infrastructure as a Service (IaaS) resources, such as those provided by Amazon Web Services, Google Compute Engine,...
• Software defined networks.
• Network devices with APIs.
• Cloud networks.
• Overlay networks, such as SocketPlane and Weave.

In the medium term it still has its place in:

• Distributed configuration systems, as replacement for configuration files, with technologies such as etcd, Consul and Apache ZooKeeper. These systems still need to manage the configuration going in.
• Containers as a new package format. Managing both images and running containers, tied for provenance. Containers as virtual machines, running more for a lot less money, but also containers as processes, the more pure approach. Docker containers as well as new containers following the App Container specification, i.e. Rocket.
• New operating systems, addressing host level complexity, such as Project Atomic, CoreOS and Snappy Ubuntu Core, using read only filesystems and dealing with atomic changes.
• New cloud infrastructure, with Platform as a Service providers, such as Cloud Foundry, OpenShift and Heroku, as they still require management of build packs (JVM, Ruby,...), application composition, security groups, environment variables,...

In the longer term, configuration management needs to be applied to:

• Infrastructure-less execution environments, such as Azure WebJobs and Amazon Lambda.
• Autonomous systems, that still need configuration. For example, autoscaling needs group size, scaling policies or instance details.
• Distributed container environments, such as Kubernetes and Apache Mesos, which need to configure pods, services, replication controllers,...
• Unikernels

The slides from his talk are already available in SpeakerDeck.