Your code is ready, you have the green light on your tests, and you can run your application in your local environment. Your application rocks. Now you must put your service into production, and you have to containerize it. Here comes the dreaded moment… you start to read about dockerfile, docker-compose, docker repository… too many concepts. After you acquaint yourself with these concepts, you decide to create your dockerfile. Alas, the architecture of your application did not have containers in mind, and you must refactor the application in order to generate the container. If this situation looks familiar, in this article, we would like to give you some tips for surviving the containerization process.
Paramaters are your friend
Consider all the assumptions that you have made when coding and how those may change in the real deployment, so if you think that the path to your config file is always /etc/your_awsome_app.config, then including a parameter to change the config path is a great idea. Also, overwriting parameters using arguments/flags gives you more flexibility in the deployment stage. Take a look at libraries such as Cobra in Golang, Commander in Node, or Click in Python.
Dependencies’ hell
The container is a clean environment that starts with a fresh installation of the base image. If your application requires other packages, tools, or libraries to work, you will need to install those in the Dockerfile. To improve reusability, avoid using dynamic references such as main, master, or latest and always use fixed versions (v1.0, 2.34.10-45, etc).
Logs are important
When running an application as a service on the OS, a common practice is to store your logs in a folder such as/var/log/your_awsome_app. However, when using containers, you should redirect the logs to the standard output. Your container runtime will make those available for you. If you use a container orchestrator like Kubernetes, you can access them without worrying about the container location.
Service communication
If your service needs to communicate with another service, you should put this address in a flag or argument of your container. Maybe in your development environment, using localhost:3306 to connect with MySQL works, but you don’t know the final address of your database. A flag or argument gives you the required flexibility and is a more scalable solution.
Don’t run as root
In most cases, your service won’t require any special permissions. You should make sure that your service works with a standard user. Always change the user from root to a non-privileged user in your Dockerfile when you no longer need root privileges. That way, your container is run in a more secure way.
We welcome you to use the Napptive Playground so you can experience how to deploy cloud-native apps within seconds. It’s free to use, you simply need to log in with your existing GitHub account to get started!
