An overview of the

  • Dockerfiles are choreographed files designed to automate building images (just like Jenkins 2.0’s Jenkinsfiles were choreographed for Jenkins jobs and stages), We can use the Docker build command to automatically build a custom Docker image from the steps described in the Dockerfile, which is much more efficient than we go to the command line to build a step-by-step command.

  • On the other hand, because Dockerfile provides a uniform configuration syntax, so through such a configuration file, we can be distributed on a variety of different platforms, when needed through Dockerfile build can get the required image.

  • The last advantage that must be mentioned is that Dockerfile is used with the image, so that Docker image construction can make full use of the “image cache function”, so it also improves a lot!

However, writing Dockerfile is also like writing Code. A well-designed Clean Code Dockerfile can not only improve readability but also greatly improve the efficiency of using Docker

So the following is a combination of practice to tell a few Dockerfile practice experience!

Note: This article was published on My public account CodeSheep. You can subscribe by holding down or scanning the heart below ↓ ↓ ↓



The choice of basic mirror image is exquisite

In my article “Building a Personal Private Cloud with K8S Stack (Serial: Basic Image Creation and Experimentation),” we took a Linux base image as a base package and packaged it with the functionality I needed to build my own image.

There are considerations in choosing the base image:

  • One is to try to choose the official mirror base mirror;
  • The second is to choose lightweight mirror as the bottom package

For a typical Linux base image, the size relationship is as follows:

Ubuntu > CentOS > Debian
Copy the code

Therefore, it is recommended to use the lightest Debian image rather than Ubuntu, and it is also a complete Release that can be used with confidence



It’s good to use tags more often

  • When building an image, tag it with an easy-to-read image label to help you understand the function of the image. For example:
Docker build - t = "centos: wordpress".Copy the code

For example, the centos image above is used for wordpress, so it has integrated wordpress functions, which is very clear

  • Also, we should specify the Tag in the Dockerfile FROM directive, so that the Docker daemon does not have to guess, e.g
FROM debian:codesheep
Copy the code


Take advantage of the image cache

What is mirror cache?

The resulting image from Dockerfile is layered on top of the underlying image, so new image layers are created in the process. The Docker Daemon caches a series of intermediate images during the image building process.

When docker builds the image, it will execute the instructions in Dockerfile in sequence and compare all the sub-images of the current instruction and its base image at the same time. If a sub-image is found to be generated by the same instruction, the cache will be hit, and the sub-image can be directly used to avoid re-generation.

In order to use cache effectively, it is necessary to ensure the continuity and consistency of instructions in Dockerfile, try to put the part of the same instruction in front, and put the different instruction in the back

** If I want to build two different dockerfiles based on the basic CentOS image, the start of the two dockerfiles can be the same:

FROM centos:latest

# Install two common tools below
RUN yum install -y net-tools.x86_64

RUN yum install lrzsz

######## above is the same part of the two Dockerfile files ######

######## Below are the different parts of the two Dockerfile files ######.Copy the code


Correct use of ADD and COPY instructions

Although both can ADD files to the image, COPY is still recommended as the first choice in general usage. The reason is that ADD is not as pure as COPY. ADD will ADD some additional functions, for example, when adding a compressed package, it will not only COPY but also automatically decompress. Sometimes we don’t need that extra functionality.

ADD codesheep.tar.gz /path
Copy the code

In addition, when you need to add multiple files to an image, instead of adding them all at once, you can add them one at a time as needed, as this helps to take advantage of the image cache



## Use docker Volume whenever possible

Although it is recommended to use COPY to ADD multiple files to the image, in practice it is better to use docker -v to mount large files instead of relying on ADD or COPY

Finally, it must be said that there is a degree of “as far as possible” here, moderate grasp of the line.



Understanding and using CMD and ENTRYPOINT directives

When Dockerfile creates an image, it combines CMD and ENTRYPOINT directives as the default command for container runtime: CMD + ENTRYPOINT. The default command composition is as follows:

  • The part of the ENTRYPOINT instruction is “generally” fixed and not modified while the container is running
  • The commands in the CMD section can also be changed when running the container.docker runThe arguments provided in the command override the contents of the CMD directive.

Here’s an example:

FROM debian:latest

MAINTAINER [email protected]

ENTRYPOINT [ "ls"."-l"]
CMD ["-a"]
Copy the code

If you run the container with the default command, you can find that the ls -a -l command is executed:

If -t is added to docker run

docker run -it --rm --name test debian:codesheep -t
Copy the code

The CMD argument in the Dockerfile is overwritten by ls -l -t:

Therefore, the recommended usage is:

  • Set fixed default commands and parameters using ENTRYPOINT directives in exec format

  • Use CMD directives to set variable parameters



Port mapping in Dockerfiles is not recommended

Dockerfile can map container ports to host ports using the EXPOSE directive, but this results in mirroring only one container on a host!

Therefore, you should specify the port mapping in the docker run command with the -p argument instead of putting the work in the Dockerfile:

# Try to avoid this approach to EXPOSE 8080:8899 # EXPOSE ports onlyCopy the code


Use Dockerfile to share the image

It is recommended to share an image by sharing a Dockerfile, which has many advantages:

  • Users of images built from Dockerfile can clearly see the build process

  • Just as Jenkinsfiles can be added to version control to track CHANGES in a CI system and the rollback of steps, Dockerfile can also be added to the repository as a choreography file for version control, which can also be traced back

  • Images built with Dockerfile are deterministic and have no metaphysical elements



Afterword.

  • The author’s more original articles are here, welcome to watch

If you are interested, take some time to read some of the author’s articles on containerization and microservitization:

  • Nginx server configuration from a detailed configuration list
  • Use K8S technology stack to create personal private cloud serial articles
  • Docker container visual monitoring center was built
  • Use ELK to build Docker containerized application log center
  • Use TICK to build Docker container visual monitoring center
  • RPC framework practice: Apache Thrift
  • RPC framework practice: Google gRPC
  • Establishment of microservice call chain tracking center
  • Docker containers communicate across hosts
  • Preliminary study on Docker Swarm cluster

The author’s relevant SpringBt practice article is here:

  • The SpringBoot application is deployed in an external Tomcat container
  • ElasticSearch in SpringBt practice
  • A preliminary study on Kotlin+SpringBoot joint programming
  • Spring Boot Logging framework practices
  • SpringBoot elegant coding: Lombok plus