Picking the right Docker Image
A docker image can be thought of as a blueprint for a docker container – every docker container is built using a docker image. Think of when you first started your computer for the first time – what were the first steps that you took? You probably installed some software that you were going to need and made some configurations. You can think of a docker image in a similar manner, in that it is essentially a compiled list of steps that docker will execute to build your container. These steps are defined in a Dockerfile – I will be discussing how to create these in the next part of this series.
What is DockerHub?
Docker has many users, many of which have made their Docker images available publically via a service called DockerHub. Most software is available in the form of a docker image that you can download and run in seconds, saving you the need to install it or define your own image. Images on DockerHub are versioned, meaning that you can choose the best fit for your technology stack. Many companies actually create official docker images for their software and publish them, giving you a degree of certainty that your container will work as expected. Because of all of these features provided with DockerHub, I suggest you always check whether an image for some software you are trying to install already exists.
DockerHub also gives you the ability to upload your own Docker images. This has several benefits – you can help the community by creating an image that might be useful to a larger group of users or you can upload your application container as a private image and then simply download it straight to your remote server using the Docker client.
Choosing Versions of Docker Images with Tags
Docker has a versioning system in place for container images – it is called “tags”. On DockerHub, you will see a list of tags for each image that you can use to choose what version of a given image you want to build. These usually relate to the version of the software running in the container, but can also include specific settings or configurations. For example, a lot of vendors release tags for their container images which are based on Alpine Linux, an extremely lightweight Linux distribution designed specifically for running in containers.
Just like on any operating system, Docker containers can have environment variables that can help define the behavior of components installed on the system. Images on DockerHub often have a list of environment variables with descriptions, which are set once the container is built, allowing the user to customize the software.
What makes a good Image?
- If a Docker image is an “official” image, it can be assumed that it meets a high quality standard
- The image only has the necessary components installed to execute the task it is meant to, without causing unnecessary overhead
- It allows the user to configure the comtainer using descriptive environment variables
- It provides a wide range of tags, allowing the user to choose older versions of the software that might work better with their techstack
- Make sure that the Docker Image is used by a lot of people, usually indicated by the number of downloads and stars that particular image has
- There are tools (such as Anchore) which can help you analyze an image and help detect any security flaws with your configurations
Pulling an Image
For this example, I am going to be using the official MySQL image. After executing the following code, I see that docker begins to download (or “pull”) the MySQL image:
docker pull mysql:8
You might be wondering why I added “:8” to the name of my image. As aforementioned, images can have tags, usually representing different versions of that image. With this syntax, I am saying that I want to pull the version of my image which correlates to the tag “8”, which in this case means that I will be getting an image for a container running MySQL version 8. By default, if you do not specify a tag, you will get the latest image that was uploaded (which can also be retrieved by setting “latest” as the tag). I usually specify a tag for my docker images, so that I can always be sure I know what version to reference when I run into issues – this is personal preference, of course.
Building and Running a Container
Once pulled, docker stores our image for future use. If we want to use our image for a container, we need to build the container and start it. Note: If you execute a command to try and run a container based on an image that does not exist locally, docker will download that image automatically from the hub.
docker run --name mysql-container -e MYSQL_ROOT_PASSWORD=password -d mysql:8
The previous command will build and run a container named “mysql-container”. Our MySQL image has several parameters that we can specify, which are specific to that particular image. You can usually see what parameters (or “environment variables”) are available for a given image on DockerHub. When inspecting the variables for the official MySQL image, we can see that the MYSQL_ROOT_PASSWORD variable is in fact mandatory. We want to repeatedly use the pattern -e MY_ENVIRONMENT_VARIABLE=myvalue for each variable that we want to define, when running our container via the command line.
Upon entering the previous command, we want to confirm that our new container has been built using the image we defined. Enter the following commands:
docker ps docker stop mysql-container
The first command will list all running containers. The second command will stop a container with the name that we pass as the argument, in this case “mysql-container”. Hopefully, the first command showed you that our container was in fact running! In the next tutorial, we will take a deeper dive into the different Docker commands that are available.