IuriiO Notebook
  • Broken Code Notebook
  • Architecture and Design
    • Architectural Decision Records
    • Trade-off Analysis
    • Data Decomposition Drivers
    • Selecting a Database Type
    • Service Granularity
    • Consumer-driven Contracts
  • Cloud
    • AWS
      • Resources
      • Compute
        • EC2
        • Batch
        • ECS & ECR
        • Elastic Beanstalk
      • Storage & Data Management
        • S3
        • Storage Gateway
        • RDS
        • DynamoDB
        • ElastiCache
        • Redshift
        • EBS
        • EFS
        • FSx
        • Snowball
        • Athena
        • Encryption and Downtime
        • Untitled
      • Security & Compliance
        • IAM
        • Web Identity Federation
        • Organizations
        • Service Catalog
        • Tags and Resource Groups
        • STS
        • KMS
        • GuardDuty
        • Compliance
        • Marketplace Security Products
        • DDOS
        • Compliance Frameworks
      • High Availability
        • Global Infrastructure
        • Disaster recovery
        • Elastic Load Balancers
        • Untitled
      • Monitoring & Reporting
        • Cost Explorer
        • CloudWatch
        • Systems Manager
        • Config
        • CloudTrail
        • Cost control
        • Untitled
      • Networking
        • Networking 101
        • Route53
        • CloudFront
        • VPC
        • DirectConnect
        • WAF
        • Shield
        • Global Accelerator
      • Deployment & Provisioning
        • Untitled
        • Untitled
      • Automation & Optimization
        • CloudFormation
          • Links
          • Github resources
          • YAML 101
          • Videos
        • OpsWorks
        • Untitled
      • Application Services
        • SQS
        • SWF
        • SNS
        • Untitled
      • Serverless
        • Lambda
        • API Gateway
        • DynamoDB
        • SAM
        • Untitled
      • Well-Architected Framework
    • Azure
      • Tools
      • Organization & Management
      • Authentication & Authorization
      • Compute
      • Networking
      • Storage
      • Databases
      • Security
      • Privacy, Compliance & Trust
      • Cost Management
  • Containers & Services
    • Docker
      • Useful Links
      • Containers
      • Images
      • Dockerfile
      • System
      • Compose
      • Swarm
      • Docker & NodeJS
    • Kubernetes
      • Useful Links
      • Introduction
      • Getting started
      • Exposing containers
      • Kubernetes Management Techniques
        • Declarative YAML
      • Labels and Annotations
      • Storage in Kubernetes
      • Ingress Controller
      • CRD's and The Operator Pattern
      • Kubernetes Dashboard
      • Kubectl Namespaces and Context
  • Frontend
    • Resources
    • Design
      • Search experience
Powered by GitBook
On this page
  • Instructions
  • Sample Dockerfile
  • Building image

Was this helpful?

  1. Containers & Services
  2. Docker

Dockerfile

What Dockerfile is and common commands

PreviousImagesNextSystem

Last updated 5 years ago

Was this helpful?

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.

Instructions

  • 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

  • ENV - The ENV instruction sets the environment variable

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

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

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

  • COPY - The COPY instruction copies new files or directories from <src> and adds them to the filesystem of the container at the path <dest>

  • WORKDIR - The WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions that follow it in the Dockerfile. If the WORKDIR doesn’t exist, it will be created even if it’s not used in any subsequent Dockerfile instruction.

  • CMD - Specifies the command to run when container starts. If you would like your container to run the same executable every time, then you should consider using ENTRYPOINT in combination with CMD

Order of instructions in Dockerfile matters, as all commands on Dockerfile as executed sequentially, and some instruction resulting in its own layer, increasing image size as a result. Instructions that are changing more frequently should be placed closer to the bottom, and instructions that don't change or change less frequently, should be placed higher in the Dockerfile. When one of the instruction changes, COPY for instance, all subsequent instructions must be re-run.

For more best practices see:

Sample Dockerfile

# From Node 10, Alpine 3.9 OS.
FROM node:10-alpine3.9

# Current directory.
WORKDIR /usr/app

# Install NPM packages
COPY ./package.json ./
RUN npm install

# Copy app files
COPY ./*.js ./

# Run app
CMD ["npm", "start"]

Building image

▶️
▶️
▶️
▶️
▶️
▶️
▶️
▶️
Dockerfile best practices