Docker-Compose kan brukes til å enkelt automatisere distribusjoner av flere container. En av de mest utfordrende oppgavene mens du kjører slike distribusjoner er å skille data fra programvare.

Mens containere er flyktige, må brukerdata vedvare. Et klassisk eksempel, av dette er når vi prøver å kjøre databasebeholderbilder. Hvis du ødelegger databasebeholderen, går dataene også tapt. Det vi ønsker er en situasjon der containerbildet av, for eksempel, PostgreSQL versjon 9 kan erstattes med et bilde av versjon 10 uten at vi trenger å miste noen data. Dette er Docker -måten å oppgradere programvare, du slipper ikke inne i containeren og oppdaterer pakker ved hjelp av en pakkebehandler. Du erstatter hele containerbildet.

La oss se noen få fallgruver du kan møte mens du gjør dette og hvordan vi kan gjøre prosessen mye jevnere og renere fra et operativt synspunkt.

Forutsetninger

1. En Docker -installasjon
2. Grunnleggende forståelse av Docker CLI og Docker-Compose

Docker -volum og PostgreSQL standard oppførsel

Docker -volumer er den anbefalte måten å vedvare data. Dette er filsystemer som administreres av Docker -demonet, og oftere enn ikke forventes det at du lager en og monterer den inne i beholderen når du starter den. Postgres offisielle bilde kommer imidlertid med et volum forhåndsdefinert i bildebeskrivelsen.

Dette betyr at når du kjører et postgreSQL -bilde som en beholder, oppretter det et volum for seg selv og lagrer data der inne.

$ Docker Run -D -Navn MyDB Postgres

Du kan liste opp de eksisterende volumene ved hjelp av Docker Volume LS -kommandoen, og du kan inspisere Docker Container MyDB for å se hvilke av disse volumene som er montert inne i databasebeholderen.

$ docker volum ls
Drivervolumnavn
Lokal 8328940661C0703ED867B004EA6343B9432E70069280B71CFCE592ECDD12E55D
$ docker inspiserer mydb
..
"Ridedyr": [

"Type": "Volum",
"Navn": "8328940661C0703Ed867b004EA6343B9432E70069280B71CFCE592ECDD12E55D",
"Kilde": "/var/lib/docker/volum/8328940661c0703ed867b004a6343b9432e70069280b71cf
CE592ECDD12E55D/_DATA ",
"Destinasjon": "/var/lib/postgreSql/data",
"Driver": "Lokal",
"Mode": "",
"RW": True,
"Forplantning": ""

],
..

Du vil merke at volumet har et ganske uvennlig navn og er montert på /var/lib/postgreSql/data.

La oss fjerne denne beholderen og det tilhørende volumet for nå:

$ docker rm -f mydb
$ docker volum RM 8328940661C0703ED867B004EA6343B9432E70069280B71CFCE592ECDD12E55D

Det samme er tilfelle når du oppretter en beholder ved hjelp av en enkel Docker-Compose-fil. Følgende er en Docker-komponering.YML -fil plassert i en katalog som heter Postgres.

Versjon: '3'
tjenester:
MYDB:
Bilde: Postgres

Du kan mate den til Docker-Compose, ved å åpne en terminal i samme katalog der denne filen er og kjører:

$ docker -compose up -d

Dette skaper en beholder og et volum omtrent som Docker Run -kommandoen vi så tidligere. Imidlertid har begge disse metodene, en som involverer Docker-Compose og en annen Docker CLI et dødelig problem, og det kommer i spill når du trenger å erstatte det gamle Postgres-bildet med et nytt.

Nye volum hver gang

Hvis du fjerner distribusjonen ovenfor ved å kjøre:

$ Docker-Compose Down

Beholderen og nettverket fjernes, men volumet stikker rundt og dataene dine er trygge i det. Men neste gang du løper:

$ docker -compose up -d

Komponer vil lage et nytt volum og montere som i stedet for å bruke det tidligere opprettet volum. Og hvordan kan det huske at det forrige bindet var ment for denne spesielle postgreSql -beholderen uansett? Men den stakkars brukeren som kanskje ikke engang er klar over volumbegrepet, vil bli forvirret og lurer på hvor alle dataene er borte.

Brukerdefinert volum

For å omgå dette problemet, kan vi bruke informasjonen vi samlet tidligere som viste oss at volumet er montert på /var/lib/postgreSql/data. Inne i beholderen er denne katalogen der Postgres lagrer alle relevante tabeller og databaser.

Vi må nå definere et volum inne i komponeringsfilen og montere den på dette monteringspunktet. Slik docker-komponeres.YML ville se ut.

Versjon: '3'
tjenester:
MYDB:
Bilde: Postgres
Volum:
- db-data:/var/lib/postgreSql/data
Porter:
- 5432: 5432
Volum:
DB-data:
Driver: Lokal

Den siste linjen “Driver: Local” er helt valgfritt og nevnes her bare for å vise at “Nøkkel på toppnivå Volum ” kan ha flere volumer definert under den. DB-data er et slikt volum som igjen har spesifikasjoner, som sjåfører, inkludert som en innrykket blokk under den.

Under MYDB -tjenesten har vi volumnøkkelen igjen. Dette "service nivå Volum Key ” Det er bare en liste over volumer definert under toppnivået Volumes-tasten som blir kartlagt på monteringspunkter inne i containerne

Når du kjører Docker-Compose Up -D-kommando første gang med ovennevnte YML-definisjon, vil den lage et volum, ikke med en tilfeldig streng som navn, men DB-bata som navn. Så og utover hver gang du tar ned applikasjonen (Docker-Compose ned) og deretter kjører Docker-Composer-Compose-komponeringen til å lage et volum som heter DB-data, men da vil det merke at et volum med det navnet allerede eksisterer. Da vil det hjelpe det samme volumet igjen. La oss få ned søknaden for nå:

$ Docker-Compose Down

Bruke PostgreSQL

Det offisielle postgres -bildet utsetter porten 5432 mye til vår fordel. Strengt tatt er dette ikke nødvendig. Databaser er bare en av de mange tjenestene som kjører på et Docker -nettverk. De andre tjenestene, som webserver, kan snakke med databasen uten at noen eksplisitt port blir publisert. Dette er fordi brukerdefinerte bronettverk, som de Docker-komponeringene skaper for at appene dine kan kjøre på, la medlemsbeholdere fritt snakke med hverandre. Så hvis webserveren og databasen er i samme bronettverk, kan de snakke med hverandre selv uten at noen porter eksplisitt åpnes.

Databaser blir ofte ikke utsatt for omverdenen, men får tilgang til andre tjenester. Derfor er det ikke noe du ofte vil se i produksjon.

Vi skal imidlertid eksperimentere med den containeriserte applikasjonen for å se om dataene faktisk vedvarer, slik at vi kan eksponere og publisere portene for nå. Endre docker-komponering.YML -fil med ekstra porter -alternativ.

Versjon: '3'
tjenester:
MYDB:
Bilde: Postgres
Volum:
- db-data:/var/lib/postgreSql/data
Porter:
- 5432: 5432/TC
Volum:
DB-data:
Driver: Lokal

Nå er vi klare til å grensesnitt mot Postgres -forekomsten ved å bruke PGADMIN -klientprogram. Du kan installere denne klienten på din lokale maskin ved hjelp av din foretrukne metode hvis du følger denne lenken. Etter å ha installert klienten, kan du koble til databaseserveren, men la oss først starte databaseserveren.

$ docker -compose up -d

Denne gangen vil innkommende forespørsler hos Docker Host Port 5432 bli videresendt til Port 5432 i databasebeholderen, der Postgres Server kan behandle den.

Koble til serveren

Start PGADMIN -klienten, så får du tilgang til den via nettleseren din. I dashbordet finner du alternativet som heter Legg til ny server.

Gi det et rimelig navn, vi går med "Min database ”:

Og under fanen Tilkoblinger angir du adressen der databasen kjører:

Adressen kan være lokalhost hvis du kjører både PGADMIN og Postgres -beholderen kjører på samme maskin. Hvis du for eksempel kjører Postgres -beholder på en ekstern VPS, vil det være nødvendig med IP -adressen til den VPS her. Generelt kaller vi det adressen til Docker -verten fordi det er der Docker kjører.

Vi lar passordfeltet være tomt, og standard portnummer 5432 er også bra. Lagre serverinnstillingene og la oss opprette en database der inne.

Ved vellykket forbindelse kan du se alle interne aktiviteter:

Fra nettlesermenyen kan vi raskt velge Min database server og under den høyreklikk på databasen og Opprett en database.

La oss raskt lage en database som heter Eksempel på database.

Du trenger ikke å lage noe annet her inne. Nå kan vi lukke vinduet og gå tilbake til terminalen som er åpnet i samme katalog der Docker-komponeringen vår.YML lever.

$ Docker-Compose Down
$ docker -compose up -d

Den gamle beholderen er nå borte, og en ny har tatt sin plass. Du kan åpne pgadmin igjen, og du må koble deg på nytt til denne databasen (et tomt passord vil gjøre), og inni den vil du finne at alt er som du har hatt det til å være. Det er til og med en Eksempel på database der inne.

Konklusjon

Vi ønsket å skrive en Docker-Compose-fil som gjorde Postgres oppgraderbar. Hvis et nytt bilde av Postgres følger med å løpe postgres 11, kan du nå trekker det nye bildet inn og kjøre en oppgradering uten noen bekymringer for tilstanden til applikasjonen som går tapt.

Standardoppførselen til Postgres -bildet som skal lage et nytt volum hver gang en beholder opprettes er ikke et dårlig designvalg. Det implementeres med de beste interessene i hjertet.

Men det legger ganske enkelt ut en ny bruker som ville klø på hodet og lure på hvor alle dataene går seg vill, og hvorfor er det så mange volumer som ligger rundt i Docker -verten. Forhåpentligvis vil det ikke være noe problem for leserne lenger.