A modern container architecture – like one based on Docker – has various advantages:
- Fast to utilise
- Fully documenting
- Easy to reuse containers
- Easy to update containers
- Improved security
This post first explains what a container is and then delves further into their advantages.
- A container is essentially a complete machine only containing the parts necessary for a particular piece of software to run. A container can be based on another container – called a base container – to inherit its capabilities and be adapted further.
- A container exists on a host machine. The host machine runs the container application which can run one or more containers.
- A container system involves many containers working together.
- A container hub is a repository of already configured containers each for a particular piece of software. (e.g. Docker Hub)
Docker means agile (faster setup). Once the container application is installed a system of containers can be setup with a single command. This involves retrieving a base system and building each specific container. Any system can be quickly rebuilt. For developers, multiple systems can run on a single machine for easy testing.
It is also possible to retrieve already configured containers with a single command. Servers such as MySQL, Solr, WordPress can be retrieved and running within seconds.
A container is specified in a single file. All the parts that are needed are installed through that. This text-file can be added to a normal version control system.
This file will hold the full specification for setting up a particular piece of software and thus can be used to rebuild the software even outside of a container architecture.
A further text-file can be used to setup the full container system. Again, compatible with version control.
Each container runs as a separate entity. This means it is simple to reuse each part. It also means a container system can have one of more of it’s containers replaced without affecting the others. Each container can be built and tested separately.
Updates to containers can happen without downtime if containers are simply switched from an old to a new one. New container versions (or base systems) can also be retrieved from a hub and individual containers rebuilt using the newer versions.
It is possible and desirable to have a private hub holding our own containers. This enables reuse and standard practice across servers and projects and speeds up future development work.
It can also hold a base system which we can use to build all our systems.
Root privileges obtained through compromised software can only affect the container they occur in, other containers and the host system itself run separately and are not affected.
Separation of work files
Containers can have virtual folders which connect the host file system with the containers. Configuration files, database storage, logs, etc can be accessed from the host for example for easy backup. Virtual folders can use folders mounted on the host and therefore use different drive storage.
As all the softwares necessary to run a server are controlled under a single container application it should be clearer what needs to be running. The container application also monitors its containers and can restart those that fail.
Reboot scripts are also simplified as essentially this involves starting the one container application.