Container Management Cheat Sheet

Updated 2026-04-29

Next Topic: Container Networking Cheat Sheet

🧠Study flashcards on this topic139 cards · spaced repetition→

Container management encompasses the complete lifecycle of container operations—from image creation and registry storage to runtime configuration, networking, persistent storage, and resource control. While containers provide lightweight application isolation through Linux namespaces and cgroups, effective management requires understanding how to build, distribute, run, and monitor containerized workloads at scale. Modern container management spans multiple layers: image optimization for fast deployments, registry authentication for secure distribution, volume strategies for data persistence, network drivers for connectivity, and resource limits to prevent contention—all critical for running reliable production workloads.

What This Cheat Sheet Covers

This topic spans 22 focused tables and 167 indexed concepts, 139 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Container RegistriesTable 2: Image Building and OptimizationTable 3: Image Tagging and VersioningTable 4: Container Lifecycle StatesTable 5: Restart PoliciesTable 6: Volume Types and Data PersistenceTable 7: Networking DriversTable 8: Port PublishingTable 9: Resource LimitsTable 10: Environment Variables and SecretsTable 11: Health ChecksTable 12: Logging DriversTable 13: Image ManagementTable 14: Container Inspection and DebuggingTable 15: Cleanup and MaintenanceTable 16: Dockerfile InstructionsTable 17: Security Best PracticesTable 18: Multi-Container ManagementTable 19: Container RuntimesTable 20: Advanced NetworkingTable 21: Labels and MetadataTable 22: Resource Isolation (cgroups)

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Container Registries

A registry is where your built images live before they run anywhere — the warehouse between docker build and docker run. Choosing one is mostly about where the rest of your stack already sits: ECR for AWS, Artifact Registry for GCP, ACR for Azure, GHCR for GitHub-centric workflows, or Harbor and a self-hosted registry when you need everything on-premises. Most of the managed options bundle vulnerability scanning and RBAC, which matters more than raw storage once you're running in production.

Type	Example	Description
Docker Hub	`docker pull nginx:latest`	• Public container registry hosting millions of images • supports automated builds, webhooks, and free public repositories with rate limiting (100 pulls/6h unauthenticated).
Harbor	`docker push harbor.example.com/myproject/app:v1.0.0`	Open-source OCI-compliant registry with vulnerability scanning, policy enforcement, replication, and RBAC—ideal for on-premises enterprise use.
Amazon ECR	`aws ecr get-login-password \| docker login` `docker push 123456.dkr.ecr.us-east-1.amazonaws.com/app`	AWS-managed private registry with IAM integration, image scanning, lifecycle policies, and tight integration with ECS/EKS.
Google Artifact Registry	`gcloud auth configure-docker` `docker push us-docker.pkg.dev/project/repo/image`	Unified registry for Docker images, Helm charts, and language packages with vulnerability scanning and SLSA provenance support.
Azure Container Registry	`az acr login --name myregistry` `docker push myregistry.azurecr.io/app:latest`	Azure-managed registry with geo-replication, content trust, webhooks, and integration with Azure services.
GitHub Container Registry	`echo $GITHUB_TOKEN \| docker login ghcr.io -u USERNAME --password-stdin` `docker push ghcr.io/owner/repo/image:tag`	GitHub-native OCI registry with package visibility control, fine-grained permissions, and automatic linkage to repositories.
GitLab Container Registry	`docker login registry.gitlab.com` `docker push registry.gitlab.com/group/project/image`	Built-in registry per GitLab project with dependency proxy, cleanup policies, and CI/CD integration.
Quay.io	`docker pull quay.io/organization/image:tag`	Red Hat's container registry with security scanning, robot accounts, time-machine (rollback), and geo-replication.
JFrog Artifactory	`docker login artifactory.example.com` `docker push artifactory.example.com/docker-local/app`	Universal artifact manager supporting Docker, Helm, Maven, npm with promotion pipelines, Xray scanning, and federation.
Self-hosted Registry	`docker run -d -p 5000:5000 --name registry registry:2`	Lightweight open-source distribution registry for private, on-premises deployments—requires separate authentication and scanning solutions.

Table 2: Image Building and Optimization

Smaller, faster, more secure images come down to a few high-leverage techniques, and multi-stage builds are the single biggest win — they let you compile in a fat builder image and ship only the artifacts, often shaving 70-90% off the final size. The rest of these rows tune the build itself: ordering instructions for cache hits, using BuildKit's cache and secret mounts, and attaching SBOMs and provenance so your supply chain is auditable.

Technique	Example	Description
Multi-stage builds	`FROM node:20 AS build` `COPY . .` `RUN npm ci && npm run build` `FROM nginx:alpine` `COPY --from=build /app/dist /usr/share/nginx/html`	Separate build and runtime stages to produce smaller final images by excluding build tools—can reduce image size by 70-90%.

The rest of this section is part of the full cheat sheet

Table 3: Image Tagging and Versioning

How you name images determines whether a deployment is reproducible or a guessing game. The spectrum runs from convenient-but-dangerous latest to bulletproof digest pinning, with semantic versions, commit SHAs, and environment suffixes in between. The guiding rule across all of them is immutability — treat a published tag as write-once so the same name always means the same bytes.

Strategy	Example	Description
Semantic versioning	`myapp:1.2.3` `myapp:1.2` `myapp:1`	• Version tags following MAJOR.MINOR.PATCH convention • update alias tags (1, 1.2) to point to latest patch.

The rest of this section is part of the full cheat sheet

Table 4: Container Lifecycle States

A container moves through a predictable set of states from creation to removal, and knowing them makes docker ps output far less mysterious. The distinction worth internalizing is that a stopped container still keeps its filesystem and exit code — only docker rm actually deletes it — while the rare Dead state signals something went wrong at the daemon level.

State	Example	Description
Created	`docker create nginx`	• Container exists with allocated filesystem and config, but process not started • no CPU/memory consumption.

The rest of this section is part of the full cheat sheet

Table 1: Container Registries

Type	Example	Description
Docker Hub	`docker pull nginx:latest`	• Public container registry hosting millions of images • supports automated builds, webhooks, and free public repositories with rate limiting (100 pulls/6h unauthenticated).
Harbor	`docker push harbor.example.com/myproject/app:v1.0.0`	Open-source OCI-compliant registry with vulnerability scanning, policy enforcement, replication, and RBAC—ideal for on-premises enterprise use.
Amazon ECR	`aws ecr get-login-password \| docker login` `docker push 123456.dkr.ecr.us-east-1.amazonaws.com/app`	AWS-managed private registry with IAM integration, image scanning, lifecycle policies, and tight integration with ECS/EKS.
Google Artifact Registry	`gcloud auth configure-docker` `docker push us-docker.pkg.dev/project/repo/image`	Unified registry for Docker images, Helm charts, and language packages with vulnerability scanning and SLSA provenance support.
Azure Container Registry	`az acr login --name myregistry` `docker push myregistry.azurecr.io/app:latest`	Azure-managed registry with geo-replication, content trust, webhooks, and integration with Azure services.
GitHub Container Registry	`echo $GITHUB_TOKEN \| docker login ghcr.io -u USERNAME --password-stdin` `docker push ghcr.io/owner/repo/image:tag`	GitHub-native OCI registry with package visibility control, fine-grained permissions, and automatic linkage to repositories.
GitLab Container Registry	`docker login registry.gitlab.com` `docker push registry.gitlab.com/group/project/image`	Built-in registry per GitLab project with dependency proxy, cleanup policies, and CI/CD integration.
Quay.io	`docker pull quay.io/organization/image:tag`	Red Hat's container registry with security scanning, robot accounts, time-machine (rollback), and geo-replication.
JFrog Artifactory	`docker login artifactory.example.com` `docker push artifactory.example.com/docker-local/app`	Universal artifact manager supporting Docker, Helm, Maven, npm with promotion pipelines, Xray scanning, and federation.
Self-hosted Registry	`docker run -d -p 5000:5000 --name registry registry:2`	Lightweight open-source distribution registry for private, on-premises deployments—requires separate authentication and scanning solutions.

Table 2: Image Building and Optimization

Technique	Example	Description
Multi-stage builds	`FROM node:20 AS build` `COPY . .` `RUN npm ci && npm run build` `FROM nginx:alpine` `COPY --from=build /app/dist /usr/share/nginx/html`	Separate build and runtime stages to produce smaller final images by excluding build tools—can reduce image size by 70-90%.

Table 3: Image Tagging and Versioning

Strategy	Example	Description
Semantic versioning	`myapp:1.2.3` `myapp:1.2` `myapp:1`	• Version tags following MAJOR.MINOR.PATCH convention • update alias tags (1, 1.2) to point to latest patch.

Table 4: Container Lifecycle States

State	Example	Description
Created	`docker create nginx`	• Container exists with allocated filesystem and config, but process not started • no CPU/memory consumption.