947b07
% "CONTAINERFILE" "5" "Aug 2021" "" "Container User Manuals"
947b07
947b07
# NAME
947b07
947b07
Containerfile(Dockerfile) - automate the steps of creating a container image
947b07
947b07
# INTRODUCTION
947b07
947b07
The **Containerfile** is a configuration file that automates the steps of creating a container image. It is similar to a Makefile. Container engines (Podman, Buildah, Docker) read instructions from the **Containerfile** to automate the steps otherwise performed manually to create an image. To build an image, create a file called **Containerfile**.
947b07
947b07
The **Containerfile** describes the steps taken to assemble the image. When the
947b07
**Containerfile** has been created, call the `buildah bud`, `podman build`, `docker build` command,
947b07
using the path of context directory that contains **Containerfile** as the argument. Podman and Buildah default to **Containerfile** and will fall back to **Dockerfile**. Docker only will search for **Dockerfile** in the context directory.
947b07
947b07
947b07
**Dockerfile** is an alternate name for the same object.  **Containerfile** and **Dockerfile** support the same syntax.
947b07
947b07
# SYNOPSIS
947b07
947b07
INSTRUCTION arguments
947b07
947b07
For example:
947b07
947b07
  FROM image
947b07
947b07
# DESCRIPTION
947b07
947b07
A Containerfile is a file that automates the steps of creating a container image.
947b07
A Containerfile is similar to a Makefile.
947b07
947b07
# USAGE
947b07
947b07
  ```
947b07
  buildah bud .
947b07
  podman build .
947b07
  ```
947b07
947b07
  -- Runs the steps and commits them, building a final image.
947b07
  The path to the source repository defines where to find the context of the
947b07
  build.
947b07
947b07
  ```
947b07
  buildah bud -t repository/tag .
947b07
  podman build -t repository/tag .
947b07
  ```
947b07
947b07
  -- specifies a repository and tag at which to save the new image if the build
947b07
  succeeds. The container engine runs the steps one-by-one, committing the result
947b07
  to a new image if necessary, before finally outputting the ID of the new
947b07
  image.
947b07
947b07
  Container engines re-use intermediate images whenever possible. This significantly
947b07
  accelerates the *build* process.
947b07
947b07
# FORMAT
947b07
947b07
  `FROM image`
947b07
947b07
  `FROM image:tag`
947b07
947b07
  `FROM image@digest`
947b07
947b07
  -- The **FROM** instruction sets the base image for subsequent instructions. A
947b07
  valid Containerfile must have either **ARG** or *FROM** as its first instruction.
947b07
  If **FROM** is not the first instruction in the file, it may only be preceded by
947b07
  one or more ARG instructions, which declare arguments that are used in the next FROM line in the Containerfile.
947b07
  The image can be any valid image. It is easy to start by pulling an image from the public
947b07
  repositories.
947b07
947b07
  -- **FROM** must appear at least once in the Containerfile.
947b07
947b07
  -- **FROM** The first **FROM** command must come before all other instructions in
947b07
  the Containerfile except **ARG**
947b07
947b07
  -- **FROM** may appear multiple times within a single Containerfile in order to create
947b07
  multiple images. Make a note of the last image ID output by the commit before
947b07
  each new **FROM** command.
947b07
947b07
  -- If no tag is given to the **FROM** instruction, container engines apply the
947b07
  `latest` tag. If the used tag does not exist, an error is returned.
947b07
947b07
  -- If no digest is given to the **FROM** instruction, container engines apply the
947b07
  `latest` tag. If the used tag does not exist, an error is returned.
947b07
947b07
**MAINTAINER**
947b07
  -- **MAINTAINER** sets the Author field for the generated images.
947b07
  Useful for providing users with an email or url for support.
947b07
947b07
**RUN**
947b07
  -- **RUN** has two forms:
947b07
947b07
  ```
947b07
  # the command is run in a shell - /bin/sh -c
947b07
  RUN <command>
947b07
947b07
  # Executable form
947b07
  RUN ["executable", "param1", "param2"]
947b07
  ```
947b07
**RUN mounts**
947b07
947b07
**--mount**=*type=TYPE,TYPE-SPECIFIC-OPTION[,...]*
947b07
947b07
Attach a filesystem mount to the container
947b07
947b07
Current supported mount TYPES are bind, cache, secret and tmpfs.
947b07
947b07
       e.g.
947b07
947b07
       mount=type=bind,source=/path/on/host,destination=/path/in/container
947b07
947b07
       mount=type=tmpfs,tmpfs-size=512M,destination=/path/in/container
947b07
947b07
       mount=type=secret,id=mysecret cat /run/secrets/mysecret
947b07
947b07
       Common Options:
947b07
947b07
              · src, source: mount source spec for bind and volume. Mandatory for bind. If `from` is specified, `src` is the subpath in the `from` field.
947b07
947b07
              · dst, destination, target: mount destination spec.
947b07
eec041
              · ro, read-only: true (default) or false.
947b07
947b07
       Options specific to bind:
947b07
947b07
              · bind-propagation: shared, slave, private, rshared, rslave, or rprivate(default). See also mount(2).
947b07
947b07
              . bind-nonrecursive: do not setup a recursive bind mount.  By default it is recursive.
947b07
947b07
              · from: stage or image name for the root of the source. Defaults to the build context.
947b07
eec041
              · rw, read-write: allows writes on the mount.
eec041
947b07
       Options specific to tmpfs:
947b07
947b07
              · tmpfs-size: Size of the tmpfs mount in bytes. Unlimited by default in Linux.
947b07
947b07
              · tmpfs-mode: File mode of the tmpfs in octal. (e.g. 700 or 0700.) Defaults to 1777 in Linux.
947b07
947b07
              · tmpcopyup: Path that is shadowed by the tmpfs mount is recursively copied up to the tmpfs itself.
947b07
947b07
	Options specific to cache:
947b07
947b07
              · id: Create a separate cache directory for a particular id.
947b07
947b07
              · mode: File mode for new cache directory in octal. Default 0755.
947b07
947b07
              · ro, readonly: read only cache if set.
947b07
947b07
              · uid: uid for cache directory.
947b07
947b07
              · gid: gid for cache directory.
947b07
947b07
              · from: stage name for the root of the source. Defaults to host cache directory.
947b07
eec041
              · rw, read-write: allows writes on the mount.
eec041
947b07
947b07
**RUN Secrets**
947b07
947b07
The RUN command has a feature to allow the passing of secret information into the image build. These secrets files can be used during the RUN command but are not committed to the final image. The `RUN` command supports the `--mount` option to identify the secret file. A secret file from the host is mounted into the container while the image is being built.
947b07
947b07
Container engines pass secret the secret file into the build using the `--secret` flag.
947b07
947b07
**--mount**=*type=secret,TYPE-SPECIFIC-OPTION[,...]*
947b07
947b07
- `id` is the identifier for the secret passed into the `buildah bud --secret` or `podman build --secret`. This identifier is associated with the RUN --mount identifier to use in the Containerfile.
947b07
947b07
- `dst`|`target`|`destination` rename the secret file to a specific file in the Containerfile RUN command to use.
947b07
947b07
- `type=secret` tells the --mount command that it is mounting in a secret file
947b07
947b07
```
947b07
# shows secret from default secret location:
947b07
RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret
947b07
```
947b07
```
947b07
# shows secret from custom secret location:
947b07
RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar
947b07
```
947b07
The secret needs to be passed to the build using the --secret flag. The final image built does not container the secret file:
947b07
947b07
```
947b07
 buildah bud --no-cache --secret id=mysecret,src=mysecret.txt .
947b07
```
947b07
947b07
  -- The **RUN** instruction executes any commands in a new layer on top of the current
947b07
  image and commits the results. The committed image is used for the next step in
947b07
  Containerfile.
947b07
947b07
  -- Layering **RUN** instructions and generating commits conforms to the core
947b07
  concepts of container engines where commits are cheap and containers can be created from
947b07
  any point in the history of an image. This is similar to source control.  The
947b07
  exec form makes it possible to avoid shell string munging. The exec form makes
947b07
  it possible to **RUN** commands using a base image that does not contain `/bin/sh`.
947b07
947b07
  Note that the exec form is parsed as a JSON array, which means that you must
947b07
  use double-quotes (") around words, not single-quotes (').
947b07
947b07
**CMD**
947b07
  -- **CMD** has three forms:
947b07
947b07
  ```
947b07
  # Executable form
947b07
  CMD ["executable", "param1", "param2"]`
947b07
947b07
  # Provide default arguments to ENTRYPOINT
947b07
  CMD ["param1", "param2"]`
947b07
947b07
  # the command is run in a shell - /bin/sh -c
947b07
  CMD command param1 param2
947b07
  ```
947b07
947b07
  -- There should be only one **CMD** in a Containerfile. If more than one **CMD** is listed, only
947b07
  the last **CMD** takes effect.
947b07
  The main purpose of a **CMD** is to provide defaults for an executing container.
947b07
  These defaults may include an executable, or they can omit the executable. If
947b07
  they omit the executable, an **ENTRYPOINT** must be specified.
947b07
  When used in the shell or exec formats, the **CMD** instruction sets the command to
947b07
  be executed when running the image.
947b07
  If you use the shell form of the **CMD**, the `<command>` executes in `/bin/sh -c`:
947b07
947b07
  Note that the exec form is parsed as a JSON array, which means that you must
947b07
  use double-quotes (") around words, not single-quotes (').
947b07
947b07
  ```
947b07
  FROM ubuntu
947b07
  CMD echo "This is a test." | wc -
947b07
  ```
947b07
947b07
  -- If you run **command** without a shell, then you must express the command as a
947b07
  JSON array and give the full path to the executable. This array form is the
947b07
  preferred form of **CMD**. All additional parameters must be individually expressed
947b07
  as strings in the array:
947b07
947b07
  ```
947b07
  FROM ubuntu
947b07
  CMD ["/usr/bin/wc","--help"]
947b07
  ```
947b07
947b07
  -- To make the container run the same executable every time, use **ENTRYPOINT** in
947b07
  combination with **CMD**.
947b07
  If the user specifies arguments to `podman run` or `docker run`, the specified commands
947b07
  override the default in **CMD**.
947b07
  Do not confuse **RUN** with **CMD**. **RUN** runs a command and commits the result.
947b07
  **CMD** executes nothing at build time, but specifies the intended command for
947b07
  the image.
947b07
947b07
**LABEL**
947b07
  -- `LABEL <key>=<value> [<key>=<value> ...]`or
947b07
  ```
947b07
  LABEL <key>[ <value>]
947b07
  LABEL <key>[ <value>]
947b07
  ...
947b07
  ```
947b07
  The **LABEL** instruction adds metadata to an image. A **LABEL** is a
947b07
  key-value pair. To specify a **LABEL** without a value, simply use an empty
947b07
  string. To include spaces within a **LABEL** value, use quotes and
947b07
  backslashes as you would in command-line parsing.
947b07
947b07
  ```
947b07
  LABEL com.example.vendor="ACME Incorporated"
947b07
  LABEL com.example.vendor "ACME Incorporated"
947b07
  LABEL com.example.vendor.is-beta ""
947b07
  LABEL com.example.vendor.is-beta=
947b07
  LABEL com.example.vendor.is-beta=""
947b07
  ```
947b07
947b07
  An image can have more than one label. To specify multiple labels, separate
947b07
  each key-value pair by a space.
947b07
947b07
  Labels are additive including `LABEL`s in `FROM` images. As the system
947b07
  encounters and then applies a new label, new `key`s override any previous
947b07
  labels with identical keys.
947b07
947b07
  To display an image's labels, use the `buildah inspect` command.
947b07
947b07
**EXPOSE**
947b07
  -- `EXPOSE <port> [<port>...]`
947b07
  The **EXPOSE** instruction informs the container engine that the container listens on the
947b07
  specified network ports at runtime. The container engine uses this information to
947b07
  interconnect containers using links and to set up port redirection on the host
947b07
  system.
947b07
947b07
**ENV**
947b07
  -- `ENV <key> <value>`
947b07
  The **ENV** instruction sets the environment variable <key> to
947b07
  the value `<value>`. This value is passed to all future
947b07
  **RUN**, **ENTRYPOINT**, and **CMD** instructions. This is
947b07
  functionally equivalent to prefixing the command with `<key>=<value>`.  The
947b07
  environment variables that are set with **ENV** persist when a container is run
947b07
  from the resulting image. Use `podman inspect` to inspect these values, and
947b07
  change them using `podman run --env <key>=<value>`.
947b07
947b07
  Note that setting "`ENV DEBIAN_FRONTEND=noninteractive`" may cause
947b07
  unintended consequences, because it will persist when the container is run
947b07
  interactively, as with the following command: `podman run -t -i image bash`
947b07
947b07
**ADD**
947b07
  -- **ADD** has two forms:
947b07
947b07
  ```
947b07
  ADD <src> <dest>
947b07
947b07
  # Required for paths with whitespace
947b07
  ADD ["<src>",... "<dest>"]
947b07
  ```
947b07
947b07
  The **ADD** instruction copies new files, directories
947b07
  or remote file URLs to the filesystem of the container at path `<dest>`.
947b07
  Multiple `<src>` resources may be specified but if they are files or directories
947b07
  then they must be relative to the source directory that is being built
947b07
  (the context of the build). The `<dest>` is the absolute path, or path relative
947b07
  to **WORKDIR**, into which the source is copied inside the target container.
947b07
  If the `<src>` argument is a local file in a recognized compression format
947b07
  (tar, gzip, bzip2, etc) then it is unpacked at the specified `<dest>` in the
947b07
  container's filesystem.  Note that only local compressed files will be unpacked,
947b07
  i.e., the URL download and archive unpacking features cannot be used together.
947b07
  All new directories are created with mode 0755 and with the uid and gid of **0**.
947b07
947b07
**COPY**
947b07
  -- **COPY** has two forms:
947b07
947b07
  ```
947b07
  COPY <src> <dest>
947b07
947b07
  # Required for paths with whitespace
947b07
  COPY ["<src>",... "<dest>"]
947b07
  ```
947b07
947b07
  The **COPY** instruction copies new files from `<src>` and
947b07
  adds them to the filesystem of the container at path <dest>. The `<src>` must be
947b07
  the path to a file or directory relative to the source directory that is
947b07
  being built (the context of the build) or a remote file URL. The `<dest>` is an
947b07
  absolute path, or a path relative to **WORKDIR**, into which the source will
947b07
  be copied inside the target container. If you **COPY** an archive file it will
947b07
  land in the container exactly as it appears in the build context without any
947b07
  attempt to unpack it.  All new files and directories are created with mode **0755**
947b07
  and with the uid and gid of **0**.
947b07
947b07
**ENTRYPOINT**
947b07
  -- **ENTRYPOINT** has two forms:
947b07
947b07
  ```
947b07
  # executable form
947b07
  ENTRYPOINT ["executable", "param1", "param2"]`
947b07
947b07
  # run command in a shell - /bin/sh -c
947b07
  ENTRYPOINT command param1 param2
947b07
  ```
947b07
947b07
  -- An **ENTRYPOINT** helps you configure a
947b07
  container that can be run as an executable. When you specify an **ENTRYPOINT**,
947b07
  the whole container runs as if it was only that executable.  The **ENTRYPOINT**
947b07
  instruction adds an entry command that is not overwritten when arguments are
947b07
  passed to `podman run`. This is different from the behavior of **CMD**. This allows
947b07
  arguments to be passed to the entrypoint, for instance `podman run <image> -d`
947b07
  passes the -d argument to the **ENTRYPOINT**.  Specify parameters either in the
947b07
  **ENTRYPOINT** JSON array (as in the preferred exec form above), or by using a **CMD**
947b07
  statement.  Parameters in the **ENTRYPOINT** are not overwritten by the `podman run` arguments.  Parameters specified via **CMD** are overwritten by `podman run` arguments.  Specify a plain string for the **ENTRYPOINT**, and it will execute in
947b07
  `/bin/sh -c`, like a **CMD** instruction:
947b07
947b07
  ```
947b07
  FROM ubuntu
947b07
  ENTRYPOINT wc -l -
947b07
  ```
947b07
947b07
  This means that the Containerfile's image always takes stdin as input (that's
947b07
  what "-" means), and prints the number of lines (that's what "-l" means). To
947b07
  make this optional but default, use a **CMD**:
947b07
947b07
  ```
947b07
  FROM ubuntu
947b07
  CMD ["-l", "-"]
947b07
  ENTRYPOINT ["/usr/bin/wc"]
947b07
  ```
947b07
947b07
**VOLUME**
947b07
  -- `VOLUME ["/data"]`
947b07
  The **VOLUME** instruction creates a mount point with the specified name and marks
947b07
  it as holding externally-mounted volumes from the native host or from other
947b07
  containers.
947b07
947b07
**USER**
947b07
  -- `USER daemon`
947b07
  Sets the username or UID used for running subsequent commands.
947b07
947b07
  The **USER** instruction can optionally be used to set the group or GID. The
947b07
  following examples are all valid:
947b07
  USER [user | user:group | uid | uid:gid | user:gid | uid:group ]
947b07
947b07
  Until the **USER** instruction is set, instructions will be run as root. The USER
947b07
  instruction can be used any number of times in a Containerfile, and will only affect
947b07
  subsequent commands.
947b07
947b07
**WORKDIR**
947b07
  -- `WORKDIR /path/to/workdir`
947b07
  The **WORKDIR** instruction sets the working directory for the **RUN**, **CMD**,
947b07
  **ENTRYPOINT**, **COPY** and **ADD** Containerfile commands that follow it. It can
947b07
  be used multiple times in a single Containerfile. Relative paths are defined
947b07
  relative to the path of the previous **WORKDIR** instruction. For example:
947b07
947b07
  ```
947b07
  WORKDIR /a
947b07
  WORKDIR b
947b07
  WORKDIR c
947b07
  RUN pwd
947b07
  ```
947b07
947b07
  In the above example, the output of the **pwd** command is **a/b/c**.
947b07
947b07
**ARG**
947b07
   -- ARG <name>[=<default value>]
947b07
947b07
  The `ARG` instruction defines a variable that users can pass at build-time to
947b07
  the builder with the `podman build` and `buildah build` commands using the
947b07
  `--build-arg <varname>=<value>` flag. If a user specifies a build argument that
947b07
  was not defined in the Containerfile, the build outputs a warning.
947b07
947b07
  Note that a second FROM in a Containerfile sets the values associated with an
947b07
  Arg variable to nil and they must be reset if they are to be used later in
947b07
  the Containerfile
947b07
947b07
```
947b07
  [Warning] One or more build-args [foo] were not consumed
947b07
  ```
947b07
947b07
  The Containerfile author can define a single variable by specifying `ARG` once or many
947b07
  variables by specifying `ARG` more than once. For example, a valid Containerfile:
947b07
947b07
  ```
947b07
  FROM busybox
947b07
  ARG user1
947b07
  ARG buildno
947b07
  ...
947b07
  ```
947b07
947b07
  A Containerfile author may optionally specify a default value for an `ARG` instruction:
947b07
947b07
  ```
947b07
  FROM busybox
947b07
  ARG user1=someuser
947b07
  ARG buildno=1
947b07
  ...
947b07
  ```
947b07
947b07
  If an `ARG` value has a default and if there is no value passed at build-time, the
947b07
  builder uses the default.
947b07
947b07
  An `ARG` variable definition comes into effect from the line on which it is
947b07
  defined in the `Containerfile` not from the argument's use on the command-line or
947b07
  elsewhere.  For example, consider this Containerfile:
947b07
947b07
  ```
947b07
  1 FROM busybox
947b07
  2 USER ${user:-some_user}
947b07
  3 ARG user
947b07
  4 USER $user
947b07
  ...
947b07
  ```
947b07
  A user builds this file by calling:
947b07
947b07
  ```
947b07
  $ podman build --build-arg user=what_user Containerfile
947b07
  ```
947b07
947b07
  The `USER` at line 2 evaluates to `some_user` as the `user` variable is defined on the
947b07
  subsequent line 3. The `USER` at line 4 evaluates to `what_user` as `user` is
947b07
  defined and the `what_user` value was passed on the command line. Prior to its definition by an
947b07
  `ARG` instruction, any use of a variable results in an empty string.
947b07
947b07
  > **Warning:** It is not recommended to use build-time variables for
947b07
  >  passing secrets like github keys, user credentials etc. Build-time variable
947b07
  >  values are visible to any user of the image with the `podman history` command.
947b07
947b07
  You can use an `ARG` or an `ENV` instruction to specify variables that are
947b07
  available to the `RUN` instruction. Environment variables defined using the
947b07
  `ENV` instruction always override an `ARG` instruction of the same name. Consider
947b07
  this Containerfile with an `ENV` and `ARG` instruction.
947b07
947b07
  ```
947b07
  1 FROM ubuntu
947b07
  2 ARG CONT_IMG_VER
947b07
  3 ENV CONT_IMG_VER=v1.0.0
947b07
  4 RUN echo $CONT_IMG_VER
947b07
  ```
947b07
  Then, assume this image is built with this command:
947b07
947b07
  ```
947b07
  $ podman build --build-arg CONT_IMG_VER=v2.0.1 Containerfile
947b07
  ```
947b07
947b07
  In this case, the `RUN` instruction uses `v1.0.0` instead of the `ARG` setting
947b07
  passed by the user:`v2.0.1` This behavior is similar to a shell
947b07
  script where a locally scoped variable overrides the variables passed as
947b07
  arguments or inherited from environment, from its point of definition.
947b07
947b07
  Using the example above but a different `ENV` specification you can create more
947b07
  useful interactions between `ARG` and `ENV` instructions:
947b07
947b07
  ```
947b07
  1 FROM ubuntu
947b07
  2 ARG CONT_IMG_VER
947b07
  3 ENV CONT_IMG_VER=${CONT_IMG_VER:-v1.0.0}
947b07
  4 RUN echo $CONT_IMG_VER
947b07
  ```
947b07
947b07
  Unlike an `ARG` instruction, `ENV` values are always persisted in the built
947b07
  image. Consider a `podman build` without the --build-arg flag:
947b07
947b07
  ```
947b07
  $ podman build Containerfile
947b07
  ```
947b07
947b07
  Using this Containerfile example, `CONT_IMG_VER` is still persisted in the image but
947b07
  its value would be `v1.0.0` as it is the default set in line 3 by the `ENV` instruction.
947b07
947b07
  The variable expansion technique in this example allows you to pass arguments
947b07
  from the command line and persist them in the final image by leveraging the
947b07
  `ENV` instruction. Variable expansion is only supported for [a limited set of
947b07
  Containerfile instructions.](#environment-replacement)
947b07
947b07
  Container engines have a set of predefined `ARG` variables that you can use without a
947b07
  corresponding `ARG` instruction in the Containerfile.
947b07
947b07
  * `HTTP_PROXY`
947b07
  * `http_proxy`
947b07
  * `HTTPS_PROXY`
947b07
  * `https_proxy`
947b07
  * `FTP_PROXY`
947b07
  * `ftp_proxy`
947b07
  * `NO_PROXY`
947b07
  * `no_proxy`
947b07
  * `ALL_PROXY`
947b07
  * `all_proxy`
947b07
947b07
  To use these, pass them on the command line using `--build-arg` flag, for
947b07
  example:
947b07
947b07
  ```
947b07
  $ podman build --build-arg HTTPS_PROXY=https://my-proxy.example.com .
947b07
  ```
947b07
947b07
**ONBUILD**
947b07
  -- `ONBUILD [INSTRUCTION]`
947b07
  The **ONBUILD** instruction adds a trigger instruction to an image. The
947b07
  trigger is executed at a later time, when the image is used as the base for
947b07
  another build. Container engines execute the trigger in the context of the downstream
947b07
  build, as if the trigger existed immediately after the **FROM** instruction in
947b07
  the downstream Containerfile.
947b07
947b07
  You can register any build instruction as a trigger. A trigger is useful if
947b07
  you are defining an image to use as a base for building other images. For
947b07
  example, if you are defining an application build environment or a daemon that
947b07
  is customized with a user-specific configuration.
947b07
947b07
  Consider an image intended as a reusable python application builder. It must
947b07
  add application source code to a particular directory, and might need a build
947b07
  script called after that. You can't just call **ADD** and **RUN** now, because
947b07
  you don't yet have access to the application source code, and it is different
947b07
  for each application build.
947b07
947b07
  -- Providing application developers with a boilerplate Containerfile to copy-paste
947b07
  into their application is inefficient, error-prone, and
947b07
  difficult to update because it mixes with application-specific code.
947b07
  The solution is to use **ONBUILD** to register instructions in advance, to
947b07
  run later, during the next build stage.
947b07
947b07
## SEE ALSO
947b07
buildah(1), podman(1), docker(1)
947b07
947b07
# HISTORY
947b07
```
947b07
May 2014, Compiled by Zac Dover (zdover at redhat dot com) based on docker.com Dockerfile documentation.
947b07
Feb 2015, updated by Brian Goff (cpuguy83@gmail.com) for readability
947b07
Sept 2015, updated by Sally O'Malley (somalley@redhat.com)
947b07
Oct 2016, updated by Addam Hardy (addam.hardy@gmail.com)
947b07
Aug 2021, converted Dockerfile man page to Containerfile by Dan Walsh (dwalsh@redhat.com)
947b07
```