If you do not want publish your docker to public registry(e.g. dockerhub, aws, aliyun etc). You can use a local/private registry.
Docker provide docker registry(which is is a docker image)
As discussed early, we can use a infrastructure container to share system variable to other container. (e.g use consul)
and generate configure file based on system variable. e.g. a nginx file in /etc/nginx/conf.d/
ADD is similar to COPY, expects that it can add and unzip compressed file (gz, Z, bz2, zip). It also can fetch files from URL e.g. ADD http://nginx.org/download/nginx-1.18.0.tar.gz /usr/local/
or nginx-1.18.0.tar.gz /usr/local (will untar to /usr/local, docker will have /usr/local/nginx-1.18.0)
* Syntax:
* ADD \ [\ …] \
* ADD [“\“, … “\“]
* Same as COPY 1~5 bullet points
* to un-compress, \ must not end with /
* If use ADD ["<src>", ... "<dest>"] and wildcard existed in src, \ should end with / if \ not end with / it will be treat as a single file instead of a dir
The WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions that follow it in the Dockerfile. If the WORKDIR doesn’t exist, it will be created even if it’s not used in any subsequent Dockerfile instruction.
* Syntax:
* WORKDIR /path/to/workdir
The VOLUME instruction creates a mount point(volume) and marks it as holding externally mounted volumes from native host or other containers.
* Syntax:
* VOLUME \ e.g. VOLUME /var/log
* VOLUME [“\“] e.g. VOLUME [“/opt”]
* VOLUME is used to share folder between Docker and host/other dockers
* Docker VOLUME is similar to -v option in docker run command. Difference is that VOLUME does not specify the directory mapping. Normally is uses to gether the logs in container. More specific, VOLUME /var/log will expose the folder to a folder like /var/lib/docker/volumes/3207....84e4 and docker container will know the mapping. Any logs in /var/log in docker will also appear in /var/lib/docker/volumes/3207....84e4
ENV sets the environment variable \ to the value \.
Note ENV is set in docker build also it will be passed to docker run
The ENV setup can be overwrite with docker run -e <key>=<value>
* Syntax:
ENV \ \
ENV \=\ …
Refer to the env variable with $variable_name or ${variable_name}
e.g
ENV myName John Doe equal to ENV myName="John Doe"
ENV myName="John Doe" myDog=Rex\ The\ Dog \
myCat=fluffy
* To set a value for a single command, use RUN \=\ \
Run the executable in docke durning docker build.
The RUN instruction will execute any commands in a new layer on top of the current image and commit the results. The resulting committed image will be used for the next step in the Dockerfile.
Syntax
RUN \ (shell form, /bin/sh -c \)
RUN [“executable”, “param1”, “param2”] (exec form)
Shell form PID not 1 and can not receive Unix signals
exec form does not support shell operator (e.g wildcard, &, >, | etc) to use shell , you need to run RUN ["/bin/bash", "-c", "<command>", "<argument1>", "<argument2>" ... ]
Tp prevent demon stop after shell stops, need to use
nohub or exec.
Note:
nohub command
exec: replaces the current process image with a new process image. This means it replace
nohub: no hungup, Run a Command or Shell-Script Even after You Logout
The main purpose of a CMD is to provide defaults for an executing container. e.g. buxybox default CMD is /usr/sh, nginx default is nginx
* Syntax
* CMD [“executable”,”param1”,”param2”] (exec form, this is the preferred form)
* CMD [“param1”,”param2”] (as default parameters to ENTRYPOINT)
* CMD command param1 param2 (shell form)
* If multipule CMD provided, only the last one is effective
* To build a busybox httpd, which is correct:
* Pitfull
* CMD /bin/httpd -f -h \({WEB_ROOT}
* CMD ["/bin/httpd", "-f", "-h", "\)”]
* CMD [“/bin/sh”, “-c”, “/bin/httpd”, “-f”, “-h ${WEB_ROOT}”]
* CMD [“/bin/sh”, “-c”, “/bin/httpd”, “-f”, “-h /opt/data/web”]
* form 1, you can not enter interative mode with -it, If you need to inspect, need to run `docker exec ‘/bin/sh’
* form 2, will not work, ${WEB_ROOT} not found
* form 3, will not work, start and then exit(httpd is a backend deamon sh -c httpd will return so PID 1 will exit too, this will stop the container)
* form 4, will not work, start and then exit(same as above)
An ENTRYPOINT allows you to configure a container that will run as an executable.
* Syntax
* ENTRYPOINT [“executable”, “param1”, “param2”] (exec form)
* ENTRYPOINT command param1 param2
* Command line arguments to docker run \ will be appended after all elements in an exec form ENTRYPOINT, and will override all elements specified using CMD. This allows arguments to be passed to the entry point, i.e., docker run \ -d will pass the -d argument to the entry point. You can override the ENTRYPOINT instruction using the docker run –entrypoint flag.
* The shell form prevents any CMD or run command line arguments from being used, but has the disadvantage that your ENTRYPOINT will be started as a subcommand of /bin/sh -c, which does not pass signals. This means that the executable will not be the container’s PID 1 - and will not receive Unix signals - so your executable will not receive a SIGTERM from docker stop \.
Only the last ENTRYPOINT instruction in the Dockerfile will have an effect.
docker run --entrypoint <cmd> <args> overwrite the ENTRYPOINT in dockerfile
ENTRYPOINT solve the issue that CMD ["/bin/sh", "-c", "/bin/httpd", "-f", "-h /opt/data/web"] has
ENTRYPOINT /bin/httpd -f =h /opt/data/web will not exit
If both CMD and ENTRYPOINT exists, arguments of CMD will be pass to ENTRYPOINT as argument
The HEALTHCHECK instruction tells Docker how to test a container to check that it is still working. (e.g. not responding, infinite loop)
Syntax
* HEALTHCHECK [OPTIONS] CMD command (check container health by running a command inside the container)
* The options that can appear before CMD are:
* –interval=DURATION (default: 30s)
* –timeout=DURATION (default: 30s)
* –start-period=DURATION (default: 0s)
* –retries=N (default: 3)
* Response:
* 0: success - the container is healthy and ready for use
* 1: unhealthy - the container is not working correctly
* 2: reserved - do not use this exit code
* HEALTHCHECK NONE (disable any healthcheck inherited from the base image)
example:
The SHELL instruction allows the default shell used for the shell form of commands to be overridden. The default shell on Linux is [“/bin/sh”, “-c”], and on Windows is [“cmd”, “/S”, “/C”]. The SHELL instruction must be written in JSON form in a Dockerfile.
* Syntax
* SHELL [“executable”, “parameters”]
* Example
* SHELL ["powershell", "-command"]
* SHELL ["/usr/bin/zsh", "-c"]
The ARG instruction defines a variable that users can pass at build-time to the builder with the docker build command using the –build-arg = flag. If a user specifies a build argument that was not defined in the Dockerfile, the build outputs a warning.
This provide a way to use one dockerfile to meet different requirement
* Syntex
* ARG \[=\]
The ONBUILD instruction adds a trigger instruction to be executed at a later time, when the image is used as the base for another build.
The trigger will be executed in the context of the downstream build, as if it had been inserted immediately after the FROM instruction in the downstream Dockerfile.
* Syntax
* ONBUILD \
* ONBUILD can not use in ONBUILD ONBUILD ONBUILD CMD ["ls"] is illegal
* Use onbuild tag for base image has onbuild
* COPY, ADD may not work....(different context)
Quote from docker.com “Copy-on-write is a strategy of sharing and copying files for maximum efficiency. If a file or
directory exists in a lower layer within the image, and another layer (including the writable layer) needs read access
to it, it just uses the existing file. The first time another layer needs to modify the file (when building the image or
running the container), the file is copied into that layer and modified. This minimizes I/O and the size of each of the
subsequent layers. These advantages are explained in more depth below.”
COW is low efficiency and thus I/O intensive application will need to mount data volume from host to docker.
Storage volume will help data persistency after docker image removed. Also split data with binary executable.
Inspect bbox1 container volume, volume id and directory in host ([{volume
bb23e94e907dc29f3e62deddd332520d34f489177c5bbd5b03a8a75426430a19
/var/lib/docker/volumes/bb23e94e907dc29f3e62deddd332520d34f489177c5bbd5b03a8a75426430a19/_data /data local true }]
)
Bind mount volume
docker run -it –name bbox2 -v HOSTDIR:VOLUMEDIR busybox e.g.
docker run -it --name bbox2 -v /data/volumes/b2:/data busybox
Some most used docker commands.
On ubuntu, if docker install with snap, add /snap/bin/ to PATH
Most docker command should have two levels. But for comparability reason commands can be both top level command and command with sub commands.
e.g.
docker pull nginx should be dockerimagepull nginx in latest docker versions. I will use docker [image] pull to indicate the command can either be docker image pull or docker pull
From article How to Automate Docker Deployments
An image is an inert, immutable, file that’s essentially a snapshot of a container. Images are created with the build command, and they’ll produce a container when started with run.
/my/bind/volume -> (bind) to host
/user/configured/directory
