Docker has been a recent but very important addition to a SysAdmins toolbox.
Docker describes itself as an open platform for building, shipping, and running distributed applications. This means that developers can bundle their code and pass it to their operations team. From here, they can deploy safe in the knowledge that it will be done so in a way that introduces consistency with the environment in which the code is running.
When this process is followed, it should make the age-old developers versus operations argument of "it worked on my local development server"—a thing of the past. Since before its "production ready" 1.0 release back in June 2014, there had been over 10,000 Dockerized applications available. By the end of 2014, that number had risen to over 71,000. You can see how Docker grew in 2014 by looking at the infographic that was published by Docker in early 2015, which can be found at https://blog.docker.com/2015/01/docker-project-2014-a-whirlwind-year-in-review/.
While the debate is still raging about how production ready the technology is, Docker has gained an impressive list of technology partners, including RedHat, Canonical, HP, and even Microsoft.
Companies such as Google, Spotify, Soundcloud, and CenturyLink, have all open sourced tools that support Docker in some way, shape, or form and there has also been numerous independent developers who have released apps that provide additional functionality to the core Docker product set. Also, all the companies have sprung up around the Docker ecosystem.
This module assumes that you have had some level of experience building, running, and managing Docker containers, and that you would now like to start to metrics from your running applications to further tune them, or that you would like to know when a problem occurs with a container so that you can debug any ongoing issues.
If you have never used Docker before, you may want to try one of the excellent modules that serve and introduce you to all the things that Docker provides, modules such as Learning Docker, Packt Publishing, or Docker's own introduction to containers, which can be found at their documentation pages, as follows:
Now, we have a brought ourselves up to speed with what Docker is; the rest of this chapter will cover the following topics:
Before we start discussing the various ways in which you can monitor your containers, we should get an understanding of what a SysAdmins world looks like these days and also where containers fit into it.
A typical SysAdmin will probably be looking after an estate of servers that are hosted in either an on-site or third-party data center, some may even manage instances hosted in a public cloud such as Amazon Web Services or Microsoft Azure, and some SysAdmins may juggle all their server estates across multiple hosting environments.
Each of these different environments has its own way of doing things, as well as performing best practices. Back in February 2012, Randy Bias gave a talk at Cloudscaling that discussed architectures for open and scalable clouds. Towards the end of the slide deck, Randy introduced the concept of Pets versus Cattle (which he attributes to Bill Baker, who was then an engineer at Microsoft).
You can view the original slide deck at http://www.slideshare.net/randybias/architectures-for-open-and-scalable-clouds.
Pets versus Cattle is now widely accepted as a good analogy to describe modern hosting practices.
Pets are akin to traditional physical servers or virtual machines, as follows:
myserver.domain.com
.Cattle, on the other hand, represent more modern cloud computing instances, as follows:
ip123123123123.eu.public-cloud.com
.Next up is a term that is a good way of describing how containers fit into the Pets versus Cattle world; in a blog post title "Cloud Computing: Pets, Cattle and ... Chickens?" on ActiveState, Bernard Golden describes containers as Chickens:
The original blog post can be found at http://www.activestate.com/blog/2015/02/cloud-computing-pets-cattle-and-chickens.
The final term is not animal-related and it describes a type of server that you defiantly don't want to have in your server estate, a Snowflake. This term was penned by Martin Fowler in a blog post titled "SnowflakeServer". Snowflakes is a term applied to "legacy" or "inherited" servers:
Martin's post can be found at http://martinfowler.com/bliki/SnowflakeServer.html.
Depending on your requirements and the application you want to deploy, your containers can be launched onto either pet or cattle style servers. You can also create a clutch of chickens and have your containers run micro-services.
Also, in theory, you can replace your feared snowflake servers with a container-based application that meets all the end-of-life software requirements while remaining deployable on a modern supportable platform.
Each of the different styles of server has different monitoring requirements, in the final chapter we will look at Pets, Cattle, Chickens, and Snowflakes again and discuss the tools we have covered in the coming chapters. We will also cover best practices you should take into consideration when planning your monitoring.
We assume that you have Docker Compose 1.3.3 or later installed; the docker-compose.yml
files mentioned in this module have been written with this version in mind.
Finally, the majority of the images we will be deploying during this module will be sourced from the Docker Hub (https://hub.docker.com/), which not only houses a public registry containing over 40,000 public images but also 100 official images. The following screenshot shows the official repositories listing on the Docker Hub website:
You can also sign up and use the Docker Hub to host your own public and private images.