Docker - Instruction Commands

Docker - Common Dockerfile Instructions

Dockerfiles use a set of specific instructions to define how an image is built. Understanding these commands is key to creating efficient and effective Docker images.

Here are some of the most common instructions:

FROM

Specifies the base image for your build. Every Dockerfile must start with a FROM instruction (unless using multi-stage builds with multiple FROM lines).

FROM ubuntu:22.04
FROM python:3.9-slim

RUN

Executes commands in a new layer on top of the current image during the build process. Commonly used for installing packages, compiling code, etc.

# Shell form
RUN apt-get update && apt-get install -y curl

# Exec form (preferred for avoiding shell string munging)
RUN ["apt-get", "update"]

Best practice: Chain related commands (like apt-get update and apt-get install) and clean up in the same RUN instruction using && to minimize image layers.

CMD

Provides defaults for an executing container. It specifies the command to run when the container starts. There can only be one CMD instruction in a Dockerfile. If multiple CMD instructions exist, only the last one takes effect.

If you provide arguments to docker run <image> [command], they will override the default CMD.

# Exec form (preferred)
CMD ["python", "app.py"]

# Shell form
CMD echo "Default command executed"

ENTRYPOINT

Configures a container that will run as an executable. It’s similar to CMD, but commands passed to docker run <image> [command] are appended as arguments to the ENTRYPOINT.

This is useful for creating images that act like a specific command-line tool.

# Exec form (preferred)
ENTRYPOINT ["redis-server"]

# Use ENTRYPOINT with CMD to provide default arguments
ENTRYPOINT ["ping"]
CMD ["localhost"]
# Running 'docker run <image>' executes 'ping localhost'
# Running 'docker run <image> google.com' executes 'ping google.com'

LABEL

Adds metadata to an image as key-value pairs. Useful for organization, automation, licensing information, etc. Replaces the deprecated MAINTAINER instruction.

LABEL maintainer="Your Name <you@example.com>"
LABEL version="1.0"
LABEL description="My awesome application image"

EXPOSE

Documents which ports the containerized application listens on at runtime. It does not actually publish the port; it serves as documentation for users and can be used by other tools.

EXPOSE 80
EXPOSE 8080/tcp

ENV

Sets environment variables within the image. These variables are available during the build process (after they are defined) and when containers are run from the image.

ENV APP_VERSION=1.1
ENV APP_HOME=/app
WORKDIR $APP_HOME # Use the variable later

COPY

Copies files or directories from the build context (your local machine) into the image’s filesystem.

# Copy a single file
COPY requirements.txt /app/

# Copy an entire directory
COPY src/ /app/src/

ADD

Similar to COPY, but with additional features like automatically extracting local tar archives and supporting URLs as a source. Best practice generally favors COPY unless you specifically need ADD’s extra features, as COPY is more transparent.

ADD https://example.com/file.tar.gz /tmp/
ADD app.tar.gz /app/

WORKDIR

Sets the working directory for subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions in the Dockerfile. If the directory doesn’t exist, it will be created.

WORKDIR /app
COPY . .
RUN make install
CMD ["./start-app"]

USER

Sets the user name (or UID) and optionally the group name (or GID) to use when running subsequent commands and for the final image runtime. Running containers as a non-root user is a security best practice.

RUN groupadd -r myuser && useradd -r -g myuser myuser
# ... copy application files and set permissions ...
USER myuser

VOLUME

Creates a mount point with the specified name and marks it as holding externally mounted volumes from the native host or other containers. Often used to designate directories for persistent data (like database files).

# Specify that /var/lib/mysql should be managed as a volume
VOLUME /var/lib/mysql

These are some of the most frequently used instructions. Refer to the official Dockerfile reference for a complete list and detailed explanations.