Skip to content

Project · DevOps: Git, Docker, Kubernetes and CI/CD

Project: monitor and secure a clinic appointments API

Projectexpert· about 6 hours· 8 steps

The brief

Arogya Clinic's booking API sometimes fails when its SMS gateway is flaky. You scan its image before release, scrape it with Prometheus, measure the failures with PromQL, write and test an alert rule, watch it fire, work out the error budget and burn rate for its SLO in JavaScript, and write the blameless postmortem.

Why it matters

Keeping a service reliable once it is live is what SRE and senior DevOps roles are paid for: scanning images in the pipeline, metrics and alerts that wake the right person for the right reason, SLOs that turn "is it good enough?" into a number, and postmortems that fix the system instead of blaming people. Interviews for these roles ask you to write PromQL and explain burn-rate alerts.

Skills you practise

  • Trivy image scanning
  • non-root images
  • Prometheus scraping
  • PromQL: sum by, rate
  • alert rules and promtool
  • SLOs, error budgets and burn rates
  • blameless postmortems

You need

  • Docker Desktop or Docker Engine with the Compose plugin
  • Trivy (brew install trivy, apt or the official install script, or run it as the aquasec/trivy container)
  • A bash-style terminal: on Windows use Git Bash or WSL

What you will have at the end

A monitored clinic API: the scan gate command, prometheus.yml, a promtool-checked alerts.yml with an alert you watched fire, slo.js with tested error-budget and burn-rate maths, and a blameless postmortem.

How it is marked (rubric, 100 points)
Monitoring worksThe target is up, the PromQL counts are right, promtool passes and the alert reached firing.35
Security gateThe image runs as non-root and passes the Trivy gate; you can explain --ignore-unfixed and --exit-code.15
SLO mathsslo.js passes every test; you can explain why paging uses two windows.20
PostmortemBlameless, specific numbers and times, causes in the system, owned and dated actions.20
Good alertingThe alert is on a user symptom, has for:, a severity label and a runbook pointer.10

0/8 steps done

Step 1 of 8

Gate the image: non-root and no fixable criticals

clinic-api:1.0.0 runs as a non-root user, and Trivy finds no fixable CRITICAL vulnerabilities in it.

Before an image is released, the pipeline checks it. Build clinic-api:1.0.0 from the files. The Dockerfile already sets USER 10001; the inspect command proves it.

Trivy compares the packages in the image with public vulnerability databases. --severity CRITICAL --ignore-unfixed --exit-code 1 makes it fail only for critical problems that already have a fix, which is the usual release gate: you can act on those today. If the gate fails, rebuild with docker build --pull to get the patched base image, and scan again.

Run this on your machine, then paste the output below
$ docker image inspect clinic-api:1.0.0 --format 'user={{.Config.User}}'; trivy image --severity CRITICAL --ignore-unfixed --exit-code 1 --quiet clinic-api:1.0.0 > /dev/null; echo "trivy exit=$?"
Your notes: prometheus.yml, alerts.yml, slo.js, postmortem.md

Write down each command you ran. It goes into your project summary.