Formålet med Docker Volumes

Docker-containere er ment å være en drop-in-erstatning for applikasjoner. De er ment å være engangs og enkle å erstatte. Denne egenskapen er faktisk hjørnesteinen i mange CI/CD -rørledninger. Når en endring blir gjort presset til kildelageret ditt som utløser en hendelseskjede. Docker -bilder bygges automatisk, testet og (noen ganger) til og med distribuert rett i produksjon, og erstatter de eldre versjonene sømløst.

Men det er ofte vedvarende data som må bevares mellom forskjellige utgivelser av applikasjonen din. Eksempler inkluderer databaser, konfigurasjonsfiler for appene dine, loggfiler og sikkerhetsopplysninger som API -nøkler og TLS -sertifikater.

For å la alle disse dataene vedvare, vil vi bruke Docker -volumer som bare er deler av Docker Hosts filsystem (en katalog eller en blokkeringsenhet formatert med et filsystem) som kan monteres inne i en beholder på et hvilket som helst ønsket sted i beholderens filsystem.

Sett opp

For å sikre at vi alle er på samme side, her er versjonen av Docker Runtime og Docker-Compose som jeg bruker:

1. Docker versjon 18.09.2, bygg 6247962
2. Docker-Compose versjon 1.23.2, bygg 1110AD01
3. Komponere filversjon 3: fungerer med 1.1. 3.0 og over

Eksempel: Hosting et Ghost CMS -nettsted

Å jobbe med komponering er virkelig rett frem. Du skriver en YAML-fil som beskriver distribusjonen din og kjører den deretter ved hjelp av Docker-Compose CLI. La oss starte med en enkel spøkelses CMS -distribusjon.

Opprett en katalog som heter ComposesAmples og lag i den, oppretter en fil som heter Docker-Compose.Yaml

$ mkdir komposerer
$ CD ComposesAmples
Innholdet i Docker-Compose.Yaml:
Versjon: "3.0 "
tjenester:
Web:
Bilde: Ghost: Siste
Porter:
- "2368: 2368"
Volum:
- CMS-Content:/var/lib/spøkelse/innhold
Volum:
CMS-innhold:

Denne komponeringsfilen erklærer en enkelt tjeneste som er nett som kjører det siste bildet av Ghost CMS fra Docker Hubs offisielle depot. Porten eksponert er 2368 (mer om dette i litt senere), og et volum er da et volum som kalles CMS-innhold montert på/var/lib/spøkelse/innhold du kan lese om din spesielle applikasjon og nyanser ved å slå opp de appene Dokumentasjon. For eksempel er Ghost Container's standardport 2368 og standard monteringspunkt for nettstedets innhold/var/lib/spøkelse/innhold begge nevner det containerens offisielle dokumentasjon.

Hvis du skriver en ny applikasjon av din egen, kan du tenke på alle vedvarende data den vil trenge tilgang til og følgelig angi monteringspunktene for Docker -volumene dine.

For å teste at det vedvarende volumet fungerer, kan du prøve dette:

1. Åpne en nettleser og skriv inn Docker -vertens IP, det vil si http: // dockerhostip: 2368/ghost (eller bare http: // localhost: 2368/ghost) og opprett en admin -konto. Endre et av de eksisterende innleggene og lagre.
2. Liste opp alle Docker -komponentene som kjører ved hjelp av kommandoene: Docker PS, Docker Network LS, Docker Volume LS
3. I samme katalog som komponeringsfilen din, utfør kommandoen $ Docker-Compose Down, og nå kan du liste opp alle Docker-containere, nettverk og volum. Interessant nok vil du legge merke til at mens containeren og nettverket opprettet av Docker-Compose fjernes, er Docker-volumet fortsatt intakt.
4. Kjør Docker -Compose Up -D, og ​​du vil merke at det modifiserte innlegget er akkurat der du forlot det, til og med admin -påloggingsinformasjonen din kan brukes igjen, og du trenger ikke å opprette en ny admin -konto.
5. Fjern seksjonene med volum fra begge tjenestene: Web: Seksjon og fra hoveddelen, og nå hvis du gjentar de ovennevnte tre trinnene, vil du legge merke til det.

Syntaks og verbositet

Syntaksen for å introdusere et volum ved hjelp av Docker-Compose er ganske grei. Du starter med noe som ligner på en beholder, og nevner navnet på volumet du vil montere inni den. Hvis du ikke nevner et navn, kan du gå for en lat syntaks som nedenfor:

Versjon: "3.0 "
tjenester:
Web:
Bilde: Ghost: Siste
Porter:
- "2368: 2368"
Volum:
- /var/lib/spøkelse/innhold

Hvis du vil være litt mer ordentlig, må du nevne Docker -volumet som en definisjon på toppnivå:

Versjon: "3.0 "
tjenester:
Web:
Bilde: Ghost: Siste
Porter:
- "2368: 2368"
Volum:
- CMS-Content:/var/lib/spøkelse/innhold
## definere at CMS-innhold faktisk er et volum.
Volum:
CMS-innhold:

Selv om den sistnevnte versjonen krever at du skriver mer, er den mer ordentlig. Velg relevant navn for volumene dine, slik at kollegene kan forstå hva som er gjort. Du kan gå enda lenger og nevne typen volum (mer om dette senere) og påpeke kilde og mål.

Volum:
- Type: Volum
Kilde: CMS-data
Mål:/var/lib/spøkelse/innhold

Bind monteringer

Bind monteringer er deler av vertsfilsystemet som kan monteres direkte inne i Docker -beholderen. For å introdusere en bindingsfeste, bare nevne vertskatalogen du vil dele og monteringspunktet inne i Docker -beholderen der den burde monteres:

Volum:
- /hjem//prosjekter/spøkelse:/var/lib/spøkelse/innhold

Jeg brukte banen/hjemmet // prosjekter/spøkelse som bare et eksempel, du kan bruke hvilken vei på Docker -verten du ønsker, forutsatt at du har tilgang til den, selvfølgelig.

Du kan også bruke relative stier ved å bruke $ PWD eller ~, men det kan lett føre til feil og katastrofer i de virkelige scenariene der du samarbeider med flere andre mennesker hver med sitt eget Linux-miljø. På baksiden er noen ganger relative stier faktisk lettere å håndtere. For eksempel, hvis din git -repo også skal være din bindingsfeste ved hjelp av prikk (.) Å symbolisere gjeldende katalog kan godt være ideelt.

Nye brukere kloner repoen og kloner den hvor som helst i vertssystemet, og kjør Docker -Compose Up -D og får stort sett det samme resultatet.

Hvis du bruker en mer ordentlig syntaks, er dette hva din komponeringsfil vil inneholde:

Volum:
- Type: Bind
Kilde:/Hjem/bruker/prosjekter/spøkelse
Mål:/var/lib/spøkelse/innhold

Konklusjon

Å organisere applikasjonene dine slik at appen er atskilt fra dataene kan være veldig nyttige. Volumene er tilregnelige måter å oppnå nettopp det. Forutsatt at de er sikkerhetskopiert og sikre, kan du fritt bruke til å bruke containerne som engangsmiljøer, selv i produksjonen!

Oppgradering fra en versjon av appen til den neste eller bruke forskjellige versjoner av appen din for A/B -testing kan bli veldig strømlinjeformet så lenge måten data er lagret på, eller tilgjengelig er den samme for begge versjonene.