Cloud, Linux & DevOps Basics

Weeks 1–2 — files, processes and logs. Everything cloud-side begins here, and it is the part candidates skip.

1. Files, paths and permissions

   A Linux path is either absolute from / or relative from where you are. Permissions are the three permissions of owner, group and others — and most "permission denied" errors are fixed by understanding which one you are.

   Example chmod +x deploy.sh makes a script runnable; chmod 644 on a private key exposes it; sudo is not a fix for not knowing why the write failed.

   Practice Create a folder tree, move and rename files, make a script executable, and create a file whose owner cannot read it — then explain to yourself why.

2. Processes, ports and logs

   A running program is a process with an id; a service listens on a port; a log is a file that tells you what happened. Those three sentences are most of production troubleshooting.

   Example When a site is down the questions are the same every time: is the process running (ps), is anything listening on the port (ss -tulpn), and what does the last hundred lines of the log say (tail -n 100)?

   Practice Start a small web server locally, find its process id, find the port it listens on, and kill it — then start it again in the background.

3. Shell scripts that save you time

   A shell script is a list of commands in a file, plus enough logic to make it worth saving. Variables, an if and a loop are 90% of every script you will ever write for a job.

   Example A ten-line script that prints disk usage, deletes log files older than seven days and writes one line to a summary file replaces fifteen minutes of manual work every Monday.

   Practice Write one script that takes a folder name as an argument, counts the files in it and prints a warning if the count is zero.

Weeks 3–4 — versions, reviews and the automated pipeline. Git is a job requirement, not a footnote.

1. Commits, branches and merge conflicts

   A commit is a labelled snapshot; a branch is a movable line of snapshots. A merge conflict is Git refusing to guess which of two edits you meant — and it is normal, not a failure.

   Example Two people editing the same line of the same file produce a conflict block with <<<<<<< markers. Resolving it means choosing or combining the two versions and deleting the markers, then committing the result.

   Practice Deliberately create a conflict between two branches of your own project and resolve it both ways: keeping one side, then keeping both.

2. Pull requests and code review

   A pull request is how a change gets discussed before it lands. One small change, a title that says what it does, and a short description of why — that is a good PR, and nobody cares how much code it contains.

   Example A PR with fourteen unrelated changes cannot be reviewed and will be approved unread, which is worse than no review. Ten small PRs get read.

   Practice Open a PR against one of your own repositories with a proper title and description, then review it as if you were the reviewer and leave two comments.

3. CI: the pipeline that runs your tests

   Continuous integration is a robot that checks every push: it installs the project, runs the tests and reports back. Free on every major host, and it is the answer to "how do you know your code works?"

   Example A GitHub Actions workflow of about fifteen lines runs pytest on every push and shows a green tick beside the commit. That tick is evidence; "it works on my machine" is not.

   Practice Add a workflow to one of your repositories that runs your tests on every push, then break a test on purpose and watch it fail.

Weeks 5–6 — deploy something real, then keep it alive and affordable.

1. What a VM, a bucket and a load balancer are

   A virtual machine is a computer somebody else runs; object storage holds files; a load balancer spreads requests across machines. Three ideas, and the menus in every cloud console are variations of them.

   Example Uploading a file to storage rather than serving it from the application server is why a video site does not fall over. That one design decision comes up constantly in interviews.

   Practice Draw your own project as boxes — server, storage, database — and label which piece would break first under heavy traffic.

2. Deploying a real app to a free-tier VM

   Deployment is: copy the code, install its dependencies, run it under a process manager that restarts it, and open the port. Doing it once by hand teaches more than a hundred deploy-button tutorials.

   Example A service managed by systemd restarts when the machine reboots; a statement started over SSH does not. That difference is why a demo works today and is down tomorrow — and "persist the process" is what fixes it.

   Practice Deploy one of your own projects to a free server, give it a domain or IP, and confirm it still answers after a reboot.

3. Monitoring, costs and what to put on the resume

   Cloud bills surprise people who never looked. A budget alert takes two minutes to configure and is the single most useful thing a beginner can do on any cloud account.

   Example Setting a spending alert at a low amount, knowing where disk usage is, and being able to say "I deployed and monitored it" separates you from candidates who only know the words.

   Practice Set a billing alert, check how much memory and disk your deployment uses, and write three resume bullets on what you built and what you had to fix.

Docker, compose and keeping development and production the same shape.

1. Docker: the same app everywhere

   A container packs the app with the exact versions of everything it needs, so it behaves the same on your laptop and the server. That is the whole point: no more "works on my machine".

   Example docker run -p 3000:3000 app runs the image and maps the port; the Node version inside is fixed by the Dockerfile, not by whatever is on the host.

   Practice Write a Dockerfile for a small Node or Python app, build the image and run it with a mapped port.

2. docker-compose: the whole stack in one file

   Compose starts several containers together - app, database, cache - and wires them to each other by name. One command brings a developer from nothing to a running stack.

   Example In the compose file the app reaches the database at the hostname db, because Compose puts every service on the same network with its service name as the address.

   Practice Write a compose file with your app and a database, and start both with docker compose up.

3. Config and secrets across environments

   The same code runs in development, staging and production; only the configuration differs. Keys, hosts and flags come from the environment, not from code that gets edited by hand.

   Example process.env.DATABASE_URL is set differently on each machine, so the deploy never has to change a line of source.

   Practice Move three hard-coded settings into environment variables and provide a .env.example for the next developer.

HTTPS, safe deploys, uptime checks and what to do when something breaks at 2am.

1. HTTPS, domains and certificates

   A real deployment answers on a domain name over HTTPS with a certificate that renews itself. This is one command with certbot, and it is the difference between a demo and a site.

   Example certbot --nginx -d app.example.com issues the certificate and rewrites the nginx config; the renew timer keeps it valid without you.

   Practice Point a domain at a VM, install a certificate, and confirm the padlock by loading the site.

2. Backups, rollback and zero-downtime deploy

   A deploy you cannot undo is a deploy that will one day cost a weekend. Keep the last good release on disk, keep a database backup, and know the one command that goes back.

   Example Deploying into a fresh release directory and repointing the symlink means the rollback is a single ln -sfn to the previous release.

   Practice Add a rollback step to your deploy script and practise it once on purpose.

3. Uptime checks, alerts and incidents

   Monitoring is a check that runs on a timer and shouts when it fails. If nobody is told, there is no monitoring - and the first time you learn the site is down should not be from a customer.

   Example A cron job that fetches the health endpoint every five minutes and posts to a webhook when it fails turns a silent outage into a message you see.

   Practice Set up one uptime check against a health endpoint and a free alert channel, then take the app down to prove it fires.