Linux and networking for cloud

The server and network basics every cloud service sits on: a Linux shell, SSH keys, IP addresses and CIDR blocks, ports, DNS and HTTPS.

Linux shell essentials

Also called bash, terminal, command line, systemd

What: The commands you use on a cloud server: moving around the filesystem, reading logs, checking disk and memory, managing packages and starting or stopping services with systemctl.
Why: Most cloud virtual machines run Linux and have no desktop. When an app on a VM fails, the shell over SSH is how you find out why.

Shell

df -h                      # disk space
free -m                    # memory
sudo systemctl status nginx
sudo journalctl -u nginx -n 50
sudo apt update && sudo apt install -y nginx
curl -I http://localhost

Watch out

Learning only the provider console and freezing the first time you need to debug a VM from its terminal.

SSH key pairs

Also called SSH, public key, private key, ssh-keygen

What: A private key that stays on your laptop and a public key placed on the server. SSH proves you hold the private key without sending it, so no password crosses the network.
Why: It is the standard way to log in to Linux VMs on every cloud, and the same idea sits behind Git over SSH and many deploy tools.

Shell

ssh-keygen -t ed25519 -C "me@laptop"
chmod 600 ~/.ssh/id_ed25519
ssh -i ~/.ssh/id_ed25519 ubuntu@203.0.113.10

Watch out

Committing a private key to Git or sharing one key between people, so you can never tell who logged in or revoke one person.

IP addresses and CIDR blocks

Also called CIDR, subnet mask, IPv4, prefix length

What: An IPv4 address is 32 bits. CIDR notation such as 10.0.0.0/16 says how many leading bits are fixed; the rest are free, so a /16 holds 65,536 addresses and a /24 holds 256.
Why: Every virtual network and subnet you create asks for a CIDR block. Choosing sizes that do not overlap is what lets networks connect later.

Code

/16  65,536 addresses   whole network, e.g. 10.0.0.0/16
/20   4,096 addresses   large subnet
/24     256 addresses   typical subnet, e.g. 10.0.1.0/24
/28      16 addresses   tiny subnet
Usable in a subnet: AWS and Azure keep 5 addresses,
Google Cloud keeps 4 in each primary range.

Watch out

Giving every network 10.0.0.0/16 so that two of them can never be peered or joined by VPN later.

Private IP ranges

Also called RFC 1918, private address, public IP

What: Three IPv4 ranges are reserved for private networks and never routed on the internet: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Cloud networks use them inside, and give out public IPs only where you ask.
Why: Knowing which addresses are private tells you at a glance whether something is reachable from the internet or only from inside your network.

Watch out

Picking 192.168.1.0/24 for a cloud network, which clashes with most home and office routers once you connect over VPN.

Ports, TCP and UDP

Also called port, TCP, UDP, port 443, port 22

What: A port number picks which service on a machine receives traffic. TCP gives an ordered, reliable connection; UDP sends independent packets. Common ports: 22 SSH, 80 HTTP, 443 HTTPS, 5432 PostgreSQL, 3306 MySQL.
Why: Every firewall rule you write in the cloud is a list of ports, protocols and sources, so you need to know which ones your app actually uses.

Watch out

Opening port 22 or a database port to 0.0.0.0/0, the whole internet, to make a connection error go away.

DNS records

Also called DNS, A record, CNAME, TTL, nameserver

What: DNS turns names into addresses. An A record points a name at an IPv4 address, AAAA at IPv6, CNAME at another name, and TTL says how long resolvers may cache the answer.
Why: Custom domains, load balancers, certificates and email all depend on DNS, and many outages are a wrong or slow-to-update record.

Shell

dig +short app.example.com
dig app.example.com CNAME
nslookup app.example.com 8.8.8.8

Watch out

Changing a record with a long TTL just before a migration, then waiting hours for caches to expire.

HTTPS and TLS certificates

Also called TLS, SSL, certificate, HTTPS

What: TLS encrypts traffic between a client and a server, and a certificate proves the server owns the domain. HTTPS is HTTP over TLS on port 443.
Why: Browsers warn on plain HTTP, and every cloud load balancer and CDN can hold a free managed certificate for you once DNS is right.

Watch out

Managing certificates by hand on each VM and letting one expire, instead of terminating TLS at a managed load balancer.

Go deeper