Introduction
The container landscape has changed a fair bit since Docker changed the way we packaged and deployed applications. While Docker is still one of the most widely used options today, some compelling alternatives are well worth considering that might better fit your needs. Let me share my journey to explore these alternatives and what I've learned along the way.
The Evolution of Container Runtimes
timeline
title Evolution of Container Technology
2013 : Docker Release
: Unified Container Toolchain
: Built-in Registry & CLI
2015 : OCI Formation
: Image Specification
: Runtime Standards
2016 : containerd
: Kubernetes Runtime
: Performance Focus
2017 : BuildKit
: Concurrent Builds
: Multi-platform Support
2018 : Podman 1.0
: Daemonless Design
: Rootless Containers
2020 : Modern Era
: Desktop Alternatives
: Multi-Runtime Support
} />
When Docker first came into this world, that was the technology that was able to collect in one tool functions of container creation and managing with runtime. This was somewhat revolutionary, but then with time, as usage for containers matured, it became evident that teams needed particular tools for particular aspects in containerization, and that is what led to alternative specialization.
Understanding Container Standards
The container ecosystem is based on open standards - most notably the [Open Container Initiative (OCI)]. That standardizes:
graph TD
A[OCI Standards] --> B[Image Format]
A --> C[Runtime Spec]
A --> D[Distribution Spec]
B --> E[How images are structured]
C --> F[How containers are executed]
D --> G[How images are distributed]
This standardization means you are not being locked into any particular tool. You can build your images in one tool and run them in another. This gives you the choice to utilize the best tool to get a particular job done.
Podman: The Daemon-free Alternative
In the intensity of working as a DevOps engineer with the container, I have found Podman to be a game-changer in teams that take the security aspect seriously-that means avoiding root privileges. It's daemonless compared with Docker, which is a big architectural change. Daemonless approach just magically changes how teams do container security in production environments.
Security through Designs
The first time I had switched to Podman for a security-conscious client, this daemonless architecture made total sense. Each container runs with your user permissions - not as a privileged daemon:
Running a container as your user
podman run nginx # No root, no daemon
# Even rootless containers can bind to privileged ports
podman run -p 80:80 nginx # Works without root!
Kubernetes-like Experience on Desktop
But what was a really pleasant surprise was the pod-native support in Podman. It allows trying out Kubernetes-like concepts on a local system:
# Create a pod with multi containers
podman pod create --name my-app
podman run --pod my-app -d nginx
podman run --pod my-app -d redis
containerd: The Kubernetes Runtime
Having operated large Kubernetes clusters, one learns to love the focused approach of containerd. A light-weight, high-performance container runtime, it powers a lot of container platforms, including indirectly, Kubernetes. From my experience, containerd really does one thing and does it well: it runs containers efficiently.
Platform Building
This focus of containerd shines when looking at building container platforms:
// Simple integration with containerd
client, err := containerd.New("/run/containerd/containerd.sock")
container, err := client.NewContainer(ctx, "nginx",
containerd.WithNewSnapshot("nginx", image),
containerd.WithNewSpec(oci.WithImageConfig(image))
BuildKit: Reimagining Container Building
I remember when container builds were slow and not really efficient, and were usually a bottleneck of our CI/CD pipelines. That is until I discovered BuildKit and my life changed. BuildKit is the next-generation builder engine for Docker, but it can also be used independently.
Concurrent and Efficient Builds
The best thing about BuildKit is how it parallelizes the steps of building:
Dockerfile
# These stages build concurrently
FROM golang:1.21 AS backend
COPY backend.
RUN go build
FROM node:18 AS frontend
COPY frontend.
RUN npm build
FROM alpine
COPY --from=backend /app/backend.
COPY --from=frontend /app/dist ./dist
LXC/LXD: System Containers
Working with legacy applications that needed full system access taught me that a different way to do containerization is by using LXC/LXD. The focus in system containers, rather than application containers, can be thought of like a light VM rather than what most consider the typical container.
Development Environments
LXD does great at isolated development environments:
# Create a full Ubuntu environment
lxc launch ubuntu:20.04 dev-env
lxc exec dev-env -- sudo apt install python3
# Share your project folder
lxc config device add dev-env code disk source=/path/to/code path=/code
Monitoring GitHub Actions Workflows
CICube is a GitHub Actions monitoring tool that provides you with detailed insights into your workflows to further optimize your CI/CD pipeline. With CICube, you will be able to track your workflow runs, understand where the bottlenecks are, and tease out the best from your build times. Go to cicube.io now and create a free account to better optimize your GitHub Actions workflows!
Conclusion
Through my journey of exploring alternatives to Docker, it has been learned that the container ecosystem is a lot more to do with selecting the right tool for your needs opposed to finding a perfect replacement. Podman's rootless approach brings security without sacrifice, Containerd's simplicity lends itself perfectly in Kubernetes environments, BuildKit transforms how we build images, and LXC/LXD offers a unique take on system containerization.
The cool thing about modern container tools is in the way they interoperate: You can have efficient builds with BuildKit, run them with Podman in development, and deploy to Containerd in production. This flexibility, enabled by OCI standards, lets us create workflows that truly fit our needs rather than adapting our needs to fit a single tool.
Top comments (0)