Time to Thank Dockerfiles for Their Service and Send Them on Their Way

Dockerfiles have been a mainstay of containerization for years, but as the industry evolves, so do the tools we rely on. While Dockerfiles are functional, they are also brittle, verbose, and challenging to test effectively. This article explores alternatives to Dockerfiles, including BuildKit, Buildah, and Packer, along with my ideal solution for container building.

The Problem with Dockerfiles

Dockerfiles get the job done but:

  • They lack flexibility.
  • Testing them effectively is a challenge.
  • They force developers into a rigid, imperative syntax.

What if we could move towards a declarative or API-driven approach that integrates seamlessly into existing CI/CD pipelines? Let’s explore some promising tools.

BuildKit

BuildKit, part of the Moby Project, offers a modern alternative to Docker’s default build system. It introduces LLB, an intermediate binary format that allows:

  • Concurrency in builds: Parallel execution of build steps.
  • Advanced caching: With --mount=type=cache, you can persist build caches between runs.
  • Secrets management: --mount=type=secret ensures secrets aren’t baked into images.

Strengths

  • Supports multiple frontends, including Dockerfile.
  • Enables SSH mounts for secure Git operations.
  • Offers a Go client for programmatic container building.

Drawbacks

  • Requires custom tooling for non-Dockerfile builds.
  • Limited ecosystem support outside Docker’s tooling.

If you’re building containers with Go and want to embrace modern features like granular caching, BuildKit is worth exploring. Check out their documentation for examples.

Buildah

Buildah, developed by Red Hat, focuses on scripting-based container builds. Unlike Dockerfiles, it allows:

  • Layer control: Start with an empty container and add layers incrementally.
  • Direct CLI manipulation: Buildah scripts provide more control over container internals.

Why Choose Buildah?

  • It integrates seamlessly with Podman, a popular Docker alternative.
  • It supports existing Dockerfiles while enabling script-based workflows.

Use Case

For teams transitioning from Docker but seeking more control over the build process, Buildah is an excellent middle ground.

PouchContainer

PouchContainer, an Alibaba-developed project, is a now-dormant but intriguing alternative. It introduced:

  • Rich containers: Designed for legacy applications requiring multiple processes.
  • API-driven builds: Containers could be created and managed via REST calls.
  • P2P container distribution: Through Alibaba’s Dragonfly.

Takeaway

While it’s no longer maintained, PouchContainer highlights the potential of API-first containerization. I’d love to see a modern iteration of this idea.

Packer

HashiCorp’s Packer is traditionally used for VM image creation but shines for containers when paired with:

  • Provisioners: Define container configurations using tools like Ansible or shell scripts.
  • Post-processors: Push built images to Docker registries.

Why It Works

Packer’s flexibility lets you reuse existing infrastructure-as-code workflows. For organizations heavily invested in Ansible, Puppet, or Chef, Packer provides a natural extension into containerization.

What’s the Best Option?

For Simplicity: Buildah

  • Great for small teams or projects.
  • Minimal setup with the flexibility of scripting.

For Scalability: BuildKit

  • Ideal for organizations seeking modern caching, concurrency, and secrets management.

For Existing IAC Workflows: Packer

  • Best for teams already using Ansible or similar tools.

Outstanding Questions

  1. Is there a library or abstraction layer for BuildKit that simplifies container building?
  2. Are there client libraries for Buildah, allowing interaction beyond shell scripts?
  3. Is there an actively maintained API-driven container builder like PouchContainer?