One method of creating container images has been covered so far: create a container, modify it to meet the requirements of the application to run in it, and then commit the changes to an image. This option, although straightforward, is only suitable for using or testing very specific changes. It does not follow best software practices, like maintainability, automation of building, and repeatability.
\nDockerfiles are another option for creating container images, addressing these limitations. Dockerfiles are easy to share, version control, reuse, and extend.<\/p>\n
Dockerfiles also make it easy to extend one image, called a child image<\/i>, from another image, called a parent image<\/i>. A child image incorporates everything in the parent image and all changes and additions made to create it.<\/p>\n
The following is an example Dockerfile for building a simple Apache web server container:<\/p>\n
FROM ubi7\/ubi:7.7\r\nLABEL description=\"This is a custom httpd container image\"\r\nMAINTAINER John Doe <jdoe@xyz.com>\r\nRUN yum install -y httpd\r\nEXPOSE 80\r\nENV LogLevel \"info\"\r\nADD http:\/\/someserver.com\/filename.pdf \/var\/www\/html\r\nCOPY .\/src\/ \/var\/www\/html\/\r\nUSER apache\r\nENTRYPOINT [\"\/usr\/sbin\/httpd\"]\r\nCMD [\"-D\", \"FOREGROUND\"]<\/pre>\n
FROM<\/code> instruction declares that the new container image extends ubi7\/ubi:7.7 container base image. Dockerfiles can use any other container image as a base image, not only images from operating system distributions.<\/li>\n- The
LABEL<\/code> is responsible for adding generic metadata to an image. A LABEL<\/code> is a simple keyvalue pair.<\/li>\nMAINTAINER<\/code> indicates the Author field of the generated container image’s metadata. You can use the podman inspect<\/code> command to view image metadata.<\/li>\nRUN<\/code> executes commands in a new layer on top of the current image. The shell that is used to execute commands is \/bin\/sh<\/code>.<\/li>\nEXPOSE<\/code> indicates that the container listens on the specified network port at runtime. The EXPOSE<\/code> instruction defines metadata only; it does not make ports accessible from the host. The -p<\/code> option in the podman run<\/code> command exposes container ports from the host.<\/li>\nENV<\/code> is responsible for defining environment variables that are available in the container. You can declare multiple ENV instructions within the Dockerfile. You can use the env<\/code> command inside the container to view each of the environment variables.<\/li>\nADD<\/code> instruction copies files or folders from a local or remote source and adds them to the container’s file system. If used to copy local files, those must be in the working directory. ADD<\/code> instruction unpacks local .tar files to the destination image directory.<\/li>\nCOPY<\/code> copies files from the working directory and adds them to the container’s file system. It is not possible to copy a remote file using its URL with this Dockerfile instruction.<\/li>\nUSER<\/code> specifies the username or the UID to use when running the container image for the RUN<\/code>, CMD<\/code>, and ENTRYPOINT<\/code> instructions. It is a good practice to define a different user other than root for security reasons.<\/li>\nENTRYPOINT<\/code> specifies the default command to execute when the image runs in a container. If omitted, the default ENTRYPOINT is \/bin\/sh -c.<\/li>\nCMD<\/code> provides the default arguments for the ENTRYPOINT instruction. If the default ENTRYPOINT applies (\/bin\/sh -c), then CMD forms an executable command and parameters that run at container start.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"One method of creating container images has been covered so far: create a container, modify it to meet the requirements of the application to run in it, and then commit the changes to an image. This option, although straightforward, is only suitable for using or testing very specific changes. It does not follow best software … <\/p>\n