Friday, 12 June 2020

Understanding docker file

Docker can build images automatically by reading the instructions from a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Using docker build users can create an automated build that executes several command-line instructions in succession.

Now its time to understand about the docker engine and docker daemon.


Docker Engine.

Docker engine or Docker is a client server application that builds and executes containers using Docker components. REST API is a primary mode of communication between Docker Client and Docker Daemon.


Docker Daemon.

Docker Daemon is a server which interacts with the operating system and performs all kind of services. The Docker Daemon listens for REST API request and performs the operation. A command dockerd is used to start a Docker Daemon. Docker Host runs the Docker Daemon and Registry.

 

Docker Daemon checks the client request and communicates with the Docker components in order to perform a service whereas, Docker Engine or Docker is the base engine installed on your host machine to build and run containers using Docker components and services.

Environment variables are supported by the following list of instructions in the Dockerfile:


 COPY

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 but the paths of files and directories will be interpreted as relative to the source of the context of the build.

Each <src> may contain wildcards and matching will be done using Go’s filepath.Match rules. For example:

COPY test.txt relativeDir/


ADD

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 but if they are files or directories, their paths are interpreted as relative to the source of the context of the build.

 Each <src> may contain wildcards and matching will be done using Go’s filepath.Match rules

eg: To add all the files starting with "sye"

ADD sye* /mydir/


CMD

The main purpose of a CMD is to provide defaults for an executing container. These defaults can include an executable, or they can omit the executable, in which case you must specify an ENTRYPOINT instruction as well.

If CMD is used to provide default arguments for the ENTRYPOINT instruction, both the CMD and ENTRYPOINT instructions should be specified with the JSON array format.

eg:

FROM ubuntu

CMD echo "This is a test." | wc -


ENTRYPOINT

An ENTRYPOINT allows you to configure a container that will run as an executable.

eg:

ENTRYPOINT ["java","-jar","/app.jar"]


ENV

The ENV instruction sets the environment variable <key> to the value <value>. This value will be in the environment for all subsequent instructions in the build stage and can be replaced inline in many as well.

eg:

ENV myName="Syed Ghouse"


EXPOSE

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.

eg:

EXPOSE 80/udp


FROM

The FROM instruction initializes a new build stage and sets the Base Image for subsequent instructions. As such, a valid Dockerfile must start with a FROM instruction. The image can be any valid image – it is especially easy to start by pulling an image from the Public Repositories.

eg:FROM openjdk:8-jdk-alpine

FROM instructions support variables that are declared by any ARG instructions that occur before the first FROM

An ARG declared before a FROM is outside of a build stage, so it can’t be used in any instruction after a FROM. To use the default value of an ARG declared before the first FROM use an ARG instruction without a value inside of a build stage:

eg:

ARG VERSION=latest

FROM busybox:$VERSION

ARG VERSION

RUN echo $VERSION > image_version


MAINTAINER

The MAINTAINER instruction sets the Author field of the generated images. The LABEL instruction is a much more flexible version of this and you should use it instead, as it enables setting any metadata you require, and can be viewed easily, for example with docker inspect. To set a label corresponding to the MAINTAINER field you could use

eg: LABEL maintainer="syedghouse14@gmail.com"


RUN

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.

eg:

RUN ["/bin/bash", "-c", "echo hello"]


USER sets the UID (or username) which is to run the container.


VOLUME is used to enable access from the container to a directory on the host machine.


WORKDIR sets the path where the command, defined with CMD, is to be executed.


LABEL

The LABEL instruction adds metadata to an image. A LABEL is a key-value pair. To include spaces within a LABEL value, use quotes and backslashes as you would in command-line parsing.

eg: LABEL version="1.0"

 


No comments:
Write comments