Week 6 Day 4 — NETW-0014

0:00–0:10
Recap

0:10–1:45
Capstone

1:45–2:00
Debrief

0:00 – 0:10Recap · 10 min

Map the full chain before writing a single line of config

Draw the architecture on the board before opening any terminals:
1. Browser → https://app.yourname.net
2. DNS (Week 3): app.yourname.net → S1's external IP (172.17.x.x)
3. Nginx (Week 4): listens on 443, matches server_name app.yourname.net, terminates SSL
4. proxy_pass (new today): Nginx forwards the request to http://127.0.0.1:8080
5. Docker (Week 6): a container listening on port 8080 handles the request
6. Response travels back through the same chain
Ask: "What pieces are already built and working?" — DNS zones (Week 3), Nginx with SSL on yourname.net (Week 4). What's needed today: (1) the Docker container on port 8080, (2) the proxy_pass location block in Nginx, (3) a DNS A record for app.yourname.net.

0:10 – 1:45Capstone Lab · 95 min

Lab 6D — Deploy a Docker web app, proxy through Nginx, wire up DNS

Part 1 — Deploy the Docker web application (20 min)

Create a simple application to containerise. The simplest option is an Nginx container serving a custom page that distinguishes it from the host Nginx:
mkdir -p ~/app && echo "<html><body><h1>Served from Docker</h1><p>Container: app.yourname.net</p></body></html>" > ~/app/index.html
Create a docker-compose.yml for the application:
mkdir -p ~/docker/app && nano ~/docker/app/docker-compose.yml
services:
app:
image: nginx
ports:
- "8080:80"
volumes:
- ~/app:/usr/share/nginx/html:ro
restart: unless-stopped
Start it: docker-compose up -d (from ~/docker/app/). Verify: curl http://localhost:8080 — should return the "Served from Docker" page. Check: docker-compose ps — service Up.

Part 2 — Add a DNS record for app.yourname.net (15 min)

Add an A record to the yourname.net zone files. Edit both the internal and external zone database files on S1:
In the internal zone: app A 192.168.50.1 (internal clients go directly to S1's LAN1 IP)
In the external zone: app A 172.17.[S1-external] (external clients use S1's external IP)
Increment the serial number in both zone files. Reload BIND9: sudo systemctl reload named. Verify: dig @192.168.50.1 app.yourname.net — should return the internal IP. From Windows: nslookup app.yourname.net [S1-external-IP] — should return the external IP.

Part 3 — Configure Nginx reverse proxy for app.yourname.net (30 min)

Create a new Nginx server block for app.yourname.net. Create the file:
sudo nano /etc/nginx/sites-available/app.yourname.net
Write the server block — HTTP redirect and HTTPS proxy:
server {
listen 80;
listen [::]:80;
server_name app.yourname.net;
return 301 https://$server_name$request_uri;
}

server {
listen 443 ssl;
listen [::]:443 ssl;
include snippets/self-signed.conf;
include snippets/ssl-params.conf;
server_name app.yourname.net;
access_log /var/log/nginx/app.yourname.net.access.log;
error_log /var/log/nginx/app.yourname.net.error.log;

location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Explain the proxy headers: proxy_set_header directives pass the original client information to the backend container. Without them, the container would see every request appearing to come from 127.0.0.1. With them, X-Real-IP carries the actual client IP, which the container can log and act on.
Enable the site: sudo ln -s /etc/nginx/sites-available/app.yourname.net /etc/nginx/sites-enabled/
Test and reload:
sudo nginx -t — must pass.
sudo systemctl reload nginx

Part 4 — End-to-end verification (30 min)

Point the Windows host DNS at S1's external IP. Browse to https://app.yourname.net. Accept the certificate warning (same self-signed cert as yourname.net). The "Served from Docker" page should appear. The full chain is working.
Verify each component in the chain:
· DNS: nslookup app.yourname.net [S1-external-IP] returns S1's external IP ✓
· Nginx: sudo nginx -t passes, sudo systemctl status nginx shows active ✓
· proxy_pass: curl -k https://localhost/ with Host header: curl -k -H "Host: app.yourname.net" https://localhost/ returns the Docker app page ✓
· Docker: docker-compose ps from ~/docker/app/ shows app service Up ✓
· Logs: sudo tail -f /var/log/nginx/app.yourname.net.access.log — watch entries appear as you reload the browser ✓
Check the Docker container saw the request: docker-compose logs app — should show the Nginx access log entry for the proxied request.

Capstone complete when: app.yourname.net DNS record resolves. http://app.yourname.net redirects to HTTPS. https://app.yourname.net shows the "Served from Docker" page. Access log shows entries. docker-compose logs shows the container received the request. All verified live.

1:45 – 2:00Debrief · 15 min

Course arc reflection and Week 7 preview

Walk through what just happened: a browser on the classroom network resolved a domain name, which routed through a firewall, hit an Nginx server that terminated SSL and forwarded the request to a Docker container, which returned the response. All built from scratch over six weeks. Students who understand every piece of this chain — and they do, because they built each piece — have demonstrated real sysadmin competency.
The services inventory: SSH hardened with key auth and fail2ban (Week 1). Network analysis, firewalling, NTP, and centralised logging (Week 2). DHCP and DNS with secondary server (Week 3). Nginx with SSL and log-driven troubleshooting (Week 4). IPSec and WireGuard VPNs (Week 5). Docker containers with compose (Week 6). Six weeks of infrastructure, all running on three VMs.
Week 7 preview: four review days (Mon–Thu), then a single-sitting final exam Friday — 20 minutes written, 100 minutes practical. The practical uses these same VMs. Students who kept their environments healthy throughout the course arrive at the exam with working infrastructure and just need to demonstrate competency with a new scenario. Students who let services drift will need Thursday's open lab time to fix things before Friday.

Learning outcomes — by end of Day 4, students can…

Configure Nginx as a reverse proxyWrite a proxy_pass location block with correct proxy headers and verify requests reach the backend container

Add a DNS record for a containerised serviceUpdate both internal and external zone files with a new A record, increment the serial, and verify resolution

Verify an end-to-end service chainConfirm each layer (DNS → Nginx → proxy_pass → Docker) is working using targeted diagnostic commands

Read proxy logs for both Nginx and DockerIdentify which layer handled a request by reading access.log and docker-compose logs simultaneously

Common issues and fixes

Issue	Likely cause	Fix
Nginx returns 502 Bad Gateway	Docker container not running, or proxy_pass pointing to wrong port	Check: docker-compose ps — is the app service Up? Check: curl http://localhost:8080 — does it return the app page directly? If not, container issue. If yes, proxy_pass port is wrong in the Nginx config
Browser shows yourname.net page instead of app page	server_name in the app.yourname.net block doesn't match the hostname, or symlink not created	Check: sudo nginx -T \| grep server_name — app.yourname.net should appear. Check: ls /etc/nginx/sites-enabled/ — symlink should exist
DNS record for app.yourname.net not resolving	Serial number not incremented, or named not reloaded after zone file change	Verify serial is higher than before in the zone file. Reload: sudo systemctl reload named. Check: dig @192.168.50.1 app.yourname.net

← Day 3 Lab 6D Handout Day 5 →