Komplet Docker Compose-vejledning til orkestrering af containere

Hvis du allerede har eksperimenteret med containere og indset, at en "rigtig" app kræver mere end én tjeneste, der kører samtidigt (database, API, frontend, cache osv.), vil du med tiden støde på Docker Compose. Dette værktøj giver dig mulighed for at opsætte al den infrastruktur med en enkelt fil og et par kommandoer, uden at skulle jonglere med terminaler og endeløse scripts.

I denne vejledning lærer du, hvad Docker Compose er, hvordan dens compose.yaml-fil fungerer, og hvordan du nemt orkestrerer multi-container-applikationer: fra simple eksempler med Flask og Redis til mere komplekse arkitekturer med en frontend, backend og database. Du vil også dække 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 giver dig mulighed for at definere og administrere flere containere, som om de var én applikation. I stedet for at starte hver tjeneste manuelt med dens `docker run`-kommando og parametre, beskriver du alt i en YAML-fil og starter det med en enkelt kommando.

Det smarte ved Compose er, at mange moderne applikationer er bygget på mikrotjenester, der kører i individuelle containere : en database, en API, en frontend, et køsystem, en Redis-lignende cache osv. Docker anbefaler, at hver container kører en enkelt tjeneste, 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 ødelægger en stor del af Dockers fordele : hvis én går ned, trækker den de andre ned, du kan ikke kun skalere den del, der modtager den største belastning, og administration af logs, ressourcer og fejl bliver et stort rod.

Med Docker Compose definerer du hver tjeneste separat, specificerer hvordan de forbinder til hinanden, hvilke data de persisterer, hvilke porte de eksponerer, hvilke miljøvariabler de bruger osv. På denne måde kan resten fortsætte med at fungere, hvis én container fejler, afhængigt af hvordan du konfigurerer den, og skalering af en specifik komponent er lige så simpelt som at ændre dens konfiguration eller antallet af replikaer.

Derudover passer Compose perfekt ind i CI/CD-arbejdsgange og produktionsimplementeringer . Du 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 manuelt.

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

For nemt at følge eksemplerne i denne vejledning skal du have Docker og Docker Compose installeret . I øjeblikket er der to hovedstier:

• 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 have en grundlæggende forståelse af Docker-kommandoer (billeder, containere, porte, volumener) og ikke være bange for at bruge kommandolinjen. Eksemplerne er normalt baseret på Linux (f.eks. Ubuntu 22.04), men logikken gælder ligeligt for Windows og macOS med Docker Desktop.

Bekræft at alt er i orden ved at køre noget så simpelt som "docker --version" og "docker compose version" i din terminal . Hvis begge kommandoer svarer 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: services . Derfra 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 en API , samt 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 indstille en række parametre , herunder nogle der almindeligvis bruges i virkelige projekter:

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 opsætte nogenlunde komplette tjenester. Compose-specifikationen indeholder mange mere avancerede muligheder (tilstand, ressourcegrænser, opstartskommandoer osv.), men disse dækker allerede de fleste almindelige anvendelser.

Eksempel 1: Webapplikation i Python med Flask og Redis

Et typisk eksempel på forståelse af Docker Compose er at oprette en simpel webapplikation i Python , hvor man bruger Flask til at servere sider og Redis som et in-memory-lager til en besøgstæller. Ideen er, at man ikke behøver at installere hverken Python eller Redis på sin 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 håndterer hit-tælleren, forsøger at oprette forbindelse til Redis flere gange, før den giver op, da Redis-containeren kan tage et par sekunder, før den bliver tilgængelig, når du åbner 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 din projektmappe og køre "docker compose up" . Compose downloader Redis-billedet, bygger dit webapplikationsbillede og starter 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 praktisk at arbejde i udvikling med Docker, hvis du ikke behøver at genopbygge imaget hver gang du ændrer koden. Det er her, Bind Mounts og, i nyere versioner, Docker Compose Watch kommer ind i billedet.

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 går et skridt videre: Du kan bruge `docker compose watch` eller `docker compose up --watch` til at få Compose til at overvåge dine projektfiler og synkronisere ændringer med dine 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 mere realistisk arkitektur, forestil dig en to-do-listeapplikation (Todo List) med en frontend i Vue.js, en API i Node.js og en MongoDB-database. Hver del findes 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 gør det muligt for dine containere at "se" og kommunikere med hinanden på en kontrolleret måde . Som 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 ville ikke nødvendigvis dele et netværk , hvilket reducerer den interne angrebsflade.

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

Volumer er den anbefalede måde at bevare information genereret af containere , såsom databaser , brugerfiler, 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 monterer et volumen, hvor den gemmer sine data, og en anden tjeneste dedikeret til backups monterer det samme volumen i skrivebeskyttet tilstand for at udføre eksport eller synkroniseringer uden at røre hovedcontaineren.

Docker giver dig mulighed for at finjustere volumenkonfigurationer med flere parametre (drivertype, specifikke muligheder for eksterne drivere osv.), men i de fleste tilfælde er det mere praktisk at lade Docker administrere volumener automatisk uden at sidde fast i 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 i Docker. Du skal sandsynligvis justere dens konfigurationsfil ret ofte. Det er ineffektivt og irriterende at genopbygge imaget, 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 genopbygge stakken uden at skulle genopbygge basisbilledet , idet du holder billedkoden 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 . Den sædvanlige måde 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 tillade containere, der har brug for adgang til disse legitimationsoplysninger , at læse dem på en kontrolleret måde uden at skulle efterlade dem synlige i kodelageret eller i selve compose.yaml-filen, hvilket styrker sikkerheden for 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 opdele 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 en masse delt infrastruktur.

Vigtige Docker Compose-kommandoer

Selvom Compose har et godt katalog af kommandoer, bruger de fleste kun en håndfuld af dem regelmæssigt dagligt . Det er værd at mestre disse, fordi de 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 betragtning af alt ovenstående er dette et nøgleværktøj for alle, der arbejder med containere ud over blot individuelle projekter. 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 ret svært at gå tilbage.