Docker & Containers
Learn about containerization with Docker and related technologies.
Why Containers Changed Everything
Before containers, deploying software meant wrestling with environment inconsistencies - "it works on my machine" was a daily frustration. Docker solved this by packaging applications with everything they need to run, making deployments reproducible from a developer laptop to a production cluster. Today, containers are the standard unit of deployment for startups and enterprises alike.
At Wizard Tech Services, our web development projects are containerized by default, ensuring smooth handoffs and consistent environments. We also help teams containerize existing applications and set up orchestration as part of our automation and infrastructure services.
Containers vs. VMs
Virtual machines emulate entire operating systems and take minutes to boot. Containers share the host OS kernel and start in milliseconds, using a fraction of the memory. Use VMs when you need full OS isolation; use containers for application-level packaging and rapid scaling.
Dev-to-Prod Parity
Use Docker Compose locally and Kubernetes in production to keep your environments as similar as possible. The same Dockerfile builds the same image everywhere, eliminating configuration drift and "works on my machine" bugs.
YAML files define your entire application stack in one place. Learn how docker-compose.yml works, essential Compose commands, and see real-world examples including a modded Valheim game server and a Portainer deployment.
Two ways to run Docker - the Desktop GUI application for Mac/Windows or the command-line Engine on Linux. Compare features, resource usage, and learn which approach fits your workflow.
A web-based management UI for Docker - start, stop, and inspect containers from your browser. Deploy stacks from Compose files, manage multiple hosts, and use app templates for one-click deployments.
Health checks, log aggregation, resource metrics, and alerting for your containers. Covers Docker's built-in logging, Prometheus + Grafana stacks, Uptime Kuma, and terminal tools like ctop and Lazydocker.
Containers package your app, runtime, libraries, and config into one portable unit that runs identically anywhere. Covers the container lifecycle, volumes for persistent data, port mapping, and environment variable injection.
Docker images are built in layers via Dockerfile instructions. Write multi-stage builds for smaller images, tag versions, push to Docker Hub or GitHub Container Registry, and scan for vulnerabilities.
Containers
The building block of Docker - portable, isolated units that package your app and everything it needs to run.
$ docker run -d --name myapp -p 3000:3000 myimage # Start a container
$ docker ps -a # List all containers
$ docker stop myapp # Stop a container
$ docker start myapp # Start a stopped container
$ docker rm myapp # Remove a container
$ docker logs -f myapp # Follow container logs
$ docker exec -it myapp /bin/sh # Open a shell inside
$ docker inspect myapp # Full container details
-d - run in detached (background) mode
--name myapp - assign a name to the container
-p 8080:80 - map host port 8080 to container port 80
-v ./data:/app/data - mount a host directory as a volume
-e MY_VAR=value - set an environment variable
--env-file .env - load variables from a file
--restart unless-stopped - auto-restart on failure or reboot
--network my-network - attach to a custom Docker network
--rm - automatically remove when stopped
Container filesystems are ephemeral - when the container is removed, all data inside it is lost. Volumes solve this by mapping host directories or named volumes into the container.
# Bind mount (host directory)
-v ./my-data:/app/data
# Named volume (Docker-managed)
-v pgdata:/var/lib/postgresql/data
Named volumes are managed by Docker and persist across container restarts. Bind mounts map a specific host path and are useful for development.
Every container goes through a predictable lifecycle:
Created → container exists but is not running
Running → main process is active
Paused → processes are suspended (SIGSTOP)
Stopped → main process has exited
Removed → container is deleted
Use docker ps for running containers and docker ps -a to include stopped ones.
Docker creates an isolated bridge network by default. Containers on the same network can reach each other by container name.
bridge - default isolated network with DNS
host - container shares host network directly
none - no networking at all
Configure containers at runtime without modifying the image. Use -e flags, --env-file, or the environment key in Compose.
# .env file
DATABASE_URL=postgresql://user:pass@db:5432/app
NODE_ENV=production
SECRET_KEY=your-secret-here
Tip: Never hardcode secrets in Dockerfiles. Use .env files or a secrets manager.