Disclaimer
The following is a review of a presentation given at FLOSSUK Spring DevOps Conference. The event was held at Mary Ward House in London between 15th-17th March 2016. Although this is a description of a presentation with some dissection of what was discussed it is not a verbatim account and will contain personal impressions and interpretation. The content therefore does not reflect the quality of the original presentation and should be considered a review and personal opinion.
This is one of a series of reviews of the talks I saw at the event.
Introduction
Stephen Grier works at the University of Central London where he mostly focuses on what he terms as ‘web technologies’ and utilises Puppet for configuration management. At the start of the talk he posed the following question:
What does Configuration Management actually give us?
To Stephen is provides:
- Automation
- Reproducibility
- Reliability
- Infrastructure as code
- Convergence towards a desired state
Stephen Grier (with a fuzzy friend) during his presentation
Containerisation
We should look at containerisation. To Stephen the idea is gaining popularity now but it is not a new idea. In the 1970s we were introduced to a concept of it in the CHROOT daemon, spin forward a couple of decades and FreeBSD has the first container project with the introduction of Jails. This is probably the first proper usage of containers as we have come to see them today.
There is an important note, a container is not a VM. A VM has an entire system OS inside whereas a container shares the underlying kernel.
With containers you gain some features; you can have control groups and namespaces as tools for control, analysis and data collection of containers.
Since the field was only occupied by Jails for a decade and then has grown quickly there is a sense of a new land. As such there are few similarities to existing ideas and virtually no standards for containers. However due to popularity Docker has now emerged as a de facto, or proto-, standard.
Steven gave a list of what he sees as the reasons for using containers:
- Process isolation
- Security - processes can’t interfere with each other
- Resource limitation
- Portability
- Self-contained with all their own dependencies
- Fast to deploy
- It is a unit of deployment
- Non-repudiation
There is a sense that containers can allow you to forget about versions, dependencies as when the container is created it is properly baked. Then it is just a matter of controlling it. You can even add levels of security as to who can bake a container by using a notary framework. It is also wise to use just one process per container, containers do allow you to use more than one process (after a fashion) but this is an ill-advised behaviour.
Since the containers are baked and a known unit we suddenly have a measurement for our deployment systems, there is a ‘unit of deployment’ that is a container and its contents.
The nature of containers means that we do not usually need to config manage them, but then we will have to build the container images manually. This seems like a backwards step in automation. With Docker there are Docker-files to build the Docker images to make the manual process creation easier but it still feels retrogressive in regards to configuration management.
Management and Control
Then we come to the issue of management and control of an underlying system. Docker may give application, or more correctly process, containerisation but you may still need to manage a number of underlying kernels across many servers or VMs.
Stephen recommends the use of a system such as CareOS. It would seem that although the top level system can be containerised there is still a place for configuration management of the underlying systems. This is where Puppet has a place as management of Docker using Puppet is made easy with a gathr-docker module.
The advantage of containerisation is that you can define applications with code. This can be done with docker-swarm, gathr-docker and kubernetes. You can now move from just having the infrastructure as code to having the application layer as code.
To bake an image you need a recipe
Stephen used the above (Chef-aimed) pun to indicate that although containers are a step forward you still need the power of configuration management but it is in a much reduced manner. Configuration Management tools make a powerful way to declare the state of an image with values, resources and packages. So we should run config. management tools to make local file baking automated and share this across our systems.
Convergence is less important, declaring desired state is more important.
So Config. Management is still relevant, but in a greatly reduced capacity.
[Don't forget that you can join in this conversation by using the comments form or by tweeting at @shadowcat_mdk]
