Docker is a tool for packaging an application with the files, settings, and dependencies it needs to run. This cheat sheet helps students remember the most common container concepts and commands without searching documentation. It is useful for programming classes, web development projects, and deployment practice.
Containers make it easier to run the same app on different computers with fewer setup problems.
The most important ideas are images, containers, Dockerfiles, volumes, ports, and Compose files. An image is a reusable template, while a container is a running instance of that image. Dockerfiles describe how to build images, and docker-compose.yml files describe multi-container apps.
Commands like docker build, docker run, docker ps, and docker compose up control the main container workflow.
Key Facts
- An image is a read-only template, and a container is a running instance created from an image.
- Build an image from the current folder with docker build -t app-name .
- Run a container in the background with docker run -d --name my-app -p 8080:80 app-name.
- List running containers with docker ps, and list all containers with docker ps -a.
- Stop a container with docker stop container-name, and remove it with docker rm container-name.
- Map ports using hostPort:containerPort, such as -p 8080:80, which sends host port 8080 traffic to container port 80.
- Persist data with a volume using docker run -v my-data:/app/data image-name.
- Start services from a Compose file with docker compose up, and stop them with docker compose down.
Vocabulary
- Container
- A lightweight running environment that packages an application with the files and dependencies it needs.
- Image
- A reusable blueprint used to create one or more containers.
- Dockerfile
- A text file containing step-by-step instructions for building a Docker image.
- Volume
- A storage location managed by Docker that keeps data even after a container is removed.
- Port Mapping
- A rule that connects a port on the host computer to a port inside a container.
- Docker Compose
- A tool for defining and running multi-container applications using a docker-compose.yml file.
Common Mistakes to Avoid
- Confusing an image with a container is wrong because an image is the template, while a container is the running or stopped instance made from it.
- Forgetting the final dot in docker build -t app-name . is wrong because the dot tells Docker to use the current folder as the build context.
- Mapping ports backward is wrong because -p 8080:80 means host port 8080 connects to container port 80, not the other way around.
- Storing important data only inside a container is risky because removing the container can delete that data unless a volume is used.
- Editing files inside a running container as the main workflow is a mistake because those changes are usually not saved in the image or project source files.
Practice Questions
- 1 Write the command to build an image named school-api from the current directory.
- 2 A web server listens on port 3000 inside a container. Write a docker run port option that makes it available on host port 8080.
- 3 A container is named test-db. Write the commands to stop it and then remove it.
- 4 Explain why a team might use Docker Compose instead of starting each container with separate docker run commands.
Understanding Docker & Containers Quick Reference
A Docker build works in layers. Each instruction in a Dockerfile creates a layer that Docker can often reuse later. This is why the order of instructions matters.
Put steps that change rarely near the top, such as installing system packages. Put frequently changed application code near the bottom. A small code edit can then reuse earlier layers and make rebuilding faster.
The build context matters too. It is the folder sent to Docker during a build.
A .dockerignore file keeps large folders, secret files, test output, and local dependency folders out of that context. This reduces build time and prevents accidental copying.
Containers isolate processes, files, and networking, but they do not act like full virtual machines. They share the host computer's operating system kernel. This makes them start quickly and use less memory than many virtual machines.
It also means isolation has limits. A process running as root inside a container can still be risky if the container has too many permissions.
Good practice includes using a small trusted base image, running the app as a nonroot user, and never placing passwords or API keys directly in an image. Environment variables can provide settings at run time, though sensitive values still need careful handling.
Files inside a container can disappear when that container is removed. This is useful for temporary app files, but it causes trouble for databases and uploaded work. A named volume stores important data outside the container's writable layer, so a replacement container can use the same data.
Students often meet this when running a database for a website project. The database software can be recreated, while its records remain in the volume. Bind mounts are another option.
They connect a folder on the host computer to a folder in the container. During development, a bind mount lets code edits on the computer appear immediately inside the container.
Networking explains why an app may run but still not open in a browser. The application must listen on the correct container port and usually on all network interfaces, not only localhost inside the container. Port publishing creates a path from a port on the computer to that internal port.
In a multi-service project, services can usually reach each other by service name on the Compose network. A web service might connect to a database by its service name rather than by localhost.
Compose starts related services together, but startup order does not guarantee that a database is ready to accept connections. Health checks and retry logic solve that common problem.
When something fails, inspect evidence before changing random settings. Container logs show messages written by the program and often reveal missing files, bad environment values, or connection failures. An interactive shell inside a running container can help check folders, processes, and network access.
Compare the Dockerfile, Compose file, and application settings carefully. Pay attention to port numbers, file paths, permissions, volume locations, and service names.
Clean up unused containers and images as projects grow, but check volume names before deleting anything. Removing a volume can permanently erase stored project data.