FIT5225 · Cloud Computing And Security
Containers
Containers are the next rung above the virtual machine on the abstraction ladder. A container packages an application with its dependencies and runs as an isolated, OS-level process that shares the host kernel — so it starts in milliseconds and ships in megabytes, where a VM virtualises a whole machine (its own guest OS) and takes seconds and gigabytes. FIT5225 teaches the Docker toolchain that made containers mainstream: the engine pipeline (client → daemon → containerd → runc), how an image is a stack of read-only layers identified by content hash, how registries distribute images, and how a Dockerfile is an audit log that builds the image one layer at a time. You also learn the run-time lifecycle CLI and Docker Compose for multi-container apps. The quizzes here are heavy on distinctions (container vs VM, image vs container, COPY vs ADD, RUN vs CMD) and on reading a Dockerfile.
What this chapter covers
- 01Containers vs virtual machines — shared kernel, the isolation trade-off
- 02Docker architecture: client → daemon → containerd → runc
- 03Images, layers & registries — read-only layers, content-addressed
- 04The Dockerfile — instructions, layer caching, COPY vs ADD, RUN vs CMD
- 05Worked example: reasoning through a Dockerfile
- 06Lifecycle, the CLI & Docker Compose for multi-container apps
Worked example: container vs VM — pick the right isolation
- +1(a) Choose containers — one container per microservice instance, all sharing the host kernel.
- +1(b) Reason 1 — weight: a container shares the host OS kernel, so there is no guest OS per instance — megabytes, not gigabytes, and it starts in milliseconds rather than the seconds a VM needs to boot an OS.
- +1(b) Reason 2 — density & identical builds: shared, cached read-only image layers let many identical instances pack densely on one host with little duplication.
- +1(c) Security trade-off: containers share one kernel, so isolation is weaker than a VM's hardware-level boundary — a kernel escape can affect neighbours.
- +1Mitigation: run untrusted or strongly-isolated workloads in VMs (or VM-isolated sandboxes), keep the kernel patched, and apply least-privilege (drop capabilities, no root).
Key terms
- Container vs virtual machine
- A container is an OS-level isolated process that shares the host kernel and packages only the app and its dependencies — lightweight, fast to start. A VM virtualises a whole machine including its own guest OS on a hypervisor — heavier, slower, but with stronger hardware-level isolation. The quiz tells them apart by the shared-kernel line.
- Image vs container
- An image is the read-only, layered template (the build artefact); a container is a running instance of that image with a thin writable layer on top. One image runs many containers. This is the build/run boundary: docker build makes an image, docker run starts a container from it.
- Image layers & content hash
- A Docker image is a stack of read-only layers, each the diff produced by one build step, identified by a content (SHA-256) hash. Identical layers are shared and cached across images, so unchanged layers are not rebuilt or re-pulled — this is what makes builds and distribution fast.
- Dockerfile
- A text file of instructions (FROM, WORKDIR, COPY, RUN, EXPOSE, CMD…) that builds an image one layer at a time — an audit log of how the image was made. Ordering matters: put rarely-changing steps (dependency installs) before frequently-changing ones (source copy) to maximise layer-cache reuse.
- Docker Compose
- A tool that defines and runs a multi-container application from a single declarative YAML file — services, networks and volumes — so a web app plus its database and cache start together with one command. It is single-host orchestration; multi-host scaling needs Swarm or Kubernetes.
Containers FAQ
What is the single line that separates a container from a VM?
The kernel. A container shares the host operating-system kernel and isolates at the OS-process level; a VM runs its own complete guest OS on top of a hypervisor and isolates at the hardware level. Everything else — containers are lighter, start faster and pack denser; VMs isolate more strongly — follows from that one fact.
Why does the order of instructions in a Dockerfile matter?
Because each instruction creates a cached layer, and Docker rebuilds only from the first changed layer downward. Copying requirements.txt and installing dependencies before copying your source means the expensive dependency-install layer is cached and reused whenever only your code changes — a much faster rebuild. Reorder it and every code edit reinstalls everything.
What's the difference between RUN, CMD and ENTRYPOINT?
RUN executes during the build and bakes its result into an image layer (e.g. installing packages). CMD sets the default command run when the container starts, and can be overridden on the command line. ENTRYPOINT sets a fixed command the container always runs, with CMD supplying default arguments. Build-time vs default-run vs fixed-run is a recurring quiz distinction.
When should I prefer COPY over ADD in a Dockerfile?
Prefer COPY for plain file and directory copies — it does exactly that and nothing surprising. ADD additionally auto-extracts local tar archives and can fetch remote URLs, which is easy to misuse and harder to reason about. The guidance the quiz rewards: use COPY unless you specifically need ADD's archive-unpacking behaviour.
Exam move
Anchor everything on the shared-kernel line: be able to state container vs VM in one sentence and derive the weight, speed, density and isolation consequences from it. Memorise the Docker engine pipeline (client → daemon → containerd → runc) and which component does the actual kernel work. Practise reading a Dockerfile cold — name what each instruction does, explain the dependency-before-source ordering for layer caching, and be ready for the three trap pairs the quiz loves: image vs container, COPY vs ADD, and RUN vs CMD vs ENTRYPOINT. Finally, know that Compose is single-host multi-container, which sets up the jump to orchestration in the next chapter.
