1. Catalogue
- 1. Catalogue
- 2. How to make a mirror
- 3. Environmental preparation
- 4. Ways of docker commit command
- 5. docker builder
2. How to make a mirror
Docker builds mirrors in two ways, using the docker commit command and using the Dockerfile.
3. Environmental preparation
I installed CentOS 7.0, the smallest installed version, on a virtual machine with Windows 10 operating system. After installation, I need to update the server kernel and patches all once.
After installing Docker on CentOS, you can see that the Docker version is 20.10.17 and is currently the latest version in the Docekr community version.
- Windows 10 Home 64bit
- VMware Workstation Pro 16
- CentOS 7.0
- docker 20.10.17
I use a self-written SpringBoot Web project that already has a running boot-app as the source image to make another image named clone-boot.
4. Ways of docker commit command
docker commit makes mirrors by running container scripts, packaging mirrors, and importing mirrors.
4.1. Command Details
There are four parameters for docker commit, which, in order, mean specifying the author, applying the Dockerfile directive to the created image, submitting descriptive information, and pausing the container during submission.
Flag shorthand -h has been deprecated, please use --help Usage: docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]] Create a new image from a container's changes Options: -a, --author string Author (e.g., "John Hannibal Smith <hannibal@a-team.com>") -c, --change list Apply Dockerfile instruction to the created image -m, --message string Commit message -p, --pause Pause container during commit (default true)
- Execute the command tool and see a new mirror identity returned.
docker commit boot-app clone-boot
- Create containers using built mirrors
docker run -di --name clone-boot -p 19091:19090 clone-boot
4.2. Running Containers
The command used is docker exec. The specific usage is shown in the table below, and all the commands it contains are listed here.
docker exec [OPTIONS] CONTAINER COMMAND [ARG...]
| Name | describe | Remarks |
|---|---|---|
| -d | Run as a daemon | |
| -e | Setting environment variables | |
| -i | Keep STDIN open even if there is no connection | |
| -t | TTY mode | |
| -u | user | |
| -w | Working directory in container |
- Enter Container
docker exec -it clone-boot /bin/bash
- View JDk version
java -version
I updated the yum command inside the container and finally installed the vim text, but I could actually do anything I wanted to do.
4.3. Packaging
Pack the running container with docker save [OPTIONS] IMAGE [IMAGE...] and output it to a disk path with -o.
docker save -o /data/clone-boot.tar clone-boot
4.4. Import
With Mirror Reporting, we import docker load [OPTIONS], which has only two parameters
- -i, --input string read from tar file
- -q, --quiet completes the import silently
docker load -i /data/clone-boot.tar
5. docker builder
Dockerfile uses basic DSL-based instructions to build a Docker image, and then we use the docker builder command directly to build a new image based on the instructions in the Dockerfile.
5.1. docker builder command details
Flag shorthand -h has been deprecated, please use --help
Usage: docker build [OPTIONS] PATH | URL | -
Build an image from a Dockerfile
Options:
--add-host list Add a custom host-to-IP mapping (host:ip)
--build-arg list Set build-time variables
--cache-from strings Images to consider as cache sources
--cgroup-parent string Optional parent cgroup for the container
--compress Compress the build context using gzip
--cpu-period int Limit the CPU CFS (Completely Fair Scheduler) period
--cpu-quota int Limit the CPU CFS (Completely Fair Scheduler) quota
-c, --cpu-shares int CPU shares (relative weight)
--cpuset-cpus string CPUs in which to allow execution (0-3, 0,1)
--cpuset-mems string MEMs in which to allow execution (0-3, 0,1)
--disable-content-trust Skip image verification (default true)
-f, --file string Name of the Dockerfile (Default is 'PATH/Dockerfile')
--force-rm Always remove intermediate containers
--iidfile string Write the image ID to the file
--isolation string Container isolation technology
--label list Set metadata for an image
-m, --memory bytes Memory limit
--memory-swap bytes Swap limit equal to memory plus swap: '-1' to enable unlimited swap
--network string Set the networking mode for the RUN instructions during build (default
"default")
--no-cache Do not use cache when building the image
--pull Always attempt to pull a newer version of the image
-q, --quiet Suppress the build output and print image ID on success
--rm Remove intermediate containers after a successful build (default true)
--security-opt strings Security options
--shm-size bytes Size of /dev/shm
-t, --tag list Name and optionally a tag in the 'name:tag' format
--target string Set the target build stage to build.
--ulimit ulimit Ulimit options (default [])
5.2. Dockerfile syntax
5.2.1. FROM<Required>
Used to specify the base image, written at the beginning of the Dockerfile file. All subsequent instructions depend on the specified base image. The underlying mirror specified in the FROM directive can be an official remote warehouse, a private warehouse, or a local warehouse.
Since it is required, you can specify multiple FROM instructions when you encounter a process that requires multiple mirrors in use.
In practice, the instruction has two writing formats:
- FROM $IMAGE: Specifies that the base image is the last modified version of the image, and we often default to disdain, which is the latest version used until the image is used.
- FROM $IMAGE:$TAG: Specify its mirror branch version for the base image
5.2.2. MAINTAINER
This directive specifies the basic information about the creator of this image, the image creator's tag for this image.
- MAINTAINER $Desc
5.2.3. RUN
When mirroring in the warehouse does not meet our requirements, we need to install custom software during the mirroring process. It is common for us to install RUN yum install y vim in the mirror.
In practice, the instruction has two writing formats:
- RUN $COMMAND
- RUN ["executable", "param1", "param2" ... ]]
5.2.4. ADD/COPY
ADD, COPY are similar instructions that copy files from the host to the target image. The main difference in usage is that ADD also supports tar files and URL paths.
ADD/COPY <src>... <dest>
5.2.5. WORKDIR
The WORKDIR directive, which is used to switch the working directory in the mirror, similar to the cd command.
Note: After setting up the working directory through WORKDIR, the following commands in Dockerfile, such as RUN, CMD, ENTRYPOINT, ADD, COPY, etc., will be executed in this directory. However, when running containers with docker run, you can override the working directory that was set at the time of the build with the -w parameter.
WORKDIR /usr/local/
5.2.6. VOLUME
The VOLUME directive specifies the directory in the container that needs to be persisted to prevent the loss of changes in the container due to container closure. However, it can only specify paths within containers, not hosts.
- Usage 1: The Dockerfile generates a mirror container, and the data in the /data/mysql directory still exists after the container is closed
FROM base VOLUME ["/data/mysql"]
- Usage 2: Share the directory to another container, $Source_Container's/data/mysql is shared to $Target_Container.
docker run ‐t ‐i ‐rm ‐volumes‐from $Source_Container $Target_Container bash
5.2.7. EXPOSE
EXPOSE directive stating that the port mapping of this container will be to the port of the host machine, defaulting to tcp mode, and that udp usage needs attention.
- First set the container ports that need to be mapped using EXPOSE in the Dockerfile.
- Next, specify the P parameter when running the container, plus the port set by EXPOSE, so that the port number set by EXPOSE is randomly mapped to the host's higher-order port. The `P'here is capitalized
If the port exposed by EXPOSE determines that a mapping relationship is to be established between the host port, be sure to use P in docker run -p here as lowercase
5.2.8. CMD
The CMD directive specifies the default program to run for the startup container, a process command with a PID of 1, and the container terminates when it has finished running. If not specified, the default is bash. This directive can only exist once in a Dockerfile, and if there are more than one, only the last one is executed.
In practice, the directive has three writing formats:
- RCMDUN ["executable","param1","param2"]
- CMD command param1 param2
- CMD ["param1","param2"]
5.2.9. ENTRYPOINT
The ENTRYPOINT directive specifies the default program to run for the startup container, similar to CMD. However, ENTRYPOINT can only use JSON to specify execution commands, not parameters, which needs to be used in conjunction with CMD.
In practice, the instruction has two writing formats:
- ENTRYPOINT ["executable", "param1", "param2"]
- ENTRYPOINT command param1 param2
Execution method: ENTRYPOINT executes separately, if there is CMD at this time, CMD and ENTRYPOINT will cover each other, only the last CMD or ENTRYPOINT is valid.
5.2.10. USER
The USER directive sets the user who starts the container, defaulting to the root user.
5.3. Dockerfile sample
The following example is the simplest one where I package a JavaWeb file on my local disk as a mirror and specify the run parameters.
FROM openjdk:8 ADD demo-will.jar /demo.jar ENTRYPOINT ["java", "-jar", "demo.jar"]