Introduction to Docker Containers

A Docker container is a running instance of a Docker image.

The image supplies the application, runtime, libraries, and initial filesystem. When Docker starts a container, it adds a writable layer and runs the image’s configured process.

This makes an application much more portable. A machine with a compatible container runtime does not need you to install the application’s language runtime and libraries one by one.

It does not guarantee that every image works on every machine. CPU architecture, operating system kernel, available resources, permissions, and external services still matter.

Is a container a virtual machine?

No. A virtual machine normally runs a complete guest operating system and its own kernel.

A Linux container is an isolated process that shares the host’s Linux kernel. Namespaces separate resources such as processes, networks, and filesystems. Control groups can limit CPU and memory.

This usually makes containers faster to start and lighter than virtual machines. But the shared kernel also means a container is not the same security boundary as a virtual machine.

How do you run a container?

This command starts an Nginx container:

docker run --name web -p 8080:80 nginx:alpine

Docker downloads the image if it is not already local, creates the container, and starts its main process.

The --name option gives it a useful name. The -p 8080:80 option publishes port 80 from the container as port 8080 on the host. You can now open http://localhost:8080.

Press Ctrl-C to stop it, or start it in the background with -d:

docker run -d --name web -p 8080:80 nginx:alpine

How do you manage a container?

List running containers:

docker container ls

Include stopped containers:

docker container ls --all

Read the logs:

docker container logs web

Stop and start it:

docker container stop web
docker container start web

Remove the stopped container:

docker container rm web

Removing a container does not remove its image.

What happens to data in a container?

Files written inside a container go to its writable layer by default. That layer belongs to that specific container and disappears when you remove it.

Use a Docker volume for data that must survive the container:

docker volume create app-data

docker run --rm \
  --mount type=volume,src=app-data,dst=/data \
  alpine sh -c 'echo hello > /data/message.txt'

The --rm option removes the container when its process exits. The app-data volume remains.

You can also use bind mounts when the container needs direct access to a host file or directory.

What should run in one container?

A useful default is one main concern per container: a web app in one, a database in another, and a queue worker in another.

This is not a rule that only one operating-system process may exist. The point is to give each container a clear lifecycle and make components easier to replace and scale.

Are containers secure by default?

Containers provide process isolation, but isolation is not perfect.

Run application processes as a non-root user when possible. Avoid --privileged, do not mount the Docker socket into untrusted containers, keep the host and images updated, and grant only the capabilities and filesystem access the application needs.

Do not bake passwords or API keys into an image. Use the secret-management feature of your deployment platform.

The official Docker documentation explains more about container storage and Docker Engine security.

Related posts about docker: