Mistakes to Avoid in Docker Images with Reason and Solution


Docker is a leader in platform as a service (PaaS) products, which makes easier to create, deploy, and run applications by using containers, utilizing the features of encapsulation, isolation, resource utilization, portability, reliability etc. Docker image, is the basic building block that need to get crafted considering various aspects like cyber security, data persistence, performance, memory utilization etc. Here we briefs the common mistakes to avoid while creating docker images.

Best Practices

  1. Don’t create an image which stores data inside container
    • Reason: Loss of data while container stops or while image version upgrade.
    • Solution: Declare volume externally.
  2.  Don’t Run too many services in the same container
    • Reason: Every service increases your vulnerability in container security. In some case it affects scaling (application and DB in same container). Difficult to monitor, Inefficient resource utilization.
    • Solution: Follow the process of one process per container. It’s better to let a baseline image (linux) handle those services (cron, syslog) for you.
  3. Don’t use multiple RUN, ADD, V0LUMES in Docker image
    • Reason: Such kind of usage increase the image size, which eventually results in time delay for Docker build.
    • Solution: Group RUN/COPY shell sequences together.
  4. Don’t RUN utility package update and install in separate lines/cache layer
    • Reason: Update will get cached by the build and won’t actually run every time the installation runs.
    • Solution: RUN package update and install in the same line.
  5. Don’t use ADD instead of COPY
    • Reason: ADD will download/copy and extract the object.
    • Solution: Use COPY only, unless need extraction in same step.
  6. Don’t use latest tag for base images as maintainer of Docker file
    • Reason: This will update the base image to latest change and can fail the container to give expected result, because of changes in image unknown to maintainer.
    • Solution: Use version number as tag.
  7. Don’t interact with declared volume during build process
    • Reason: Volume in your image are added only during run time.
    • Solution: Volume interactions can be done only in containers.
  8. Don’t use single layered image
    • Reason: It is difficult to recreate, manage and distribute.
    • Solution: First create base layer image for the OS to use, then layer of username definition, then run time installation and configuration.
  9. Don’t store credentials in image
    • Reason: Increase vulnerability for container.         
    • Solution: Use confidential parameters as Environment variables integrated with Vault.
  10. Don’t run processes as root user
    • Reason: Cracking containers cause the whole host vulnerable to attacks.
    • Solution: Image should use USER instruction to create non-root user.
  11. Don’t rely on IP address
    • Reason: Containers have internal ip address which will change on restart.
    • Solution: In order to communicate to another container use environment variables to pass host name and port number.
  12. Don’t let containers run non-monitored
    • Reason: Will end up infinite possible reasons when container fails.
    • Solution: Design container images such that it supports configuring and connecting with monitoring tools.
  13. Don’t let the container write logs to local files
    • Reason: Chance to get lost the logs is more.
    • Solution:Integrate with a centralized logging solution and redirect logging to the STDOUT.


While writing Dockerfile, keep main objective to create image layers which comprises only the inevitable packages and sub-processes. The features like zero vulnerability, light weight, efficient resource utilization, data persistence will help the images to stand out in the world of docker.  AppZ Stacks, docker images by CloudControl, are built using the best practices and are available for multiple languages and platforms. They are ready to use to layer business applications on top of them.

About The Author

Iwin Mathew

With more than 5 years of experience in supporting Test environments, automating and optimizing  deployments in both Development and Non-Prod Environments , leveraging configuration management, CI/CD, and DevOps processes. With profound knowledge and experience in Orchestartion of Applications in Multi-Hybrid-Cloud Platforms.