Dockerizing an application is the process of converting an application to run within a Docker container. While dockerizing most applications is straightforward, there are a few problems that need to check each time.
What Is a Dockerizing
Dockerizing is the process of packing, deploying, and running applications using Docker containers. Docker is an open-source tool that ships your application with all the necessary functionalities as one package. You can use Docker to pack your application with everything you need to run the application (such as libraries) and ship it as one package – a container. Containers are created from images that specify their precise contents.
There are two parts of Docker:
- The Docker Engine – a portable packaging tool
- The Docker Hub – cloud service for sharing applications
Why You Might Want to Employ Dockerizing
Easy to use
Docker simplified the way we deploy applications. You do not distribute the software as source code – you send the binary image of a part of your disk. It is easy to use for developers, system admins, architects, and others. It runs the application unmodified on any cloud. Docker also lets you use the Docker Hub, which contains tens of thousands of public images ready to use.
Docker containers are just sand boxed environments that run on the kernel. You can create and run the containers in seconds.
Able to create a reproducible environment
Docker creates a consistent work environment that is necessary for recreating applications and their functionalities. Wrapping everything into containers means that the application you build runs on other devices without friction.
How to Implement the Dockerizing
Once we install Docker, be sure to test and ensure that Docker is properly on your laptop, open your command line terminal. Some good commands to run are
docker --version to see what version of Docker is installed as well as
docker ps to see if there are any existing running containers.
2. Choose a base Image
You can start from a Base OS and install everything by yourself. But there is no need to create a brand new image. Just pick one of the public images with all the functions and databases that you need.
Choose an image based on the used technology, such as:
3. Install the necessary packages
Install only what you really need. Think about image size, security, or maintainability. If necessary, create a different Dockerfile for build/debugging/development time. This is not only about image size, think about security, maintainability.
4. Add your custom files
Check the attributes of the files you are adding. If you need execution permission, there is no need to add a new layer on your image (RUN chmod +x …). Just fix the original attributes on your code repository.
5. Define which user will (or can) run your container
You only need to run your container with a specific (fixed ID) user if your application needs access to the user or group tables (/etc/passwd or /etc/group).
6. Define the exposed ports
This is usually a very trivial process, please, just don’t create the need for your container to run as root because you want it to expose a privileged low port (80). Just expose a non-privileged port (e.g. 8080) and map it during the container execution.
7. Define the entrypoint
Usually just run your executable file, right away. A better way is to create a “docker-entrypoint.sh” script where you can hook things like configuration using environment variables (more about this below):
8. Define a Configuration method
Every application requires some kind of parametrization. There are basically two paths you can follow:
Use an application-specific configuration file: you will need to document the format, fields, location, and so on (not good if you have a complex environment, with applications spanning different technologies).
Use (operating system) Environment variables: Simple and efficient.
9. Externalize your data
The golden rule is: do not save any persistent data inside the container.
The container file system is to intended to be temporary, ephemeral. So any user-generated content, data files, process output should save either on a mounted volume or on a bind mount (that is, on a folder on the Base OS linked inside the container).
Common Pitfalls of the Dockerizing
- Inexperienced users create their own base images. They risk stability.
- Docker is used during the production phase without detailed knowledge of how to use it. It is recommended to use Docker during the development phase.
- Docker is used only during the production phase and not during the testing phase.
There is certainly work that must be done at the front end of the process that can be intimidating. As far as the actual dockerization, it was surprisingly straightforward. Without building and running the app, all it took was creating a Dockerfile with seven commands.