What is Container?
Updated: 3 days ago
A container is an isolated environment for running an application and its dependencies while sharing the host operating system kernel. Unlike a traditional virtual machine, a conventional operating system container does not normally boot a complete guest operating system for every application instance. That difference is why containers can be comparatively lightweight and quick to create.
The important distinction is between a container image and a running container. An image is the packaged filesystem and configuration used as a template. A container is a runnable instance created from that image, with its own isolated process environment, networking and writable state as configured by the container platform.
How does a container work?
On Linux, container platforms use operating system features to isolate processes and control resources. Namespaces can give processes separate views of resources such as process IDs, networking and mounts, while control groups can organise and constrain resource use. A container runtime then creates and manages the container according to its configuration.
Docker's documentation describes a container as an isolated process and explains that multiple containers share the host kernel. The Open Container Initiative runtime specification defines behaviour and configuration interfaces used by low-level container runtimes.
What is a container image?
A container image is a packaged template containing the files, binaries, libraries and configuration required by the application. Images are commonly built in layers. When a container is created, the platform adds runtime configuration and typically a writable container layer over the image.
This separation is useful because the same image can be used to create multiple container instances. Persistent application data should normally be stored deliberately in volumes, bind mounts or another persistent storage system rather than assumed to survive simply because it existed inside a disposable container.
Container vs virtual machine
Containers and virtual machines both provide isolated environments, but they isolate at different layers. A VM normally has virtual hardware and its own guest operating system kernel. Conventional containers share the host kernel while isolating application processes and their environment.
Container: normally shares the host operating system kernel and packages the application with its user-space dependencies.
Virtual machine: normally includes a complete guest operating system running on virtual hardware.
Container: can usually be created and started with less overhead than a full VM.
Virtual machine: can provide a separate operating system environment and can run a different supported guest OS from the host.
Both: still consume real CPU, memory, storage and network resources from the underlying infrastructure.
What is a container runtime?
A container runtime is software responsible for creating and running containers according to the platform's configuration. Low-level runtimes such as runc implement OCI runtime behaviour, while higher-level systems such as containerd and CRI-O manage broader container lifecycle functions.
Docker is a wider container platform rather than a synonym for the container concept itself. Containers can be implemented and managed by multiple runtimes and orchestration systems.
Container networking
A container can have an isolated network namespace with its own interfaces, addresses and routing view. Container platforms can connect containers through software bridges, overlay networks or other virtual networking mechanisms. Traffic can remain between containers on a host or travel through the host's physical network interfaces to other networks.
Applications inside containers commonly listen on network ports. Publishing or forwarding a port can map traffic arriving at a host address and port to the service inside a container. An exposed service still needs appropriate firewall and access-control policy.
Do containers have their own IP addresses?
They can. Depending on the networking model, a container may receive its own IP address on an internal container network or another network segment. It may also be reached through host port publishing, address translation, proxies or load balancers rather than directly from the wider network.
The exact behaviour can involve IPv4, IPv6 or both, depending on the host, runtime, network driver and wider infrastructure.
Containers, VLANs and network segmentation
Container networks can form part of a broader network segmentation strategy. In some environments, container hosts or workloads may also connect to VLANs. Container isolation does not replace deliberate network security architecture.
Common uses for containers
Web applications: package a web service and its runtime dependencies into a repeatable environment.
APIs: deploy independently managed application interfaces and supporting services.
Microservices: run individual application components as separate containerised services.
Development and testing: reproduce application environments across developer, test and deployment systems.
CI/CD: create consistent build, test and deployment environments.
Databases and supporting services: run stateful software when persistent storage and operational requirements are handled correctly.
Edge and home-lab services: isolate self-hosted applications on servers, NAS devices and other capable systems.
Techie Broadband calculation: pulling a container image
Suppose a container image is 2 GB and must be downloaded from a remote registry. Using decimal units, 2 GB equals 16 gigabits. On a theoretical 100 Mbps connection, 16,000 Mb ÷ 100 Mb/s = 160 seconds, or 2 minutes 40 seconds. On a theoretical 1 Gbps connection, the same transfer is 16 seconds.
These are theoretical payload-only examples. Real image pull times can be longer because image layers may be compressed, registry and server performance varies, protocol overhead exists, the connection may be shared, and the host must also write and unpack data. Cached layers can make subsequent pulls much smaller.
Containers on UK broadband connections
A container does not inherently need broadband. It can run entirely on a local host. Internet connectivity matters when images are pulled from remote registries, services call external APIs, users connect remotely, data is replicated off site or workloads communicate with cloud platforms.
For large image pulls and remote data transfer, available bandwidth affects transfer capacity, while latency affects responsiveness and repeated request round trips. The practical result depends on the ISP, access network, product and location, as well as the remote registry or service.
What happens when you publish a container port?
Publishing a port creates a path from a host interface and port to a service inside the container. For example, a web server listening on container port 80 could be published on host port 8080. That does not automatically mean the service is reachable from the public internet: router configuration, firewall rules, address translation, CGNAT, IPv6 policy and upstream filtering can all affect reachability.
If inbound internet access is deliberately required, understand the difference between container port publishing and router port forwarding. They operate at different points in the network path.
Container storage and persistence
Containers are often designed to be replaceable. Data written only to a container's writable layer can disappear when that container is removed. Persistent data therefore needs an explicit storage design, such as a managed volume, bind mount, network storage or external database.
This is particularly important for databases, uploads and configuration that must survive container replacement. Treating a container as disposable does not mean the application's important data should be disposable.
Are containers secure?
Containers provide isolation, not an automatic security boundary that makes every workload safe. Because conventional containers share the host kernel, host security, runtime configuration, image provenance, privileges and exposed interfaces all matter.
Use trusted and maintained images and keep application dependencies patched.
Run workloads with the minimum privileges they require.
Avoid exposing management interfaces or application ports unnecessarily.
Separate sensitive workloads with appropriate network policy.
Protect secrets rather than baking credentials into images.
Keep the host operating system and container runtime patched.
Use stronger isolation where the threat model requires it.
How to troubleshoot a container that cannot reach the network
Confirm the application process is actually running inside the container.
Check which address and port the application is listening on.
Inspect the container's network interfaces, IP address and routing table.
Confirm the container is attached to the intended container network.
Test name resolution separately from raw IP connectivity.
Check host firewall and container network rules.
If inbound access is required, confirm the host port is published correctly.
If access crosses the local router, check the router and upstream path separately.
Test whether the destination service itself is reachable from the host.
Change one network variable at a time and retest.
Containers and APIs
Containerised applications frequently communicate through an API. A frontend, API and database can each run in separate containers, with container networking controlling how those components discover and reach one another. This separation can make deployment and scaling easier, but it also makes service discovery, authentication and observability important.
Frequently asked questions
Is Docker the same as a container?
No. A container is the isolated runtime concept. Docker is a platform and toolset for building, distributing and running containerised applications.
Does a container include an operating system?
A conventional container can include operating system user-space files and libraries, but it normally shares the host kernel rather than booting its own complete guest operating system kernel like a VM.
Can a container have its own IP address?
Yes, depending on the container networking model. It may have an address on an internal or external network, or it may be reached through host port publishing or another proxying mechanism.
Can containers run inside virtual machines?
Yes. This is common in cloud and data-centre environments. A VM can provide the operating system environment and isolation boundary, while multiple containers run inside that VM.
Do containers make broadband faster?
No. Containers do not increase broadband capacity. Remote container traffic is still constrained by the complete network path, including the host interface, router, access network, ISP and remote service.
What happens when a container is deleted?
The container instance and changes held only in its writable layer can be removed. Data deliberately stored in persistent volumes or external storage can remain, depending on how that storage is configured.
Key takeaway
A container is an isolated application environment created from an image and managed by a container runtime. Conventional containers share the host operating system kernel, which distinguishes them from full virtual machines and can reduce overhead. Their performance and security still depend on real host CPU, memory, storage, networking, runtime configuration and the wider broadband path when remote services are involved.
To explore the related technical concepts used in this Container guide, visit our broadband terminology guide.
