Come monitorare PostgreSQL in esecuzione all'interno di un contenitore Docker:prima parte

Il monitoraggio è l'azione di guardare e controllare per un periodo di tempo per vedere come si sviluppa e si comporta ciò che stai monitorando. Lo fai in modo da poter apportare tutte le modifiche necessarie per assicurarti che le cose funzionino correttamente. È essenziale che i processi siano monitorati per produrre buone informazioni sulle attività che vengono eseguite al fine di pianificare, organizzare ed eseguire una soluzione efficiente.

Docker è un programma creato per operare come builder pronto a rispondere alla domanda "Il software verrà eseguito sulla mia macchina?" Fondamentalmente assembla diverse parti insieme creando un modello facile da riporre e trasportare. Il modello, noto anche come container, può essere spedito a qualsiasi computer su cui sia installato Docker.

In questo articolo verremo introdotti a Docker, descrivendo alcune modalità di configurazione e confrontandole. Inoltre, PostgreSQL entra in gioco e lo implementeremo all'interno di un container Docker in modo intelligente e, infine, vedremo i vantaggi che ClusterControl può fornire, per monitorare le metriche chiave su PostgreSQL e il sistema operativo al di fuori di esso.

Panoramica Docker

Quando Docker si avvia, crea una nuova connessione di rete per consentire la trasmissione di dati tra due endpoint, chiamata bridge, ed è qui che vengono mantenuti i nuovi container per impostazione predefinita.

Di seguito, vedremo i dettagli su questo bridge e discuteremo del motivo per cui non è una buona idea utilizzarlo in produzione.

$ docker network inspect bridge

Nota le opzioni incorporate, perché se esegui un container senza specificare la rete desiderata, sarai d'accordo con esso.

Su questa connessione di rete predefinita, perdiamo alcuni buoni vantaggi della rete, come il DNS. Immagina di voler accedere a Google, quale indirizzo preferisci, www.google.com o 172.217.165.4?

Non so voi, ma io preferisco la scelta anticipata e, a dire il vero, non scrivo "www.".

Rete bridge definita dall'utente

Quindi vogliamo il DNS nella nostra connessione di rete e il vantaggio dell'isolamento, perché immagina lo scenario in cui distribuisci contenitori diversi all'interno della stessa rete.

Quando creiamo un contenitore Docker, possiamo dargli un nome, oppure Docker lo fa per noi randomizzando due parole collegate da sottolineatura, o '_'.

Se non utilizziamo una rete bridge definita dall'utente, in futuro potrebbe esserci un problema nel mezzo degli indirizzi IP, perché chiaramente non siamo macchine e ricordiamo che questi valori possono essere difficili e soggetti a errori.

Creare un bridge personalizzato, o una rete di bridge definita dall'utente, è molto semplice.

Prima di creare il nostro primo, per capire meglio il processo, apriamo un nuovo terminale, digitiamo un comando Linux del pacchetto iproute2 e ormai lasciamo perdere.

$ ip monitor all

Questo terminale ora ascolterà l'attività di rete e la visualizzerà.

Potresti aver già visto comandi come "ifconfig" o "netstat" e ti dico che sono deprecati dal 2001. Il pacchetto net-tools è ancora ampiamente utilizzato, ma non più aggiornato.

Ora è il momento di creare la nostra prima rete personalizzata, quindi apri un altro terminale e inserisci:

$ docker network create --driver bridge br-db

Questo lunghissimo mix di lettere e numeri è chiamato UUID o Universally Unique IDentifier. In pratica sta dicendo che la rete è stata creata con successo.

Il nome dato per la nostra prima rete creata manualmente è stato "br-db" e deve essere nella parte finale del comando, ma prima abbiamo l'argomento "-driver" e quindi il valore "bridge" , perché?

Nella Community Edition, Docker fornisce tre diversi driver disponibili:bridge, host e nessuno. Al momento della creazione, in questo modo, l'impostazione predefinita è bridge e non è necessario specificarlo, ma lo stiamo imparando.

Se hai fatto tutto con me, guarda l'altro terminale perché ti spiegherò cosa ti sta succedendo.

Docker ha creato la rete, chiamata “br-db”, ma questa è chiamata così solo da lui.

Sull'altro lato di questo bridge personalizzato creato, c'è un altro livello, il sistema operativo. Il nome dato per la stessa rete di bridge è cambiato e diventa una rappresentazione della nomenclatura del bridge, "br", seguito dai primi 12 caratteri del valore UUID sopra, in rosso.

Con la nostra nuova connessione di rete, abbiamo una sottorete, un gateway e una trasmissione.

Il Gateway, come suggerisce il nome, è il luogo in cui tutto il traffico dei pacchetti avviene tra gli endpoint del bridge e, come puoi vedere, è chiamato "inet" per il sistema operativo.

Broadcast si trova nell'ultimo indirizzo IP ed è responsabile dell'invio dello stesso traffico di dati per tutti gli indirizzi IP nella sottorete quando necessario.

Sono sempre presenti nelle connessioni di rete, per questo abbiamo all'inizio dell'output il valore “[ADDR]”. Questo valore rappresenta le modifiche all'indirizzo IP ed è come un evento che viene attivato per il monitoraggio dell'attività di rete, perché abbiamo creato una nuova connessione di rete!

Contenitore Docker

Visita il Docker Hub e osserva che ciò che è disponibile è noto come Docker Image, ed è fondamentalmente lo scheletro del contenitore (modello).

Le Docker Images sono generate da Dockerfiles e contengono tutte le informazioni necessarie per creare un container, al fine di semplificarne la manutenzione e la personalizzazione.

Se guardi con attenzione nel Docker Hub, è facile vedere che l'immagine PostgreSQL, chiamata postgres, ha tag e versioni diversi, e se non ne specifichi uno verrà utilizzato il valore predefinito, l'ultimo, ma forse in il futuro se hai bisogno di diversi contenitori di PostgreSQL che lavorino insieme, potresti volere che siano nella stessa versione.

Creiamo ora il nostro primo contenitore giusto, ricordando la necessità dell'argomento '--network', altrimenti verrà distribuito nel bridge predefinito.

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

Di nuovo l'UUID, successo, e nell'altro terminale, cosa sta succedendo?

Le modifiche all'interfaccia di rete sono l'evento che sta accadendo in questo momento, o semplicemente "[LINK]". Qualsiasi cosa dopo il "veth" puoi dimenticare, fidati, il valore cambia sempre quando il contenitore viene riavviato o succede qualcosa di simile.

L'altra opzione "-e POSTGRES_PASSWORD=?" sta per Environment, ed è disponibile solo quando si eseguono container PostgreSQL, sta configurando la password per l'account super utente nel database, chiamato postgres.

Publish è il nome lungo del parametro "-p 6551:5432" e fondamentalmente rende la porta 6551 del sistema operativo associata bidirezionale alla porta 5432 del contenitore.

Ultima, ma non meno importante, è l'opzione Stacca, "-d", e ciò che fa è rendere il contenitore indipendente da questo terminale.

Il nome dell'immagine Docker deve essere alla fine, seguendo lo stesso schema della creazione della rete, con tutti gli argomenti e le opzioni a sinistra, e alla fine la cosa più importante, in questo caso, il nome dell'immagine.

Ricorda che i container sono conservati nella sottorete di rete, in piedi su indirizzi IP consentiti per ciascuno di essi, e non saranno mai nel primo o nell'ultimo indirizzo, perché il Gateway e il Broadcast saranno sempre lì.

Abbiamo mostrato i dettagli del ponte creato e ora verranno visualizzati da ciascuno degli endpoint questi dettagli da loro conservati.

$ docker network inspect br-db

$ brctl show

Come puoi vedere, i nomi di rete e container differiscono, poiché il secondo è riconosciuto come interfaccia dal sistema operativo, chiamato "veth768ff71", e il nome originale da noi dato "postgres-1" per Docker.

Nel comando Docker è possibile annotare l'indirizzo IP del container creato in precedenza, la sottorete corrispondente a quanto apparso nell'altro terminale aperto pochi istanti fa, e infine le opzioni vuote per questa rete personalizzata.

Il comando Linux "brctl show" fa parte del pacchetto bridge-utils e, come suggerisce il nome, il suo scopo è fornire una serie di strumenti per configurare e gestire i bridge Ethernet Linux.

Un'altra rete bridge personalizzata

Discuteremo presto del DNS, ma è stato molto positivo semplificarci le cose in futuro. Le grandi configurazioni tendono a semplificare la vita del DBA in futuro.

Con le reti è lo stesso, quindi possiamo cambiare il modo in cui il sistema operativo riconosce la sottorete l'indirizzo e il nome della rete aggiungendo più argomenti al momento della creazione.

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

$ ip route show

Con questo comando Linux, possiamo vedere quasi la stessa cosa dell'altro comando precedente, ma ora invece di elencare le interfacce "veth" per ciascuna rete, abbiamo semplicemente questo "linkdown" che mostra quelle vuote.

L'indirizzo di sottorete desiderato è stato specificato come argomento e, analogamente all'opzione Ambiente per la creazione del contenitore, per la rete abbiamo "-o" seguito dalla coppia di chiave e valore. In questo caso, stiamo dicendo a Docker, di dire al sistema operativo, che dovrebbe chiamare la rete come "host bridge".

L'esistenza di queste tre reti può essere verificata anche in Docker, basta inserire:

$ docker network ls

Ora abbiamo discusso in precedenza che i valori di questi "veth" per i contenitori non contano e te lo mostrerò in pratica.

L'esercizio consiste nel verificare il valore corrente, quindi riavviare il contenitore, quindi verificare nuovamente. Per farlo avremo bisogno di un mix di comandi Linux usati in precedenza e di quelli Docker, che qui sono nuovi ma molto semplici:

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

Quando il container viene arrestato, l'indirizzo IP deve essere libero per riceverne uno nuovo, se necessario, e questo è un promemoria di quanto il DNS può essere importante.

Il sistema operativo fornisce questi nomi per le interfacce ogni volta che un container si trova in un indirizzo IP e vengono generati utilizzando il pacchetto iptables, che sarà presto sostituito dal nuovo framework chiamato nftables.

Non è consigliabile modificare queste regole, ma esistono strumenti disponibili per aiutare con la loro visualizzazione, se necessario, come dockerveth.

Normativa sul riavvio del contenitore

Quando riavviamo il programma Docker, o anche il computer, le reti da lui create vengono mantenute nel sistema operativo, ma vuote.

I contenitori hanno ciò che viene chiamato Criterio di riavvio del contenitore e questo è un altro argomento molto importante specificato al momento della creazione. PostgreSQL, in quanto database di produzione, la sua disponibilità è fondamentale ed è così che Docker può aiutarti.

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

A meno che non lo fermi manualmente, questo contenitore "postgres-2" sarà sempre disponibile.

Per capirlo meglio, verranno visualizzati i container in esecuzione e il programma Docker riavviato, quindi il primo passaggio ancora:

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

Solo il container "postgres-2" è in esecuzione, l'altro container "postgres-1" non si avvia da solo. Maggiori informazioni a riguardo possono essere visualizzate nella documentazione Docker.

Sistema dei nomi di dominio (DNS)

Un vantaggio della rete di bridge definita dall'utente è sicuramente l'organizzazione, perché possiamo crearne quanti ne vogliamo per eseguire nuovi container e persino connettere quelli vecchi, ma un altro vantaggio che non abbiamo utilizzando il bridge predefinito Docker è DNS.

Quando i container devono comunicare tra loro può essere doloroso per il DBA memorizzare gli indirizzi IP e ne abbiamo discusso in precedenza mostrando l'esempio di www.google.com e 172.217.165.4. Il DNS risolve questo problema senza problemi, rendendo possibile l'interazione con i container utilizzando i nomi forniti da noi in fase di creazione, come "postgres-2", invece dell'indirizzo IP "172.23.0.2".

Vediamo come funziona. Creeremo un altro container solo a scopo dimostrativo nella stessa rete chiamato “postgres-3”, quindi installeremo il pacchetto iputils-ping per trasmettere pacchetti di dati al container “postgres-2”, usando ovviamente il suo nome .

$ 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

Per una migliore comprensione separiamolo in parti, nei seguenti output, la freccia blu indicherà quando il comando viene eseguito all'interno di un container, e in rosso, nel sistema operativo.

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

$ ping postgres-2

Riepilogo

PostgreSQL è in esecuzione all'interno di Docker e la sua disponibilità è ormai garantita. Se utilizzati all'interno di una rete bridge definita dall'utente, i container possono essere gestiti più facilmente con molti vantaggi come DNS, indirizzi di sottorete personalizzati e nomi di sistemi operativi per le reti.

Abbiamo visto dettagli su Docker e l'importanza di essere a conoscenza di pacchetti e framework aggiornati sul sistema operativo.