Comment surveiller l'exécution de PostgreSQL dans un conteneur Docker :première partie

La surveillance est l'action d'observer et de vérifier sur une période de temps afin de voir comment ce que vous surveillez se développe et fonctionne. Vous le faites afin de pouvoir apporter les modifications nécessaires pour vous assurer que tout fonctionne correctement. Il est essentiel que les processus soient surveillés pour produire de bonnes informations sur les activités en cours d'exécution afin de planifier, d'organiser et d'exécuter une solution efficace.

Docker est un programme créé pour fonctionner comme un constructeur prêt à répondre à la question « Le logiciel fonctionnera-t-il sur ma machine ? » Il assemble essentiellement différentes pièces pour créer un modèle facile à stocker et à transporter. Le modèle, également appelé conteneur, peut être envoyé à n'importe quel ordinateur sur lequel Docker est installé.

Dans cet article, nous allons découvrir Docker, décrire quelques modes de configuration et les comparer. De plus, PostgreSQL entre en jeu, et nous le déploierons dans un conteneur Docker de manière intelligente, et enfin, nous verrons les avantages que ClusterControl peut fournir, pour surveiller les métriques clés sur PostgreSQL et le système d'exploitation en dehors de celui-ci.

Présentation de Docker

Lorsque Docker démarre, il crée une nouvelle connexion réseau pour permettre la transmission de données entre deux points de terminaison, appelée pont, et c'est là que les nouveaux conteneurs sont conservés par défaut.

Dans ce qui suit, nous verrons des détails sur ce pont et expliquerons pourquoi ce n'est pas une bonne idée de l'utiliser en production.

$ docker network inspect bridge

Veuillez noter les options intégrées, car si vous exécutez un conteneur sans spécifier le réseau souhaité, vous serez d'accord avec lui.

Sur cette connexion réseau par défaut, nous perdons certains bons avantages de la mise en réseau, comme le DNS. Imaginez que vous souhaitiez accéder à Google, quelle adresse préférez-vous, www.google.com ou 172.217.165.4 ?

Je ne sais pas pour vous mais je préfère le premier choix, et pour être honnête, je ne tape pas le "www".

Réseau de pont défini par l'utilisateur

Nous voulons donc le DNS dans notre connexion réseau, et l'avantage de l'isolement, car imaginez le scénario dans lequel vous déployez différents conteneurs à l'intérieur du même réseau.

Lorsque nous créons un conteneur Docker, nous pouvons lui donner un nom, ou Docker le fait pour nous en randomisant deux mots reliés par un soulignement, ou '_'.

Si nous n'utilisons pas un réseau de pont défini par l'utilisateur, à l'avenir, il pourrait y avoir un problème au milieu des adresses IP, car nous ne sommes clairement pas des machines, et rappelez-vous que ces valeurs peuvent être difficiles et sujettes aux erreurs.

La création d'un pont personnalisé ou d'un réseau de pont défini par l'utilisateur est très simple.

Avant de créer notre premier, pour mieux comprendre le processus, ouvrons un nouveau terminal, tapons une commande Linux du package iproute2, et oublions-le maintenant.

$ ip monitor all

Ce terminal va maintenant écouter l'activité du réseau et s'y afficher.

Vous avez peut-être déjà vu des commandes comme "ifconfig" ou "netstat", et je vous dis qu'elles sont obsolètes depuis 2001. Le paquet net-tools est encore largement utilisé, mais n'est plus mis à jour.

Il est maintenant temps de créer notre premier réseau personnalisé, alors ouvrez un autre terminal et entrez :

$ docker network create --driver bridge br-db

Ce très long mélange de lettres et de chiffres est appelé UUID, ou Universally Unique IDentifier. Cela signifie essentiellement que le réseau a été créé avec succès.

Le nom donné pour notre premier réseau créé manuellement a été "br-db", et il doit être dans la finale de la commande, mais avant cela, nous avons l'argument '"-driver", puis la valeur "bridge" , pourquoi ?

Dans l'édition communautaire, Docker propose trois pilotes différents :pont, hôte et aucun. Au moment de la création, comme celui-ci, la valeur par défaut est bridge et il n'est pas nécessaire de le spécifier, mais nous apprenons à le connaître.

Si vous avez tout fait avec moi, regardez l'autre terminal car je vais vous expliquer ce qui se passe.

Docker a créé le réseau, appelé "br-db", mais celui-ci n'est appelé ainsi que par lui.

De l'autre côté de ce pont personnalisé créé, il y a une autre couche, le système d'exploitation. Le nom donné pour le même réseau de ponts a changé et devient une représentation de la nomenclature du pont, "br", suivi des 12 premiers caractères de la valeur UUID ci-dessus, en rouge.

Avec notre nouvelle connexion réseau, nous avons un sous-réseau, une passerelle et une diffusion.

La passerelle, comme son nom l'indique, est l'endroit où tout le trafic de paquets se produit entre les points de terminaison du pont, et elle s'appelle "inet" pour le système d'exploitation, comme vous pouvez le voir.

La diffusion se trouve dans la dernière adresse IP et est responsable de l'envoi du même trafic de données pour toutes les adresses IP du sous-réseau si nécessaire.

Ils sont toujours présents dans les connexions réseau, et c'est pourquoi nous avons au début de la sortie, la valeur "[ADDR]". Cette valeur représente les changements d'adresse IP, et c'est comme si un événement était déclenché pour la surveillance de l'activité du réseau, car nous avons créé une nouvelle connexion réseau !

Conteneur Docker

Veuillez visiter le Docker Hub et voir que ce qui s'y trouve est connu sous le nom d'image Docker et qu'il s'agit essentiellement du squelette du conteneur (modèle).

Les images Docker sont générées par Dockerfiles et contiennent toutes les informations nécessaires à la création d'un conteneur, afin de faciliter sa maintenance et sa personnalisation.

Si vous regardez attentivement le Docker Hub, il est facile de voir que l'image PostgreSQL, appelée postgres, a des balises et des versions différentes, et si vous n'en spécifiez pas une, la valeur par défaut sera utilisée, la plus récente, mais peut-être dans à l'avenir, si vous avez besoin que différents conteneurs de PostgreSQL fonctionnent ensemble, vous souhaiterez peut-être qu'ils soient dans la même version.

Créons maintenant notre premier conteneur de droite, souvenez-vous de la nécessité de l'argument "--network", sinon il sera déployé dans le pont par défaut.

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

Encore l'UUID, succès, et dans l'autre terminal, que se passe-t-il ?

Les changements d'interface réseau sont l'événement qui se produit en ce moment, ou simplement "[LIEN]". Tout ce que vous pouvez oublier après le "veth", croyez-moi, la valeur change toujours lorsque le conteneur est redémarré ou que quelque chose de similaire se produit.

L'autre option "-e POSTGRES_PASSWORD=?" signifie Environnement, et il n'est disponible que lors de l'exécution de conteneurs PostgreSQL, il configure le mot de passe du compte super utilisateur dans la base de données, appelé postgres.

Publish est le nom long du paramètre "-p 6551:5432", et il rend essentiellement le port 6551 du système d'exploitation lié de manière bidirectionnelle au port 5432 du conteneur.

Enfin, mais non des moindres, l'option Détacher, "-d", et ce qu'elle fait, c'est que le conteneur s'exécute indépendamment de ce terminal.

Le nom de l'image Docker doit être à la fin, suivant le même modèle de création de réseau, ayant tous les arguments et options à gauche, et à la fin la chose la plus importante, dans ce cas, le nom de l'image.

N'oubliez pas que les conteneurs sont détenus dans le sous-réseau du réseau, sur les adresses IP autorisées pour chacun d'eux, et qu'ils ne figureront jamais dans la première ou la dernière adresse, car la passerelle et la diffusion seront toujours là.

Nous avons montré les détails du pont créé, et maintenant seront affichés par chacun des terminaux ces détails conservés par eux.

$ docker network inspect br-db

$ brctl show

Comme vous pouvez le voir, les noms de réseau et de conteneur diffèrent, le second étant reconnu comme une interface par le système d'exploitation, appelé "veth768ff71", et le nom d'origine donné par nous "postgres-1" pour Docker.

Dans la commande Docker, il est possible de noter l'adresse IP du conteneur créé précédemment, le sous-réseau correspondant à ce qui est apparu dans l'autre terminal ouvert il y a quelques instants, et enfin les options vides pour ce réseau personnalisé.

La commande Linux "brctl show" fait partie du package bridge-utils, et comme son nom l'indique, son but est de fournir un ensemble d'outils pour configurer et gérer les ponts Ethernet Linux.

Un autre réseau de pont personnalisé

Nous discuterons bientôt du DNS, mais cela a été très bien de nous simplifier les choses à l'avenir. Les bonnes configurations ont tendance à faciliter la vie du DBA à l'avenir.

Avec les réseaux, c'est la même chose, nous pouvons donc changer la façon dont le système d'exploitation reconnaît l'adresse du sous-réseau et le nom du réseau en ajoutant plus d'arguments au moment de la création.

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

$ ip route show

Avec cette commande Linux, nous pouvons voir presque la même chose que l'autre commande précédente, mais maintenant au lieu de lister les interfaces "veth" pour chaque réseau, nous avons simplement ce "linkdown" affichant ceux qui sont vides.

L'adresse de sous-réseau souhaitée a été spécifiée en tant qu'argument, et similaire à l'option Environnement pour la création du conteneur, pour le réseau, nous avons le "-o" suivi de la paire de clé et de valeur. Dans ce cas, nous disons à Docker, pour indiquer au système d'exploitation, qu'il doit appeler le réseau en tant que "bridge-host".

L'existence de ces trois réseaux peut également être vérifiée dans Docker, il suffit d'entrer :

$ docker network ls

Maintenant, nous avons discuté plus tôt que les valeurs de ces "veth" pour les conteneurs n'ont pas d'importance, et je vais vous montrer dans la pratique.

L'exercice consiste à vérifier la valeur actuelle, puis à redémarrer le conteneur, puis à vérifier à nouveau. Pour ce faire, nous aurons besoin d'un mélange de commandes Linux utilisées auparavant et de commandes Docker, qui sont nouvelles ici mais très simples :

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

Lorsque le conteneur est arrêté, l'adresse IP doit être libérée pour en recevoir une nouvelle si nécessaire, et cela rappelle à quel point le DNS peut être important.

Le système d'exploitation donne ces noms aux interfaces chaque fois qu'un conteneur se trouve dans une adresse IP, et ils sont générés à l'aide du package iptables, qui sera bientôt remplacé par le nouveau framework appelé nftables.

Il n'est pas recommandé de modifier ces règles, mais il existe des outils disponibles pour aider à leur visualisation, si nécessaire, comme dockerveth.

Politique de redémarrage du conteneur

Lorsque nous redémarrons le programme Docker, ou même l'ordinateur, les réseaux créés par lui sont conservés dans le système d'exploitation, mais vides.

Les conteneurs ont ce qu'on appelle la politique de redémarrage des conteneurs, et c'est un autre argument très important spécifié au moment de la création. PostgreSQL, en tant que base de données de production, sa disponibilité est cruciale, et c'est ainsi que Docker peut y contribuer.

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

À moins que vous ne l'arrêtiez manuellement, ce conteneur "postgres-2" sera toujours disponible.

Pour mieux comprendre, les conteneurs en cours d'exécution seront affichés et le programme Docker redémarré, puis la première étape à nouveau :

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

Seul le conteneur "postgres-2" est en cours d'exécution, l'autre conteneur "postgres-1" ne démarre pas seul. Plus d'informations à ce sujet peuvent être consultées dans la documentation Docker.

Système de nom de domaine (DNS)

L'un des avantages du réseau de pont défini par l'utilisateur est l'organisation, certainement, car nous pouvons en créer autant que nous le voulons pour exécuter de nouveaux conteneurs et même connecter les anciens, mais un autre avantage que nous n'avons pas en utilisant le pont par défaut de Docker, est DNS.

Lorsque les conteneurs doivent communiquer entre eux, il peut être difficile pour le DBA de mémoriser les adresses IP, et nous en avons discuté précédemment en montrant l'exemple de www.google.com et 172.217.165.4. DNS résout ce problème de manière transparente, permettant d'interagir avec les conteneurs en utilisant leurs noms donnés au moment de la création par nous, comme "postgres-2", au lieu de l'adresse IP "172.23.0.2".

Voyons voir comment ça fonctionne. Nous allons créer un autre conteneur juste à des fins de démonstration dans le même réseau appelé "postgres-3", puis, nous installerons le package iputils-ping pour transmettre des paquets de données au conteneur "postgres-2", en utilisant son nom bien sûr .

$ 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

Pour une meilleure compréhension, séparons-le en parties, dans les sorties suivantes, la flèche bleue indiquera quand la commande est exécutée à l'intérieur d'un conteneur, et en rouge, dans le système d'exploitation.

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

$ ping postgres-2

Résumé

PostgreSQL s'exécute dans Docker et sa disponibilité est désormais garantie. Lorsqu'ils sont utilisés à l'intérieur d'un réseau pont défini par l'utilisateur, les conteneurs peuvent être gérés plus facilement avec de nombreux avantages tels que le DNS, les adresses de sous-réseau personnalisées et les noms de système d'exploitation pour les réseaux.

Nous avons vu des détails sur Docker et l'importance d'être au courant des packages et des frameworks mis à jour sur le système d'exploitation.