Docker Compose starter applikationen før databasen: hvordan man undgår fejlen

Et af de mest frustrerende problemer, når man arbejder med Docker Compose, opstår, når man starter et projekt, og applikationen forsøger at oprette forbindelse til databasen. før den er klarSidder du fast i dette rod? Vi forklarer, hvad du skal gøre, når Docker Compose starter applikationen før databasen: løsningen er enklere, end den ser ud til.

Hvorfor starter Docker Compose applikationen før databasen?

Lad os begynde med at forstå, hvorfor Docker Compose starter applikationen før databasen. I et typisk projekt, Webapplikationen skal oprette forbindelse til en database såsom MySQL, PostgreSQL eller MariaDB. Typisk kører begge tjenester i separate containere og koordineres via en konfigurationsfil. compose.yaml o docker-compose.yml.

Men problemet opstår under opstart. Docker Compose kan starte databasecontaineren først og derefter applikationscontaineren (depends_onMen det Det garanterer ikke, at databasemotoren er færdig med initialiseringen.For eksempel kan MySQL bruge et par sekunder på at forberede sine interne filer, oprette systemtabeller, anvende konfigurationer og aktivere forbindelser.

I mellemtiden kører applikationen allerede og forsøger at få adgang til serveren. Men da dette Den er endnu ikke klar til at modtage forbindelserApplikationen registrerer fejl som f.eks. forbindelse afvist, Kunne ikke oprette forbindelse til serveren o database utilgængeligDet samme gælder, hvis der opstår en afbrydelse, eller Du genstarter containerneApplikationen forsøger muligvis at genoprette forbindelsen for tidligt.

Her skal vi skelne mellem to forskellige begreber: containernes startrækkefølge og faktisk tilgængelighed af tjenesterMens serveren synkroniserer, starter applikationen øjeblikkeligt og forsøger at oprette forbindelse. Men hvis den mangler en gentagelseslogik, går den ned og genoplives først ved et andet manuelt forsøg på at oprette forbindelse.docker compose restart appSelvfølgelig: ved andet forsøg har databasen kørt et stykke tid og er klar.

Docker Compose starter applikationen før databasen: hvordan man undgår fejlen

Kort sagt initialiserer Compose containere i den rækkefølge, der er dikteret af depends_onMen den venter ikke på, at containeren er klar, kun på at den kører. Den korte form af `depends_on` (den simple liste over tjenester) garanterer kun oprettelsesrækkefølgen, ikke tilgængeligheden af ​​den afhængige tjeneste. Løsning? For virkelig synkronisere, skal du bruge den lange form med condition og på databasesiden, en healthcheck der definerer, hvad det vil sige at "være sund".

Hvilke officielt Det anbefales at gøre dette, når Docker Compose starter applikationen, før databasen kræver det. to elementerFørst en healthcheck i databasetjenesten, der udfører en faktisk diagnostisk kommando. For PostgreSQL er standarden f.eks. pg_isready, som kontrollerer om serveren accepterer forbindelser.

For det andet, på servicesiden af ​​applikationen, en depends_on med condition: service_healthyDette fortæller Compose ikke at oprette app-containeren, før healthcheck der er sket i databasen. Derefter, en compose.yaml minimal og funktionel til PostgreSQL Det ville se sådan ud:

tjenester: db: billede: postgres:16-alpine miljø: POSTGRES_USER: app POSTGRES_PASSWORD: hemmelig POSTGRES_DB: app healthcheck: test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"] interval: 5s timeout: 5s genforsøg: 10 start_period: 30s volumener: - pgdata:/var/lib/postgresql/data app: build: . depends_on: db: betingelse: service_healthy restart: true volumener: pgdata:

Konfigurer databasen og applikationen korrekt

Ovenstående konfiguration retter den fejl, der opstår, når Docker Compose starter applikationen før databasen. Nøglen ligger i tre detaljer, der bør undersøges omhyggeligt for at forstå logikken bag koden. Den første er den dobbelte dollar ($$) i den healthcheck.

Som du måske allerede ved, interpolerer Compose værtens miljøvariabler, før kommandoen sendes til containeren. Hvis du skriver $${POSTGRES_USER}, Compose efterlader det bogstavelige $${POSTGRES_USER} y skallen inde i containeren udvider den med sin egen variabelMen hvis du skriver ${POSTGRES_USER}Compose vil forsøge at erstatte den på værten, og hvis den ikke findes, vil kommandoen køre med en tom værdi og healthcheck Det vil altid mislykkes.

Den anden detalje, du ser i 30 sekunder allokeret til værdien start_periodDette er den tid, du giver PostgreSQL til initialisering, hvilket kan tage en betydelig mængde tid på en ny diskenhed. I løbet af denne tid tæller fejl i sundhedstjekket ikke med i grænsen. retriesMen uden start_period, en retries: 5 med interval: 5s kunne markere databasen som unhealthy før den er færdig med at starte, og Compose vil afbryde appens opstart.

Og hvis Docker Compose starter applikationen før databasen, er det tredje element, der forhindrer fejl, værdien restart: true i afhængigheden. Uden denne indstilling, hvis du genstarter tjenesten db med docker compose restart dbApplikationen genstarter ikke automatisk og kan opleve afbrudte forbindelser. Men med restart: true, Compose genstarter også afhængige tjenester når den tjeneste, de er afhængige af, opdateres eller genstartes under deres administration.

Docker Compose starter applikationen før databasen: verificér, at løsningen fungerer

Efter ændring af Compose-filen anbefales det at Bekræft, at konfigurationen er gyldig, og at tjenesterne opfører sig som forventet.Først, løb docker compose config for at validere og vise den resulterende konfiguration. Dette er især nyttigt til at detektere syntaksfejl og problemer med miljøvariabler.

Start derefter tjenesterne med docker compose up -d –build og, for tjek containernes tilstand, bruger docker compose psHvis du desuden har brug for at forespørge databasemeddelelserne, skal du køre docker compose logs -f dbOg for at kontrollere for programfejl, brug docker compose logs -f web.

Endelig, hvis databasen vises som healthyMen appen vil stadig ikke oprette forbindelse. Kontroller værtsnavn, legitimationsoplysninger, intern port og brugertilladelserMed dette slipper du for at lide, fordi Docker Compose starter applikationen før databasen.

Konklusion: Vent, indtil databasen er klar

Når Docker Compose starter applikationen, før databasen er klar, er problemet ikke altid opstartsrækkefølgen. I mange tilfælde er det egentlige problem, at databasecontaineren allerede kører, men Den accepterer endnu ikke forbindelser..

For at undgå dette, brug depends_on med condition: service_healthy og konfigurere en healthcheck Velegnet til MySQL, PostgreSQL eller den motor, du bruger. Supplér disse målinger med forbindelsesforsøg i applikationen for at understøtte afbrydelser efter opstart.