DevOps Bot

A complete Kubernetes delivery pipeline — build, deploy, monitor, alert, log — built around a deliberately trivial Flask service.

The application is not the point. It is a small "bot" that generates a payload of a requested size and forwards it to other bots along a tree of addresses, which makes it easy to produce traffic, latency and failures on demand. Everything worth reading here is the infrastructure that ships and observes it: Helm charts, werf builds, Flux GitOps, Prometheus alert rules, and a Loki logging stack.

The application

Three endpoints plus metrics:

Endpoint	Method	Purpose
/hello	GET	plain text, for smoke-testing a deployment
/send_data	POST	entry point — generates payloads and dispatches them
/receive_data	POST	bot-to-bot hop, same body format
/metrics	GET	Prometheus exposition

The request body is a recursive tree: each entry names an address to send to, a human-readable size, and its own nested addresses to forward on to.

{
  "addresses": [
    {
      "address": "http://testbot-2:5000",
      "size": "10kB",
      "addresses": [
        { "address": "http://testbot-3:5000", "size": "5kB", "addresses": [] }
      ]
    }
  ]
}

Bot 1 sends 10 kB to bot 2, which then sends 5 kB onward to bot 3. Payloads are os.urandom base64-encoded to the requested size, so traffic volume is controlled precisely.

The infrastructure

Build — werf (werf.yaml) builds the image from the Dockerfile and drives the Helm release, so build and deploy are one step tied to the git state.

Deploy — three Helm charts, each independently installable:

Chart	Contents
app-chart	the Flask deployment, service, service account, plus Grafana / Loki / Promtail values
prometheus-chart	Prometheus deployment, scrape config, RBAC, alert rules
alertmanager-chart	Alertmanager deployment and service

GitOps — clusters/production/flux-system holds the Flux toolkit components and sync configuration, so the cluster reconciles itself from this repository rather than from kubectl apply.

Monitoring — Prometheus scrapes the app's /metrics and evaluates two alert groups:

• InstanceDown — up == 0 for 1 minute, severity critical
• TooManyRequestsToHello — flask_app_requests_hello > 10 for 30 seconds, severity warning, an application-level metric rather than an infrastructure one

Alerts route to Alertmanager; Grafana renders the dashboards.

Logging — Promtail ships container logs to Loki, queried from the same Grafana instance.

Local cluster — the Vagrantfile provisions Ubuntu VMs with Docker and Kubernetes 1.32 from scratch, so the whole stack can be brought up locally without a cloud account.

Stack

App · Python 3.9 · Flask 3 · prometheus-client · APScheduler · confuse

Infra · Kubernetes · Helm · werf · Flux · Prometheus · Alertmanager · Grafana · Loki · Promtail · Docker · Vagrant

Quick start

Run the app on its own:

pip install -r src/requirements.txt
python src/main.py

Or the whole stack in containers:

docker compose up -d

Deploy to a cluster with werf:

werf converge

Or install a chart directly:

helm install devops-bot ./app-chart -f app-chart/app.values.yaml
helm install prometheus ./prometheus-chart
helm install alertmanager ./alertmanager-chart

Bring up a local Kubernetes cluster first if you need one:

vagrant up

Linting

ruff check --per-file-ignores="__init__.py:F401"

License

MIT