Find session:

History of Dockerfiles

  • Dockerfile is the instruction to create a Docker image.
  • Dockerfile is well documented
  • About a year ago, Docker no longer accepts patches to Dockerfile syntax
    • Dockerfile since has been frozen
    • Creates stability for legacy Dockerfiles
    • Not frozen forever, will accept bug fixes and adds non-essential commands

1.12 commands:


Dockerfiles are great

Has immense simplicity, readability, and flexibility.

IDEs also highlight, which is nice.

Dockerfile Problems

Get very complex with certain RUN commands.
Only two approaches for reusing, Inheritance (FROM X) and copy/paste.
Docket file is not the source of truth for your image. Docker commits can create issues when inheriting.
The number of Dockerfiles can become overwhelming, even for small/medium departments.
Inheriting multiple nested layers of Docker images can create problems when needing to change a fundamental image, and causes issues with refactoring.
Should Dockerfiles be center ally managed, or person-by-person basis?

Possible solutions

  • Generate Dockerfiles with a programming language.

    • Ability to use variables/logic to create dynamic Dockerfiles
    • JavaScript, Python, you name it, most languages can do it
    • PROS
      • Powerful Abstractions
      • Mature languages
    • CONS
      • Need to compile down to dockerfile
      • Everyone has their favorite language
  • Generate Dockerfile using tools


YAML based image builder following open container standards.


By Redhat, has a nice CLI for building images that can be exported to Docker.


Has a programming language to define the kind of image you need, has support for Dockerfile export. Complexity, bleh.

  • PROS
    • Powerful
  • CONS
    • OCI image spec not finalized
    • Higher barrier to entry than Dockerfile
    • Limited support for things like labels

Expand on Dockerfile


  • Reuses Docker binaries
  • Adds "Critical" features missing from Dockerfile
    • MOUNT: Allows mount container volumes are build time, instead of run time.
    • ATTACH: Jump into half built containers
    • TAG: Add a tag at the build process instead of run time.
  • Runs any Standard Dockerfile


  • Client side compilation.

Preprocessing Dockerfiles

Domain specific instructions
Creates the ability to create commands that run their own files.
Using a file called dockerfilepp, the file contains Dockerfile commands that contains the instruction you have written. Very useful for RUN commands that are re-used within an organization, or applications that are used constantly.

  • PROS
    • Simple and familiar
    • Great proving ground for upstream
  • CONS
    • Still line oriented
    • Limited tooling

The Future

  • Formal specification for Dockerfile
  • RUN, FROM, COPY, ect, as first class API primitives
  • Oppinionated workflow tooling around image build
  • Shared libraries and support for pre-processors
  • Complimentary tools that take an organization-wide view of image building
  • More tools for building Dockerfiles