Slik bruker du Docker i hverdagen for å få forutsigbare utviklingsmiljøer

Forskjellen mellom at ting “funker hos meg” og at de fungerer hos alle, ligger ofte i miljøet: versjoner, avhengigheter og små lokale tilpasninger. Docker er laget for å gjøre denne delen kjedelig og forutsigbar.

Her får du en praktisk gjennomgang av hvordan du kan bruke Docker i vanlig utviklingsarbeid, med enkle eksempler, typisk oppsett og vanlige feil du bør unngå.

Hva Docker egentlig løser i et utviklerteam

Docker lar deg pakke en applikasjon sammen med alt den trenger: språkruntime, systembiblioteker, verktøy og konfig. Resultatet er en container som kjører likt på alle maskiner som har Docker installert.

I stedet for å dokumentere en lang “installer dette først”-liste, kan du definere miljøet i kode. Det gjør onboarding, feilsøking og deploy mye enklere, spesielt når flere jobber på samme prosjekt over tid.

Kjapp omvisning: image, container og Dockerfile

Tre begreper går igjen i all Docker-bruk:image,containerogDockerfile. Et image er en “mal” for miljøet ditt, for eksempel en Node- eller PHP-app med alt den trenger.

En container er en kjørende instans av et image. Dockerfile er oppskriften som beskriver hvordan imaget bygges: hvilke pakker som installeres, hvilke porter som åpnes og hvilken kommando som skal kjøres når containeren starter.

Et minimalt eksempel: kjør en webapp uten lokal installasjon

Si at du skal teste en enkel Node-basert webapp, men vil slippe å installere Node lokalt. Du kan lage en mappe medDockerfilei rot:

Eksempel på enkel Dockerfile:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD [“npm”, “start”]

Nå kan du bygge og kjøre miljøet:

docker build -t min-node-app .
docker run -p 3000:3000 min-node-app

Gjør det utviklingsvennlig med volumes

Oppsettet over er greit for test, men ikke for daglig utvikling. Du vil at kodeendringer skal reflekteres uten å bygge på nytt hver gang. Løsningen er å mounte prosjektmappen inn i containeren som et volume.

Da kan du bruke en basecontainer for runtime, men fortsatt jobbe direkte på filene dine lokalt, gjerne med nodemon eller tilsvarende for autorestart.

docker-compose: kjør flere tjenester som hører sammen

De fleste prosjekter er mer enn én prosess: API, database, kanskje en cache.Docker Composelar deg definere alle tjenester i endocker-compose.yml, og starte alt med én kommando.

Det gjør det lett å få opp komplekse miljøer lokalt, som ligner mer på produksjon enn en enkel “npm start” eller “php -S”.

Typisk docker-compose for en webapp med database

Et vanlig scenario er en webapp som trenger en database. Her er et forenklet eksempel som illustrasjon:

services:
  app:
    build: .
    ports:
      – “3000:3000”
    volumes:
      – .:/app
    depends_on:
      – db
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
      POSTGRES_DB: app_dev
    ports:
      – “5432:5432”

Nå kan du starte alt med: docker compose up. Hele miljøet står og går i containere, uten at du har installert Postgres lokalt.

Praktisk arbeidsflyt i hverdagen med Docker

For å få nytte av Docker utover et enkelt demooppsett, lønner det seg å bake inn bruken i den daglige arbeidsflyten. En typisk struktur er å ha bådeDockerfileogdocker-compose.ymli prosjektroten, og en kort instruksjon i prosjektets dokumentasjon.

En enkel arbeidssyklus kan se slik ut: du kloner repoet, kopierer en eksempelmiljøfil, kjører docker compose up og deretter utvikler lokalt mens containeren gir deg runtime og tjenester som database og cache.

Miljøvariabler og hemmeligheter

Miljøvariabler er nesten alltid nødvendig i containeriserte apper, for eksempel database-url, API-nøkler og ulike toggles. Ofte brukes en.env-fil som leses inn av Docker Compose.

Unngå å sjekke inn hemmeligheter i Git. Bruk gjerne en egen.env.examplei repoet, slik at nye utviklere ser hvilke nøkler som trengs, men må fylle inn egne verdier lokalt.

Vanlige feil og enkle måter å løse dem på

Noen problemer går igjen når man starter med Docker. Én typisk felle er portkonflikter, for eksempel at 3000 eller 5432 allerede er i bruk. Da kan du enten stoppe den andre prosessen eller endre portmapping i docker-compose.yml.

En annen klassiker er “det funker ikke etter at jeg endret Dockerfile”. Husk å bygge på nytt når du gjør endringer som påvirker imaget: docker compose build eller docker build, avhengig av oppsettet ditt.

Ytelse og begrensninger du bør være klar over

På macOS og Windows kan filsystemet mellom host og container være tregere enn rene lokale filer, spesielt hvis du moun­ter en hel kodebase. Dette merkes særlig ved verktøy som gjør mange små filoperasjoner.

Det finnes ulike optimaliseringer og alternative volumløsninger, men første steg er å være oppmerksom på at slike flaskehalser kan skyldes Docker, ikke nødvendigvis koden din.

Når Docker passer og når det er overkill

Docker er mest nyttig når prosjektet ditt har flere avhengigheter, trenger eksterne tjenester eller skal kjøres likt på mange maskiner eller miljøer. Da sparer du raskt inn tidsbruken på litt ekstra oppsett.

For helt enkle prosjekter kan ren lokal kjøring fortsatt være enklest. Poenget er ikke å tvinge alt inn i containere, men å bruke dem når de gir bedre forutsigbarhet og mindre friksjon i teamet.

En liten sjekkliste for Docker i nye prosjekter

Hvis du vil gjøre Docker til en naturlig del av neste prosjekt, kan du bruke denne korte sjekklisten:

• Har du en Dockerfile som bygger applikasjonen uten manuelle steg?
• Har du en docker-compose.yml som starter alle nødvendige tjenester lokalt?
• Er miljøvariabler dokumentert og håndtert via .env eller tilsvarende?
• Er grunnleggende kommandorer kort forklart i prosjektets dokumentasjon?

Med dette på plass får du et miljø som er lettere å dele, lettere å reprodusere og enklere å feilsøke når noe går galt.