Python and Bash for DevOps: What to Learn First

Why scripting comes after Linux and Git

By now, you have typed the same commands many times. That repetition tells you what to automate. It also means you already know what each command should do, so you can focus on the script.

Scripts also fail in ways you must plan for. A script that keeps going after an error can do real damage on a server. Your Git repo gives you a safe place to change scripts and undo mistakes. You will also reuse what you build here at step 5, where your backups need a script.

What to learn, in order

Spend about 2 weeks on the Bash items, then about 3 on Python.

Bash

1. Variables and quoting. Write "$name", not $name. Without quotes, a file name with a space turns into two arguments. That can make rm delete the wrong thing.
2. Arguments. Learn $1, $@ and $#, so one script can work on any folder or server you give it.
3. Exit codes. Every command returns a number, and 0 means success. Check the last one with $?. CI tools use this number to decide whether a job failed. Cron does not act on it, so your script must report its own failures.
4. Tests and loops. Learn if, for, and file checks such as [ -d "$dir" ].
5. Safe defaults. Start scripts with set -euo pipefail. It stops on most command failures, treats unset variables as errors, and catches failures inside pipes. It has exceptions, so still check the steps that matter.
6. Text tools. Learn grep, sed and awk to pull values out of logs and command output. Learn just enough to handle common cases.
7. Scheduling. Learn cron (the Linux tool that runs commands on a schedule). Cron hides output by default on many servers, so send it to a log file.
8. Checking. Run ShellCheck on every script. It finds quoting bugs and other errors that are easy to miss.

Python

1. The core language. Start with the official tutorial. You need variables, lists, dictionaries, loops, functions and reading files. Dictionaries matter most, because JSON loads into them.
2. Virtual environments. A virtual environment gives one project its own packages. Create one with python3 -m venv .venv. On Ubuntu, you may first need sudo apt install python3-venv.
3. Calling APIs. Use the Requests library to call REST APIs (web addresses that programs use to send and receive data). This is where Python starts to beat Bash.
4. JSON. The json module turns text into dictionaries and lists. Then you can read a nested value with a line like data["items"][0]["status"].
5. Error handling and exit codes. Learn try and except, then use sys.exit(1) when a task fails. Without this, a failed tool can look like a success to CI or to a script that calls it.
6. Running commands. subprocess.run calls other programs. Pass check=True, so a failed command raises an error instead of being ignored.
7. Files and arguments. pathlib handles file paths. argparse gives your tool real options and a --help message.
8. One test. Python includes unittest. Test the part that makes a decision, such as "is this certificate close to expiry?", without making real network calls.

Bash vs Python: which to use

Use this rule of thumb, and expect some overlap:

• Use Bash when the job is mostly running other commands in order. A backup, a log cleanup and a deploy helper are good fits.
• Use Python when the job works with data. Calling an API, reading JSON, retrying on failure and writing tests are all easier there.
• Switch from Bash to Python when you need arrays of records, nested logic or tests. Those are signs that the Bash script has outgrown its job.

Here is the same idea of "fail loudly" in each. This Bash script is mostly running commands:

#!/usr/bin/env bash
set -euo pipefail

source_dir="$1"
backup_dir="$2"

if [ ! -d "$source_dir" ]; then
  echo "Folder not found: $source_dir" >&2
  exit 1
fi

backup_file="$backup_dir/backup-$(date +%F).tar.gz"
tar -czf "$backup_file" "$source_dir"
echo "Backup written: $backup_file"

This Python script checks a web reply, so it needs real error handling. Run pip install requests inside your virtual environment first:

import sys

import requests

url = sys.argv[1]

try:
    response = requests.get(url, timeout=5)
    response.raise_for_status()
except requests.RequestException as error:
    print(f"FAIL {url}: {error}")
    sys.exit(1)

print(f"OK {url}: {response.status_code}")

What to skip for now

• Object-oriented design and design patterns.
• Web frameworks such as Django and Flask, beyond what the small API at step 5 needs.
• Algorithm drills and LeetCode. They rarely help you automate a server.
• Go and other extra languages.
• Long comparisons of Python tools. venv, pip and unittest are enough.

Common mistakes

• Using pip install system-wide. Recent Ubuntu versions block this with an externally-managed-environment error, as described in PEP 668. Do not force it. Use a virtual environment.
• Calling an API without a timeout. Requests waits with no time limit unless you set one. A hung server can then hang your cron job too.
• Catching every error and printing it. A script that prints a message and exits with 0 reports success. Exit with a non-zero code when the job failed.
• Putting passwords in scripts. Your scripts are in Git, so read secrets from environment variables instead.
• Writing a 300-line Bash script. If you are building data structures in Bash, move to Python.
• Using Python for everything. Three commands in a row do not need a Python program. A short Bash script is easier to read.

Your project

Build a health-check tool in Python that takes a list of URLs. For each one, it should:

1. Request the URL and report the status code. Use a timeout.
2. Report how many days are left on the TLS certificate. The ssl module can read this.
3. Check free disk space with shutil.disk_usage.
4. Exit with a non-zero code if any check fails.

Add one test, and keep the tool in your Git repo through a pull request. Separately, write the Bash backup script above and run it from cron. Make it send you a message when it fails, by email or a chat webhook (a URL that posts a message to a chat room).

You will use both again: the backup script at step 5, and the health check once you reach observability.