Hoe PostgreSQL in een Docker-container te controleren:deel één

Monitoring is het observeren en controleren gedurende een bepaalde periode om te zien hoe datgene wat u bewaakt zich ontwikkelt en presteert. U doet dit zodat u de nodige wijzigingen kunt aanbrengen om ervoor te zorgen dat alles correct werkt. Het is essentieel dat processen worden gemonitord om een ​​goed inzicht te krijgen in de activiteiten die worden uitgevoerd om een ​​efficiënte oplossing te plannen, organiseren en uitvoeren.

Docker is een programma dat is gemaakt om als bouwer te werken en klaar is om de vraag te beantwoorden:"Wordt de software op mijn machine uitgevoerd?" Het assembleert in feite verschillende onderdelen, waardoor een model ontstaat dat gemakkelijk op te bergen en te vervoeren is. Het model, ook wel container genoemd, kan worden verzonden naar elke computer waarop Docker is geïnstalleerd.

In dit artikel maken we kennis met Docker, beschrijven we enkele manieren van configuratie en vergelijken we ze. Verder komt PostgreSQL om de hoek kijken, en we zullen het op een slimme manier in een Docker-container implementeren, en tot slot zullen we de voordelen zien die ClusterControl kan bieden, om belangrijke statistieken over PostgreSQL en het besturingssysteem daarbuiten te bewaken.

Overzicht Docker

Wanneer Docker start, maakt het een nieuwe netwerkverbinding om de overdracht van gegevens tussen twee eindpunten mogelijk te maken, bridge genoemd, en dit is waar standaard nieuwe containers worden bewaard.

Hieronder zullen we details over deze brug bekijken en bespreken waarom het geen goed idee is om deze in productie te gebruiken.

$ docker network inspect bridge

Let op de ingesloten opties, want als u een container uitvoert zonder het gewenste netwerk op te geven, gaat u ermee akkoord.

Op deze standaard netwerkverbinding verliezen we enkele goede voordelen van netwerken, zoals DNS. Stel u voor dat u toegang wilt tot Google, welk adres heeft uw voorkeur, www.google.com of 172.217.165.4?

Ik weet niet hoe het met u zit, maar ik geef de voorkeur aan de eerdere keuze, en om eerlijk te zijn typ ik de 'www.' niet.

Door gebruiker gedefinieerd bridge-netwerk

Dus we willen DNS in onze netwerkverbinding en het voordeel van isolatie, want stel je het scenario voor waarin je verschillende containers in hetzelfde netwerk implementeert.

Wanneer we een Docker-container maken, kunnen we er een naam aan geven, of Docker maakt het voor ons door twee woorden willekeurig met elkaar te verbinden door onderstreping of '_'.

Als we geen User-Defined Bridge-netwerk gebruiken, kan er in de toekomst een probleem ontstaan ​​in het midden van de IP-adressen, omdat we duidelijk geen machines zijn, en onthoud dat deze waarden moeilijk en foutgevoelig kunnen zijn.

Het maken van een aangepaste brug, of een door de gebruiker gedefinieerd brugnetwerk, is heel eenvoudig.

Voordat we onze eerste maken, laten we, om het proces beter te begrijpen, een nieuwe terminal openen, een Linux-opdracht van het pakket iproute2 typen en het nu vergeten.

$ ip monitor all

Deze terminal luistert nu naar de netwerkactiviteit en wordt daar weergegeven.

Je hebt misschien eerder commando's als "ifconfig" of "netstat" gezien, en ik zeg je dat ze sinds 2001 verouderd zijn. Het pakket net-tools wordt nog steeds veel gebruikt, maar wordt niet meer bijgewerkt.

Nu is het tijd om ons eerste aangepaste netwerk te maken, dus open een andere terminal en voer in:

$ docker network create --driver bridge br-db

Deze zeer lange mix van letters en cijfers wordt UUID of Universally Unique IDentifier genoemd. Het zegt eigenlijk dat het netwerk succesvol is gemaakt.

De opgegeven naam voor ons eerste handmatig gemaakte netwerk is "br-db", en het moet in de finale van de opdracht staan, maar daarvoor hebben we het argument '"-driver", en dan de waarde "bridge" , waarom?

In de Community-editie biedt Docker drie verschillende stuurprogramma's:bridge, host en geen. Tijdens het maken, zoals dit, is bridge de standaard en hoeft dit niet te worden gespecificeerd, maar we leren erover.

Als je alles met mij hebt gedaan, kijk dan naar de andere terminal, want ik zal je uitleggen wat er aan de hand is.

Docker heeft het netwerk gemaakt, genaamd "br-db", maar dit wordt alleen door hem zo genoemd.

Aan de andere kant van deze aangepaste brug die is gemaakt, is er een andere laag, het besturingssysteem. De opgegeven naam voor hetzelfde bridge-netwerk is veranderd en wordt een weergave van de nomenclatuur voor bridge, "br", gevolgd door de eerste 12 tekens van de UUID-waarde hierboven, in het rood.

Met onze nieuwe netwerkverbinding hebben we een subnet, gateway en broadcast.

De Gateway, zoals de naam al doet vermoeden, is waar al het verkeer van pakketten plaatsvindt tussen de bridge-eindpunten, en het wordt "inet" genoemd voor het besturingssysteem, zoals u kunt zien.

Broadcast staat in het laatste IP-adres en is verantwoordelijk voor het verzenden van hetzelfde dataverkeer voor alle IP-adressen in het subnet indien nodig.

Ze zijn altijd aanwezig in netwerkverbindingen en daarom hebben we aan het begin van de uitvoer de waarde "[ADDR]". Deze waarde vertegenwoordigt IP-adreswijzigingen en het is alsof een gebeurtenis wordt geactiveerd voor de bewaking van netwerkactiviteit, omdat we een nieuwe netwerkverbinding hebben gemaakt!

Docker-container

Bezoek de Docker Hub en zie dat wat er is bekend staat als Docker Image, en het is in feite het skelet van de container (model).

Docker-afbeeldingen worden gegenereerd door Dockerfiles en bevatten alle informatie die nodig is om een ​​container te maken, zodat deze gemakkelijk te onderhouden en aan te passen is.

Als je aandachtig in de Docker Hub kijkt, is het gemakkelijk te zien dat de PostgreSQL-afbeelding, postgres genaamd, verschillende tags en versies heeft, en als je er geen opgeeft, wordt de standaard gebruikt, de nieuwste, maar misschien in de toekomst als je verschillende containers van PostgreSQL nodig hebt die samenwerken, wil je misschien dat ze in dezelfde versie zijn.

Laten we nu onze eerste juiste container maken, onthoud de noodzaak van het argument '--network', anders wordt het geïmplementeerd in de standaardbrug.

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

Weer de UUID, succes, en in de andere terminal, wat is er aan de hand?

Veranderingen in de netwerkinterface zijn de gebeurtenis die nu plaatsvindt, of gewoon "[LINK]". Alles na de "veth" kun je vergeten, geloof me, de waarde verandert altijd wanneer de container opnieuw wordt gestart of iets soortgelijks gebeurt.

De andere optie “-e POSTGRES_PASSWORD=?” staat voor Environment, en het is alleen beschikbaar bij het uitvoeren van PostgreSQL-containers, het configureert het wachtwoord voor het supergebruikersaccount in de database, postgres genaamd.

Publish is de lange naam voor de parameter "-p 6551:5432", en het maakt in feite de OS-poort 6551 bidirectioneel gebonden aan de poort 5432 van de container.

Als laatste, maar daarom niet minder belangrijk, is de optie Detach, "-d", en wat deze doet is de container onafhankelijk van deze terminal te laten draaien.

De naam van de Docker-afbeelding moet aan het einde hetzelfde patroon volgen als bij het maken van het netwerk, met alle argumenten en opties aan de linkerkant, en aan het einde het belangrijkste, in dit geval de naam van de afbeelding.

Onthoud dat de containers zich in het netwerksubnet bevinden, op IP-adressen die voor elk van hen zijn toegestaan, en dat ze nooit op het eerste of laatste adres zullen staan, omdat de gateway en broadcast er altijd zullen zijn.

We hebben de details van de gemaakte brug getoond en worden nu weergegeven door elk van de eindpunten die deze details bewaren.

$ docker network inspect br-db

$ brctl show

Zoals u kunt zien, verschillen de netwerk- en containernamen, waarbij de tweede wordt herkend als een interface door het besturingssysteem, genaamd "veth768ff71", en de oorspronkelijke naam die door ons is gegeven "postgres-1" voor Docker.

In het Docker-commando is het mogelijk om het IP-adres voor de eerder gemaakte container te noteren, het subnet dat overeenkomt met wat er in de andere terminal is geopend, en tot slot de opties leeg voor dit aangepaste netwerk.

Het Linux-commando "brctl show" maakt deel uit van het pakket bridge-utils, en zoals de naam al doet vermoeden, is het bedoeld om een ​​set tools te bieden voor het configureren en beheren van Linux Ethernet-bridges.

Nog een aangepast bridge-netwerk

We zullen het binnenkort hebben over DNS, maar het is heel goed geweest om dingen in de toekomst eenvoudig voor ons te maken. Geweldige configuraties hebben de neiging om het leven van de DBA in de toekomst gemakkelijker te maken.

Met netwerken is hetzelfde, dus we kunnen veranderen hoe het besturingssysteem het subnet het adres en de netwerknaam herkent door meer argumenten toe te voegen tijdens het maken.

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

$ ip route show

Met deze Linux-opdracht kunnen we bijna hetzelfde zien als de andere opdracht eerder, maar in plaats van de "veth" -interfaces voor elk netwerk op te sommen, hebben we gewoon deze "linkdown" die degenen weergeeft die leeg zijn.

Het gewenste subnetadres is opgegeven als een argument, en vergelijkbaar met de optie Omgeving voor het maken van de container, voor netwerk hebben we de "-o" gevolgd door het paar sleutel en waarde. In dit geval vertellen we Docker, om het besturingssysteem te vertellen, dat hij het netwerk als "bridge-host" moet noemen.

Het bestaan ​​van die drie netwerken kan ook worden geverifieerd in Docker, voer gewoon in:

$ docker network ls

Nu hebben we eerder besproken dat de waarden van deze "veth" voor de containers er niet toe doen, en ik zal het je in de praktijk laten zien.

De oefening bestaat uit het verifiëren van de huidige waarde, vervolgens de container opnieuw opstarten en opnieuw verifiëren. Om dit te doen, hebben we een mix van Linux-commando's nodig die eerder werden gebruikt, en Docker-commando's, die hier nieuw zijn, maar heel eenvoudig:

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

Wanneer de container wordt gestopt, moet het IP-adres worden vrijgemaakt om indien nodig een nieuw te ontvangen, en dat is een herinnering aan hoe DNS belangrijk kan zijn.

Het besturingssysteem geeft deze namen voor de interfaces elke keer dat een container in een IP-adres staat, en ze worden gegenereerd met behulp van het pakket iptables, dat binnenkort zal worden vervangen door het nieuwe framework genaamd nftables.

Het wordt niet aanbevolen om deze regels te wijzigen, maar er zijn hulpmiddelen beschikbaar om, indien nodig, te helpen met hun visualisatie, zoals dockerveth.

Beleid voor herstarten van containers

Wanneer we het Docker-programma of zelfs de computer opnieuw opstarten, worden de door hem gemaakte netwerken in het besturingssysteem bewaard, maar leeg.

Containers hebben een zogenaamd Container Restart-beleid, en dit is een ander zeer belangrijk argument dat tijdens het maken is opgegeven. PostgreSQL, als productiedatabase, is zijn beschikbaarheid cruciaal, en dit is hoe Docker daarbij kan helpen.

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

Tenzij u het handmatig stopt, is deze container "postgres-2" altijd beschikbaar.

Om het beter te begrijpen, worden de lopende containers weergegeven en wordt het Docker-programma opnieuw gestart, en vervolgens de eerste stap opnieuw:

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

Alleen de container “postgres-2” draait, de andere “postgres-1” container start niet alleen. Meer informatie hierover is te vinden in de Docker-documentatie.

Domeinnaamsysteem (DNS)

Een voordeel van het User-Defined Bridge Network is de organisatie, zeker omdat we er zoveel kunnen maken als we willen om nieuwe containers te draaien en zelfs oude aan te sluiten, maar een ander voordeel dat we niet hebben bij het gebruik van de Docker-standaardbridge, is DNS.

Wanneer containers met elkaar moeten communiceren, kan het lastig zijn voor de DBA om de IP-adressen te onthouden, en we hebben dit eerder besproken met het voorbeeld van www.google.com en 172.217.165.4. DNS lost dit probleem naadloos op door interactie met containers mogelijk te maken met hun namen die bij het maken door ons zijn opgegeven, zoals "postgres-2", in plaats van het IP-adres "172.23.0.2".

Laten we eens kijken hoe het werkt. We zullen een andere container maken alleen voor demonstratiedoeleinden in hetzelfde netwerk genaamd "postgres-3", dan zullen we het pakket iputils-ping installeren om pakketten met gegevens naar de container "postgres-2" te verzenden, waarbij we natuurlijk de naam ervan gebruiken .

$ 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

Laten we het voor een beter begrip in delen scheiden. In de volgende uitvoer geeft de blauwe pijl aan wanneer de opdracht wordt uitgevoerd in een container en in rood in het besturingssysteem.

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

$ ping postgres-2

Samenvatting

PostgreSQL draait in Docker en zijn beschikbaarheid is nu gegarandeerd. Bij gebruik binnen een door de gebruiker gedefinieerd brugnetwerk kunnen de containers gemakkelijker worden beheerd met veel voordelen, zoals DNS, aangepaste subnetadressen en OS-namen voor de netwerken.

We hebben details gezien over Docker en hoe belangrijk het is om op de hoogte te zijn van bijgewerkte pakketten en frameworks op het besturingssysteem.