TEK2 · Teaching Videos

Before containers: every project has a different set of dependencies, and every machine runs a different combination. Walk through three escalating versions of the 'works on my machine' problem and see why packaging the whole environment is the fix.

VMs package a full virtual computer; containers share the host kernel and package only the userspace. The architectural difference drives everything else — size, speed, and what runs where.

Images are recipes (immutable files on disk); containers are meals (running instances). Walk through what happens when you docker run — twice — and see why the image never changes.

Students copy-paste `docker run` commands forever but rarely understand each flag. Dissect it from the bare minimum to a real-world web server, one flag at a time.

Every beginner makes this mistake: they want to poke inside a running container and type `docker run` again, creating a second container by accident. One quick, focused video on the one distinction that stops the confusion forever.

Containers are Linux, and Linux puts everything in one tree starting at /. A guided tour of the directories you'll actually meet this semester — and the three commands that let you move around.

A container isn't just 'running' or 'not running'. It has a lifecycle: created, started, maybe paused, stopped, eventually removed. Knowing the transitions — and which command triggers each — makes everything else in Docker obvious.

The first time you run a database in Docker, create some data, and then docker rm the container, the data is gone — and it feels like Docker ate your homework. This video explains why: a container's filesystem is a stack of read-only image layers with one writable layer on top. That writable layer belongs to the container, and docker rm deletes it. Once you see the diagram, the behavior is obvious and volumes are the natural fix.

You'll write dozens of Dockerfiles. Before that becomes muscle memory, it helps to really understand what each of those ALL-CAPS words means. Walk through FROM, WORKDIR, COPY, RUN, EXPOSE, CMD — one at a time — then watch them assemble into a real Dockerfile.

You wrote a Dockerfile — now turn it into a real image. Dissect `docker build -t name:tag .` piece by piece: what the context folder really is, how name and tag work, why multiple tags can point at one image ID, and what :latest actually means. Finishes with a quick look at pushing to Docker Hub.

The previous video showed that docker rm eats your data. Volumes are the fix — but Docker's -v flag is overloaded and does two completely different things depending on what you put on the left-hand side. This video explains named volumes (Docker manages the storage, data survives docker rm) and bind mounts (a folder on your laptop appears inside the container, great for live code editing), shows both in action, and gives you a simple rule for picking the right one: database data goes in a named volume, source code and config files go in a bind mount.

The Flask container connects to Postgres with host equal to db — and it just works. There's no DNS entry for 'db' anywhere on your machine. How? Compose silently creates a default network for the project, attaches every service to it, and Docker runs a tiny DNS server that resolves service names to container IPs. This video walks through that invisible machinery, proves it with docker exec, then shows how custom networks let you isolate frontend from backend.

Real apps are never just one container — you need nginx and postgres and probably redis too. Writing a dozen docker run commands with all the flags gets miserable fast. Docker Compose is a single YAML file that describes every container, network, and volume your app needs, and one command brings them all up together. Walk through a minimal one-service file, add a second service, then tour the anatomy of a realistic web + postgres compose file.

Your first Docker build takes two minutes. You change one line of Python, rebuild, and it takes two minutes again. It shouldn't — Docker caches every layer. This video explains what a layer actually is, when Docker reuses a cached layer vs. rebuilds it, and the one trick that turns a two-minute rebuild into a five-second one: copy your dependency file and install before copying the rest of your source.

Before touching any YAML: what problems does CI/CD actually solve? Walk from one developer forgetting to run tests, through two developers whose code passes alone but breaks together, to a full pipeline where every push builds, tests, and deploys automatically.

You type mvn package and a hundred lines of output scroll by. What's actually happening? Maven has a fixed sequence of phases — validate, compile, test, package, verify, install, deploy — and running any phase runs all phases before it. Walk through what each phase does, why mvn test also compiles, and what mvn clean package really means.

One Hello World compiles fine by hand. Add a library, then a library that needs another library, then a team — and compiling by hand falls apart. Walk through the pain points a build tool removes: dependency management, compilation consistency, testing, and packaging. End with what Maven (and Gradle) actually provides.

You've cloned your first Maven project and you're staring at a pile of folders you didn't create and a file called pom.xml. This video walks through both. First the Standard Maven Directory Layout — src/main/java, src/main/resources, src/test/java, target — and why Maven's 'convention over configuration' means following the layout saves you hours. Then the POM: the coordinates that identify every Maven project on the planet (groupId, artifactId, version), the dependencies block, scopes, and a complete realistic pom you can read line by line.

Walk through the structure of a .github/workflows/ci.yml file. Start with where the file lives, then a minimal workflow, then the parts explained one by one — name, on, jobs, runs-on, steps — then uses vs run, the common actions, and finally a real Maven CI workflow. Ends with what actually happens when you push.

You don't actually need to install Maven on your laptop. Docker Hub hosts an official Maven image that already contains Maven and the JDK, and you can run any mvn command from a container in a single docker run line. Walk through the canonical command flag by flag — the bind mount that shows your project to the container, the working directory, and the auto-cleanup flag — then fix the obvious problem (every run re-downloads the world) by mounting your local Maven cache. Finally, show how this graduates into a production-grade multi-stage Dockerfile that builds the JAR in one stage and ships it in a small runtime stage.

You wrote a perfectly good workflow, pushed it, and nothing happened. The on block controls when your workflow runs — push, pull_request, schedule, workflow_dispatch. Walk through each trigger with a concrete example so you know which one you need.

A red X appears on your commit. Now what? Walk through three kinds of CI failures — a test failure, a compile error, and the dreaded works-locally-fails-in-CI — and the systematic way to read the Actions log, find the actual error, and fix it.

Three flavors of cloud, one pyramid. SaaS gives you a finished app; PaaS gives you a platform that runs your code; IaaS gives you a raw server you have to configure. Who is responsible for what — and why this course lives in IaaS land.

A VM is a software-simulated computer running on top of a real one. One beefy physical server hosts many VMs, each thinking it has the whole machine to itself. This video builds the mental model you need before you rent your first cloud VM.

Two files, a public key and a private key, together replace your password. Walk through what each file is, where it lives, and the challenge-response dance that convinces the server you are who you say you are — without ever sending anything secret over the network.

The practical side of SSH. The ssh command itself, the known_hosts fingerprint prompt, scp for copying files, and what to do when 'host key verification failed' flashes red.

sudo apt update. sudo apt upgrade. sudo apt install. Three verbs that do three different things — and the one everyone misreads. What each actually does, why update alone never installs anything, and why you always run update before install.

Linux runs lots of background services — ssh, nginx, docker — and systemd is the thing that keeps them alive. systemctl is how you talk to it. Status, start, stop, restart, enable. And how to peek at logs with journalctl.

A firewall decides which ports are reachable from the outside world. ufw makes that setup almost gentle. But there's exactly one way to lock yourself out of your own server — by enabling ufw before allowing SSH. This video shows the safe order and the story you never want to live.

You git push. GitHub Actions builds your image, pushes it to GHCR, then SSHes into your server and restarts the container. The big picture of how weeks 1-4 fit together — Docker, Compose, Maven, GitHub Actions, SSH — all connecting into one push-to-deploy pipeline.

Your laptop has two addresses. A street address — the IP — that works anywhere on the internet. And a lot number — the MAC — that only means something to your local network. Walk through why both exist, and what ARP does in the middle.

Your laptop says 192.168.1.42. The internet sees a totally different number. Why? NAT. Plus the three private ranges, why Docker uses 172.17, and what localhost and 0.0.0.0 actually mean.

An IP address gets a packet to the right machine. A port decides which application on that machine should handle it. Well-known ports, ephemeral ports, and the socket pair that uniquely identifies one connection.

Two transport protocols. TCP is registered mail — it sets up a connection, numbers packets, resends lost ones. UDP is shouting across the room — fire and forget. Which one you want depends on what you're doing.

Before any data flows over TCP, the client and server shake hands. Three packets: SYN, SYN-ACK, ACK. This video shows the exchange, explains why three (not two), and hints at what sequence numbers do.

The -p flag says: forward host port 8080 to container port 80. This video shows what that looks like, why two containers can't both bind host port 8080, and how to run many containers of the same image on different host ports.

Docker runs its own tiny DNS server, but only on user-defined networks. That's why Compose quietly creates one. This video explains the default bridge, why container-to-container name resolution doesn't work on it, and the one fix — docker network create.

Open Wireshark, pick an interface, start capturing. Then filter — icmp for ping, tcp.port==80 for HTTP. This video gets you oriented, away from the scary packet ocean, and into useful filtered views.

HTTP looks magical until you see what it really is: plain text. One request with a method, a path, and a pile of key-value headers. One response with a status line and more headers. That's it. Once you see it on the wire, HTTP is demystified forever.

Every URL has a scheme, a host, optionally a port, a path, and optionally a query string. This video breaks down a real URL piece by piece — and explains why http:// implies port 80 and https:// implies port 443.

Four methods cover most of what you'll ever need. GET reads. POST creates. PUT updates. DELETE deletes. This video maps them to the CRUD pattern REST APIs live on, and explains why GET never carries a body.

Three digits on every HTTP response, grouped into five families. 1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error. The first digit tells you almost everything.

curl is the universal HTTP client. This video walks the five flags that cover 95% of what you'll ever type: URL alone, -v, -X POST, -d, -H, -I, -L.

The single most convincing argument for HTTPS. Watch a plain HTTP login expose the password in a Wireshark packet. Then watch the same login over HTTPS — bytes of encrypted static. This is why HTTPS matters.

Headers are how clients and servers share metadata. Content-Type, Content-Length, User-Agent. And cookies — Set-Cookie on the way down, Cookie on the way back up — are how stateless HTTP fakes statefulness for logins.

Press F12. Click Network. Now you can see every HTTP request your browser makes, the headers, the payload, the response, the cookies, the timing. The single best debugger built into the browser.

You type google.com, not 142.250.74.46. Something translates human-friendly names to IP addresses before any TCP handshake can happen. That something is DNS. This video sets up everything else in Week 9 by showing where DNS fits in the request flow.

DNS isn't one giant server in a basement somewhere. It's a tree — root at the top, .com and .dk on the next level, then google.com and github.com below. A resolver walks that tree on your behalf every time you open a site. This video shows the tree and the recursive walk step by step.

DNS doesn't just map a name to one IP. It has a whole menu of record types — A for IPv4, AAAA for IPv6, CNAME for aliases, MX for mail, NS for delegation, TXT for verification. This video walks through each one with a real use case.

dig is the practical tool for inspecting DNS. This video walks through the essential invocations — the default output, +short, specifying record type, choosing a resolver with @, and +trace for the full recursion. Gives you the mental model to read the ;QUESTION, ;ANSWER, and ;AUTHORITY sections.

Every DNS record has a TTL — time to live — that says how long answers can be cached. Browser, OS, resolver, everybody caches. That's why moving a site to a new server doesn't take effect everywhere immediately. This video shows the cache chain and the pro trick of lowering TTL before a migration.

Click the padlock and you see 'Issued to: github.com'. What's actually stored in a TLS certificate? This video walks through the fields — subject, issuer, validity dates, public key, SAN entries, signature — and shows how to dump them yourself with openssl.

A server cert alone isn't trusted — your browser has never heard of the issuing company. So why do you see a padlock? Because the issuer was vouched for by someone else, who was vouched for by a root CA your OS trusts. Three levels of signatures. This video walks the chain.

Ten years ago, HTTPS certificates cost money and had to be renewed by hand. Then Let's Encrypt appeared and gave them away for free, automated. This video explains how it works — the ACME protocol, the HTTP-01 and DNS-01 challenges, and why certificates now expire every 90 days.

Type github.com. By the time the page appears, your laptop has done DNS, a TCP handshake, a TLS handshake with certificate verification, and finally an HTTP request. This video stitches every week together — DNS from week 9, TCP from week 5, TLS from week 9/10, HTTP from week 8 — into one six-step timeline.

Symmetric encryption uses one shared key for both sides of a conversation. AES is the workhorse — fast enough for gigabytes per second. This video builds the 'one key' mental model with a padlocked box analogy, an openssl demo, and the 2^256 keyspace intuition.

Symmetric encryption is useless unless both sides share the same key — and for centuries, sharing that key safely was hands-down the hardest problem in cryptography. This video motivates the whole idea of asymmetric encryption by making the problem feel impossible.

Two mathematically linked keys — a public one you share freely and a private one you guard. Anything encrypted with the public key can only be decrypted with the private key. That one property solves the key distribution problem that stumped cryptographers for centuries.

TLS is the best of both worlds. It uses slow asymmetric encryption once — to safely agree on a shared symmetric key — then switches to fast symmetric encryption for everything after. This video walks the seven-step handshake and stitches weeks 8, 9, and 10 into one mental model.

Encryption uses the public key to lock and private to unlock. Signatures flip it: private key signs, public key verifies. That asymmetry proves who wrote the message and that it wasn't tampered with — the foundation of TLS cert trust, SSH, and Git commits.

A hash is a fixed-size fingerprint of any input. Deterministic, irreversible, avalanche-sensitive. This video clears up the #1 security confusion (hashing is NOT encryption) and shows four places hashes run the world: passwords, downloads, signatures, git commits.

You've used SSH keys since week 4. Now you have the crypto vocabulary to see what's really happening. Your id_ed25519 file is an asymmetric key pair. Logging in is a digital signature. This video closes the loop with the math under the hood.

GPG is the hands-on playground for asymmetric crypto. Generate keys, exchange public keys, encrypt a file to a recipient, sign a message. This video walks the commands that turn the theory of weeks 9/10 into something you can run yourself.

Everyone types chmod 600 or chmod 755 and nods sagely. This video decodes it: owner/group/others, the rwx bits, octal math, and the patterns you'll actually need — 600, 644, 700, 755. The foundation of Linux security.

A single map for everything you already know about networking. The seven layers and how they stack together to send one HTTPS request.

IPv4 gave us 4 billion addresses. The internet blew past that decades ago. IPv6 gives us 340 undecillion. This video explains the format, the abbreviation rules, link-local vs global, and why you keep seeing fe80:: on your laptop.

A VPN wraps your network traffic in an encrypted tunnel, making it look like one point-to-point link between your device and the VPN endpoint. Useful for reaching private networks, bypassing censorship, and not leaking traffic on hostile Wi-Fi.