Praktisk intro til Docker Compose: slik får du lokale utviklingsmiljøer til å henge sammen

Mange prosjekter trenger flere tjenester samtidig: API, frontend, database, køsystem og kanskje en cache. Lokalt utviklingsoppsett kan fort bli kaotisk med manuelle installasjoner, forskjellig konfigurasjon per maskin og “det funker bare hos meg”.

Docker Compose gir en strukturert måte å beskrive hele miljøet på i én fil. Da kan alle i teamet starte samme oppsett med én kommando, feilsøking blir enklere, og du unngår mye friksjon i oppstart og vedlikehold.

Hva Docker Compose faktisk løser

Docker alene er fint for én container av gangen. Utfordringen kommer når du trenger flere tjenester som skal snakke sammen, for eksempel et API som bruker en database og en message broker.

Docker Compose lar deg beskrive alle tjenestene i endocker-compose.yml. Der definerer du hvilke images som skal brukes, hvilke porter som skal eksponeres, hvordan nettverk skal fungere, og hvilke volumer som skal monteres for data og kildekode.

En konkret mental modell: prosjektet som en liten by

Se for deg hvert prosjekt som en liten by der hver tjeneste er en bygning: database, API, frontend osv. Docker Compose er kartet som beskriver hvor bygningene står, hvordan de er koblet til hverandre, og hvor inngangsdørene er.

Fordelen er at kartet er versjonert i Git sammen med koden. Nye utviklere kan starte miljøet uten å installere database lokalt, gi den riktig versjon eller finne gamle installasjonsguider.

Minimal docker-compose.yml du kan bygge videre på

Et typisk startscenario er et API og en database. Her er et nedstrippet eksempel som er lett å forstå og tilpasse:

docker-compose.yml

Merk:juster versjoner og porter til ditt eget prosjekt.

version: “3.9”
services:
  api:
    build: .
    ports:
      – “8080:8080”
    environment:
      – DB_HOST=db
    depends_on:
      – db
    volumes:
      – .:/app
  db:
    image: postgres:16
    environment:
      – POSTGRES_USER=app
      – POSTGRES_PASSWORD=secret
      – POSTGRES_DB=app_db
    ports:
      – “5432:5432”
    volumes:
      – db_data:/var/lib/postgresql/data
volumes:
  db_data:

Grunnkommandoer du bruker hele tiden

Jobber du mye i terminalen, blir Compose raskt en naturlig del av flyten. Her er et lite sett kommandoer som dekker mesteparten av bruken i daglig utvikling:

• docker compose upstarter tjenestene. Legg til-dfor å kjøre i bakgrunnen.
• docker compose downstopper og rydder bort containerne.
• docker compose psviser status på tjenestene.
• docker compose logs apiviser logger for en spesifikk tjeneste.
• docker compose exec api shkjører en shell inne i en container.

Lag gjerne en kort README-seksjon i prosjektet med “Start lokalt” og et par av kommandoene over. Det reduserer spørsmål og onboardingtid betraktelig.

Volumer: skill kode, konfig og data

En vanlig felle er å blande vedvarende data og midlertidige filer. Med Compose kan du skille mellom tre ting: kildekode, databasedata og cache/logg-filer.

En praktisk tommelfingerregel er å bruke:

• Bind mountsfor kildekode (for eksempel.:/app) når du vil at endringer på maskinen din skal reflekteres direkte i containeren.
• Navngitte volumerfor data som skal overleve container-restart, som databaser (db_datai eksemplet over).
• Ingen volum for bygg-artefakter hvis du bare trenger dem i containerens levetid.

Nettverk og tjenestenavn: slutt å hardkode IP-adresser

Compose oppretter et eget nettverk der alle tjenestene ligger. Hver tjeneste får et DNS-navn lik tjenestenavnet i filen. Det betyr at API-et kan nå databasen viadb:5432, uten å vite noe om IP-adresser.

Prøv å unngå IP-baserte konfigverdier og localhost inne i containerne. Bruk tjenestenavn i stedet, for eksempelDB_HOST=dbellerREDIS_HOST=cache. Det gjør oppsettet mer portabelt og enklere å flytte til andre maskiner.

Vanlige feil og hvordan du kjenner dem igjen

Noen feil går igjen i de fleste utviklingsteam. Det kan være nyttig å kjenne igjen symptomene og vite hvor du skal begynne å lete.

• API får ikke kontakt med database:sjekk at du bruker tjenestenavnet fra Compose, at porten er riktig, og at databasen er ferdig oppe. Brukdepends_on, men husk at den bare sikrer startrekkefølge, ikke at databasen er klar til å ta imot forbindelser.
• Endringer i kode vises ikke:se om kildekoden er montert inn med et bind mount. Uten volum vil containeren bruke koden som lå i image ved build.
• Merkelige rettighetsfeil på filer:kan skyldes at containeren kjører som en annen bruker enn deg. Start med å sjekke uid/gid i Dockerfile og vurdere justering hvis det skaper trøbbel på utviklingsmaskiner.

Miljøfiler og hemmeligheter på en ansvarlig måte

Compose gjør det fristende å legge alle passord rett inn idocker-compose.yml. Det er praktisk, men sjelden en god idé hvis filen sjekkes inn i Git. Bruk heller.env-filer lokalt for ting som varierer per utvikler eller maskin.

En typisk strategi er å ha en.env.examplemed placeholder-verdier i repoet og en lokal.envsom aldri sjekkes inn. Dokumenter hvilke variabler som må settes, og la Compose plukke dem opp automatisk.

Når du ikke bør bruke Docker Compose

Compose er nyttig i mange prosjekt, men ikke alltid nødvendig. For små verktøy eller skript kan det være like greit å kjøre ting direkte på maskinen, særlig hvis du ikke har ekstra avhengigheter som databaser eller køsystemer.

I større oppsett for produksjon brukes ofte andre verktøy, for eksempel Kubernetes eller skyleverandørens egne tjenester. Compose kan likevel være nyttig som lokal speiling av produksjonsmiljøet, men skal ikke alltid kopieres direkte til drift uten vurdering.

En enkel sjekkliste for et sunt Compose-oppsett

Avslutningsvis kan det være praktisk med en liten sjekkliste du kan bruke neste gang du setter opp et prosjekt med Docker Compose.

• Har du endocker-compose.ymlsom beskriver alle tjenestene du trenger lokalt?
• Bruker tjenestenetjenestenavnfor å snakke sammen, ikke IP-adresser?
• Er kildekode, data og konfig klart skilt i volumer og miljøvariabler?
• Er det dokumentert med noen få kommandoer hvordan man starter og stopper miljøet?
• Har du tenkt gjennom hva som skal inn i Git, og hva som bør ligge i lokale.env-filer?

Hvis du kan krysse av på punktene over, har du allerede et Docker Compose-oppsett som gjør det enklere å jobbe konsistent med prosjektet på tvers av maskiner og utviklere.