Sådan overvåger du PostgreSQL, der kører inde i en Docker-container:Del 1

Overvågning er handlingen med at se og tjekke over en periode for at se, hvordan det, du overvåger, udvikler sig og præsterer. Du gør det, så du kan foretage de nødvendige ændringer for at sikre, at tingene fungerer korrekt. Det er vigtigt, at processer overvåges for at give god indsigt i de aktiviteter, der udføres, for at planlægge, organisere og drive en effektiv løsning.

Docker er et program, der er skabt til at fungere som en bygherre, der er klar til at besvare spørgsmålet "Kører softwaren på min maskine?" Den samler grundlæggende forskellige dele sammen og skaber en model, der er nem at opbevare og transportere. Modellen, også kendt som container, kan sendes til enhver computer, som har Docker installeret.

I denne artikel vil vi blive introduceret til Docker, hvor vi beskriver nogle måder at konfigurere på og sammenligne dem. Desuden kommer PostgreSQL til at spille, og vi vil implementere det inde i en Docker-container på en smart måde, og endelig vil vi se de fordele, som ClusterControl kan give, for at overvåge nøglemålinger om PostgreSQL og operativsystemet udenfor.

Docker-oversigt

Når Docker starter, opretter den en ny netværksforbindelse for at tillade transmission af data mellem to endepunkter, kaldet bridge, og det er her, nye containere holdes som standard.

I det følgende vil vi se detaljer om denne bro og diskutere, hvorfor den ikke er en god idé at bruge i produktionen.

$ docker network inspect bridge

Bemærk venligst de indlejrede muligheder, for hvis du kører en container uden at angive det ønskede netværk, vil du acceptere det.

På denne standard netværksforbindelse mister vi nogle gode fordele ved netværk, såsom DNS. Forestil dig, at du vil have adgang til Google, hvilken adresse foretrækker du, www.google.com eller 172.217.165.4?

Jeg ved ikke med dig, men jeg foretrækker det tidligere valg, og for at være ærlig, skriver jeg ikke 'www.'.

Brugerdefineret bronetværk

Så vi vil have DNS i vores netværksforbindelse og fordelen ved isolation, for forestil dig scenariet, hvor du installerer forskellige containere inde i det samme netværk.

Når vi opretter en Docker-container, kan vi give den et navn, eller Docker gør det til os ved at randomisere to ord forbundet med understregning eller '_'.

Hvis vi ikke bruger et brugerdefineret bronetværk, kan det i fremtiden være et problem i midten af ​​IP-adresserne, fordi vi tydeligvis ikke er maskiner, og husk at disse værdier kan være svære og fejlbehæftede.

Det er meget nemt at oprette en brugerdefineret bro eller et brugerdefineret bronetværk.

Før du opretter vores første, for at forstå processen bedre, lad os åbne en ny terminal, skrive en Linux-kommando af pakken iproute2 og glemme det nu.

$ ip monitor all

Denne terminal vil nu lytte til netværksaktiviteten og vises der.

Du har måske set kommandoer som "ifconfig" eller "netstat" før, og jeg fortæller dig, at de er forældet siden 2001. Pakkens net-værktøjer er stadig meget brugt, men opdateres ikke længere.

Nu er det tid til at oprette vores første brugerdefinerede netværk, så åbn en anden terminal og indtast:

$ docker network create --driver bridge br-db

Denne meget lange blanding af bogstaver og tal kaldes UUID eller Universally Unique IDentifier. Det er dybest set at sige, at netværket er blevet oprettet med succes.

Det givne navn for vores første manuelt oprettede netværk har været "br-db", og det skal være i den sidste del af kommandoen, men før det har vi argumentet "-driver" og derefter værdien "bro" , hvorfor?

I Community Edition tilbyder Docker tre forskellige drivere:bro, vært og ingen. På oprettelsestidspunktet, som dette, er standarden bridge, og det behøver ikke at blive specificeret, men vi lærer om det.

Hvis du har gjort alt sammen med mig, så se på den anden terminal, for jeg vil forklare dig, hvad der foregår.

Docker har oprettet netværket, kaldet "br-db", men dette kaldes kun sådan af ham.

På den anden side af denne oprettede brugerdefinerede bro er der et andet lag, OS. Det givne navn for det samme bronetværk er ændret og bliver en repræsentation af nomenklaturen for bro, "br", efterfulgt af de første 12 tegn i UUID-værdien ovenfor, i rødt.

Med vores nye netværksforbindelse har vi et undernet, gateway og broadcast.

Gatewayen er, som navnet antyder, hvor al trafikken af ​​pakker sker mellem broens endepunkter, og det kaldes "inet" for OS, som du kan se.

Broadcast står i den sidste IP-adresse og er ansvarlig for at sende den samme trafik af data for alle IP-adresserne i undernettet, når det er nødvendigt.

De er altid til stede i netværksforbindelser, og det er derfor, vi har i begyndelsen af ​​output, værdien "[ADDR]". Denne værdi repræsenterer IP-adresseændringer, og det er som en hændelse, der udløses til netværksaktivitetsovervågning, fordi vi har oprettet en ny netværksforbindelse!

Docker-beholder

Besøg venligst Docker Hub, og se, at det, der findes, er kendt som Docker Image, og det er dybest set skelettet af containeren (modellen).

Docker-billeder genereres af Dockerfiles, og de indeholder al den information, der er nødvendig for at oprette en container, for at gøre den nem at vedligeholde og tilpasse.

Hvis du kigger med opmærksomhed ind i Docker Hub, er det let at se, at PostgreSQL-billedet, kaldet postgres, har forskellige tags og versioner, og hvis du ikke angiver et af dem, vil standarden blive brugt, det seneste, men måske i fremtiden, hvis du har brug for forskellige beholdere af PostgreSQL, der arbejder sammen, vil du måske have dem i samme version.

Lad os skabe vores første rigtige container nu, husk behovet for argumentet "--netværk", ellers vil det blive implementeret i standardbroen.

$ docker container run --name postgres-1 --network br-db -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6551:5432 -d postgres

Igen UUID, succes, og i den anden terminal, hvad sker der?

Ændringer i netværksgrænsefladen er den begivenhed, der sker lige nu, eller blot "[LINK]". Alt efter "veth" kan du glemme, tro mig, værdien ændres altid, når containeren genstartes, eller noget lignende sker.

Den anden mulighed "-e POSTGRES_PASSWORD=?" står for Environment, og det er kun tilgængeligt, når du kører PostgreSQL-containere, det konfigurerer adgangskoden til superbrugerkontoen i databasen, kaldet postgres.

Publish er det lange navn for parameteren "-p 6551:5432", og det gør i bund og grund OS-port 6551 tovejsbundet til port 5432 på containeren.

Sidst, men ikke mindre vigtigt, er detach-indstillingen, "-d", og det, den gør, er at få containeren til at køre uafhængigt af denne terminal.

Docker Image-navnet skal være til sidst, efter det samme mønster som netværksoprettelse, have alle argumenter og muligheder til venstre, og til sidst det vigtigste, i dette tilfælde, billednavnet.

Husk, at containerne holdes i netværksundernettet og står på IP-adresser, der er tilladt for hver enkelt af dem, og de vil aldrig være i den første eller sidste adresse, fordi Gateway og Broadcast altid vil være der.

Vi har vist detaljerne for den oprettede bro, og vil nu blive vist af hvert af de endepunkter, disse detaljer opbevares af dem.

$ docker network inspect br-db

$ brctl show

Som du kan se, er netværks- og containernavnene forskellige, idet det andet genkendes som en grænseflade af OS, kaldet "veth768ff71", og det oprindelige navn givet af os "postgres-1" for Docker.

I Docker-kommandoen er det muligt at notere IP-adressen for containeren, der blev oprettet tidligere, undernettet, der matcher det, der dukkede op i den anden terminal, åbnede for et øjeblik siden, og til sidst er indstillingerne tomme for dette brugerdefinerede netværk.

Linux-kommandoen "brctl show" er en del af pakken bridge-utils, og som navnet antyder, er dens formål at give et sæt værktøjer til at konfigurere og administrere Linux Ethernet-broer.

Et andet Custom Bridge-netværk

Vi vil snart diskutere DNS, men det har været meget godt at gøre tingene nemmere for os i fremtiden. Fantastiske konfigurationer har en tendens til at gøre livet for DBA lettere i fremtiden.

Med netværk er det det samme, så vi kan ændre, hvordan OS genkender subnet-adressen og netværksnavnet ved at tilføje flere argumenter ved oprettelsestidspunktet.

$ docker network create --driver bridge --subnet 172.23.0.0/16 -o “com.docker.network.bridge.name”=”bridge-host” bridge-docker

$ ip route show

Med denne Linux-kommando kan vi se næsten det samme som den anden kommando tidligere, men nu i stedet for at angive "veth"-grænsefladerne for hvert netværk, har vi simpelthen denne "linkdown", der viser dem, der er tomme.

Den ønskede undernetadresse er blevet angivet som et argument, og i lighed med indstillingen Environment for containeroprettelse har vi for netværket "-o" efterfulgt af parret af nøgle og værdi. I dette tilfælde fortæller vi Docker, at han skal fortælle OS, at han skal kalde netværket som "bro-vært".

Eksistensen af ​​disse tre netværk kan også verificeres i Docker, bare indtast:

$ docker network ls

Nu har vi tidligere diskuteret, at værdierne af disse "veth" for containerne er ligegyldige, og jeg vil vise dig i praksis.

Øvelsen består i at verificere den aktuelle værdi, derefter genstarte beholderen og derefter bekræfte igen. For at gøre det har vi brug for en blanding af Linux-kommandoer brugt før, og Docker-kommandoer, som er nye her, men meget enkle:

$ brctl show
$ docker container stop postgres-1
$ docker container start postgres-1
$ brctl show

Når containeren er stoppet, skal IP-adressen frigives til at modtage en ny, hvis det er nødvendigt, og det er en påmindelse om, hvordan DNS kan være vigtig.

OS giver disse navne til grænsefladerne, hver gang en container står i en IP-adresse, og de genereres ved hjælp af pakken iptables, som snart vil blive erstattet af den nye ramme kaldet nftables.

Det anbefales ikke at ændre disse regler, men der findes værktøjer til at hjælpe med deres visualisering, hvis det er nødvendigt, såsom dockerveth.

Beholdergenstartspolitik

Når vi genstarter Docker-programmet, eller endda computeren, bliver de netværk, han har oprettet, bevaret i OS, men tomme.

Containere har det, der kaldes Container Restart Policy, og dette er et andet meget vigtigt argument, der er angivet ved oprettelsestidspunktet. PostgreSQL, som en produktionsdatabase, er hans tilgængelighed afgørende, og det er sådan Docker kan hjælpe med det.

$ docker container run --name postgres-2 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6552:5432 -d postgres

Medmindre du stopper det manuelt, vil denne beholder "postgres-2" altid være tilgængelig.

For at forstå det bedre, vil de kørende containere blive vist og Docker-programmet genstartet, derefter det første trin igen:

$ docker container ls
$ systemctl restart docker
$ docker container ls

Kun containeren "postgres-2" kører, den anden "postgres-1" container starter ikke alene. Mere information om det kan ses i Docker-dokumentationen.

Domænenavnesystem (DNS)

En fordel ved det brugerdefinerede Bridge-netværk er helt sikkert organisationen, fordi vi kan oprette så mange, som vi vil, til at køre nye containere og endda forbinde gamle, men en anden fordel, som vi ikke har ved at bruge Docker-standardbroen, er DNS.

Når containere skal kommunikere med hinanden, kan det være smertefuldt for DBA at huske IP-adresserne, og vi har diskuteret det tidligere og vist eksemplet med www.google.com og 172.217.165.4. DNS løser dette problem problemfrit, hvilket gør det muligt at interagere med containere ved hjælp af deres navne givet ved oprettelsestidspunktet af os, som "postgres-2", i stedet for IP-adressen "172.23.0.2".

Lad os se, hvordan det virker. Vi vil oprette en anden container kun til demonstrationsformål i det samme netværk kaldet "postgres-3", så installerer vi pakken iputils-ping for at overføre pakker med data til containeren "postgres-2", selvfølgelig ved at bruge dens navn .

$ docker container run --name postgres-3 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6553:5432 -d postgres
$ docker container exec -it postgres-3 bash

For en bedre forståelse, lad os opdele det i dele, i de følgende output, vil den blå pil angive, når kommandoen udføres inde i en container, og i rødt, i OS.

$ apt-get update && apt-get install -y iputils-ping

$ ping postgres-2

Oversigt

PostgreSQL kører inde i Docker, og hans tilgængelighed er garanteret nu. Når de bruges inden for et brugerdefineret bronetværk, kan containerne administreres lettere med mange fordele såsom DNS, tilpassede undernetadresser og OS-navne til netværkene.

Vi har set detaljer om Docker og vigtigheden af ​​at være opmærksom på opdaterede pakker og rammer på operativsystemet.