sql >> Databasteknik >  >> RDS >> PostgreSQL

Hur man övervakar PostgreSQL som körs inuti en Docker-behållare:Del ett

Övervakning är handlingen att titta och kontrollera under en tidsperiod för att se hur det du övervakar utvecklas och presterar. Du gör det så att du kan göra nödvändiga ändringar för att säkerställa att saker fungerar korrekt. Det är viktigt att processer övervakas för att ge goda insikter om de aktiviteter som utförs för att kunna planera, organisera och driva en effektiv lösning.

Docker är ett program skapat för att fungera som en byggare redo att svara på frågan "Kommer programvaran att köras på min maskin?" Den sätter i princip ihop olika delar och skapar en modell som är lätt att lagra och transportera. Modellen, även känd som container, kan skickas till vilken dator som helst som har Docker installerat.

I den här artikeln kommer vi att introduceras till Docker, där vi beskriver några sätt att konfigurera och jämföra dem. Dessutom kommer PostgreSQL att spela, och vi kommer att distribuera det i en Docker-behållare på ett smart sätt, och slutligen kommer vi att se fördelarna som ClusterControl kan ge, för att övervaka nyckelmått om PostgreSQL och operativsystemet utanför det.

Dockeröversikt

När Docker startar skapar den en ny nätverksanslutning för att möjliggöra överföring av data mellan två slutpunkter, kallad brygga, och det är här som nya behållare hålls som standard.

I det följande kommer vi att se detaljer om den här bron och diskutera varför den inte är en bra idé att använda i produktionen.

$ docker network inspect bridge
Inspektera Docker-standardbryggan docker0.

Observera de inbäddade alternativen, för om du kör en behållare utan att ange önskat nätverk kommer du att acceptera det.

På denna standardnätverksanslutning förlorar vi några bra fördelar med nätverk, som DNS. Föreställ dig att du vill komma åt Google, vilken adress föredrar du, www.google.com eller 172.217.165.4?

Jag vet inte om dig men jag föredrar det tidigare valet, och för att vara ärlig skriver jag inte "www.".

Användardefinierat bryggnätverk

Så vi vill ha DNS i vår nätverksanslutning, och fördelen med isolering, för föreställ dig scenariot där du distribuerar olika behållare inuti samma nätverk.

När vi skapar en Docker-behållare kan vi ge den ett namn, eller så gör Docker det åt oss att randomisera två ord som är sammankopplade med understrykning, eller "_".

Om vi ​​inte använder ett användardefinierat bryggnätverk kan det i framtiden bli ett problem i mitten av IP-adresserna, eftersom vi uppenbarligen inte är maskiner, och kom ihåg att dessa värden kan vara svåra och felbenägna.

Att skapa en anpassad brygga, eller ett användardefinierat bryggnätverk, är mycket enkelt.

Innan vi skapar vår första, för att förstå processen bättre, låt oss öppna en ny terminal, skriva ett Linux-kommando för paketet iproute2 och glömma det vid det här laget.

$ ip monitor all
Initiering av en terminal för att övervaka nätverkstrafiken i Docker Host.

Den här terminalen kommer nu att lyssna på nätverksaktiviteten och visas där.

Du kanske har sett kommandon som "ifconfig" eller "netstat" tidigare, och jag säger att de är utfasade sedan 2001. Paketet net-tools används fortfarande i stor utsträckning, men uppdateras inte längre.

Nu är det dags att skapa vårt första anpassade nätverk, så öppna en annan terminal och ange:

$ docker network create --driver bridge br-db
Skapa det användardefinierade bryggnätverket "br-db".

Denna mycket långa blandning av bokstäver och siffror kallas UUID, eller Universally Unique IDentifier. Det är i princip att säga att nätverket har skapats framgångsrikt.

Det givna namnet för vårt första nätverk som skapades manuellt har varit "br-db", och det måste vara i den sista delen av kommandot, men innan dess har vi argumentet "-driver" och sedan värdet "bridge" , varför?

I Community Edition tillhandahåller Docker tre olika drivrutiner tillgängliga:brygga, värd och ingen. Vid skapandet, som den här, är standarden bridge och det behöver inte specificeras, men vi lär oss om det.

Om du har gjort allt med mig, titta på den andra terminalen för jag kommer att förklara vad som händer för dig.

Docker har skapat nätverket, kallat "br-db", men detta kallas bara så här av honom.

På andra sidan av den här anpassade bryggan som skapas finns det ett annat lager, OS. Det angivna namnet för samma bronätverk har ändrats och blir en representation av nomenklaturen för bro, "br", följt av de första 12 tecknen i UUID-värdet ovan, i rött.

Övervaka ändringar av Docker-IP-adresser.

Med vår nya nätverksanslutning har vi ett subnät, gateway och broadcast.

Gatewayen, som namnet antyder, är där all trafik av paket sker mellan bryggans slutpunkter, och det kallas "inet" för operativsystemet som du kan se.

Broadcast står i den sista IP-adressen och ansvarar för att skicka samma trafik av data för alla IP-adresser i subnätet vid behov.

De finns alltid i nätverksanslutningar, och det är därför vi har i början av utgången värdet "[ADDR]". Detta värde representerar IP-adressändringar, och det är som en händelse som utlöses för nätverksaktivitetsövervakningen, eftersom vi har skapat en ny nätverksanslutning!

Docker Container

Vänligen besök Docker Hub och se att det som finns där kallas Docker Image, och det är i grunden skelettet av behållaren (modellen).

Docker-bilder genereras av Dockerfiles och de innehåller all information som behövs för att skapa en behållare, för att göra den enkel att underhålla och anpassa.

Om du tittar med uppmärksamhet in i Docker Hub är det lätt att se att PostgreSQL-bilden, kallad postgres, har olika taggar och versioner, och om du inte anger en av dem kommer standarden att användas, den senaste, men kanske i framtiden om du behöver olika behållare för PostgreSQL som arbetar tillsammans, kanske du vill att de ska vara i samma version.

Låt oss skapa vår första rätta behållare nu, kom ihåg behovet av argumentet "--nätverk", annars kommer det att distribueras i standardbryggan.

$ docker container run --name postgres-1 --network br-db -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6551:5432 -d postgres
Köra en PostgreSQL-behållare i nätverket "br-db".

Återigen UUID, framgång, och i den andra terminalen, vad händer?

Nätverksgränssnittsändringar är händelsen som händer just nu, eller helt enkelt "[LINK]". Allt efter "veth" du kan glömma, tro mig, värdet ändras alltid när behållaren startas om eller något liknande händer.

Övervaka ändringar i Docker-nätverkets gränssnitt.

Det andra alternativet "-e POSTGRES_PASSWORD=?" står för Environment, och det är endast tillgängligt när man kör PostgreSQL-behållare, det konfigurerar lösenordet för superanvändarkontot i databasen, kallat postgres.

Publicera är det långa namnet för parametern "-p 6551:5432", och det gör i princip att OS-port 6551 är dubbelriktad bunden till port 5432 på containern.

Sist men inte mindre viktigt är alternativet Lossa, "-d", och vad det gör är att få behållaren att köras oberoende av denna terminal.

Docker Image-namnet måste vara i slutet, följa samma mönster som nätverksskapandet, ha alla argument och alternativ till vänster, och i slutet det viktigaste, i det här fallet, bildnamnet.

Kom ihåg att behållarna hålls i nätverkets undernät och står på IP-adresser som är tillåtna för var och en av dem, och de kommer aldrig att finnas i den första eller sista adressen, eftersom Gateway och Broadcast alltid kommer att finnas där.

Vi har visat detaljerna för den skapade bryggan, och kommer nu att visas av var och en av ändpunkterna som dessa detaljer behålls av dem.

$ docker network inspect br-db
Inspektera Docker användardefinierade nätverksgränssnitt "br-db".
$ brctl show
Visar information om det användardefinierade bryggnätverket av Docker-värden.

Som du kan se skiljer sig nätverks- och behållarnamnen, eftersom det andra känns igen som ett gränssnitt av operativsystemet, kallat "veth768ff71", och det ursprungliga namnet som vi gav "postgres-1" för Docker.

I Docker-kommandot är det möjligt att notera IP-adressen för behållaren som skapades tidigare, subnätet som matchade det som dök upp i den andra terminalen öppnade för ett ögonblick sedan, och slutligen är alternativen tomma för detta anpassade nätverk.

Linux-kommandot "brctl show" är en del av paketet bridge-utils, och som namnet antyder är dess syfte att tillhandahålla en uppsättning verktyg för att konfigurera och hantera Linux Ethernet-bryggor.

Ännu ett anpassat bryggnätverk

Vi kommer att diskutera DNS snart, men det har varit väldigt bra för att göra det enkelt för oss i framtiden. Bra konfigurationer tenderar att göra livet för DBA enklare i framtiden.

Med nätverk är det samma, så vi kan ändra hur operativsystemet känner igen subnätadressen och nätverksnamnet genom att lägga till fler argument vid skapandet.

$ docker network create --driver bridge --subnet 172.23.0.0/16 -o “com.docker.network.bridge.name”=”bridge-host” bridge-docker
Skapa ett användardefinierat bryggnätverksgränssnitt med anpassade alternativ.
$ ip route show
Visar Docker-rutttabellen.

Med det här Linux-kommandot kan vi se nästan samma sak som det andra kommandot tidigare, men nu istället för att lista "veth"-gränssnitten för varje nätverk, har vi helt enkelt den här "linkdown" som visar de som är tomma.

Den önskade subnätadressen har angetts som ett argument, och liknande alternativet Environment för att skapa behållare, för nätverk har vi "-o" följt av paret nyckel och värde. I det här fallet säger vi till Docker att tala om för operativsystemet att han ska anropa nätverket som "bryggvärd".

Förekomsten av dessa tre nätverk kan också verifieras i Docker, skriv bara in:

$ docker network ls
Visar nätverksgränssnitt på Docker Engine.

Nu har vi diskuterat tidigare att värdena för dessa "veth" för behållarna inte spelar någon roll, och jag ska visa dig i praktiken.

Övningen består av att verifiera det aktuella värdet, sedan starta om behållaren och sedan verifiera igen. För att göra det behöver vi en blandning av Linux-kommandon som använts tidigare och Docker-kommandon, som är nya här men väldigt enkla:

$ brctl show
$ docker container stop postgres-1
$ docker container start postgres-1
$ brctl show
Kontrollera hur "iptables" gör behållarnamnen flyktiga för Docker-värden.

När behållaren stoppas måste IP-adressen frigöras för att ta emot en ny vid behov, och det är en påminnelse om hur DNS kan vara viktigt.

OS ger dessa namn för gränssnitten varje gång en behållare står i en IP-adress, och de genereras med paketet iptables, som snart kommer att ersättas av det nya ramverket som kallas nftables.

Det rekommenderas inte att ändra dessa regler, men det finns verktyg tillgängliga för att hjälpa till med deras visualisering, om det behövs, som dockerveth.

Behållaromstartspolicy

När vi startar om Docker-programmet, eller till och med datorn, hålls nätverken som skapats av honom i operativsystemet, men tomma.

Behållare har vad som kallas Container Restart Policy, och detta är ett annat mycket viktigt argument som specificeras vid skapandet. PostgreSQL, som produktionsdatabas, är hans tillgänglighet avgörande, och det är så här Docker kan hjälpa till med det.

$ docker container run --name postgres-2 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6552:5432 -d postgres
Ange principen för omstart av behållare vid skapandet.

Såvida du inte stoppar det manuellt kommer denna behållare "postgres-2" alltid att vara tillgänglig.

För att förstå det bättre kommer behållarna som körs att visas och Docker-programmet startas om, sedan det första steget igen:

$ docker container ls
$ systemctl restart docker
$ docker container ls
Kontrollera principen för omstart av behållare i "postgres-2".

Endast behållaren "postgres-2" körs, den andra "postgres-1"-behållaren startar inte ensam. Mer information om det kan ses i Docker-dokumentationen.

Domännamnssystem (DNS)

En fördel med det användardefinierade bryggnätverket är organisationen, förvisso, eftersom vi kan skapa så många som vi vill för att köra nya behållare och till och med ansluta gamla, men en annan fördel som vi inte har med Dockers standardbrygga är DNS.

När behållare behöver kommunicera med varandra kan det vara smärtsamt för DBA att memorera IP-adresserna, och vi har diskuterat det tidigare och visat exemplet www.google.com och 172.217.165.4. DNS löser detta problem sömlöst, vilket gör det möjligt att interagera med behållare med deras namn som gavs vid skapandet av oss, som "postgres-2", istället för IP-adressen "172.23.0.2".

Låt oss se hur det fungerar. Vi kommer att skapa en annan behållare bara för demonstrationsändamål i samma nätverk som heter "postgres-3", sedan installerar vi paketet iputils-ping för att överföra paket med data till behållaren "postgres-2", med hjälp av dess namn förstås .

$ 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

För en bättre förståelse, låt oss dela upp det i delar, i följande utgångar kommer den blå pilen att indikera när kommandot utförs inuti en behållare, och i rött, i operativsystemet.

Kör en temporär behållare för att testa DNS som tillhandahålls av det användardefinierade bryggnätverksgränssnittet.
$ apt-get update && apt-get install -y iputils-ping
Installera paketet "iputils-ping" för att testa DNS.
$ ping postgres-2
Visar att DNS fungerar.

Sammanfattning

PostgreSQL körs inuti Docker, och hans tillgänglighet är garanterad vid det här laget. När de används i ett användardefinierat bryggnätverk kan behållarna hanteras enklare med många fördelar som DNS, anpassade undernätsadresser och OS-namn för nätverken.

Vi har sett detaljer om Docker och vikten av att vara medveten om uppdaterade paket och ramverk på operativsystemet.


  1. Entity Framework wizard kraschar på MySQL

  2. Hur man kör en funktion i Oracle med parametrar

  3. SQL DROP TABLE Syntax – Listad av DBMS

  4. Fixa "datum är inkompatibelt med int" i SQL Server när du lägger till eller drar ifrån ett datum