Komplet Docker Compose-vejledning til orkestrering af containere

Hvis du allerede har eksperimenteret med containere og set det for en "rigtig" app, skal du bruge mere end én tjeneste kører på samme tid (database, API, frontend, cache…), vil du før eller siden støde på Docker Compose. Dette værktøj giver dig mulighed for at konfigurere alt det udstyr med en enkelt fil og et par kommandoer, uden at jonglere med terminaler og endeløse scripts.

I denne vejledning lærer du, hvad Docker Compose er, og hvordan dens fil fungerer. compose.yaml og hvordan man orkestrerer applikationer Rene multi-container opsætninger: fra simple eksempler med Flask og Redis til mere komplekse arkitekturer med frontend, backend og database. Du lærer også om netværk, volumener, konfigurationer, hemmeligheder og de vigtigste kommandoer til at arbejde komfortabelt i udviklings- og mere krævende miljøer.

Hvad er Docker Compose, og hvorfor er det værd at bruge?

Docker Compose er en Docker-udvidelse, der tillader definer og administrer flere containere som om de var én applikation. I stedet for at starte hver tjeneste manuelt med dens "docker run" og parametre, beskriver du alt i en YAML-fil og starter det med en enkelt kommando.

Det smukke ved Compose er, at mange moderne applikationer er bygget på det. mikrotjenester, der bor i individuelle containereEn database, en API, en frontend, et køsystem, en Redis-lignende cache osv. Docker anbefaler, at hver container kører en enkelt service, så hvis du forsøger at få alt ind i et enkelt image, ender du med et monster, der er svært at skalere og vedligeholde.

Du kan køre to eller flere tjenester i den samme container, men Det ophæver mange af Dockers fordele.Hvis én fejler, trækker den de andre ned; man kan ikke kun skalere den del, der får den største belastning, og håndtering af logfiler, ressourcer og fejl bliver et stort rod.

Med Docker Compose definerer du hver tjeneste separat, og specificerer hvordan de forbinder sig til hinanden, hvilke data de bevarer, hvilke porte de eksponerer, hvilke miljøvariabler de bruger… På denne måde Hvis én beholder svigter, kan resten fortsætte med at fungere. afhængigt af hvordan du konfigurerer det, og skalering af et specifikt element er så simpelt som at ændre dets indstillinger eller antallet af replikaer.

Derudover passer Compose perfekt ind i arbejdsgange hos CI/CD og udrulning til produktionDu kan bruge det direkte med værktøjer som Portainer eller Docker Swarm, og hvis du arbejder med Kubernetes, giver projekter som Kompose dig mulighed for at oversætte en compose.yaml-fil til Kubernetes-manifester uden at skulle omskrive alt i hånden.

Forudsætninger for at følge Docker Compose-vejledningen

For at kunne følge eksemplerne i denne vejledning uden besvær skal du bruge have Docker og Docker Compose installeretI dag er der to hovedveje:

• Docker Engine + Docker Compose installeret som separate binære filer.
• DockerDesktop, som inkluderer Docker Engine, Docker Compose og en grafisk brugerflade.

Det er vigtigt, at du har et minimumsgrundlag af grundlæggende Docker-kommandoer (billeder, containere, porte, volumener) og vær ikke bange for at bruge kommandolinjen. Eksemplerne antages normalt i Linux (for eksempel Ubuntu 22.04), men logikken gælder ligeledes i Windows og macOS med Docker Desktop.

Tjek at alt er i orden ved at køre det på din terminal noget så simpelt som "docker –version" og "docker compose version"Hvis begge kommandoer reagerer uden fejl, er du klar til at fortsætte med eksemplerne.

Grundlæggende struktur af en compose.yaml-fil

Hjertet i Docker Compose er filen compose.yaml (eller docker-compose.yml)Der beskriver vi, hvilke tjenester vi ønsker at oprette, og hvordan de skal relateres. Selvom feltet tidligere blev brugt version For at markere formatversionen anbefaler den nuværende dokumentation ikke at definere den, så den nyeste version af skemaet altid bruges.

I Compose-filen vil du have flere mulige sektioner, selvom kun én er obligatorisk: tjenesterDerfra kan du tilføje andre sektioner afhængigt af projektets kompleksitet:

• tjenesterdefinition af hver mikrotjeneste (obligatorisk).
• net: brugerdefinerede netværk til at styre kommunikationen mellem containere.
• mængder: volumener til at bevare data eller dele dem mellem tjenester.
• configs: tjenestekonfiguration (f.eks. webserverkonfigurationsfiler).
• hemmelighederhåndtering af følsomme oplysninger (adgangskoder, API-nøgler…).

Gennem denne vejledning vil du se, hvordan du kombinerer alle disse afsnit til et typisk projekt, der inkluderer en applikation, en database og et APIog også et eksempel på en webapp i Python med Flask og Redis.

Tjenester i Docker Compose: Kernen i definitionen

sektion tjenester er den essentielle brik fra enhver Compose-fil. I den definerer du hver af de containere, der skal udgøre din applikation, og giver dem det ønskede navn (f.eks. web, database, api, redisOsv.).

For hver tjeneste kan du etablere et godt antal parametreBlandt dem er nogle, der er meget udbredt i projekter i den virkelige verden:

Parameter build angiver, hvor Dockerfilen er placeret hvorfra servicebilledet bygges. Typisk angives en kontekst (mappe), hvor Dockerfilen for den applikation, du vil pakke, befinder sig.

Hvis du allerede har oprettet et billede, eller hvis du vil bruge et fra registreringsdatabasen, skal du bruge image at referere til detNavnet følger formatet [<registry>/][<project>/]<image>[:<tag>|@<digest>]Og hvis du har brug for at kontrollere, hvornår billedet downloades eller opdateres, kan du bruge pull_policy.

Marken ports Det bruges til at kortlægge porte mellem værten og containerenSyntaksen er af typen [HOST:]CONTAINER[/PROTOCOL]Hvis for eksempel en PostgreSQL-database lytter på port 5432 inde i containeren, og du vil eksponere den på port 5555 på værten, ville du gøre noget i retning af dette: "5555:5432" på listen over havne.

Genstartspolitikken styres med restartsom angiver, hvad der skal gøres, når en container afsluttes ved en fejl eller stopper. Typiske værdier er no, always, on-failure y unless-stoppedså kritiske tjenester kan forblive operationelle, selv hvis de oplever lejlighedsvise afbrydelser.

Hvis én tjeneste har brug for, at en anden er tilgængelig, før den starter, kan du bruge depends_on at definere afhængigheder mellem containereEt klassisk eksempel er en app, der kræver, at databasen er oppe og kører for at undgå at den indledende forbindelse fejler.

Der er to almindelige tilgange til konfiguration og legitimationsoplysninger: env_file y environment. Med env_file Du peger på en eller flere filer .env med miljøvariablerne, mens de er i environment Du kan angive dem direkte i YAML. Den bedste fremgangsmåde er at bruge filer. .env for at forhindre adgangskoder og følsomme data i at blive integreret i selve compose.yaml-filen.

Parameter volumes tillader montering af værtsstier eller -volumener Inden for containeren bruger du både datapersistens og mappedeling mellem tjenester. Her refererer du kun til de volumener, som du senere kan definere i afsnittet ovenfor. volumes hvis du har brug for, at de deles eller administreres mere eksplicit.

Med disse felter kan du allerede bygge nogenlunde komplette tjenester. Compose-specifikationen inkluderer mange flere avancerede muligheder (sundhed, ressourcebegrænsninger, kommandoer fra støvleosv.), men med disse dækker du allerede de fleste almindelige anvendelser.

Eksempel 1: Webapplikation i Python med Flask og Redis

Et typisk eksempel på at forstå Docker Compose er at oprette en simpel webapplikation i PythonBrug af Flask til at vise sider og Redis som et in-memory-lager til en hittæller. Ideen er, at du ikke behøver at installere hverken Python eller Redis på din maskine: alt kører inde i containere.

Arbejdsgangen ville være nogenlunde sådan her: først opretter du en mappe til projektet, og indeni tilføjer du en fil app.py med Flask-koden. I den kode bruger du "redis" som værtsnavn og port 6379, som er standardporten for Redis-tjenesten i din container.

Funktionen der administrerer besøgstælleren Den forsøger at oprette forbindelse til Redis flere gange. Før du giver op, skal du huske på, at det kan tage et par sekunder, før Redis-containeren bliver tilgængelig, når du løfter hele stakken.

Ud over app.py, du opretter en fil requirements.txt med Python-afhængigheder (for eksempel Flask og redis-py), og en Dockerfile, der specificerer, hvordan du bygger dit webapplikationsbillede: basis Python-billede (3.7, 3.10 eller hvad som helst), arbejdsmappe, miljøvariabler til Flask, gcc-installation og systemafhængigheder, kopi af requirements.txt, pakkeinstallation og kodekopi.

I Dockerfilen markerer du også port, der viser containeren (for eksempel 5000) og du definerer standardkommandoen, normalt flask run --debug eller lignende, så den starter automatisk, når containeren oprettes.

Med alt dette klar definerer compose.yaml-filen to tjenester: en kaldet f.eks. web, som er bygget ud fra projektets Dockerfile og eksponerer port 8000 eksternt (kortlægger værtens port 8000 til containerens port 5000), og en anden kaldet redis at Hent det officielle Redis-billede fra Docker Hub.

For at starte applikationen skal du blot navigere til projektmappen og køre "docker compose up"Compose sørger for at downloade Redis-billedet, bygge dit webapplikationsbillede og starte begge tjenester i den rigtige rækkefølge.

Når det er oppe at køre, skal du indtaste det med din browser. http://localhost:8000 (o http://127.0.0.1:8000) og du burde se en besked af typen "Hej Verden" og en Besøgstæller, der stiger hver gang du genindlæser siden. Hvis du undersøger de lokale billeder med docker image lsDu vil se noget i retning af redis y web oprettet eller downloadet.

Når du vil stoppe alt, kan du gøre det CTRL+C i terminalen, hvor du forlod "docker compose up" eller udføre docker compose down fra projektmappen. Dette vil stoppe og fjerne de containere, der er oprettet af den pågældende compose.

Forbedring af arbejdsgang: Bind monteringer og Compose Watch

Det er mere bekvemt at arbejde i udvikling med Docker, hvis Du behøver ikke at rekonstruere billedet hver gang du berører koden. Det er her, Bind Mounts og, i nyere versioner, Docker Compose Watch kommer i spil.

En Bind Mount involverer at montere en mappe fra din maskine inde i containeren. I compose.yaml-filen tilføjer du en sektion til webtjenesten. volumes der knytter projektmappen til arbejdsmappen fra beholderen, for eksempel .:/codePå denne måde afspejles alle ændringer, du foretager i din editor, øjeblikkeligt i containeren.

Hvis du også aktiverer Flasks debug-tilstand med variablen FLASK_DEBUG=1, kommandoen flask run Den genindlæser automatisk applikationen, når den registrerer ændringer i filerne, uden at det er nødvendigt at stoppe og genstarte.

Docker Compose Watch tager det et skridt videre: du kan bruge "docker compose watch" eller "docker compose up –watch" Dette gør det muligt for Compose at overvåge projektfiler og synkronisere ændringer med containere mere intelligent. Når du gemmer en fil, kopieres den til containeren, og udviklingsserveren opdaterer applikationen uden at genstarte hele containeren.

Prøv for eksempel at ændre velkomstbeskeden i app.py fra "Hej Verden!" til en sætning som "Hej fra Docker"Gem filen, opdater din browser, og du vil se den nye besked med det samme, mens besøgstælleren fortsætter med at køre uden at miste sin tilstand.

Og når du er færdig med at arbejde, kan du som altid trække docker compose down para sluk og rengør beholderne som var i gang med den stak.

Eksempel 2: Full stack-app med frontend, backend og database

For at se Docker Compose i en noget mere realistisk arkitektur, forestil dig en to-do-liste-applikation (Todo-liste) med en frontend i Vue.js, en API i Node.js og en MongoDB-database. Hver del ligger i sin egen mappe og har sin egen Dockerfile.

I arkivet kan du muligvis finde en mappe frontend med Vue-appen og en anden backend med Node-serveren. Backend'en eksponerer slutpunkter for Opret, angiv, opdater og slet opgaverog opretter forbindelse til MongoDB for at gemme dem. Frontend'en bruger disse slutpunkter til at vise og administrere opgavelisten i browseren.

filen docker-compose.yml Den er placeret i projektets kerne og definerer tre tjenester: frontend, backend y databaseFrontend-tjenesten er bygget ud fra Dockerfilen i den tilsvarende mappe, og eksponeres normalt intern port 80 og mappes til port 5173 på værten (for eksempel for at bruge den samme URL som i lokal udvikling).

Backend'en er bygget fra Dockerfilen i mappen backend, eksponerer port 3000 (både indeni og uden for containeren, hvis du vil forenkle) og erklærer en afhængighed af databasen for at sikre at MongoDB er tilgængelig, når den starter op.

Tjenesten database brug den direkte Officielt billede af MongoDB og opbyg et volumen, lad os sige mongodb_datai /data/db, som er hvor Mongo gemmer sine data. Denne volumen er deklareret i den øverste sektion. volumes fra compose, så dataene bevares, selvom du sletter og genskaber containerne.

Endelig forbindes alle disse tjenester via et brugerdefineret netværk, for eksempel my-network, defineret i afsnittet networksDette gør det muligt at løse dem efter servicenavn (backend'en kan oprette forbindelse til Mongo ved hjælp af værtsnavnet). database) og at trafikken er indkapslet i det isolerede netværk.

Når konfigurationen er klar, skal du køre docker compose up I kernen af ​​projektet er det ansvarligt for byg eller download billederne og start de tre containereDu kan tjekke, at alt er på plads med docker compose psog derefter adgang til http://localhost:5173 for at se Vue-appen i din browser og oprette dine første opgaver.

Netværk i Docker Compose: Forbind tjenester med hinanden

Netværk er det lag, der tillader dine containere De "ser" hinanden og taler kontrolleretSom standard opretter Docker allerede netværk til Compose, men at definere dem eksplicit giver dig mere klarhed og kontrol over, hvad der kan kommunikere med hvad.

Det fungerer enkelt: hver tjeneste indeholder et felt networks hvor du angiver, hvilke netværk den tilhører, og derefter i den øverste sektion networks Du definerer disse netværk med deres konfiguration. Den mest almindelige (og anbefalede i mange tilfælde) fremgangsmåde er at bruge driveren. bridge.

Et bronetværk skaber en privat rum netværk til dine containeremed automatisk DNS-opløsning baseret på tjenestenavnet. Det betyder, at hvis din databasetjeneste f.eks. kaldes databaseEnhver anden tjeneste på samme netværk kan oprette forbindelse ved blot at bruge det database som værtsnavn.

I et projekt med en frontend, en backend og en database kan du f.eks. beslutte at oprette et frontend-netværk og et backend-netværk. Frontend'en ville oprette forbindelse til backend'en, og backend'en til databasen, men frontend'en og databasen... De behøver ikke nødvendigvis at dele et netværkreduktion af det indre eksponerede overfladeareal.

I kode oversættes dette til noget så ligetil som at tildele det tilsvarende netværk til hver tjeneste og derefter definere disse netværk med driverbroer. På applikationsniveau er den enkleste tilgang at bruge tjenestenavnet som vært ved konfiguration af forbindelser: af app a databaseFor eksempel ved blot at angive, at databaseværten er "database".

Volumener i Docker Compose: Datapersistens

Volumener er den anbefalede måde at persisterende oplysninger genereret af containerneSom databaserBrugerfiler, sikkerhedskopier osv. De bruges også til at dele data mellem tjenester inden for den samme stak.

I afsnittet services Du kan montere volumener direkte med volumesMen når du ønsker, at den pågældende mængde skal være tilgængelig for flere containere, eller du vil administrere den mere eksplicit, definerer du den også i den øverste sektion. volumes fra compose.yaml.

Forestil dig, at du vil oprette et backup-system til din database. Databasetjenesten ville montere et volumen, hvor den gemmer sine data, og en anden tjeneste dedikeret til backups, der Monter den samme diskenhed i læsetilstand at udføre eksport eller synkroniseringer uden at røre hovedcontaineren.

Docker giver dig mulighed for at finjustere konfigurationen af ​​volumener med flere parametre (drivertype, specifikke indstillinger for drivere eksterne faktorer osv.), men i de fleste tilfælde er det mest praktiske at lade det ske. Docker administrerer volumener automatisk uden at blive vanvittig med mærkelige konfigurationer.

Det vigtige er at være klar over, hvilke mapper i dine tjenester der skal være persistente, og at deklarere dem som volumener i Compose, så du ikke mister data, når du genskaber containere eller opdaterer billeder.

Konfigurationer: administration af konfigurationsfiler

sektion configs Den er designet til at administrere konfigurationsfiler af tjenester i din stak, svarende til volumener, men specifikt fokuseret på konfiguration.

Tænk på en Apache- eller Nginx-server, der kører på Docker. Du skal sandsynligvis bruge juster din konfigurationsfil Det er ineffektivt og irriterende at genopbygge billedet, hver gang du ændrer disse filer, især i miljøer, hvor parametre ofte justeres.

med configs Du kan angive i den service, du ønsker anvende en specifik konfiguration og beskriv det derefter i afsnittet configsDer er flere måder at definere dem på, den mest almindelige er:

• fileKonfigurationen genereres fra en lokal fil.
• external: hvis det er markeret som trueCompose antager, at konfigurationen allerede findes, og at der kun refereres til den.
• nameInternt navn på konfigurationen i Docker, nyttigt ved kombination med external: true.

På denne måde kan du opdatere konfigurationsfilen på din maskine og vende tilbage til hæv stakken uden at skulle genopbygge basisbilledet, hvor billedkoden holdes adskilt fra den miljøspecifikke konfiguration.

Hemmeligheder: legitimationsoplysninger og følsomme data

sektion secrets løser et klassisk problemHvor opbevarer jeg adgangskoder, API-nøgler og andre følsomme oplysninger uden at efterlade dem spredt ud over hele koden eller YAML?

Ligesom med konfigurationer kan hemmeligheder defineres på forskellige måder.Det sædvanlige er:

• fileHemmeligheden genereres ud fra indholdet af en fil (for eksempel en tekstfil med en nøgle).
• environmentHemmeligheden oprettes ved hjælp af værdien af ​​en miljøvariabel på dit system.
• external: angiver, at hemmeligheden allerede er oprettet og kun skal refereres til. Dette er nyttigt for at undgå at overskrive hemmeligheder, der administreres udefra.
• name: internt navn på hemmeligheden, især relevant ved kombination external: true med hemmeligheder skabt af et andet værktøj.

Med hemmeligheder kan du oprette containere, der skal have adgang til disse legitimationsoplysninger læs dem på en kontrolleret måde uden at skulle efterlade dem synlige i kodelageret eller i selve compose.yaml, hvilket styrker sikkerheden af ​​dine implementeringer betydeligt.

Arbejde med flere filer Komponér og inkluder

I store projekter er det ikke ualmindeligt, at din applikation er opdelt i flere tjenester, sommetider administreret af forskellige teams. I disse tilfælde er det praktisk at... opdel konfigurationen i flere Compose-filer for bedre at modularisere arkitekturen.

En typisk fremgangsmåde er at have en compose.yaml hovedfilen for applikationen og andre filer for dele af infrastrukturen. For eksempel kan du flyt definitionen af ​​Redis eller andre filsupporttjenester infra.yaml og behold kun det, der direkte vedrører din app, i hovedindholdet.

For at gøre dette opretter du filen infra.yaml med sin egen sektion services hvor du for eksempel efterlader hele Redis-tjenesten. Derefter i din compose.yaml hoved, du tilføjer en sektion include som peger på filen infra.yaml.

Når du løber docker compose up Fra projektmappen, Skriv Kombinér begge filer og det viser alle tjenesterne, som om de var i en enkelt YAML, men du har stadig logikken adskilt og mere organiseret.

Denne teknik gør det nemmere for forskellige teams at vedligeholde deres egne Compose-filer og at samle den globale applikation ved hjælp af includes, hvilket er meget nyttigt i arkitekturer med snesevis af containere eller miljøer med meget delt infrastruktur.

Vigtige Docker Compose-kommandoer

Selvom Compose har et godt katalog af kommandoer, bruger de fleste i det daglige arbejde en håndfuld af dem tilbagevendendeDet er vigtigt at mestre dem, fordi de er det, der definerer din arbejdsgang.

Det vigtigste er docker compose upDenne kommando bygger de nødvendige images (hvis de ikke allerede findes), opretter containerne, konfigurerer netværk og volumener og starter alle de tjenester, der er defineret i din Compose-fil. Det er den kommando, du bruger, når du vil starte din stak.

Det kombineres normalt med muligheden -d at køre den i "afkoblet" tilstandDet vil sige i baggrunden. På denne måde fylder du ikke terminalen med logfiler, og du kan fortsætte med at bruge den session til andre kommandoer. For eksempel: docker compose up -d.

For at stoppe og rydde op i det, du har løftet, bruger du docker compose downsom stopper og fjerner containere, netværk og eventuelt tilknyttede billeder og volumener. To meget almindelige flag her er --rmi (for at slette billeder) og -v (for at fjerne volumener defineret i afsnittet volumes).

Hvis du vil se, hvilke containere der er en del af projektet, og hvad deres status er, kan du køre docker compose psDette viser hver tjeneste, dens status (op, afsluttet osv.) og de eksponerede porte, hvilket er meget nyttigt til at verificere, at alt fungerer korrekt efter en up.

Når du starter din stak i afkoblet tilstand, vises loggene ikke i terminalen. For at se dem skal du bruge... docker compose logsenten globalt eller ved filtrering efter tjeneste. Flaget -f Det giver dig mulighed for at spore logfiler i realtid, meget nyttigt for fejlfinding af en specifik tjeneste uden at skulle have adgang til beholderens indre.

Typisk arbejdsgang: definere compose.yaml, udføre en docker compose up -d, tjek med docker compose ps, gennemgå logfiler med docker compose logs -f <servicio> Hvis noget går galt, og når du er færdig, skal du bruge docker compose down at efterlade alt rent.

Hvis du nogensinde farer vild, docker compose --help Den viser dig listen over tilgængelige underkommandoer og muligheder, der hjælper dig med at huske, hvad hver ting gør, uden at skulle gå til dokumentationen.

I lyset af alt ovenstående, nøgleværktøj For alle, der arbejder med containere ud over blot individuelle projekter, er Compose et fantastisk værktøj. Det giver dig mulighed for at udvikle direkte i et miljø, der er meget lig (eller identisk med) produktion, kontroltjenester, netværk og data fra en simpel YAML-fil, og undgå en række kompatibilitets- og implementeringsproblemer, der uundgåeligt opstår, når man kun arbejder "lokalt" uden containere. Når du først har vænnet dig til at skrive en god Compose YAML-fil til dine projekter, er det svært at gå tilbage.