Phase 2: Dev Environments & Dependency Management · ~40 minutes · Docker

Containers: What They Actually Are

Change one line of application code and Docker reruns the entire pip install from scratch — unless you deliberately order your Dockerfile so dependencies are installed before code is copied in.

Hiring signal: Orders Dockerfile instructions deliberately for cache efficiency, not by accident

What you will learn

Explain the real difference between a container and a VM: shared kernel vs. a full guest OS each
Explain image layers and why Docker caches them
Predict which Dockerfile changes invalidate the build cache, and which don't
Explain why 'reproducible on my machine' and 'reproducible on any machine' are different claims

Introduction

Type: Learn Languages: Docker Prerequisites: Lesson 02 (Virtual Environments and Dependency Management) Time: ~40 minutes

Objective

Learning objectives

Explain the real difference between a container and a VM: shared kernel vs. a full guest OS each
Explain image layers and why Docker caches them
Predict which Dockerfile changes invalidate the build cache, and which don't
Explain why "reproducible on my machine" and "reproducible on any machine" are different claims

What you're building

A small script and its dependencies, containerized:

Write a Dockerfile following this lesson's dependency-first ordering
Build it, then rebuild with zero changes — capture the real output showing every layer CACHED
Change only your application code and rebuild — capture output showing the dependency-install layer stays cached
Change your dependencies file and rebuild — capture output showing the cascade of invalidation from that point forward
Fully tear down (remove the image, prune the builder cache) and rebuild completely from scratch, then run the container and confirm it behaves identically to a direct local run — this is your reproducibility proof, one level deeper than Lesson 02's

A Dockerfile copies the entire project directory (COPY . .) as its very first instruction, before installing any dependencies. What's the practical consequence for build speed?

COPY . . copies the entire project — meaning ANY file changing anywhere (not just dependency files) invalidates this layer, per this lesson's cache rule. Since it's the first instruction, that invalidation cascades through every subsequent layer, including whatever dependency installation comes after it. In practice this means nearly every single build reinstalls every dependency from scratch, regardless of whether dependencies actually changed — the exact slow-build problem this lesson's recommended ordering (dependencies first, in their own narrowly-scoped COPY, application code last) is specifically designed to avoid.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.