Now, let's look at container management. This includes questions such as where to store the images that we will be creating, how to use these images, and what commands and GUI applications we can use. It also covers how we can easily monitor our running containers, automatically restart containers upon a failure, and how to roll the updates of our containers.
In module 1, we looked at the various locations to store the images you are creating. Remember that there are three major locations to store them:
You will want to consider where you want your images to be stored. If you are running containers that might contain data that you do not want anybody to be able to access, such as private code, you may want to run your own Docker registry to keep the data locked. If you are testing, then you may only want to use Docker Hub. If you are in an enterprise environment where uptime is necessary, then the second option of having Docker there for support would be immensely beneficial. Again, it all depends on your setup and needs. The best thing is that no matter what you choose at first, you can easily change and push your images to these locations without having to jump through a lot of extra hoops or other configurations.
The most important thing to remember about Docker images is the four Ws:
- Who: Who made the image?
- What: What is contained in the image?
- Why: Why are these things created?
- Where: Where are the items such as the Dockerfile or the other code for the image?
Remember that there are many commands that you can use to control your containers. With tools such as the Docker daemon, Docker Machine, Docker Compose, and Docker Swarm, there is almost nothing that can stop you from achieving the goal you want. Remember, however, that some of these tools are not available on all the platforms yet. I stress yet as I assume that Docker will eventually have their tools available for all the environments. Be sure to use the --help flag on all the commands to see the additional switches that might be available. I myself am always finding new switches to use every day on various commands.
There are also many GUI applications out there; they can be beneficial to your container's management needs. One that has been at the forefront of this since the beginning is Panamax. Panamax provides the ability to set up your environments in a GUI-based application for you to deploy, monitor, and manipulate your container environments. With the popularity of Docker growing each day, there will be many, many, many others that you can use to help set up and tune your environment.
We can also monitor our containers using methods similar to monitoring hosts: using Docker commands as well as GUIs that are built by others.
First, the Docker commands that you can use:
docker statsdocker portdocker logsdocker inspectdocker events
In the Host monitoring section, you can see that the same GUI applications can monitor both your Docker hosts and your containers. It is a double bonus as you don't need separate applications to monitor each service.
Another great thing you can do with your Docker images is you can set them to automatically restart upon a failure or a reboot of a Docker host. There is a flag that can be set at runtime: the --restart flag. There are three options you can set, one of which is set by default by not setting the flag.
These three options are:
no: The default by not using the flag.on-failure:max_retires: Sets the container to restart, but not indefinitely if there is a major problem. It will try to restart the container a number of times based on the value set formax_retires. After it has passed that value, it will not try to restart anymore.always: Will always restart the container. It could cause a looping issue if the container continues to just restart.
One of the benefits I have learned to love about Docker is the ability to control it the same way I control the code that I write. Just like Git, remember that your Docker images are version-controlled as well. This being said, you can do things such as rolling updates to them. There are two ways you can go about doing it. You can keep your images as a hosted code on something like GitHub. You can then update your code, build your image, and deploy your containers. If something goes wrong, you can simply use another version of that image to redeploy. There is also another way you can do this. You can get the new image up and running; when you are ready, stop the old container from running and then start up the new one. If you use items such as discovery services, it becomes even easier; you can roll your newly updated images into the discovery service while rolling out the old images. This makes for seamless upgrades and a great peace of mind for zero downtime.