The document provides instructions for building Docker images. It explains key Dockerfile instructions like FROM, RUN, CMD, ENTRYPOINT, ENV, and EXPOSE. It also provides an example of building an image that sets environment proxies and installs wget. The Dockerfile is built with 'docker build' and then the resulting image is run with 'docker run' to test the behavior of the CMD instruction.

1. Docker : Building Images
• Dawood Sayyed
• Learn to build docker images in 10 mins

2. FROM
• The FROM instruction is the most important one and it is the first valid
instruction of a Dockerfile. It sets the base image for the build process.
• The subsequent instructions would use this base image and build on top of
it.
• The docker build system lets you flexibly use the images built by anyone.
• You can also extend them by adding more precise and practical features to
them.
• By default, the docker build system looks in the Docker host for the images.
• However, if the image is not found in the Docker host, then the docker build
system will pull the image from the publicly available Docker Hub Registry.
• The docker build system will return an error if it can not find the specified
image in the Docker host and the Docker Hub Registry.

3. FROM
• Docker allows multiple FROM instructions in a single Dockerfile in order to create
• multiple images. The Docker build system will pull all the images specified in the
• FROM instruction. Docker does not provide any mechanism for naming the
individual
• images that are generated with the help of multiple FROM instructions. We
strongly
• discourage using multiple FROM instructions in a single Dockerfile, as damaging
• conflicts could arise.

4. MAINTAINER
• The MAINTAINER instruction is an informational instruction of a Dockerfile.
• This instruction capability enables the authors to set the details in an image.
• Docker does not place any restrictions on placing the MAINTAINER
instruction in Dockerfile.
• However, it is strongly recommended that you should place it after the
FROM instruction

5. COPY / ADD
• The COPY instruction enables you to copy the files from the Docker host to
the fielsystem of the new image.
• The ADD instruction is similar to the COPY instruction.
• However, in addition to the functionality supported by the COPY instruction,
the ADD instruction can handle the TAR files and the remote URLs.
• We can annotate the ADD instruction as COPY on boost or Super copy
• COPY <src> <dst> COPY html /var/www/html
• ADD <src> <dst>

6. ENV
• The ENV instruction sets an environment variable in the new image.
• An environment variable is a key-value pair, which can be accessed by any
script or application.
• Linux applications use the environment variables a lot for a starting
configuration.
• ENV <key> <value>
• <key>: Environment Variable
• <value>:Set for Environment variable
• ENV DEBUG_LVL 3 ENV APACHE_LOG_DIR /var/log/apache

7. USER
• The USER instruction sets the start up user ID or user Name in the new
image.
• By default, the containers will be launched with root as the user ID or UID.
• Essentially, the USER instruction will modify the default user ID from root to
the one specified in this instruction.
• The syntax of the USER instruction is as follows:
• USER <UID>|<UName>
• <UID> : numerical ID
• <UNAME> :Valid user ID
• USER 95

8. WORKDIR
• The WORKDIR instruction changes the current working directory from / to
the
• path specified by this instruction. The ensuing instructions, such as RUN,
CMD,
• and ENTRYPOINT will also work on the directory set by the WORKDIR
instruction.
• The following line gives the appropriate syntax for the WORKDIR instruction:
• WORKDIR <dirpath>
• WORKDIR /var/log

9. VOLUME
• The VOLUME instruction creates a directory in the image filesystem, which
can later be
• used for mounting volumes from the Docker host or the other containers.
• • The first type is either exec or JSON array (all values must be within
doublequotes(")):
• VOLUME ["<mountpoint>"]
• • The second type is shell, as shown here:
• VOLUME <mountpoint>
• In the preceding line, <mountpoint> is the mount point that has to be
created in the new image.

10. EXPOSE
• The EXPOSE instruction opens up a container network port for
communicating between the container and the external world . The syntax of
the EXPOSE instruction is as follows:
• EXPOSE <port>[/<proto>] [<port>[/<proto>]...]
• Here, the code terms mean the following:
• • <port>: This is the network port that has to be exposed to the outside
world.
• • <proto>: This is an optional field provided for a specific transport protocol ,
such as TCP and UDP. If no transport protocol has been specified, then TCP is
assumed to be the transport protocol.
• EXPOSE 7373/udp 8080

11. RUN
• The RUN instruction is the real workhorse during the build time, and it can
run any command.
• The general recommendation is to execute multiple commands by using one
RUN instruction.
• This reduces the layers in the resulting Docker image because the Docker
system inherently creates a layer for each time an instruction is called in
Dockerfile.
• • The first is the shell type, as shown here:
• RUN <command>
• Here, the <command> is the shell command that has to be executed during
the build time. If this type of syntax is to be used, then the command is
always executed by using /bin/sh -c.

12. RUN
• • The second syntax type is either exec or the JSON array, as shown here:
• RUN ["<exec>", "<arg-1>", ..., "<arg-n>"]
• Within this, the code terms mean the following:
• °° <exec>: This is the executable to run during the build time.
• °° <arg-1>, ..., <arg-n>: These are the variables (zero or more) number of the
arguments for the executable.

13. CMD
• CMD instruction can run any command (or application), which is similar to the RUN
instruction.
• Major difference between those two is the time of execution.
• Command supplied through the RUN instruction is executed during the build time
• Command specified through the CMD instruction is executed when the container is
launched from the newly created image.
• CMD instruction provides a default execution for this container.
• It can be overridden by the docker run subcommand arguments. When the
application terminates, the container will also terminate along with the application
and vice versa.

14. CMD
• The CMD instruction has three types of syntax, as shown here:
• • The first syntax type is the shell type, as shown here:
• CMD <command>
• Within this, the <command> is the shell command, which has to be executed
• during the launch of the container. If this type of syntax is used, then the
• command is always executed by using /bin/sh -c.

15. CMD
• • The second type of syntax is exec or the JSON array, as shown here:
• CMD ["<exec>", "<arg-1>", ..., "<arg-n>"]
• Within this, the code terms mean the following:
• °° <exec>: This is the executable, which is to be run during the
• container launch time.
• °° <arg-1>, ..., <arg-n>: These are the variable (zero or more)
• numbers of the arguments for the executable.

16. CMD
• • The third type of syntax is also exec or the JSON array, which is similar to
the previous type.
• However, this type is used for setting the default parameters
• to the ENTRYPOINT instruction, as shown here:
• CMD ["<arg-1>", ..., "<arg-n>"]

17. Building image to check behavior of CMD
• FROM Ubuntu:latest
• RUN all proxies
• MAINTAINER Dawood Sayyed Dawood.sayyed@sap.com
• CMD ["echo", "Dockerfile CMD demo"]
• -------------------------------------------Behaviour test --------------------------------------
----------------------------------docker build –t myimage .
• docker run myimage
• docker run myimage echo Override CMD demo

18. ENTRYPOINT
• The ENTRYPOINT instruction will help in crafting an image for running an
application(entry point) during the complete life cycle of the container, which
would have been spun out of the image.
• When the entry point application is terminated, the container would also be
terminated along with the application and vice versa.
• ENTRYPOINT instruction would make the container function like an executable.
• Entry point application is launched by using the ENTRYPOINT instruction, which
cannot be overridden by using the docker run subcommand arguments.
• Docker provides a mechanism for overriding the entry point application through
the--entrypoint option in the docker run subcommand . The --entrypoint option
can accept only word as its argument, and so it has limited functionality.

19. ENTRYPOINT
• • The first type of syntax is the shell type, as shown here:
• ENTRYPOINT <command>
• Here, <command> is the shell command, which is executed during the
launch
• of the container. If this type of syntax is used, then the command is always
• executed by using /bin/sh -c.

20. ENTRYPOINT
• • The second type of syntax is exec or the JSON array, as shown here:
• ENTRYPOINT ["<exec>", "<arg-1>", ..., "<arg-n>"]
• Within this, the code terms mean the following:
• °° <exec>: This is the executable, which has to be run during the
• container launch time.
• °° <arg-1>, ..., <arg-n>: These are the variable (zero or more)
• numbers of arguments for the executable.

21. ENTRYPOINT
• FROM ubuntu:latest
• RUN export http_proxy=http://proxy.wdf.sap.corp:8080
• RUN export ftp_proxy=http://proxy.wdf.sap.corp:8080
• RUN export all_proxy=http://proxy.wdf.sap.corp:8080
• RUN export https_proxy=http://proxy.wdf.sap.corp:8080
• ENTRYPOINT ["echo" , " dockerfile ENTRYPOINT demo "]
• docker build –t myimage .
• docker run myimage

22. ENTRYPOINT OVERRIDE
• docker run myimage with additional arguments
• docker run –entrypoint=“/bin/sh” myimage

23. ONBUILD
• The ONBUILD instruction registers a build instruction to an image and this is
triggered when another image is built by using this image as its base image.
• Any build instruction can be registered as a trigger and those instructions will be
triggered immediately after the FROM instruction in the downstream Dockerfile .
• ONBUILD instruction can be used to defer the execution of the build instruction
from the base image to the target image. Doesn’t allow FROM and MAINTAINER as
ONBUILD triggers
• The syntax of the ONBUILD instruction is as follows:
• ONBUILD <INSTRUCTION>
• ONBUILD ADD config /etc/appconfig

24. Dockerfile
• 1. Create a directory to hold our Dockerfile.
• $ mkdir myimage
• 2. Create a Dockerfile inside this directory.
• $ cd myimage
• $vim dockerfile

25. Type this into our Dockerfile
• FROM Ubuntu
• RUN export http_proxy=http://proxy.rot.sap.corp:8080
• RUN export ftp_proxy=http://proxy.rot.sap.corp:8080
• RUN export all_proxy=http://proxy.rot.sap.corp:8080
• RUN export https_proxy=http://proxy.rot.sap.corp:8080
• RUN apt-get install update
• RUN apt-get install wget
• RUN apt-get update
• RUN apt-get install –y wget
• FROM indicates the base image for our build
• Each RUN line will be executed by Docker during the build
• Our RUN commands must be non-interactive.
• (No input can be provided to Docker during the build.)
• $ docker build .

26. Build it !
• Save our file, then execute:
• $ docker build –t myimage .
• -t indicates the tag to apply to the image.
• • . indicates the location of the build context.
• (We will talk more about the build context later; but to keep things simple:
this is
• the directory where our Dockerfile is located.)

27. Running the image
• The resulting image is not different from the one produced manually.
• $ docker run –ti myimage bash
• $ mkdir sample_image
• $ FROM fedora
• $ RUN dnf upgrade
• $ MAINTAINER Dawood Sayyed
• $ CMD date