How to write a Dockerfile
0 likes643 views
The document provides information on how to write a Dockerfile, including: - What a Dockerfile is and its purpose of providing instructions to build a Docker image - Common Dockerfile instructions like FROM, RUN, COPY, EXPOSE, and CMD - Best practices for writing Dockerfiles such as making images smaller, choosing the correct build context, leveraging the build cache, and ordering instructions - Additional topics covered include the Docker build context, Dockerfile format, and tools like Docker BuildKit and Docker Scan. The presentation concludes with a demonstration of Dockerfiles.
![● Syntax:
○ FROM [--platform=<platform>] <image>[:<tag>] [AS <name>]
● The FROM instruction initializes a new build stage and sets the Base Image for subsequent instructions.
● ARG is the only instruction that may precede FROM in the Dockerfile.
● FROM can appear multiple times within a single Dockerfile to create multiple images or use one build stage
as a dependency for another.
● Optionally a name can be given to a new build stage by adding AS name to the FROM instruction. The name
can be used in subsequent FROM and COPY --from=<name> instructions to refer to the image built in
this stage.
● The optional --platform flag can be used to specify the platform of the image in case FROM references a
multi-platform image. For example, linux/amd64, linux/arm64, or windows/amd64. By default, the target
platform of the build request is used. Check arch: uname -m || arch || dpkg --print-architecture
Dockerfile Instruction: FROM
FROM](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-8-320.jpg)
![● Syntax:
○ LABEL <key>=<value> <key>=<value> <key>=<value>
● The LABEL instruction adds metadata to an image.
● A LABEL is a key-value pair.
● An image can have more than one label.
● LABEL multi.label1="value1" multi.label2="value2" other="value3"
● LABEL multi.label1="value1"
multi.label2="value2"
other="value3"
● Check Labels: docker image inspect <image> | jq '.[].Config.Labels'
Dockerfile Instruction: LABEL
LABEL](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-9-320.jpg)
![● Syntax:
○ EXPOSE <port> [<port>/<protocol>...]
○ EXPOSE 80/tcp
● The EXPOSE instruction informs Docker that the container listens on the specified network ports at runtime.
● You can specify whether the port listens on TCP or UDP, and the default is TCP if the protocol is not specified.
● The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between
the person who builds the image and the person who runs the container, about which ports are intended to
be published.
● To actually publish the port when running the container, use the -p flag on docker run to publish and map
one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports.
● docker run -d -p 80:80/tcp nginx
● docker run -dP nginx
Dockerfile Instruction: EXPOSE
EXPOSE](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-10-320.jpg)
![● Syntax:
○ ADD [--chown=<user>:<group>] <src>... <dest>
● The ADD instruction copies new files, directories or remote file URLs from <src> and adds them to the
filesystem of the image at the path <dest>.
● Multiple <src> resources may be specified.
● <src> path is always relative to the build context.
Dockerfile Instruction: ADD
ADD](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-12-320.jpg)
![● Syntax:
○ COPY [--chown=<user>:<group>] <src>... <dest>
● The COPY instruction copies new files or directories from <src> and adds them to the filesystem of the
container at the path <dest>
● Multiple <src> resources may be specified.
● <src> path is always relative to the build context.
● Optionally COPY accepts a flag --from=<name> that can be used to set the source location to a previous build
stage (created with FROM .. AS <name>) that will be used instead of a build context sent by the user. In case a
build stage with a specified name can’t be found an image with the same name is attempted to be used
instead.
Dockerfile Instruction: COPY
COPY](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-13-320.jpg)
![● Syntax:
○ USER <user>[:<group>]
○ USER <UID>[:<GID>]
● The USER instruction sets the user name (or UID) and optionally the user group (or GID) to use when running
the image and for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile.
● Won’t create a user for you
● RUN useradd yatharth
USER yatharth
Dockerfile Instruction: USER
USER](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-14-320.jpg)
![● Syntax:
○ ARG <name>[=<default value>]
● 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 <varname>=<value> flag.
● If a user specifies a build argument that was not defined in the Dockerfile, the build outputs a warning.
Dockerfile Instruction: ARG
ARG](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-16-320.jpg)
![● Syntax:
○ RUN <command> (shell format)
○ RUN [“executable”, “param1”, “param2”] (exec format)
● The RUN instruction will execute any commands in a new layer on top of the current image and commit the
results.
● Unlike the shell form, the exec form does not invoke a command shell. This means that normal shell
processing does not happen. For example, RUN [ "echo", "$HOME" ] will not do variable substitution on
$HOME. If you want shell processing then either use the shell form or execute a shell directly, for example: RUN
[ "sh", "-c", "echo $HOME" ]
● Example: RUN apt-get dist-upgrade -y
Dockerfile Instruction: RUN
RUN](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-17-320.jpg)
![● Syntax:
○ ENTRYPOINT ["executable", "param1", "param2"]
○ ENTRYPOINT command param1 param2
● An ENTRYPOINT allows you to configure a container that will run as an executable.
● You can override the ENTRYPOINT instruction using the docker run --entrypoint flag.
Dockerfile Instruction: ENTRYPOINT
ENTRYPOINT](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-18-320.jpg)
![● Syntax:
○ CMD command param1 param2 (shell format)
○ CMD ["executable","param1","param2"] (exec format)
○ CMD ["param1","param2"] (default parameter to ENTRYPOINT)
● The main purpose of a CMD is to provide defaults for an executing container.
● There can only be one CMD instruction in a Dockerfile. If you list more than one CMD then only the last CMD
will take effect.
● If you use the shell form of the CMD, then the <command> will execute in /bin/sh -c
Dockerfile Instruction: CMD
CMD](https://image.slidesharecdn.com/dockerfile-211129071544/85/How-to-write-a-Dockerfile-19-320.jpg)
How to write a Dockerfile
- 1. Presented By: Yatharth Sharma How to write a Dockerfile
- 2. Lack of etiquette and manners is a huge turn off. KnolX Etiquettes Punctuality Respect Knolx session timings, you are requested not to join sessions after a 5 minutes threshold post the session start time. Feedback Make sure to submit a constructive feedback for all sessions as it is very helpful for the presenter. Silent Mode Keep your mobile devices in silent mode, feel free to move out of session in case you need to attend an urgent call. Avoid Disturbance Avoid unwanted chit chat during the session.
- 3. Our Agenda 01 Why containers? 02 What is a Dockerfile 03 Docker Build Context 04 Dockerfile Format 05 Dockerfile Instructions with Best Practices 06 Docker BuildKit 07 Docker scan 08 Demo
- 4. ● Dependency issue Why Containerize? What problem does containers solve? Blog: Understanding Containerization and its implementation by Docker
- 5. ● It is a simple text file with a set of command or instruction. These commands/instructions are executed successively to perform actions on the base image to create a new docker image. ● Docker can build images automatically by reading the instructions from a Dockerfile. ● Using docker build users can create an automated build that executes several command-line instructions in succession. What is a Dockerfile? Dockerfile
- 6. ● The docker build command builds an image from a Dockerfile and a context. ● The build context is the set of files at a specified location PATH or URL. The PATH is a directory on your local filesystem. The URL is a Git repository location. ● Warning: Do not use your root directory, /, as the PATH for your build context, as it causes the build to transfer the entire contents of your hard drive to the Docker daemon excluding files mentioned in .dockerignore. Docker Build Context Docker Build Context
- 7. ● Dockerfile format is: ○ # Comment ○ INSTRUCTION arguments ● The instruction is not case-sensitive. However, convention is for them to be UPPERCASE to distinguish them from arguments more easily. ● A Dockerfile must begin with a FROM instruction. ● FROM may only be preceded by one or more ARG instructions, which declare arguments that are used in FROM lines in the Dockerfile. ● Instructions: ○ Build Time ○ Run Time Dockerfile Format Dockerfile format
- 8. ● Syntax: ○ FROM [--platform=<platform>] <image>[:<tag>] [AS <name>] ● The FROM instruction initializes a new build stage and sets the Base Image for subsequent instructions. ● ARG is the only instruction that may precede FROM in the Dockerfile. ● FROM can appear multiple times within a single Dockerfile to create multiple images or use one build stage as a dependency for another. ● Optionally a name can be given to a new build stage by adding AS name to the FROM instruction. The name can be used in subsequent FROM and COPY --from=<name> instructions to refer to the image built in this stage. ● The optional --platform flag can be used to specify the platform of the image in case FROM references a multi-platform image. For example, linux/amd64, linux/arm64, or windows/amd64. By default, the target platform of the build request is used. Check arch: uname -m || arch || dpkg --print-architecture Dockerfile Instruction: FROM FROM
- 9. ● Syntax: ○ LABEL <key>=<value> <key>=<value> <key>=<value> ● The LABEL instruction adds metadata to an image. ● A LABEL is a key-value pair. ● An image can have more than one label. ● LABEL multi.label1="value1" multi.label2="value2" other="value3" ● LABEL multi.label1="value1" multi.label2="value2" other="value3" ● Check Labels: docker image inspect <image> | jq '.[].Config.Labels' Dockerfile Instruction: LABEL LABEL
- 10. ● Syntax: ○ EXPOSE <port> [<port>/<protocol>...] ○ EXPOSE 80/tcp ● The EXPOSE instruction informs Docker that the container listens on the specified network ports at runtime. ● You can specify whether the port listens on TCP or UDP, and the default is TCP if the protocol is not specified. ● The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published. ● To actually publish the port when running the container, use the -p flag on docker run to publish and map one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports. ● docker run -d -p 80:80/tcp nginx ● docker run -dP nginx Dockerfile Instruction: EXPOSE EXPOSE
- 11. ● Syntax: ○ WORKDIR /path/to/workdir ● 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. ● The WORKDIR instruction can resolve environment variables previously set using ENV ● ENV DIRPATH=/path WORKDIR $DIRPATH RUN pwd Dockerfile Instruction: WORKDIR WORKDIR
- 12. ● Syntax: ○ ADD [--chown=<user>:<group>] <src>... <dest> ● The ADD instruction copies new files, directories or remote file URLs from <src> and adds them to the filesystem of the image at the path <dest>. ● Multiple <src> resources may be specified. ● <src> path is always relative to the build context. Dockerfile Instruction: ADD ADD
- 13. ● Syntax: ○ COPY [--chown=<user>:<group>] <src>... <dest> ● The COPY instruction copies new files or directories from <src> and adds them to the filesystem of the container at the path <dest> ● Multiple <src> resources may be specified. ● <src> path is always relative to the build context. ● Optionally COPY accepts a flag --from=<name> that can be used to set the source location to a previous build stage (created with FROM .. AS <name>) that will be used instead of a build context sent by the user. In case a build stage with a specified name can’t be found an image with the same name is attempted to be used instead. Dockerfile Instruction: COPY COPY
- 14. ● Syntax: ○ USER <user>[:<group>] ○ USER <UID>[:<GID>] ● The USER instruction sets the user name (or UID) and optionally the user group (or GID) to use when running the image and for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile. ● Won’t create a user for you ● RUN useradd yatharth USER yatharth Dockerfile Instruction: USER USER
- 15. ● Syntax: ○ ENV <key>=<value> ● The ENV instruction sets the environment variable <key> to the value <value>. ● ENV MY_NAME="Yatharth Sharma" ● ENV MY_DOG=Snoop Dogg MY_OTHER_DOG=Rambo ● ENV MY_CAT fluffy ● You can change the env value using docker run --env <key>=<value> ● If an environment variable is only needed during build, and not in the final image, consider not using ENV Dockerfile Instruction: ENV ENV
- 16. ● Syntax: ○ ARG <name>[=<default value>] ● 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 <varname>=<value> flag. ● If a user specifies a build argument that was not defined in the Dockerfile, the build outputs a warning. Dockerfile Instruction: ARG ARG
- 17. ● Syntax: ○ RUN <command> (shell format) ○ RUN [“executable”, “param1”, “param2”] (exec format) ● The RUN instruction will execute any commands in a new layer on top of the current image and commit the results. ● Unlike the shell form, the exec form does not invoke a command shell. This means that normal shell processing does not happen. For example, RUN [ "echo", "$HOME" ] will not do variable substitution on $HOME. If you want shell processing then either use the shell form or execute a shell directly, for example: RUN [ "sh", "-c", "echo $HOME" ] ● Example: RUN apt-get dist-upgrade -y Dockerfile Instruction: RUN RUN
- 18. ● Syntax: ○ ENTRYPOINT ["executable", "param1", "param2"] ○ ENTRYPOINT command param1 param2 ● An ENTRYPOINT allows you to configure a container that will run as an executable. ● You can override the ENTRYPOINT instruction using the docker run --entrypoint flag. Dockerfile Instruction: ENTRYPOINT ENTRYPOINT
- 19. ● Syntax: ○ CMD command param1 param2 (shell format) ○ CMD ["executable","param1","param2"] (exec format) ○ CMD ["param1","param2"] (default parameter to ENTRYPOINT) ● The main purpose of a CMD is to provide defaults for an executing container. ● There can only be one CMD instruction in a Dockerfile. If you list more than one CMD then only the last CMD will take effect. ● If you use the shell form of the CMD, then the <command> will execute in /bin/sh -c Dockerfile Instruction: CMD CMD
- 20. ● Both CMD and ENTRYPOINT instructions define what command gets executed when running a container. There are few rules that describe their co-operation. ○ Dockerfile should specify at least one of CMD or ENTRYPOINT commands. ○ ENTRYPOINT should be defined when using the container as an executable. ○ CMD should be used as a way of defining default arguments for an ENTRYPOINT command or for executing an ad-hoc command in a container. ○ CMD will be overridden when running the container with alternative arguments. Dockerfile: ENTRYPOINT && CMD
- 21. ● Make images as smaller as possible ○ Use distro-less images: Github ○ Use alpine as base-images ○ Use multi-stage builds ● Choosing Correct Build Context ● Using .dockerignore ● Leverage Build Cache ● Dockerfile Instructions sequence and usage best practices. ● Dockerfiles for language specific project - Demo Dockerfile Best Practices
- 22. ● Starting with version 18.09, Docker supports a new backend for executing your builds that is provided by the moby/buildkit project. ● Benefits: ○ Detect and skip executing unused build stages. ○ Parallelize building independent build stages. ○ Incrementally transfer only the changed files in your build context between builds ○ Detect and skip transferring unused files in your build context ● To use the BuildKit backend, you need to set an environment variable DOCKER_BUILDKIT=1 Docker BuildKit Docker BuildKit
- 23. ● This feature requires a Docker subscription ● Vulnerability scanning for Docker local images allows developers and development teams to review the security state of the container images and take actions to fix issues identified during the scan, resulting in more secure deployments. Docker Scan runs on Snyk engine, providing users with visibility into the security posture of their local Dockerfiles and local images. ● Sync Docs ● docker scan <image-name:image-tag> Docker Scan Images Docker Scan
- 24. DEMO
- 25. Thank You ! Get in touch with me: [email protected]