docker session 6 building images

Use this title slide only with an image

Docker Part 6 Building ImagesDawood Sayyed/GLDS May 17th , 2016 Internal

© 2015 SAP SE or an SAP affiliate company. All rights reserved. 2Internal

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 cannot find the specified image in the Docker host and the Docker Hub Registry.


FROM

Docker allows multiple FROM instructions in a single Dockerfile in order to create multiple images.

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.

Discourage using multiple FROM instructions in a single Dockerfile, as damaging

conflicts could arise.


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


COPY and 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>


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


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


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


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.


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


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.


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.


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.


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.


CMD

• The second type of syntax is exec or the JSON array, as shown here:

CMD ["<exec>", "<arg-1>", ..., "<arg-n>"]


°° <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.


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>"]


Building image to check behavior of CMD

FROM Ubuntu:latest

RUN all proxies

MAINTAINER Dawood Sayyed [email protected]

CMD ["echo", "Dockerfile CMD demo"]

-------------------------------------------Behaviour test ------------------------------------------------------------------------docker build –t myimage .

docker run myimage

docker run myimage echo Override CMD demo

mailto:[email protected]


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.


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.


ENTRYPOINT

• The second type of syntax is exec or the JSON array, as shown here:

ENTRYPOINT ["<exec>", "<arg-1>", ..., "<arg-n>"]


°° <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.


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


ENTRYPOINT OVERRIDE

docker run myimage with additional arguments

docker run –entrypoint=“/bin/sh” myimage


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


Dockerfile

1. Create a directory to hold our Dockerfile.

$ mkdir myimage

2. Create a Dockerfile inside this directory.

$ cd myimage

$vim dockerfile


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 .


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.)


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

docker session 6 building images

Documents