What Is a Docker Container?
A Docker container is a running, isolated instance of an image: an ordinary process on your computer that has been given its own private view of the system and its own limits. This guide explains how containers start, run, talk, store data, and stop, using plain words and everyday comparisons.
Picture a large apartment building. Every family inside has a locked front door, private rooms, and its own mailbox, yet they all share the same foundation, plumbing, and electricity. Nobody builds a new house for each family, which would be slow and wasteful. A Docker container is one of those apartments. It is a private, locked space for one application, sitting inside a shared building, which is your computer. Many apartments can exist side by side, each feeling like its own home.
1The Problem Containers Solve
Every good tool starts with a real headache.
Programs that fight each other
Imagine two applications on the same server. One needs an older version of a helper library, and the other needs a newer version. If both are installed directly on the machine, they clash, and fixing one breaks the other. Another problem is that one greedy program can use all the memory and slow down everything else.
A third problem is moving software. A program that works on one computer may fail on another because of small differences in settings or installed tools. This is the famous “it works on my machine” problem.
The old answers were heavy
The classic fix was to give every application its own virtual machine, a complete pretend computer with its own operating system. This works, but each virtual machine takes gigabytes of space and minutes to start, and it wastes memory on running a whole extra operating system. Teams needed something with the separation of a virtual machine but the lightness of an ordinary program.
Before shipping containers, cargo was loaded piece by piece, and every ship and port handled it differently. The standard steel container made everything uniform: the outside looks the same, whatever is inside. A Docker container does the same for software, packing it in a standard box that any machine with Docker can carry and run.
2So, What Exactly Is a Docker Container?
A plain definition first, then a closer look.
A Docker container is a runnable instance of a Docker image. The image is the read-only template that holds the application and everything it needs. When you start a container, Docker adds a thin writable layer on top of the image, gives the process a private view of the system, applies limits, connects it to a network, and launches your application inside it.
The most important thing to understand is what a container is not. It is not a small computer, and it does not have its own operating system kernel. A container is an ordinary process, or a small group of processes, running on the host computer. What makes it special is that Linux has been told to show that process a limited, private picture of the machine and to restrict how much of the machine it may use.
Three big ideas
Isolation
The process believes it is alone: it sees its own processes, network, files, and computer name, and nothing of its neighbors.
Resource control
Limits on memory, processor, and other resources stop one container from starving the rest.
Disposability
Containers are meant to be started, stopped, and replaced quickly, without fear of losing anything important.
Every container has a long unique ID made of letters and numbers, and Docker usually shows only the first twelve characters. You can also give a container a friendly name, which is far easier to remember.
3Container, Image, and Virtual Machine Compared
Three words that beginners often mix up.
Container versus image
An image is the frozen template. A container is the live instance made from it. If the image is a recipe card with all ingredients measured, the container is the dish being cooked right now. You can cook the same recipe many times, and each dish is separate.
An image is like a song file stored on a phone, and a container is that song playing. The same file can play on many phones at once, and stopping one playback does not damage the file.
Container versus virtual machine
A virtual machine carries a full guest operating system, including its own kernel, on top of a hypervisor. A container skips all of that and shares the kernel of the host. This is why containers are smaller and start much faster.
flowchart TB
subgraph VMS["Virtual Machines"]
HW1["Physical hardware"] --> HYP["Hypervisor"]
HYP --> VA["Guest OS + App A"]
HYP --> VB["Guest OS + App B"]
end
subgraph CTS["Containers"]
HW2["Physical hardware"] --> KER["Host OS kernel"]
KER --> ENG["Container runtime"]
ENG --> CA["Container A"]
ENG --> CB["Container B"]
end
| Feature | Virtual Machine | Container |
|---|---|---|
| Own operating system kernel | Yes | No, shares the host kernel |
| Typical size | Gigabytes | Megabytes to a few hundred megabytes, plus a small writable layer |
| Start time | Often minutes | Usually seconds or less |
| Isolation strength | Very strong, hardware-level | Strong, but the kernel is shared |
| Best for | Different operating systems, strict separation of unknown tenants | Packaging, running, and scaling applications quickly |
Because containers share the host kernel, a Linux container needs a Linux kernel. On Mac and Windows, Docker Desktop quietly runs a small Linux environment in the background and starts your containers inside it.
4How Isolation Works: Namespaces
The first of the Linux features that make a container possible.
A namespace is a way of hiding parts of the system from a process. When a container starts, it is placed into its own set of namespaces. Each kind of namespace covers one part of the system, and together they create the feeling of a private computer.
Process IDs
The container sees only its own processes. Its main program often believes it is process number one.
Network
The container gets its own network interfaces, addresses, and ports, separate from the host.
Mounts
The container has its own view of the file system, built from the image layers and any attached storage.
Hostname
The container has its own computer name, which is often its short container ID.
Inter-process communication
Shared-memory and messaging channels between processes are kept private to the container.
Users
Allows user numbers inside the container to map to different, less powerful numbers on the host.
Namespaces are like frosted windows and private mailboxes in an apartment building. Each family sees only its own rooms and receives only its own mail, with no idea what the neighbors are doing.
From inside a container you may see only two or three processes. From the host, the same processes appear in the normal list of everything running, just with different numbers. It is the same process seen through two different windows.
5How Limits Work: Control Groups
The second Linux feature keeps neighbors polite.
Namespaces control what a container can see. Control groups, usually called cgroups, control how much it can use. With cgroups, the system can cap a container’s memory, its share of the processor, the number of processes it may create, and how fast it can read from and write to disks.
Memory limit
If a container tries to use more memory than allowed, the system may stop one of its processes to protect the machine. This is often called being out of memory, and it usually ends the container.
Processor share
You can give a container a fair share or a hard cap on processor time, so one busy container does not slow everything else.
Process count limit
Limiting how many processes a container can create protects against runaway programs that keep launching more copies of themselves.
Control groups are like the electricity and water meters in each apartment, with a cap on how much each family may use, so one family cannot drain the whole building.
Unless you set them, a container may use as much of the host’s memory and processor as it can get. Always set sensible limits for anything running in production.
6Restricting Powers: Capabilities and Filters
Isolation is stronger when the process is also given fewer abilities.
Even inside its private box, a process running as the administrator user can normally do very powerful things. To reduce the risk, Docker layers several protections on top of namespaces and cgroups.
Capabilities
The administrator’s power is split into small pieces called capabilities. Docker gives containers only a limited set by default, and you can remove more.
System call filter
A default filter, called seccomp, blocks a number of risky requests that a container’s programs could make to the kernel.
Security profiles
Where available, mandatory access control systems such as AppArmor or SELinux add more rules about what files and actions are allowed.
Read-only file system
The container’s own files can be mounted read-only, so a broken-in process cannot change the program itself.
Imagine a staff badge. Instead of giving every employee a master key, the company gives each person a badge that opens only the doors they truly need. Capabilities work like that badge for container processes.
A privileged container has most of these protections removed and gets wide access to the host. Treat it as a last resort, never as a quick way to make an error message go away.
7The Team Behind a Container: Architecture
Several cooperating parts turn your request into a running process.
Docker Client
The command-line tool or desktop app you type into. It sends your request onward.
Docker Daemon
The background service that receives requests and manages images, containers, networks, and volumes.
containerd
A lower-level manager that looks after the complete life of containers, including their images and supervision.
Shim
A tiny helper that stays with each container so that it can keep running even if the manager restarts.
runc
The small worker that actually sets up the namespaces, limits, and starts the process, following an open standard.
flowchart LR
U["You"] --> CL["Docker Client"]
CL -->|"API request"| DM["Docker Daemon"]
DM --> CD["containerd"]
CD --> SH["Shim"]
SH --> RC["runc"]
RC --> PR["Your application process"]
Think of a restaurant. You are the customer and the client is the waiter. The daemon is the head chef, containerd is the kitchen manager, and runc is the cook who actually prepares the dish. The shim is like a helper who stays at the cook’s station to keep things going.
Because these parts follow standards from the Open Container Initiative, other tools can use the same image format and the same low-level runtime. This is why an image built with Docker can also be run by other systems, and why Kubernetes commonly uses containerd directly.
8What Happens When a Container Starts
Follow one start request from your keyboard to a live program.
sequenceDiagram
participant You
participant Client as Docker Client
participant Daemon as Docker Daemon
participant Reg as Registry
participant Run as Runtime
You->>Client: ask to run an application
Client->>Daemon: send the request
Daemon->>Daemon: look for the image locally
Daemon->>Reg: download missing layers
Reg-->>Daemon: image layers
Daemon->>Daemon: add writable layer and prepare network and storage
Daemon->>Run: create isolated process with limits
Run-->>Daemon: process is running
Daemon-->>Client: report success
Client-->>You: container is up
Find or download the image
Docker checks its local storage and pulls only the layers it does not already have.
Add a writable layer
A thin, empty layer is placed on top of the read-only image layers to catch any changes the container makes.
Prepare the surroundings
Docker sets up the network connection, attaches any volumes, and prepares environment values and limits.
Create the isolated process
The runtime places a new process into fresh namespaces, applies the cgroup limits, and restricts its powers.
Run the start command
The command defined in the image, or overridden when starting, launches the application. From this moment, the container is alive.
No operating system has to boot. The container reuses the kernel that is already running, so starting one is mostly a matter of arranging views and limits and then launching a single program.
9The Life Story of a Container
Every container passes through predictable stages.
stateDiagram-v2
[*] --> Created
Created --> Running: start
Running --> Paused: pause
Paused --> Running: unpause
Running --> Exited: stop or program ends
Exited --> Running: restart
Exited --> Removed: remove
Removed --> [*]
Created
Docker has prepared the container, including its writable layer, but nothing is running yet.
Running
The main process is alive. Networking, storage, and limits are all active.
Paused
All processes are frozen in memory. They resume exactly where they left off.
Exited
The main process has ended. The container still exists with its writable layer and logs until it is removed.
Removed
The container and its writable layer are deleted. Anything stored only inside it is gone for good.
The Docker mindset is that a container should be replaceable at any moment. If losing one would cause real damage, something important is stored in the wrong place.
10The Main Process, Stopping, and Exit Codes
A container lives exactly as long as its main process.
The main process rule
When a container starts, one program is designated as its main process. When that program finishes, the container exits. This is why a container that seems to “do nothing” often stops right away: its job was short and simply ended. A web server keeps running because its main loop never finishes, so its container stays up.
A container is like a theater play. The play lasts as long as the lead actor is on stage. When the lead actor leaves for good, the show is over and the lights go out, even if extra actors are still standing around.
How a container is stopped
A polite request
Docker sends a stop signal, by default a termination signal, asking the main process to finish its work and exit.
A grace period
Docker waits for a short time, ten seconds by default, so the program can save work and close connections.
A forced end
If the process is still running after the grace period, Docker forcefully kills it. Unsaved work is lost.
Why signals sometimes fail
Inside a container, the main process is process number one. On Linux, process number one is treated specially, and a program that does not expect to be in that role may ignore stop signals. The result is a container that always takes the full grace period to stop. Programs should handle the stop signal properly, or you can ask Docker to run a tiny helper program as process number one that forwards signals and cleans up finished child processes.
Exit codes
When a container exits, it leaves behind a number called an exit code. Zero usually means success, and any other number means something went wrong. A code of 137 usually means the process was forcefully killed, often because it ran out of memory or because it ignored the polite stop request. A code of 143 usually means it ended after receiving the termination signal.
| Exit Code | Usual Meaning | First Thing to Check |
|---|---|---|
| 0 | The program finished successfully | Nothing, unless it was expected to keep running |
| 1 and other small numbers | The program reported an error | Read the logs |
| 137 | Forcefully killed | Memory limit reached, or the stop request was ignored |
| 143 | Ended after the termination signal | Usually a normal stop |
11Files and Data Inside a Container
Where things are stored, and what happens to them.
The writable layer and copy-on-write
The image layers under a container are read-only and shared. On top of them sits a thin writable layer that belongs to this container alone. When a program changes a file that lives in the image, Docker first copies the file up into the writable layer and changes it there. This is called copy-on-write. The original image is untouched, and other containers from the same image never see the change.
graph TD
A["Image layer 1: base files"] --> B["Image layer 2: libraries"]
B --> C["Image layer 3: your application"]
C --> D["Container writable layer: changes made while running"]
When a container is removed, its writable layer is deleted, and so is everything stored there. Files written this way are also slower than files in a volume. Anything you want to keep must live elsewhere.
Three ways to keep data
Volume
Storage managed by Docker, outside the container. It survives removal and is the best choice for important data such as databases.
Bind Mount
A folder from the host shared directly into the container. Great for development, since edits show up instantly.
Memory Mount
Storage held only in memory, never written to disk. Useful for short-lived or sensitive scratch files.
A container is like a hotel room that is reset after every guest. A volume is like a safe deposit box at a bank. Your valuables stay there no matter how many hotel rooms you check in and out of.
12How Containers Talk: Networking
Private by default, open only where you choose.
Each container gets its own network identity inside its network namespace. Docker connects it to a virtual network, and the network decides who may talk to whom. By default, containers join a standard bridge network on the host. It is better to create your own bridge network for each application, because on user-created networks Docker provides name lookup, so one container can reach another simply by its name.
| Network Type | What It Does | When to Use It |
|---|---|---|
| Bridge | A private virtual network on one host where attached containers can reach each other | The everyday choice for a single machine |
| Host | The container shares the host’s network directly, with no separation | When maximum network speed matters and less isolation is acceptable |
| None | No network at all | Jobs that must never reach the network |
| Overlay | Joins containers on different machines as if they were together | Multi-machine clusters |
Publishing a port
A container’s network is private, so outsiders cannot reach it by default. To let visitors use a web application inside a container, you publish a port. This links a chosen port on the host to a port inside the container. It works like a doorbell on the building’s front door that rings one specific apartment.
flowchart LR
V["Visitor"] -->|"host port"| H["Host computer"]
H -->|"published port"| W["Web container"]
W -->|"private network"| A["API container"]
A -->|"private network"| DB["Database container"]
A container’s numeric address can change every time it is recreated. Use its name instead, and the connection keeps working even after the container is replaced.
13Configuring a Container
The same image can behave differently depending on how you start it.
Name
A friendly label so you do not have to type the long ID.
Environment values
Small pieces of configuration, such as a mode or a web address, passed in at start. The same image can run in test and production with different values.
Published ports
Links between host ports and container ports for outside visitors.
Resource limits
Caps on memory, processor share, and number of processes.
Storage attachments
Which volumes, bind mounts, or memory mounts the container may use.
User
Which user the program runs as, ideally an ordinary one rather than the administrator.
Restart policy
What Docker should do when the container stops or crashes.
Labels
Descriptive notes, such as owner or project, that help you find and manage containers in groups.
Restart policies
| Policy | Behavior | Typical Use |
|---|---|---|
| No | Never restart automatically | One-time jobs and experiments |
| On failure | Restart only if the program exits with an error | Jobs that should retry if they fail |
| Always | Restart whenever it stops, including after the Docker service restarts | Long-running services |
| Unless stopped | Like always, but stays stopped if you stopped it on purpose | Services you want to control manually when needed |
Environment values can show up in inspection output and logs. For passwords and keys, use proper secret handling instead.
14Working with a Running Container
The everyday things you do once it is alive.
Read the logs
Docker collects what the main process writes to its standard output and error streams, and lets you read it at any time, even after the container has exited, as long as it has not been removed.
Run a command inside
You can start an extra process inside a running container, for example to open a shell and look around. This is handy for investigation, but any change you make by hand is temporary and untracked.
Copy files in and out
Docker can copy files between your computer and a container, which is useful for pulling out a log file or a report.
Inspect the details
A detailed report shows the container’s settings, network address, attached storage, limits, and current state. It is the first place to look when something behaves unexpectedly.
Watch resource use
A live view shows how much processor, memory, network, and disk activity each running container is using.
It is fine to look inside a running container to understand a problem. But once you learn the cause, make the fix in the image or the configuration and start a fresh container, so the solution is repeatable.
15Monitoring, Logging, and Health Checks
Because containers come and go, you need eyes on them.
Logging
Applications in containers are expected to write messages to the standard output and error streams, not to log files inside the container. Docker gathers these streams using a logging driver. Because a removed container takes its local logs with it, production teams send logs to a central place where they can be searched and kept.
Metrics
Docker can report processor use, memory use, network traffic, and disk activity for each container. Monitoring systems collect these numbers, draw graphs, and raise alerts when something looks wrong, such as memory climbing steadily or a container restarting again and again.
Health checks
A container can be marked as running while the program inside it is stuck. A health check is a small regular test, such as asking the application whether it is alive, and Docker records whether it passes. Cluster tools use the result to replace containers that have quietly stopped working.
Logs
What the application said, in order.
Metrics
Numbers over time for processor, memory, network, and disk.
Health status
A simple pass or fail that shows whether the application still responds.
Events
A record of containers being created, started, stopped, or killed.
Watching containers is like caring for patients in a hospital ward. Logs are the nurse’s notes, metrics are the heart monitors, and health checks are the regular “how are you feeling?” questions.
16Container Security
Isolation is strong, but it is not the same as invincibility.
Because containers share the host kernel, a serious flaw in the kernel or a badly configured container can put the host at risk. Container security is about keeping each box as small and as locked as possible, and about trusting only what you have checked.
Run as an ordinary user
Do not run the application as the all-powerful administrator inside the container. If someone breaks in, the damage they can do is much smaller.
Drop unneeded powers
Remove Linux capabilities the application does not need, keep the default system call filter, and avoid privileged mode.
Use read-only file systems
Mount the container’s file system as read-only where possible, and give it a small writable area only where it truly needs one.
Limit resources
Set memory, processor, and process limits so that a compromised or buggy container cannot exhaust the machine.
Start from trusted, scanned images
A container is only as safe as the image it comes from. Use trusted bases, scan for known weaknesses, and rebuild regularly.
Protect the daemon and sockets
Anyone who can talk to the Docker daemon can effectively control the host. Never share the daemon’s control socket into a container casually, and consider rootless mode, where the whole engine runs without administrator rights.
Separate networks
Put containers on different networks by role, and publish only the ports that outsiders truly need.
For running code from untrusted strangers, the strongest separation comes from virtual machines or specially hardened runtimes. Ordinary containers are excellent for your own applications, but are not a magic wall.
17Advantages and Trade-offs of Containers
An honest look at both sides.
Advantages
- Consistent behavior from a laptop to a test server to production
- Fast start-up and small footprint compared with virtual machines
- Efficient hardware use, since many containers share one kernel
- Easy scaling: start more copies of the same image when demand grows
- Clean separation between applications with different needs
- Easy replacement and rollback, since containers are disposable
Disadvantages / Trade-offs
- Weaker isolation than virtual machines, because the kernel is shared
- Data persistence requires deliberate planning with volumes
- A learning curve around networking, storage, and security
- Large systems need orchestration tools, which add their own complexity
- Debugging can be harder when images are minimal or containers vanish quickly
When to think twice
Containers are less natural for programs that need a different operating system kernel than the host, for heavy graphical desktop applications, or for situations where the strongest possible separation between unknown tenants is required. In those cases, virtual machines or hardened runtimes may be a better fit.
18Design Patterns and Anti-patterns
Habits worth copying and habits worth avoiding.
Helpful patterns
One job per container
Each container does a single task, such as serving the website or running the database. That keeps updating and scaling simple.
Stateless containers
Keep containers free of important data, so any copy can be stopped, replaced, or multiplied without worry.
Sidecar
A helper container runs beside the main one to add abilities like log shipping or secure connections without changing the main application.
Immutable containers
Never change a running container by hand. Build a new image, and replace the container, so every deployment is repeatable.
Configuration from outside
Pass settings in when the container starts, so one image serves every environment.
Harmful anti-patterns
Problem
Treating a container like a virtual machine: installing many programs, logging in by hand, and expecting it to live for years.
Why It’s Harmful
Hand-made changes are invisible and cannot be repeated. When the container is replaced, all that work disappears, and nobody remembers how it was set up.
Correct Approach
Keep containers small, single-purpose, and replaceable, with every change captured in the image build or configuration.
Problem
Storing important data only in the container’s writable layer.
Why It’s Harmful
When the container is removed or replaced, the data vanishes, often at the worst possible moment.
Correct Approach
Attach a volume, or use a managed external service, for anything that must survive.
Problem
Running everything in one giant container: the website, the database, and several helper programs together.
Why It’s Harmful
You cannot update or scale one part without touching the others, and a single crash can bring everything down.
Correct Approach
Split the system into separate containers, one per responsibility, and connect them through a network.
Problem
Running containers as the administrator user, in privileged mode, with no limits.
Why It’s Harmful
A single flaw in the application can give an attacker wide access to the host or let one container starve all the others.
Correct Approach
Use an ordinary user, drop unneeded powers, and set memory and processor limits.
19Best Practices and Common Mistakes
A short checklist that will save you a lot of trouble.
Name your containers meaningfully
A name like “shop-database” helps far more than a random generated one when many containers are running.
Make the main process handle stop signals
So that containers shut down cleanly and quickly, saving work instead of being forcefully killed.
Write logs to standard output
Let Docker collect them, and send them to a central place in production.
Set limits and health checks
Give production containers sensible resource limits and a health check so problems are contained and detected.
Choose a restart policy on purpose
Long-running services usually need one, while one-time jobs usually do not.
Keep data in volumes
Decide where data lives before the container starts, not after something is lost.
Clean up regularly
Remove stopped containers and unused resources, but review what will be deleted first.
Mistakes beginners often make
Usually the main process finished, or crashed on start. Check the exit code and the logs before anything else. A container needs a main process that keeps running.
The application is running and listening, but visitors cannot reach it, because the container’s network is private until a port is published.
Inside a container, localhost means the container itself, not the host and not its neighbors. Use the other container’s name on a shared network.
Exited containers still hold their writable layers and logs, quietly using disk space. Remove those you no longer need, or start short jobs so that they remove themselves when finished.
A container killed with exit code 137 may simply have crossed its memory limit. Raise the limit, or fix the memory problem in the application.
20Docker Containers in the Real World
Where you will meet containers in everyday engineering.
Consistent development environments
Teams run the database, cache, and other services as containers on every laptop, so a new hire can be productive on the first day.
Automated testing pipelines
Build servers start fresh containers to run tests in clean surroundings, then throw them away. Every test run starts from the same known state.
Microservices
Each small service runs in its own containers, so different teams can update and scale them independently. Companies such as Netflix and Spotify have publicly described container-based service architectures.
Cloud and cluster platforms
Cloud container services and Kubernetes run and supervise containers at large scale, restarting failed ones and adding more during busy periods.
One-time and scheduled jobs
Data processing, report generation, and backups can run as short-lived containers that start, do their work, and disappear.
Trying software safely
Start a container to experiment with a database or tool, and delete it afterwards, leaving your computer clean.
| Situation | Without Containers | With Containers |
|---|---|---|
| Onboarding a developer | Long setup document and manual installs | Start the prepared containers and begin |
| Deploying a new version | Update servers by hand, risk of differences between them | Replace old containers with new ones from the new image |
| Handling a traffic spike | Prepare new servers slowly | Start more containers within seconds |
| Rolling back a bad release | Complicated manual reversal | Start containers from the previous image |
21Frequently Asked Questions
Quick answers to what beginners ask most.
No. A virtual machine carries its own operating system and kernel. A container shares the host’s kernel and is just an isolated process with limits, which makes it lighter and faster to start.
An image is a read-only template. A container is a running instance created from it, with a thin writable layer on top. One image can produce many containers.
A container lives only as long as its main process. If that program finished quickly, or crashed, the container exits. Check its exit code and logs to see which happened.
Data in the writable layer is deleted with the container. Data stored in a volume stays until you remove the volume itself.
Technically yes, but the usual advice is one main job per container. It keeps things simple to update, scale, monitor, and secure. Related helper programs are better placed in their own containers.
Through virtual networks. Containers on the same user-created network can reach each other by name, and you publish a port only for the ones that must be reachable from outside.
Yes, when configured with care: use trusted, scanned images, run as an ordinary user, drop unneeded powers, set limits, and keep everything updated. Safety depends on configuration, not only on the tool.
Generally no. A container uses the kernel of its host, so Linux containers need a Linux kernel, and Windows containers need a Windows host. Docker Desktop hides this by running a Linux environment behind the scenes.
It depends on how much memory, processor power, and disk each one needs. Because they are light, a single machine can often run many more containers than virtual machines. Setting limits helps keep them fair.
No. Many projects run happily with Docker and Compose on a single server. Kubernetes becomes useful when you must manage many containers across many machines with automatic healing and scaling.
Start with the difference between an image and a container, then learn the lifecycle, the main process rule, storage with volumes, and networking. After that, look at limits, security, and running several containers together.
22Summary and Key Takeaways
A Docker container is a live, isolated instance of an image: an ordinary process on the host that Linux has wrapped in namespaces for a private view, control groups for resource limits, and extra restrictions on its powers. It starts in seconds because it shares the host kernel, and it lives exactly as long as its main process. Its writable layer is temporary, so lasting data belongs in volumes, and its network is private until you choose to open a port. Treat containers as small, single-purpose, disposable units, keep them locked down and watched, and they become one of the most reliable ways to run software.
Key Takeaways
- A container is a running instance of an image — the image is the frozen template, and many containers can be created from one image.
- It is a process, not a tiny computer — containers share the host kernel and are isolated using namespaces, limited using control groups, and restricted using capabilities and filters.
- Its life follows its main process — when that program ends, the container exits, and handling stop signals well makes shutdowns clean and quick.
- The writable layer is temporary — anything worth keeping must live in a volume or an external service.
- Networks are private by default — use user-created networks, refer to other containers by name, and publish only the ports that outsiders need.
- Set limits and watch your containers — memory and processor caps, health checks, central logs, and metrics prevent and reveal problems early.
- Security is a habit — run as an ordinary user, drop unneeded powers, avoid privileged mode, use scanned images, and remember that a shared kernel means isolation is strong but not absolute.