How to write a Dockerfile

This session will reflect how to write a Dockerfile for any service

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
○INSTRUCTIONarguments
●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.
●LABELmulti.label1="value1"multi.label2="value2"other="value3"
●LABELmulti.label1="value1"\
multi.label2="value2"\
other="value3"
●Check Labels: dockerimageinspect<image>|jq'.[].Config.Labels'
Dockerfile Instruction: LABEL
LABEL

10. ●Syntax:
○EXPOSE<port>[<port>/<protocol>...]
○EXPOSE80/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.
●dockerrun-d-p80:80/tcpnginx
●dockerrun-dPnginx
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
●ENVDIRPATH=/path
WORKDIR$DIRPATH
RUNpwd

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
●RUNuseraddyatharth
USERyatharth
Dockerfile Instruction: USER
USER

15. ●Syntax:
○ENV<key>=<value>
●The ENV instruction sets the environment variable <key> to the value <value>.
●ENVMY_NAME="YatharthSharma"
●ENVMY_DOG=Snoop\Dogg\
MY_OTHER_DOG=Rambo
●ENVMY_CATfluffy
●You can change the env value usingdockerrun--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>[=<defaultvalue>]
●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>(shellformat)
○RUN[“executable”,“param1”,“param2”](execformat)
●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:RUNapt-getdist-upgrade-y
Dockerfile Instruction: RUN
RUN

18. ●Syntax:
○ENTRYPOINT["executable","param1","param2"]
○ENTRYPOINTcommandparam1param2
●An ENTRYPOINT allows you to configure a container that will run as an executable.
●You can override the ENTRYPOINT instruction using the dockerrun--entrypointflag.
Dockerfile Instruction: ENTRYPOINT
ENTRYPOINT

19. ●Syntax:
○CMDcommandparam1param2(shellformat)
○CMD["executable","param1","param2"](execformat)
○CMD["param1","param2"](defaultparametertoENTRYPOINT)
●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
●dockerscan<image-name:image-tag>
Docker Scan Images
Docker Scan

24. DEMO

25. Thank You !
Get in touch with me:
[email protected]