PostgreSQL i Docker Compose med beständig lagring

Din webbapp försöker ansluta till PostgreSQL, men databasen svarar inte efter att containern startats om. En PostgreSQL-container fungerar oftast smidigt med Docker Compose och en namngiven volym, men lagringsvägen beror på vilken huvudversion av PostgreSQL du kör.

Starta databasen med Compose och en namngiven volym

En databas utan beständig lagring kan verka fungera utmärkt tills containern tas bort. Jag tycker att en namngiven volym är ett klokt standardval för lokal utveckling, eftersom Docker hanterar lagringen utan att du behöver öppna databasens interna filer på värddatorn.

Skapa en fil med namnet compose.yaml. Exemplet använder PostgreSQL 18 och binder porten till den egna datorn, inte till alla nätverksgränssnitt.

services:
  db:
    image: postgres:18
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?Sätt POSTGRES_PASSWORD i .env}
      POSTGRES_DB: appdb
    ports:
      - "127.0.0.1:5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d appdb"]
      interval: 5s
      timeout: 3s
      retries: 10

volumes:
  postgres_data:

Lägg lösenordet i en lokal .env-fil och lämna inte in den i versionshantering. För en driftsmiljö bör hemligheter hanteras med en lämplig secrets-lösning i stället för att bäddas in i Compose-filen. Starta tjänsten med docker compose up -d och kontrollera loggen med docker compose logs -f db.

Hälsokontrollen använder pg_isready, ett verktyg som kontrollerar om servern kan ta emot anslutningar. Den hjälper Compose att skilja en startad container från en databas som faktiskt är redo.

Välj monteringspunkt efter PostgreSQL-version

En volym kan finnas kvar och ändå se tom ut för PostgreSQL om den monteras på fel sökväg. För PostgreSQL 18 ändrades standardplaceringen av data jämfört med äldre huvudversioner, så kopiera inte en gammal Compose-fil utan att kontrollera dess monteringspunkt.

Den officiella PostgreSQL-avbildningens dokumentation beskriver både den versionsspecifika sökvägen för PostgreSQL 18 och monteringspunkten för version 17 och äldre. Håll därför ihop avbildningens huvudversion och volymens sökväg när du ändrar konfigurationen.

Var särskilt försiktig vid uppgradering mellan huvudversioner. Ändra inte bara image:-taggen och anta att den gamla datakatalogen kan användas direkt; planera en uppgradering eller migrering och ta en säkerhetskopia först.

Ändrade miljövariabler återställer inte en befintlig databas

Byter du lösenord i Compose men får ändå ett autentiseringsfel? Det beror ofta på att variabeln bara används när datakatalogen initieras för första gången. Om volymen redan innehåller en databas lämnas befintliga användare och uppgifter i fred.

Det gäller också POSTGRES_USER, POSTGRES_DB och initieringsfilerna i /docker-entrypoint-initdb.d. De är praktiska vid en ny installation, men de körs inte om från början bara för att containern startas om. En omstart är alltså ingen genväg för att ändra databasens ursprungliga inställningar.

• Utvecklingsdatabas med data du vill behålla: ändra lösenordet via en PostgreSQL-klient och behåll volymen.
• Testdatabas som får raderas: ta bort volymen med docker compose down -v och starta sedan tjänsten på nytt. Kommandot raderar databasinnehållet.
• Initieringsskript körs inte: kontrollera om datakatalogen redan innehåller en databas. Skripten körs vid initiering, inte vid varje start.

Den officiella Docker-guiden för PostgreSQL beskriver både beständig lagring och initieringsskript. I praktiken är den säkra skiljelinjen enkel: behåll volymen om data ska finnas kvar, och radera den bara när innehållet verkligen kan försvinna.

Välj anslutning efter var appen körs

Adressen localhost betyder den egna miljön. Från en appcontainer pekar den därför på appcontainern själv, inte på databastjänsten bredvid. Använd i stället Compose-tjänstens namn som värdnamn.

Om appen och databasen ligger i samma Compose-projekt kan anslutningssträngen exempelvis vara postgresql://app:DITT_LÖSENORD@db:5432/appdb. Från ett verktyg på datorn använder du i stället localhost eller 127.0.0.1, förutsatt att porten har publicerats.

Behöver ingen ansluta från värddatorn? Ta bort ports helt. Då kan andra tjänster i Docker-nätverket nå databasen, medan PostgreSQL inte exponeras genom en publicerad värdport. Jag skulle välja den lösningen för en app som också körs i containrar.

Felsök anslutningen innan du rör volymen

När anslutningen fallerar är det lockande att radera volymen och börja om. Vänta med det. Börja med att kontrollera om containern körs och vad databasen skriver i loggen.

1. Kör docker compose ps för att kontrollera tjänstens status.
2. Kör docker compose logs db och leta efter initieringsfel, behörighetsproblem eller meddelanden om att servern är redo.
3. Kontrollera att appens värdnamn passar dess miljö: db mellan containrar, localhost från värddatorn.
4. Jämför PostgreSQL-huvudversionen med volymens monteringspunkt.
5. Ta en säkerhetskopia innan du tar bort eller byter volym.

För lokal utveckling kan en SQL-dump skapas med docker compose exec -T db pg_dump -U app appdb > backup.sql. En dump är användbar när databasen ska flyttas eller återskapas, men kontrollera att filen skapats och går att läsa innan du behandlar den som enda kopia.

Låt volymen skydda arbetet, inte förvirra det

Den vanligaste stabila grundlösningen är rätt versionssökväg, en namngiven volym och en anslutning som använder rätt värdnamn för klientens miljö. När något går fel ger loggarna och volymens monteringspunkt oftast bättre ledtrådar än att börja om från noll.

Se volymen som databasens beständiga hem och containern som processen som öppnar dörren dit. Då blir det lättare att uppdatera eller återskapa containern utan att förväxla det med att radera själva databasen.