Learning Roadmap¶
From zero to production probes in about 15 minutes.
graph TD
A[Level 0: A pico-fastapi app] --> B[Level 1: Install & first curl]
B --> C[Level 2: Your first HealthIndicator]
C --> D[Level 3: Info & configuration]
D --> E[Level 4: Kubernetes probes]
E --> F[Level 5: Testing]Level 0: Prerequisites¶
A working pico-fastapi application booted through pico-boot:
from fastapi import FastAPI
from pico_boot import init
container = init(modules=["myapp"])
app = container.get(FastAPI)
If you do not have one yet, start with the pico-fastapi docs or the examples/minimal/ app in this repo.
Level 1: Install & first curl¶
pip install pico-actuator
uvicorn myapp.main:app &
curl localhost:8000/actuator/health
# {"status":"UP","components":{}}
No code changed — the pico_boot.modules entry point did the wiring.
Level 2: Your first HealthIndicator¶
from pico_ioc import component
@component
class DbHealth:
name = "db"
def __init__(self, engine: Engine):
self.engine = engine
def check(self):
self.engine.connect().close()
return {"status": "UP"}
Re-curl /actuator/health — the db component appears. Kill the database — the endpoint answers 503 with "db": {"status": "DOWN", "error": ...}.
Read: User Guide for return-value forms and failure isolation.
Level 3: Info & configuration¶
Dynamic entries come from InfoContributor components. Read: Getting Started.
Level 4: Kubernetes probes¶
Wire /health/live into livenessProbe and /health/ready into readinessProbe — and understand why they must not be swapped. Read: Kubernetes Probes and ADR-004.
Level 5: Testing¶
Unit-test indicators as plain classes; end-to-end test the endpoints by booting a real container with TestClient. Read: Testing.
Where to go deeper¶
- Cookbook — database indicators, caching checks, securing the endpoints
- Architecture and the ADRs — why it is built this way