Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI
The Moment Someone Finally Explained Containers to Me
When IBM acquired Red Hat, my world changed overnight. Suddenly everyone around me was talking about containers. Kubernetes. Pods. Orchestration. I was nodding along in meetings while internally having absolutely no idea what any of it meant.
My background was in supply chain and logistics. I understood how physical goods moved around the world — warehouses, pallets, shipping routes. But containers in software? That meant nothing to me.
Then a colleague sat down and said: "Think about shipping containers."
And everything clicked.
The Shipping Container Analogy That Changed Everything
Before the 1950s, shipping goods around the world was chaotic. Every port loaded cargo differently. Every ship was packed differently. Moving goods from a truck to a ship to a train required repacking everything multiple times. It was slow, expensive, and things got damaged or lost constantly.
Then someone invented the standardised shipping container — a metal box of a fixed size that could be loaded once and transferred directly between trucks, ships, and trains without ever being opened or repacked.
It did not matter what was inside. The container worked the same way everywhere.
Software containers work exactly the same way.
Before containers, deploying an application was chaotic. It worked on the developer's laptop but broke on the test server. It ran fine in the test environment but crashed in production. Every environment was configured slightly differently — different operating system versions, different software libraries, different settings. Moving an application between environments meant repacking everything and hoping for the best.
A software container packages your application and everything it needs to run — the code, the libraries, the settings, the dependencies — into a single standardised unit. It does not matter whether that container runs on your laptop, a test server, an AWS cloud instance, or a Kubernetes cluster. It behaves exactly the same way everywhere.
That is the problem Docker solved. And that is why it changed everything.
What is Docker?
Docker is a platform that lets you build, run, and share containers.
It is not the only container tool — which we will come back to — but it is the one that made containers mainstream and the one most tutorials and courses use as a starting point.
When people in DevOps and Cloud talk about "containerising an application," they mean packaging it into a container image using Docker so it can run consistently anywhere.
The Key Concepts You Need to Know
Image — A blueprint for your container. It contains everything your application needs to run, frozen at a point in time. Think of it like a template or a snapshot. Images are built once and reused many times.
Container — A running instance of an image. You can run the same image as ten different containers simultaneously. Each one is isolated and independent.
Dockerfile — A simple text file with instructions for building your image. Think of it as a recipe — step by step instructions for setting up your application's environment.
Registry — A place to store and share images. Docker Hub is the most popular public registry. In Cloud environments you will use private registries like AWS ECR or Azure Container Registry.
Building Your First Docker Image
Here is a simple Dockerfile that packages a basic web application:
# Start from an official base image
FROM node:18-alpine
# Set the working directory inside the container
WORKDIR /app
# Copy your application files into the container
COPY package*.json ./
COPY . .
# Install dependencies
RUN npm install
# Tell Docker which port the app runs on
EXPOSE 3000
# The command that runs when the container starts
CMD ["node", "server.js"]
In plain English this says: start with a lightweight Node.js environment, copy my application files in, install everything it needs, and run it on port 3000.
To build and run it:
# Build the image and tag it with a name
docker build -t my-app:v1 .
# Run it as a container
docker run -p 3000:3000 my-app:v1
# See all running containers
docker ps
# Stop a container
docker stop <container-id>
A Note on Podman — Docker is Not the Only Option
Here is something worth knowing early: Docker is not the only container tool, and in many enterprise environments it is not even the default anymore.
Podman is a container tool that works almost identically to Docker — most commands are directly interchangeable — but with some important differences that matter in enterprise and Cloud environments:
- Podman runs containers without requiring a background daemon running as root, which makes it more secure
- It is the default container tool in Red Hat Enterprise Linux and related distributions
- In environments that came from the Red Hat ecosystem — like OpenShift — Podman is standard
If you are using Podman, the commands throughout this article work exactly the same way. Just replace docker with podman:
podman build -t my-app:v1 .
podman run -p 3000:3000 my-app:v1
podman ps
Same result, different tool. The concepts are identical. Learn one and you know both.
How Containers Connect to CI/CD Pipelines
Containers and CI/CD pipelines are a natural match. In a modern DevOps workflow, every time a developer pushes code to GitHub, the pipeline can automatically:
- Build a new container image from the latest code
- Run automated tests inside the container
- Push the new image to a container registry like AWS ECR
- Deploy the updated container to production
Here is a simple GitHub Actions example that builds and pushes a Docker image:
# .github/workflows/build.yml
name: Build and Push Container Image
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Build Docker image
run: docker build -t my-app:${{ github.sha }} .
- name: Push to AWS ECR
run: |
aws ecr get-login-password | docker login --username AWS \
--password-stdin ${{ secrets.ECR_REGISTRY }}
docker push ${{ secrets.ECR_REGISTRY }}/my-app:${{ github.sha }}
Every push to main builds a fresh container image tagged with the exact commit SHA — so you always know exactly which version of your code is running in production.
From Containers to Kubernetes — The Natural Next Step
Running one or two containers on a single server is straightforward. But what happens when your application grows and you need to run hundreds of containers across dozens of servers? How do you manage them all, restart ones that crash, scale up during busy periods, and distribute traffic evenly?
That is where Kubernetes comes in — and it is the natural next step after containers.
Kubernetes is a platform that manages containers at scale. Rather than running containers manually, you tell Kubernetes what you want — "run ten copies of this container and keep them running" — and it takes care of the rest.
In the real world, nobody runs Kubernetes themselves from scratch. The major cloud providers offer managed Kubernetes services so you get all the power without the complexity of managing the underlying infrastructure:
EKS — Amazon Elastic Kubernetes Service
AWS's managed Kubernetes offering and one of the most widely used in the industry. If your organisation runs on AWS, EKS is the natural choice. It integrates tightly with AWS services like IAM for security, ECR for container images, and CloudWatch for monitoring.
AKS — Azure Kubernetes Service
Microsoft Azure's managed Kubernetes offering. If your organisation is already invested in the Azure ecosystem, AKS is the most natural choice. It integrates tightly with Azure Active Directory, Azure Monitor, and Azure Container Registry.
GKE — Google Kubernetes Engine
Google's managed Kubernetes service — and arguably the most mature, since Kubernetes was originally created at Google. GKE is known for being easy to use and very well integrated with Google Cloud services.
OpenShift — Red Hat's Kubernetes Platform
OpenShift is Kubernetes with a lot of enterprise features built on top — enhanced security, a built in developer workflow, and deep integration with Red Hat tooling. If you came from a Red Hat environment like I did, you have probably already encountered OpenShift. It uses Podman under the hood and is widely used in large enterprises and regulated industries like banking and healthcare.
All four ultimately run containers. The choice depends on your cloud provider, your organisation's existing tools, and your compliance requirements.
Quick Recap
Here is everything we covered today:
- A software container packages your application and everything it needs into a single portable unit that runs consistently anywhere
- Docker is the most widely used platform for building and running containers — Podman is the enterprise alternative with nearly identical commands
- A Dockerfile is a recipe for building a container image
- Containers integrate naturally with CI/CD pipelines — push code, automatically build and deploy a new image
- Kubernetes manages containers at scale — EKS, AKS, GKE, and OpenShift are the managed Kubernetes platforms you will encounter in real Cloud environments
What's Next?
← Previous: Git: The Tool That Saves Your Code and Your Career
Now that you understand containers, it is time to go deeper into CI/CD pipelines — the automated systems that take your code from a Git commit all the way to a running container in production. Coming soon in Article 5.
Found this useful? Share it with someone just starting their DevOps or Cloud journey and follow along for a new article every week.
