Docker Development Best Practices and its use in CI/CD
Docker is very powerful tool for developers and administrators for productionizing today's complex applications involving large number of micro services. Continuous development, testing and deployment plays major role in running complex enterprise applications. Today, we will explore the best practices developers and administrators should following while using Docker for running their applications. Here we are discussing "What are Docker development best practices?" and explore some of the important best practices.
Before you start building your software project, ensure that you understand your project's setup and plan in such a way that it makes whole project lifecycle smooth. We have decided to write this article to help you grasping the best practices while working with the Docker and its related tools. We have written this article specifically about "development best practices of Docker". The goal of this article is to help you in making the process of Docker development easier and more straightforward. Read our complete guide for tips and tricks on DevOps/Docker to help you in getting up and running quickly.
What are Docker development best practices? And are we doing it right these days? These are questions we're regularly asked on Twitter, question/answer sites and technology groups; we have studied these and now presenting the best practices followed by IT gurus around the world. As per our project experience and community experience we have come up with the following list of Docker best practices to help other developers in the Docker community.
Creative developers have always shown their ingenuity in building application with Docker. Some development patterns are really seen to be helpful. Some of the most effective app. building patterns are described below.
1. The method to keep images small
Small image size makes a container or service quick to pick up the network and to load into memory. There are some guiding principles that keep the image size small:
A) One need to find an appropriate base image. It means, for a JDK the image base will be on the official openjdk image as a part of the Dockerfile rather than a generic Ubuntu images.
B) A multistage builds can keep the image size small, For example, to build Java application one can use maven image and reset it to the tomcat image followed by copying the Java artifacts to a perfect location to deploy the app, all in the same Dockerfile. This final image doesn’t include all of the libraries and dependencies, but only the artifacts and the environment these are necessary to run them.
C) In case of a Docker version without a multistage builds the number of image- layers should be reduced by reducing the number of separate RUN commands in the Dockerfile.
D) Multiple images with common components need to create their own base image, with the shared components embedding the unique images on that, Docker just loads the common layers. This offers the derivative images to use memory fast and adeptly on the Docker host.
E) When production image is used as the base image for the debug image, it becomes thin.
F) During the image- creation pathways always tag them with useful tags able to codify version information and offer desired destination, stability, or other information useful in deploying the application in varied environments.
2. A pragmatic approach to store application data
One needs to avoid storing application data in the container’s writable layer using storage drivers. This increases the size of your container and makes it less efficient so far an I/O perspective is concerned than using volumes or bind mounts.
It is wise to store data using volumes.
In case if you want to mount your source directory or a binary that you just built into your container, the use of bind mount during the development is the best option. As for production, It is necessary to use a volume mounting it into the same location where it was mounted a bind mount during development.
It is mandatory to use secrets to store sensitive application data used by services and as well as to use configs for non-sensitive data in course of a production. Single-replica services are more conducive than stand-alone containers.
3. Optimum Use of CI/CD for testing and deployment
Docker Hub or another CI/CD pipeline can be used to source control or to create a pull request to automatically build and tag a Docker image and test it.
4. Always use the latest version of Docker
While working with the Docker projects you should start with the latest version of the Docker and use the latest images for your project. With this you will be in sync with the Docker community and will be able to use the latest features of Docker.
5. Always create a separate environment for development (development) and testing (testing).
If you are using Docker for development then you should create separate environments for development, testing, integration testing and the production deployment. You may call these environments at "virtual environment" or "work environment", "test environments" and "Production environments". The difference is that virtual environments have a purpose, there is a single purpose (a developer) while the same test environment has a single purpose, also defined the way it is run.
There are little downside of such arrangement where we have many such environments for each purposes. The downside here is that you will have to manage your own environment. If your test application depends on other test components you may have to run a docker stop test command to stop all their dependencies without affecting the rest of your code. Again, this is where we run into trouble in the new Docker environment; your code is written to run as a single unit, so if some part is broken and you want to fix it, you still have to keep separate environments for development and testing (remember that they are running concurrently). This can be a major pain point, so it's best not to depend on test components. If in doubt, use a continuous integration tool that ships with the container (such as Docker Hub) and create a local development environment.
Conclusion
There is a requirement for development, testing, and security teams to sign images before they are deployed into production.
A careful attitude in maintaining the environments of development and production as well makes the process compatible for the developers.
What's next?
We hope you enjoy learning this content on Docker best practices and we've tried to add most followed best practices of Docker, which makes this document very intuitive. So you understand the best practices of using Docker in development, testing and production environment. Visit our following sections of Docker tutorial: