In my previous entry I took a quick look at some of the Docker orchestration tools. I spent a bit of time poking at docker-compose and mentioned Swarm. In this entry I’m going to poke a little at Swarm; after all, it now comes as part of the platform and is a key foundation of Docker Enterprise Edition. Docker Swarm tries to take some of the concepts of a single host model and convert it into a cluster.
In earlier posts I looked at what a Docker image looks like and a dig into how it looks at runtime. In this entry I’m going to look at ways of running containers beyond a simple docker run command. docker-compose This is an additional program to be installed, but it’s very common in use. Basically, it takes a YAML configuration file. This can describe networks, dependencies, scaling factors, volumes etc etc.
In the previous entry we looked at how a Docker container image is built. In this entry we’re going to look a little bit about how a container runs. Let’s take another look at the container we built last time, running apache: % cat Dockerfile FROM centos RUN yum -y update RUN yum -y install httpd CMD ["/usr/sbin/httpd","-DFOREGROUND"] % docker build -t web-server . % docker run --rm -d -p 80:80 -v $PWD/web_base:/var/www/html \ -v /tmp/weblogs:/var/log/httpd web-server 63250d9d48bb784ac59b39d5c0254337384ee67026f27b144e2717ae0fe3b57b % docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 63250d9d48bb web-server "/usr/sbin/httpd -.
Container technology, specifically Docker, is becoming an important part of any enterprise. Even if you don’t have development teams targeting Docker you may have a vendor wanting to deliver their software in container form. I’m not so happy with that, but we’re going to have to live with it. In order to properly control the risk around this I feel it helps to have a feeling for the basics of what a Docker container is, and since I come from a technical background I like to look at it from a technology driven perspective.