Eine echte Datenbank neben dem Job – für Tests, die mehr prüfen als Funktionen.
services: startet dafür einen Begleit-Container, der nur für
die Dauer des Jobs lebt. Das ist der Standardweg für Integrationstests in CI.
test:
runs-on: docker
container: python:3.12-slim
services:
db: # Name = Hostname im Netzwerk
image: postgres:16
env:
POSTGRES_PASSWORD: secret
POSTGRES_DB: tasks
env:
DATABASE_URL: postgres://postgres:secret@db:5432/tasks
steps:
- uses: actions/checkout@v4
- run: pip install -r requirements.txt
- run: pytest -q tests/integration
db – darum lautet der Host in
DATABASE_URL ebenfalls db, nicht localhost. Job-Container und
Service-Container teilen sich ein Docker-Netzwerk; sie erreichen sich über den Service-Namen.
Das ist ein häufiger Stolperstein für alle, die localhost erwarten.
Ein gestarteter Postgres-Container ist nicht sofort verbindungsbereit. Robuste Pipelines warten per Healthcheck oder kurzer Retry-Schleife, bevor die Tests loslegen:
- run: |
until pg_isready -h db -U postgres; do sleep 1; done
services: als Liste von Images
Host = Image-/Alias-Name
Job läuft im image:
services: als benannte Map
Host = Service-Name (Schlüssel)
Job läuft im container:
Frage: Die DATABASE_URL zeigt auf
postgres://…@localhost:5432/…, der Service heisst db. Warum scheitert die
Verbindung?
Der Host muss db sein (der Service-Name), nicht localhost.
Service- und Job-Container sind getrennte Hosts im selben Netzwerk.
Aufgabe: Füge dem Test-Job einen zweiten Service cache mit
redis:7 hinzu und gib eine passende REDIS_URL an.
services:
db: { image: postgres:16, env: { POSTGRES_PASSWORD: secret } }
cache: { image: redis:7 }
env:
REDIS_URL: redis://cache:6379/0
Host = cache (der Service-Name). Mehrere Services laufen parallel.
Unter welchem Host erreichst du den Service db?
Der Schlüssel unter services: ist der Hostname im gemeinsamen Netzwerk.
localhost wäre der Job-Container selbst.
Wie lange lebt ein Service-Container?
Services sind an den Job gebunden und werden danach verworfen – jeder Lauf bekommt eine frische DB.
services (image, env, options, Healthcheck).
services-Definition – wir bringen die DB-Verbindung zum Laufen.