Assignment: Containerize and Ship
History of Containers and CI/CD
Quick definitions for every term introduced in bold across Week 5 (Chapters 1-5). Click the chapter backlinks to jump to where the term is first used in context.
An immutable snapshot of your application and its dependencies, built with docker build. An image stays on disk until you delete it; running it creates a container. (Used in Chapter 1: Intro: Containers and CI/CD)
A running instance of a Docker image, started with docker run. When the container exits, the image is unchanged: you can start a new container from the same image at any time. (Used in Chapter 1: Intro: Containers and CI/CD)
A full software emulation of a computer that runs its own operating system and kernel. VMs are heavier and slower to start than containers because each VM carries a complete OS rather than sharing the host kernel. (Used in Chapter 1: Intro: Containers and CI/CD)
The core of an operating system that manages CPU, memory, and devices. Containers share the host machine's kernel instead of running a full OS, which is why they start faster and use less memory than VMs. (Used in Chapter 1: Intro: Containers and CI/CD)
The machine (physical or virtual) that the container runtime runs on. Containers share the host's kernel and access the host's CPU and memory, but are isolated from each other and from the host filesystem. (Used in Chapter 1: Intro: Containers and CI/CD)
An automated process that runs checks (linting, tests, Docker build) on every code push to catch problems before they reach the main branch. (Used in Chapter 1: Intro: Containers and CI/CD)
An automated process that takes a build that passed CI and deploys it to a running environment (such as Azure Container Apps). In this track you build CI in Week 5 and add CD in Week 6. (Used in Chapter 1: Intro: Containers and CI/CD)
The sequence of automated steps (lint, test, build, push) that runs on every push. A CI pipeline catches broken code before it reaches the main branch or production. (Used in Chapter 5: Python CI Pipeline)
A tool that installs external libraries into your project. In this track the practical choice is between pip + requirements.txt (classic) and uv + pyproject.toml + uv.lock (modern). (Used in Chapter 2: Dependency Management)
An external library your project needs to run (e.g. pandas, requests). Direct dependencies are listed in pyproject.toml or requirements.txt; transitive dependencies are pulled in by those packages. (Used in Chapter 2: Dependency Management)
A package that your direct dependency depends on, not listed by you explicitly. For example, requests depends on urllib3. Without a lock file, transitive dependencies can change between installs even if your direct dependency list has not changed. (Used in Chapter 2: Dependency Management)
A file (uv.lock or poetry.lock) that records the exact version of every package in the full dependency tree: your packages, their packages, and so on. Committing the lock file makes every install on every machine identical. (Used in Chapter 2: Dependency Management)
A fast Python package manager from Astral (the makers of Ruff) that combines virtual environment management, dependency resolution, and lock file generation. Replaces pip, pip-tools, pyenv, and virtualenv for most workflows. (Used in Chapter 2: Dependency Management)
The standard Python project metadata file that declares direct dependencies, dev dependency groups, and project configuration. Used by uv, Poetry, and other modern Python tooling. (Used in Chapter 2: Dependency Management)
A CI run where the same commit always installs the same package versions and produces the same test results, regardless of when it runs. Lock files achieve this by pinning the full dependency tree. (Used in Chapter 2: Dependency Management)
A text file of instructions that tells Docker how to build a container image: the base image, packages to install, files to copy, and the command to run. (Used in Chapter 3: Docker Fundamentals)
The result of one Dockerfile instruction, stored on disk as an immutable filesystem diff. Docker caches each layer and reuses it on the next build if the instruction and all files it references have not changed. (Used in Chapter 3: Docker Fundamentals)
Docker's mechanism for reusing previously built layers. If a layer's input (the instruction and all files it references) has not changed since the last build, Docker skips re-running it and uses the cached result. Correct Dockerfile layer order (dependency files before source code) keeps the cache hit rate high. (Used in Chapter 3: Docker Fundamentals)
A file that lists paths Docker should exclude from the build context sent to the daemon. Typically includes .env, .venv/, __pycache__/, and .git/ to keep images small and secrets out of the image history. (Used in Chapter 3: Docker Fundamentals)
A storage service for container images. You push images to a registry after building them and pull images from a registry to run them. Examples: Azure Container Registry (private), Docker Hub (public). (Used in Chapter 4: Azure Container Registry)
A version number following the MAJOR.MINOR.PATCH format (e.g. 1.0.3). Useful for public releases where the version communicates what changed. In CI, commit SHA tags are preferred over semantic versions because SHAs are unique and traceable back to a specific commit. (Used in Chapter 4: Azure Container Registry)
A human-readable label attached to a specific image version in a registry. Tags are mutable: latest is overwritten on every push. Commit SHA tags (abc123f) are immutable and traceable. (Used in Chapter 4: Azure Container Registry)
The unique 40-character hexadecimal hash that Git assigns to every commit. Used as a Docker tag (${{ github.sha }} in GitHub Actions) to create an immutable, traceable link between a container image and the exact code that produced it. (Used in Chapter 4: Azure Container Registry)
A non-human Azure identity used by automated systems (CI runners, scripts) to authenticate to Azure services. Unlike a personal account, a service principal has a JSON credential block with clientId, clientSecret, subscriptionId, and tenantId. Stored as a GitHub Secret (AZURE_CREDENTIALS) for use in GitHub Actions workflows. (Used in Chapter 5: Python CI Pipeline)
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.