Praktisk Docker i hverdagen: enkel lokal utvikling uten tunge oppsett

Docker har gått fra å være et hype-ord til å bli en del av helt vanlig utviklingsarbeid. Likevel er det mange som synes det er tungt å ta i bruk i egne prosjekter, spesielt når man bare vil få opp en database eller kjøre en enkel webapp lokalt.

I denne artikkelen ser vi på en konkret og jordnær måte å bruke Docker på i hverdagen: hvordan du setter opp et lite, forutsigbart utviklingsmiljø uten å bruke dager på konfigurasjon. Fokus er på få, forståelige kommandoer og en arbeidsflyt som passer inn i vanlig webutvikling.

Hvorfor gidde å bruke Docker lokalt?

Det viktigste argumentet for Docker i utvikling er forutsigbarhet. Du slipper å tilpasse prosjektet til den ene maskinen som har gammel PHP, annerledes Node-versjon eller en halvveis installert database.

Med Docker beskriver du miljøet som kode, og alle på teamet kan starte samme oppsett med én kommando. Det gjør feilsøking enklere, og reduserer “det funker bare på min maskin”-situasjoner betydelig.

De tre begrepene du må forstå

For å bruke Docker daglig trenger du egentlig bare å ha kontroll på tre ting: image, container og volume. Mange stopper opp her fordi begrepene høres tyngre ut enn de er.

Etimageer en ferdig pakke med programvare, for eksempel “offisiell MySQL 8” eller “Node 20 på Linux”. Encontainerer en kjørende instans av et image. Etvolumeer et område på disken som beholdes selv om containeren stoppes eller slettes, typisk databasedata eller prosjektfiler.

Første steg: kjør en database i Docker

La oss si at du skal utvikle en PHP- eller Node-applikasjon som trenger MySQL. I stedet for å installere alt lokalt, kan du starte en databasecontainer:

Eksempel med MySQL:

• Installer Docker Desktop (Windows/macOS) eller Docker Engine (Linux).
• Åpne terminalen i et passende katalog.
• Kjør følgende kommando (juster passord etter behov):
  docker run --name lokal-mysql -e MYSQL_ROOT_PASSWORD=hemmelig -p 3306:3306 -d mysql:8

Du har nå en kjørende MySQL-server på port 3306, som kan nås fra terminal, phpMyAdmin eller applikasjonen din. Når du er ferdig for dagen, kan du stoppe den med docker stop lokal-mysql og starte igjen senere med docker start lokal-mysql.

Unngå de vanligste feilene med porter og data

En typisk felle er portkonflikter. Hvis du allerede har MySQL installert lokalt på 3306, kan Docker-containeren ikke bruke samme port. Da kan du endre portmappingen, for eksempel -p 3307:3306, og koble deg til port 3307 fra verktøyene dine.

En annen klassiker er tap av data hvis containeren slettes. Løsningen er å bruke volumes. Et enkelt eksempel for MySQL kan se slik ut:
-v mysql_data:/var/lib/mysql. Da vil databasedata ligge i et separat volume som overlever nye containere med samme navn.

Bruk docker-compose til å samle ting i én kommando

Når du har mer enn én container, for eksempel en webapp og en database, blir det raskt tungvint å starte alt manuelt. Her erdocker-composeet godt verktøy for daglig bruk.

Legg en docker-compose.yml i prosjektmappen din. Et enkelt oppsett for en PHP-applikasjon med Nginx og MySQL kan ha tre tjenester: app, web og db. Poenget er ikke å lage et perfekt oppsett, men å samle miljøet ditt i en fil som alle kan kjøre.

Et konkret docker-compose-eksempel

Under er et forenklet eksempel som illustrerer struktur og nytte. Du kan tilpasse versjoner, porter og kataloger til prosjektet ditt:

version: "3.9" services: db: image: mysql:8 environment: MYSQL_ROOT_PASSWORD: hemmelig MYSQL_DATABASE: appdb ports: - "3307:3306" volumes: - db_data:/var/lib/mysql app: image: php:8.2-fpm volumes: - ./:/var/www/html depends_on: - db web: image: nginx:stable ports: - "8080:80" volumes: - ./:/var/www/html depends_on: - app

Med denne filen på plass kan du starte hele miljøet med docker compose up i prosjektmappen. Etter noen sekunder er web, PHP og database i gang. Når du er ferdig, trykker du Ctrl+C og eventuelt rydder opp med docker compose down.

Arbeidsflyt som passer vanlig utvikling

For at Docker skal være nyttig til daglig, bør du få det inn i helt vanlige rutiner. Et enkelt mønster for lokale prosjekter kan se slik ut:

• Klone repoet som vanlig.
• Starte miljøet med docker compose up.
• Redigere kildekoden i din vanlige editor på vertsmaskinen.
• La containerne kjøre applikasjon, database og evt. køsystemer.

Det viktigste er at du ikke låser deg til å jobbe inne i containerne hvis du ikke må. For mange prosjekter holder det at Docker kjører tjenestene rundt applikasjonen, mens du fortsetter med editor, Git og terminal direkte på egen maskin.

En enkel sjekkliste før du tar Docker inn i teamet

Hvis flere skal bruke samme oppsett, er det lurt å avtale noen enkle grenser. Det gjør at Docker blir en støtte i arbeidsflyten, ikke et ekstra hinder.

• Beskriv kort hva docker-compose.yml gjør i prosjektets dokumentasjon.
• Avklar hvilke porter som brukes, slik at ikke andre tjenester krasjer.
• Bestem hva som skal ligge i volumes, og hva som kan gjenopprettes ved behov.
• Lag en kort “kom i gang”-seksjon med 3–5 kommandoer for nye utviklere.

Start enkelt, så kan dere etter hvert legge til flere tjenester eller mer avansert konfigurasjon hvis behovet dukker opp, for eksempel separate filer for utvikling og produksjon.

Når er Docker ikke verdt bryet?

Docker er ikke alltid riktig valg. For veldig små skripter, korte eksperimenter eller rene frontend-prosjekter som bare trenger en lokal dev-server, kan det være like greit å kjøre alt direkte på maskinen.

Som tommelfingerregel er Docker mest nyttig når prosjektet ditt har flere avhengigheter, som database, cache, køsystem eller spesifikke språkversjoner. Da gir den ekstra kompleksiteten ofte gevinst i form av færre overraskelser og et mer stabilt utviklingsmiljø.

Veien videre: lær litt etter litt

Du trenger ikke lære hele Docker-universet for å få nytte. Begynn med én eller to tjenester i docker-compose.yml, bli komfortabel med å starte og stoppe miljøet, og bygg videre derfra.

Hvis du senere vil ta et steg videre, kan du utforske egne Docker-images for applikasjonen din, separate compose-filer for testmiljøer eller integrasjon med CI. Men det viktigste for hverdagen er å ha et lite, forståelig oppsett som alle på teamet klarer å bruke.