Royal Army College

Lesson Overview

When the earlier lessons spoke of "a server running a service," they pictured, for simplicity, one program running directly on one computer. The reality of how modern services run, including most of the Principality's, is more layered and more powerful: services are usually packaged into containers and run on shared machines through virtualisation, so that many services can run on one server, each neatly bundled with what it needs, started and stopped and moved with ease. This lesson explains those two ideas, virtualisation, which lets one physical machine present itself as many, and containers, which package a service with its dependencies into a portable, repeatable unit, because understanding them is essential to understanding how the Principality's estate actually runs, and how a small force fields many services on modest hardware. The Army's own systems run this way, in containers on Linux, so this is not abstract background but the literal shape of the estate a member will support.

The governing idea is that containers and virtualisation let a small force run many services reliably and repeatably on little hardware, which is exactly what a small, modestly-resourced, self-hosting Principality needs. Without them, each service would want its own machine and its own carefully-arranged surroundings, and running a dozen services would mean a dozen fragile, hand-built servers; with them, many services run side by side on shared machines, each packaged so it carries its own surroundings with it, so that a service can be started, stopped, copied, moved, and rebuilt with a reliability and repeatability that hand-built servers never had. This is a large part of how a few capable members can run an estate that would once have needed a room full of machines and staff, and it is why understanding containers is a foundational skill for supporting a small force's systems. The member who grasps how services are packaged and run can make sense of the estate; one who does not sees only a confusing tangle.

This is the knowledge layer; the practice of building and running containers is done under those who administer the estate, with elevated access following appointment (Lesson 10). It reflects the reality of the Principality's container-based, Linux estate, and is wholly defensive. Read this to understand how services run; the hands-on practice comes under guidance.

By the end you will be able to explain virtualisation and why one machine can present as many, explain what a container is and how it packages a service, describe how containers make services portable and repeatable, understand how this lets a small force run many services on modest hardware, and place containers within the estate you have learned to map.

Key Terms

Virtualisation: the technique by which one physical computer presents itself as several separate virtual machines, so its capacity can be divided and shared.
Virtual machine (VM): a software-defined computer running on shared physical hardware, behaving like a separate machine with its own operating system.
Container: a lightweight, portable package that bundles a service together with the dependencies it needs to run, so it runs the same wherever it is placed.
Image: the built, stored template from which containers are created; a repeatable definition of a service and its surroundings.
Dependencies: the libraries, settings, and supporting software a service needs to run, which a container bundles in so they are never missing or mismatched.
Isolation: the separation of containers (or VMs) from one another, so each runs in its own space and a problem in one does not spread to others.
Portability: the property that a container runs the same on any host that can run containers, so a service can be moved or copied without rebuilding.
Repeatability: the property that the same image always produces the same running service, so deployments are predictable rather than hand-crafted.
Orchestration: the coordination of many containers across machines (starting, stopping, connecting, scaling them), by which a larger estate is managed.
Host: the physical (or virtual) machine on which containers run; one host commonly runs many containers.

Virtualisation: one machine as many

The first idea is virtualisation, which solves a plain problem: a physical computer is often far more capable than any single service needs, so dedicating a whole machine to one service wastes most of its capacity, while buying a machine per service is expensive and unwieldy. Virtualisation lets one physical computer present itself as several separate virtual machines, each behaving like its own computer with its own operating system, so that the physical machine's capacity is divided and shared among several independent virtual ones. Instead of one service per physical box, several virtual machines (VMs), each running its own service or services, share one physical host, using its capacity efficiently while remaining separated from one another.

The value of virtualisation to a small force is efficiency and flexibility. Efficiency: the capacity of physical hardware is used fully, several virtual machines drawing on one physical host rather than each service idling most of a dedicated box, so a small force fields more on less hardware. Flexibility: virtual machines are software-defined, so they can be created, copied, moved, and removed far more easily than physical machines, letting the estate be reshaped without buying and wiring new boxes. And isolation: each virtual machine is separated from the others, so they share the hardware without interfering, and a problem confined to one does not directly spread to the others. Virtualisation thus turns a few physical machines into many flexible virtual ones, which is the foundation of running a varied estate on modest hardware.

Containers, the next idea, take this further and more lightly, and in much of the modern world, including the Principality's estate, containers rather than full virtual machines are the everyday unit in which services run. But virtualisation is the underlying enabler and the broader idea, that one physical machine can be divided into many independent computing spaces, and it remains in use beneath and alongside containers. The member should hold the general principle: physical hardware is shared and divided, by virtualisation and containers, so that many services run on few machines, each in its own separated space.

Containers: packaging a service with what it needs

The idea that most directly shapes how the Principality's services run is the container, and it solves a different plain problem: a service needs not just its own code but a particular set of surrounding dependencies, libraries, settings, supporting software, to run correctly, and getting those surroundings right, and keeping them right, on a hand-built server is fiddly and fragile, the source of the classic complaint that a service "works on one machine but not another" because their surroundings differ. A container solves this by packaging the service together with all the dependencies it needs into one self-contained, portable unit, so the service carries its own correct surroundings with it wherever it goes, and runs the same on any host that can run containers.

The mechanics matter less to the member than the consequences, which are transformative for a small force. Because a container bundles the service with its dependencies, the service runs the same wherever it is placed (portability): the container that runs on one host runs identically on another, so services can be moved, copied, and re-deployed without the fragile re-arranging of surroundings that hand-built servers required. Because a container is built from a stored image, a repeatable template, the same image always produces the same running service (repeatability): deployments become predictable and reproducible rather than hand-crafted and unique, so a service can be rebuilt exactly from its image rather than nursed as an irreplaceable hand-made thing. And because containers are isolated from one another and lightweight, many can run side by side on one host, each in its own space, started and stopped independently, so one host commonly runs many containerised services efficiently.

This is why the Principality's estate runs in containers on Linux, and why understanding containers is essential to understanding it. A service in the Army's estate is typically a container, built from an image, running on a shared host alongside other containers, portable and repeatable, which is a far more reliable and manageable way to run a varied estate than a collection of hand-built servers. The member who knows that "a service" usually means "a container built from an image, running on a host" can make sense of how the estate is actually shaped and run; the consequences, portability, repeatability, isolation, density, are exactly the properties a small force needs to field many services reliably on little hardware.

   A CONTAINER  (a service + its surroundings, packaged to run anywhere)

   IMAGE (the template)  ---build--->  CONTAINER (a running instance)
   service code +                      runs the SAME wherever placed
   its DEPENDENCIES                    (portability), always the SAME
   (libraries, settings,               from the same image (repeatability),
   supporting software)                ISOLATED from other containers

   ONE HOST runs MANY containers, each in its own space, started/stopped
   independently.

   Why it matters to a small force: many services run reliably and
   REPEATABLY on LITTLE hardware; a service can be moved, copied, and
   REBUILT from its image, not nursed as an irreplaceable hand-made box.

How this lets a small force do more with less

Pulling virtualisation and containers together, their combined effect is precisely what a small, modestly-resourced, self-hosting Principality needs: many services, run reliably and repeatably, on little hardware, by a few people. Each piece contributes. Virtualisation and containers let physical hardware be shared densely, many services on few machines, so the force need not buy and house a box per service. Containers make services portable and repeatable, so they can be moved, copied, and rebuilt predictably rather than hand-nursed, which a small team without spare hands depends on. Isolation keeps the many services from interfering, so density does not mean fragility. And the whole becomes manageable by a small staff, because services are uniform, packaged units rather than a zoo of bespoke servers, and can be coordinated, even across machines, by orchestration (the coordination of many containers), the tooling that starts, stops, connects, and scales them.

The deeper benefit is reliability and recoverability. Because a containerised service is built from an image and is repeatable, it is far more recoverable than a hand-built one: if a host fails or a service breaks, the service can be rebuilt exactly from its image on another host, rather than painstakingly reconstructed by hand from memory and notes. This connects directly to the backups and continuity of Lesson 05: a container-based estate is one whose services can be re-created reliably from their definitions, which is a large part of what makes recovery on a bad day feasible for a small force. The repeatability that makes deployment predictable also makes recovery predictable, which is a real resilience benefit, not just a convenience.

For the small force, then, containers and virtualisation are not optional sophistication but the very thing that makes a substantial self-hosted estate sustainable by a few capable members. They are how a Principality that cannot field a large IT department nonetheless runs the many services a digital state needs, on modest hardware, reliably and recoverably, managed by a small disciplined team. Understanding them is understanding how that is possible, which is why this lesson sits in the heart of a course about running a small force's systems.

Placing containers in the estate, and the limits

It helps to place containers back within the map of the estate the course has drawn. A host (physical or virtual) runs many containers; each container is a service built from an image; the services are connected by the network of Lesson 02 and reached through the reverse proxy; they sign people in through the identity service of Lesson 03; they are kept patched and watched by the keeping-running of Lesson 04; their data and definitions are backed up as Lesson 05 requires; and they live on infrastructure hosted as Lesson 06 describes, self-hosted for the sovereign core. Containers are thus the unit in which the services of the whole estate are packaged and run, and seeing them in this map turns the abstract estate into a concrete picture: machines hosting containers, containers being services, all networked, identified, maintained, backed up, and governed. This concrete picture is what the member needs to support the estate responsibly.

A brief, honest word on the limits, lest containers seem a cure-all. Containers make services portable, repeatable, and dense, but they do not by themselves make them secure, correct, or well-run: a badly-configured container is still badly configured (the subject of Lesson 08), an unpatched image still carries its flaws (Lesson 04 and CIS 201's updates), and a container with too much access is still a risk. The repeatability that is containers' great strength can even propagate a mistake faithfully, a flaw built into an image is reproduced in every container from it, so the discipline of building images well matters. Containers are a powerful way to run services; they do not replace the disciplines of configuring, securing, maintaining, and governing them that the rest of the course teaches. The member holds containers as the foundational how of the estate, within and not instead of those disciplines, which together make a small force's systems not just runnable but well-run.

In Practice: Many Services on Few Machines

A member of the Royal Kaharagian Army learning to support the Principality's systems comes to understand why the estate is shaped as it is: not a room full of hand-built servers, one per service, but a few hosts each running many containers, which is how a small force fields a digital state's many services on modest hardware. A member who pictured only "one program on one computer" would be baffled by the real estate; understanding containers and virtualisation makes it legible.

They see that the Principality's physical hardware is shared, by virtualisation and containers, so that many services run on few machines rather than wasting a box on each, the efficiency a small force needs. They see that each service is a container, built from an image that bundles the service with its dependencies, so the service carries its own correct surroundings and runs the same wherever placed, ending the fragility of hand-arranged servers. They see the consequences that make a small team's estate sustainable: portability, so services can be moved and copied; repeatability, so the same image always yields the same service and a broken one can be rebuilt exactly rather than reconstructed by hand; isolation, so the many services share hosts without interfering; and manageability, the uniform packaged units coordinated by orchestration rather than a zoo of bespoke boxes.

Crucially, the member grasps the resilience this gives: because services are repeatable, built from images, the estate is recoverable, a failed host's services rebuilt from their definitions on another, which is much of what makes recovery on a bad day feasible for a force without spare hands, connecting straight to the backups and continuity they learned earlier. And they hold the limits honestly: containers are how services run, not a substitute for configuring, securing, maintaining, and governing them well, which the rest of the course teaches. With this understanding the estate stops being a confusing tangle and becomes a clear picture, hosts running containers, containers being services, all networked, identified, maintained, and backed up, which is exactly the legible, supportable estate this course is building the member to understand. That understanding is what containers and virtualisation, grasped clearly, provide.

Check Your Understanding

Explain virtualisation, why one physical machine presenting itself as several virtual machines is valuable to a small force (efficiency, flexibility, isolation), and how it differs from dedicating a whole machine to one service.
Explain what a container is, how it packages a service with its dependencies, and the three consequences that transform how a small force runs services: portability, repeatability (from an image), and isolation. Why does the Principality's estate run in containers?
Explain how containers and virtualisation together let a small force run many services reliably on little hardware, the recoverability benefit that connects to backups (Lesson 05), and the limits, why containers do not replace configuring, securing, maintaining, and governing services well.

Reflection (write a short paragraph): This lesson argues that containers and virtualisation are what make a substantial self-hosted estate sustainable by a few capable members, turning a service from an irreplaceable hand-built box into a repeatable unit that can be rebuilt exactly from its image. Why is repeatability such a powerful property for a small team with no spare hands, both for everyday running and for recovery on a bad day? Then consider the limit the lesson names, that repeatability faithfully reproduces a flaw built into an image as well as a good configuration: why does that make the discipline of building images well, and of the configuring and securing taught next, matter as much as the packaging itself?

Summary

Modern services, including the Principality's, usually run in containers on shared machines via virtualisation, not as one program per computer. Virtualisation lets one physical machine present as several virtual machines, sharing its capacity efficiently and flexibly while keeping them isolated.
A container packages a service together with its dependencies into a portable, self-contained unit built from a stored image. This gives portability (runs the same wherever placed), repeatability (the same image always yields the same service), and isolation (many run side by side on one host without interfering). The Principality's estate runs in containers on Linux.
Together, containers and virtualisation let a small force run many services reliably and repeatably on little hardware, managed by a few people: dense sharing of hardware, portable and repeatable services, isolation so density is not fragility, and manageability through uniform units and orchestration. The repeatability also gives recoverability, services rebuilt exactly from their images, which underpins recovery (Lesson 05).
Containers do not replace the other disciplines: a badly-configured, unpatched, or over-privileged container is still a risk, and repeatability can propagate a flaw faithfully. They are the foundational how of running services, within and not instead of configuring, securing, maintaining, and governing them (the rest of the course).
This is the knowledge layer; building and running containers is done under those who administer the estate, with elevated access following appointment (Lesson 10). The lesson concretises the estate of Lessons 01 to 02, runs the services hosted as Lesson 06 describes, underpins the recoverability of Lesson 05, and leads into the configuration and hardening of Lesson 08. Everything here is defensive.

Containers and Virtualisation: How Services Run Today