Walkero

software engineer, Drupal follower, Docker ninja, JS explorer, PHP believer, exotic Hardware beta tester, Amiga enthusiast, truth seeker, parent & husband... at least for now...

You start a brand new project and you want to use Docker, but you don't know which images you should use? How to choose which image is the best one? Is it enough just to check the stars and the downloads on Docker Hub? If not, what else do you need to check?

Flexibility

Have in mind that you can use different images for your development environment and different ones for your production environment. Actually that's the recommended way to use Docker. Most of the times on development you need tools that do not need to exist on production, like the PHPUnit and Composer for your PHP projects, or the linters and Jest for your NodeJS projects. So you have to decide first the environment you need to support with that image.

For my local development environment I like to choose images that are flexible enough to change container's behaviour, with no need to edit configuration files in the container itself. For example, if I need to change the XDebug port or even totally disable it, I prefer to do it changing the docker-compose yaml file ENV variables. Also, I need to have root access in case I want to install a package and experiment with it.

For production of course, root access is prohibited and XDebug should not even exist. It is good to have the benefit to configure the containers, but this is not one of my decision points or a reason to not use a specific image. I prefer the containers to be more secure than flexible.

Security

Security on online applications, especially in SaaS systems, is really crucial and something you should take care from day one. For the containers I am going to use on production, I always check multiple factors before I choose the best image for the project, or decide to build my own.

First of all, I check if one of the official images, which are available on Docker Hub, can cover my needs. I tend to choose the lightest ones, with as less available software installed as possible, because more software means more possible insecure points. If this doesn't cover my needs I will try bigger images of the same organization until I find the one that works for me.

After that, I check how often this organization updates and applies fixes at their image. Is it often or once per year? Of course you wouldn't like to base you application on an old setup, rarely updated. After all, one of the benefits that you have using Docker is that you can pull the latest images whenever you want. You can even set it up to happen on every time you deploy. So why staying back with the OS or the tools you use?

You might think now that it is better to choose a light version of an official image and add what you need on top of that. And this might be the best solution, depending on the project and how many things you need to add. It is easy at the end to have a fat image with a lot of software as well.

Also, have in mind that you have to maintain your own image and create your a development process for this as well. At the end it becomes one more project you have to worry about. If you can automate the builds of your custom image, this is great. But when the newer version of the OS is released, are you sure that you are going to have the availability to update your own image? And what will happen if you have multiple images for multiple projects?

Non official images

Depending on the project you might need to use non official images. I use some of them especially for my development environment, and before I choose one of them to trust, I check the number of stars and downloads on Docker Hub, when was the last update and how often this is updated.

After that, I check the actual dockerfile on github wherever this is available, to see what exactly they do inside that image, and if I can trust it. Checking which image it is based on is also one of the necessary things to look for. If it is based on an official image this means that you can trust it more than any other. And while I am on github, I check the opened and the closed issues, to understand if the maintainer of the image actually maintains it or not, and what kind of problems people have.

These images are great for creating a Proof Of Concept or experiment on an idea, but they might not be the best choice for production. A check about the person or organization behind that image is necessary so to understand if they are trustful or not. I trust more an organization that has an expertise on Docker containerisation, providing solutions based on this technology and being available to support those images.

Lastly, using tools tools to check periodically the images for vulnarabilities is a very good idea. There are plenty of these tools out there. Lately I use Snyk, which I find really helpful.

Community

Docker has a big community right now and is used by so many developers every day. So, try to listen the community, read what developers write about the problems they solved and the solutions they followed. Discuss with them about the images they are using or even request their feedback on the ones you create. You are going to be surprised about how interesting things you will find from this process.

After all, developers adore Docker and love to discuss about.

#docker #containers #docker images #best practise
- 5 min read