Container Fundamentals

A container packages an application with the files and settings it needs. At runtime, that package becomes an isolated process. This combination gives you a consistent unit to build, test, move, and run.

Containers solve a packaging problem. They do not remove the need to understand operating systems, networks, storage, or security.

The mental model

Keep four objects separate:

1. An image is an immutable package. It contains filesystem layers and runtime configuration.
2. A registry stores and distributes images.
3. A runtime unpacks an image and starts the configured process.
4. A container is that running process plus its isolated view of system resources.

The usual flow is:

source + build instructions -> image -> registry -> runtime -> container

You can start many containers from one image. Each container gets a writable layer for runtime changes. Removing the container removes changes in that layer unless you placed the data in persistent storage.

Containers and virtual machines

A virtual machine includes a guest operating system and its own kernel. A Linux container normally shares the host kernel with other containers. Linux namespaces give its processes separate views of resources. Control groups, usually called cgroups, account for and limit resource use.

This design often lets a host run more containers than full virtual machines. It also creates a different security boundary. A container is not automatically equivalent to a virtual machine. A kernel vulnerability or an unsafe configuration can weaken isolation.

Use a virtual machine when you need a separate kernel, a different operating system, or a stronger hardware-backed boundary. Use a container when process-level isolation and a portable application package fit the workload.

What isolation means

Linux namespaces can isolate process IDs, mounts, networking, hostnames, users, interprocess communication, cgroup views, and time settings. A process inside a namespace sees a scoped view instead of the host's complete view.

Cgroups answer a different question. They organize processes and control resources such as CPU and memory. Namespaces shape what a process can see. Cgroups shape what it can consume.

Isolation is configurable. A privileged container, a host namespace, broad capabilities, or a writable host mount can remove important barriers. Treat every option that shares host resources as a security decision.

Images, layers, and identity

An OCI image contains a manifest, configuration, and filesystem layers. The manifest references content by digest. A digest identifies exact content. A tag is a movable, human-readable label such as 2.4 or latest.

Use digests when you need reproducible deployment identity. A tag may point to different content later. Keep images small and purpose-built. Fewer packages mean fewer components to patch and fewer tools available to an attacker.

Never put secrets in an image layer. Removing a secret in a later build step does not erase it from the earlier layer. Supply secrets through a runtime mechanism designed for that purpose.

Storage and networking

A container's writable layer follows the container lifecycle. Use a volume or another external store for data that must survive replacement.

A bind mount exposes a host path inside a container. It is direct and useful for development, but it couples the container to that host path. A managed volume separates persistent data from the container's writable layer.

Container networking gives a process a network interface in an isolated network namespace. Publishing a port creates a path from a host address and port to the container. Exposing a port in image metadata documents intent; it does not publish the port by itself.

Lifecycle and operations

A container's main process defines its lifecycle. When that process exits, the container stops. Logs should normally go to standard output and standard error so the runtime or platform can collect them.

Treat containers as replaceable. Build a new image for an application change. Start a new container from that image. Store durable state outside the container. This pattern makes rollback, scaling, and recovery easier to reason about.

For several related containers on one machine, a composition tool can describe their networks, volumes, and startup configuration. For scheduling across machines, an orchestrator adds placement, service discovery, rollout, and recovery behavior. Those tools manage containers; they do not change the basic image-to-process model.

Security baseline

Start with the least authority the process needs:

• Run as a non-root user when possible.
• Drop unused Linux capabilities.
• Avoid privileged mode and host namespaces.
• Mount only required paths, with read-only access where possible.
• Set CPU and memory constraints.
• use trusted base images, scan them, and rebuild for security updates.
• Pin important deployments to an immutable digest.
• Keep the runtime and host kernel patched.

Rootless mode can run the Docker daemon and containers as a non-root user. It reduces risks associated with a privileged daemon, but it does not make application code trustworthy.

When containers fit

Containers fit services, command-line tools, build jobs, test environments, and batch workloads that benefit from repeatable packaging. They also provide a standard unit for orchestration platforms.

They fit poorly when a workload needs its own kernel, direct hardware control, or a full machine environment. Persistent state also needs deliberate storage, backup, and recovery design.

Your path forward

First, learn to distinguish images from containers. Then build and inspect an image. Run it with explicit ports, environment, storage, and resource constraints. Next, study image supply-chain security and runtime hardening. Add multi-container composition after the single-container lifecycle is clear. Study orchestration only when you need to manage workloads across machines.