« Previous 1 2 3 4
Opportunities and risks: Containers for DevOps
Logistics
3. Build Base Images
The third mode of operation for handling containers is not a separate concept, but rather a variation on alternative two – even if it is more radical. The third alternative assumes that base images for containers do not come from the Internet; instead, their creation is the first step of the development process. When developers and administrators build containers together for production use, they are virtually starting from scratch and use a toolchain to produce a container for a specific purpose.
The concept seems unnecessarily complex at first. After all, it would be much more convenient to use an Ubuntu image from the Docker Hub as a basis. However, preparing the necessary environment in which containers can develop takes some time, and the process of creating containers also usually takes longer than just downloading a basic image. This approach is therefore less suitable for setups with just a few containers.
The advantages of this approach instead come to fruition in large environments with lots of containers. Because the developer and the operating team have complete control over the content of containers, they can generate it from the outset to include all the required components. If, for example, specific packages are required for operating an application, they are present and installed in the container immediately. Thus, an automated solution to install packages after the container launches would be unnecessary.
Anyone who can control their toolchain for the construction of containers also can discard the update problem elegantly. If you are tired of installing updates in running containers, the development or operations team can simply generate new containers that already contain all required updates. In the best case scenario, all this requires is the push of a button: Administrators simply trigger the reconstruction of all running containers and then replace the running containers with the new versions. In this scenario, administrators can also be certain that their container images won't contain any undesirable components.
Multistrap Aid
Those who opt for the third approach will find many tools on the web that help create Docker containers. The multistrap
tool, which is aimed at fans of Debian or Debian-based distributions, is a good example (Figure 5). A minimal Ubuntu image and configuration files for Docker containers is available online [2]. To create a Docker container for the current LTS release of Ubuntu, just call multistrap
along with a configuration file.
Multistrap starts customize.sh
at the end of the process, which allows any number of commands to be run in the filesystem of the future container before the image for the container is built. Anyone who doesn't want to delve too much into Bash magic can use one of the automation tools.
Conclusions
Containers are useful and a real asset in DevOps, as long as you observe a few rules. If containers are reproducible, they also can be managed efficiently. However, black boxes cause problems. Anyone using containers should keep this fact in mind.
Infos
- Ubuntu 16.04 kernel support: https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2FSupport.A14.04.x_Ubuntu_Kernel_Support
- Multistrap templates for Ubuntu 16.04: https://github.com/Blitznote/docker-ubuntu-debootstrap
« Previous 1 2 3 4