How apps find and talk to each other — the last foundation before containers.
Module 5 · IPs, ports, DNS, HTTP, SSH. Free · Local.
Beginner Foundations ~45 minlocalhost:8080 means what it doescurl, ping, dig, and ssh to inspect and connectPrerequisites: Module 2 (Linux). This is the final foundation before Docker.
Every DevOps problem eventually becomes a networking problem. "The container won't load." "The app can't reach the database." "The service is up but I can't connect." All networking. A little knowledge here saves hours of confusion in later modules.
Containers talk to databases over the network. Kubernetes Services route traffic over the network. Your browser reaches a server over the network. Once you understand addresses, ports, and names, the rest of the course's "magic" becomes obvious.
One program (the client, e.g. your browser) sends a request; another (the server, e.g. the notes app) sends a response. That's the whole pattern.
An IP address identifies a machine (like a street address). A port identifies a specific program on it (like an apartment number). Together they pinpoint exactly where to deliver a message.
| Thing | Meaning |
|---|---|
127.0.0.1 / localhost | "This very machine." Used constantly in development. |
0.0.0.0 | "All network interfaces" — lets outside traffic reach a server (you saw this in Docker!). |
Port (e.g. :5000) | Which program receives the traffic. 0–65535. |
localhost:8080 | "Program on port 8080, on this machine." |
22 SSH · 80 HTTP · 443 HTTPS · 5000 the Flask app · 5432 PostgreSQL · 9090 Prometheus · 3000 Grafana · 6443 the Kubernetes API.
Humans remember names; computers need numbers. DNS (Domain Name System) is the internet's phone book — it translates github.com into an IP address. This is also how containers find each other by service name (Modules 7 & 8): a built-in DNS resolves db to the database's address.
HTTP is the language browsers and web apps speak. A request has a method and a path; a response has a status code.
| Method | Means |
|---|---|
GET | Fetch something (your notes list) |
POST | Create something (add a note) |
PUT / PATCH | Update something |
DELETE | Remove something |
| Status | Means |
|---|---|
2xx (200, 201) | Success ✅ |
3xx (301, 302) | Redirect — go look elsewhere |
4xx (404, 403) | You messed up — not found / forbidden |
5xx (500, 503) | The server messed up — an error/crash |
HTTPS is just HTTP wrapped in TLS encryption so nobody can read traffic in transit. It's the default on the real internet (you'll add it in Module 13's challenge).
Open your terminal. These commands are read-only and safe — they're the ones you'll reach for when debugging connectivity all course long.
curlcurl is a command-line browser — your #1 tool for testing whether a server responds.
You just saw a human name turn into a machine address — exactly what happens billions of times a second across the internet.
A successful ping means the machine is reachable. If ping works but curl fails, the server program (or its port) is the problem, not the network — a hugely useful debugging split.
Which programs hold which ports on your machine? (Great for "port already in use" errors.)
See the client–server model live. In one terminal, start a quick web server; in another, curl it.
You're running a server and connecting to it by IP+port. That's exactly what you'll do with containers — just packaged. Press Ctrl+C in terminal 1 to stop.
When Module 6 says -p 8080:5000, you'll now understand it precisely: map port 8080 on your machine to port 5000 inside the container. It's just addresses and ports.
SSH gives you a secure terminal on a remote server — how you'll reach your cloud VM in Module 13.
SSH keys are far safer than passwords. You generate a key pair (ssh-keygen), keep the private key secret, and put the public key on the server. Same keys also authenticate you to GitHub.
A firewall decides which ports the world can reach. On a cloud server you open only what you need — e.g. 22 (SSH), 80 (HTTP), 443 (HTTPS). Everything else stays closed.
Nine times out of ten in the cloud, the server is fine but the firewall hasn't opened that port. You'll hit (and now recognize) this exact issue in Module 13.
| Command | What it does |
|---|---|
curl <url> | Make an HTTP request (test a server) |
curl -i <url> | Include status + headers |
ping -c 4 <host> | Test reachability |
dig +short <name> | Resolve a name to its IP |
nslookup <name> | DNS lookup (alternative) |
ss -tlnp | List local listening ports (Linux) |
lsof -i -P -n | grep LISTEN | List listening ports (macOS) |
ssh user@host | Open a secure shell on a remote machine |
ssh-keygen | Generate an SSH key pair |
ip a / ifconfig | Show your machine's IP addresses |
| Symptom | Likely cause & fix |
|---|---|
Connection refused | Nothing is listening on that port — is the server running? Right port? |
Connection timed out | A firewall is blocking it, or the host is unreachable. |
Could not resolve host | DNS problem — check the name spelling and your internet. |
404 Not Found | Server is up, but that path doesn't exist. |
port already in use | Another program holds it — find it with ss -tlnp / lsof. |
| ping works, curl doesn't | Network is fine; the server program or its port is the issue. |
curl to fetch only the HTTP status code of three different websites.ip a (or ifconfig).python3 -m http.server on port 9000 and reach it from your browser.dig to find all the IPs behind google.com..pub file.Explain the client–server model, IPs and ports, DNS, and HTTP — and use curl, dig, ping, and ssh to inspect and connect. You'll lean on every one of these in the modules ahead.
You've completed all five foundations: DevOps culture, Linux, Bash, Git, and Networking. That's everything you need to start the hands-on tooling track.
Next up: Module 6 — Docker, the "aha!" moment of DevOps. You'll package the notes app into a container that runs anywhere.