Scripts that fail loudly
Python for automation
An automation script has one job: return a status that can be trusted. That means a pinned environment, an explicit interface, and an exit code that is non-zero when the thing it checked is broken.
A pinned environment is a reproducible one
A virtual environment isolates the interpreter from the system, and a pinned requirements file fixes the versions you tested. Without both, the script that worked in March is a different script in June.
`python3 -m venv` plus `pip install -r requirements.txt` is the whole discipline — the same shape as a Dockerfile, without the container.
Interfaces and exit codes
`argparse` makes the inputs explicit, so the script can be called by a human and by a scheduler without editing it. A hidden constant is a script that only works for its author.
Exit codes are the contract with whatever runs the script: 0 for healthy, non-zero for not. A script that prints an error and exits 0 is worse than one that crashes.
Commands in this lesson
Every one of these runs in the sandbox — no real account, no real bill.
| Command | Why |
|---|---|
python3 -m venv /opt/venv | Isolate dependencies from the system interpreter. |
pip install -r requirements.txt | Install the pinned set you tested against. |
echo 'parser.add_argument("--url", required=True)' >> healthcheck.py | Explicit input; no editing the script to change the target. |
echo ' sys.exit(1)' >> healthcheck.py | The failure signal a scheduler or CI can actually read. |
echo ' response = requests.get(url, timeout=5)' >> healthcheck.py | A timeout turns a hang into a diagnosable failure. |
Now do it
Reading the model makes the first attempt faster. Only the lab makes you able to do it.
- Open the lab
Python: Build a Health-Check CLI
Intermediate · 25 min · members
Python for automation · OphirCloud Academy · all lessons