optimadata.nl-Comment exécuter Postgres sur Docker partie 2.pdf
0 j'aime•16 vues
Cet article de blog décrit comment exécuter PostgreSQL dans un conteneur Docker, en expliquant les commandes Docker essentielles et leur fonctionnement. Il aborde également la création d'images personnalisées avec un Dockerfile et la persistance des données à l'aide de volumes. Enfin, l'article mentionne la gestion des réseaux et l'utilisation de Docker Machine pour contrôler les machines virtuelles exécutant Docker.
optimadata.nl-Comment exécuter Postgres sur Docker partie 2.pdf
- 1. 1/9 26 septembre 2019 Comment exécuter Postgres sur Docker partie 2 optimadata.nl/blogs/3/2qg3p5-how-to-run-postgres-on-docker-part-2 Craig Healey 26-09-2019 11:45 Catégories: Blog, Open Source, PostgreSQL, Review, Technologie Dans mon précédent article de blog, j’ai rapidement expliqué comment configurer postgreSQL dans un conteneur Docker, jusqu’à ce que vous puissiez administrer la base de données avec psql ou pgAdmin. Ce que je n’ai pas fait, c’est expliquer comment tout cela fonctionnait. Si vous essayez quelque chose de même légèrement différent, ou si vous rencontrez des erreurs lors de l’exécution comme je l’ai décrit, alors vous aurez besoin de savoir ce que toutes ces commandes font réellement. Dans cet article de blog, je vais expliquer quelques bases de Docker. Comprendre les bases de Docker Docker est un ensemble de produits qui permettent d’exécuter des logiciels dans des environnements virtualisés, appelés conteneurs. Dans le cas de Docker Toolbox fonctionnant sous Windows, ces conteneurs s’exécutent à l’intérieur d’une VirtualBox, normalement appelée par défaut. Docker crée ceci lors de sa première exécution. La dernière fois, nous avons créé un conteneur appelé some-postgres. Mais où avons-nous obtenu tous les logiciels pour fabriquer le conteneur – le système d’exploitation et PostgreSQL ? Tout cela était contenu dans une image. Nous avons utilisé une image appelée postgres qui a été stockée sur le Docker Hub. Regardons la commande utilisée pour créer le conteneur : La plupart des commandes docker commencent par le mot-clé docker. docker run --help vous donnera une liste de drapeaux possibles. L’exécution de la commande crée un conteneur. Le drapeau - -name lui donne un nom. Les conteneurs sont inhabituels dans Docker, en ce sens que si vous ne spécifiez pas de nom, ils reçoivent un nom par défaut tel que angry_davinci, jolly_wing ou tender_banach. Pour la plupart des autres objets Docker, si vous ne spécifiez pas de nom, vous finissez par devoir utiliser la clé de hachage générée par Docker. Dans ce cas, j’ai utilisé some-postgres, comme suggéré sur la page Postgres Hub. Ports
- 2. 2/9 L’indicateur suivant indique le port du conteneur. Tous les drapeaux ont un nom multi- caractères précédé de 2 tirets (standard POSIX), mais certains d’entre eux ont également un alias à un seul caractère. Donc, j’aurais pu utiliser -p 5432:5432 ou --publish 5432 :5432 . Le premier numéro est le port externe et le second est le port interne. Le port par défaut pour les serveurs PostgreSQL est 5432. Donc, si nous créons plusieurs conteneurs PostgreSQL fonctionnant sur le port par défaut (ce que nous ferons bientôt), nous devons leur donner différents ports externes. Si je voulais créer 3 conteneurs de ce type accessibles depuis pgAdmin en même temps, j’utiliserais les indicateurs de port suivants:-p 5432:5432-p 5433:5432-p 5434: 5432 Sur pgAdmin, je créerais 3 serveurs avec les ports 5432 , 5433 et 5434 . L’indicateur suivant, - e ou - -env , répertorie les variables d’environnement spécifiques à l’image. Dans ce cas, nous voulons définir le mot de passe utilisateur postgres afin que nous puissions nous connecter via pgAdmin. Si une image a besoin de définir de telles variables, elles doivent être répertoriées quelque part, et dans le cas de cette image PostgreSQL, elles sont expliquées en détail à mi-chemin de la page. première page. Le dernier indicateur est -d ou --detach, spécifiant que nous voulons que le conteneur s’exécute en arrière-plan . Si vous oubliez cela, l’exécution de la commande vous mettra directement dans le conteneur et lorsque vous quitterez, le conteneur s’arrêtera. Enfin, le nom de l’image est spécifié, dans ce cas postgres. Vous pouvez taper une liste de commandes que vous souhaitez que le conteneur exécute, immédiatement après le nom de l’image, mais dans ce cas, nous n’avons pas besoin de le faire. Dockerfile L’exécution directe des conteneurs de cette manière ne vous donne pas beaucoup de contrôle, d’autant plus que Docker est censé améliorer l’automatisation plutôt que les compétences en dactylographie. La façon normale d’exécuter Docker est un processus en trois étapes. Tout d’abord, vous créez un fichier texte, appelé Dockerfile, contenant une image de base. L’image de base est la première chose dans le Dockerfile (bien que vous puissiez avoir des commentaires, commençant par #) et est précédée du mot-clé FROM. Il existe une image de base spéciale, appelée scratch, qui ne contient rien du tout. Donc, pour construire votre propre image à partir de zéro, la première ligne de votre Dockerfile sera: FROM scratch Vous pouvez ensuite ajouter ce que vous voulez dans votre image. Mais vous n’avez pas besoin de repartir de zéro. Vous pouvez étendre les images existantes. Vous pouvez créer une image ubuntu avec des outils et des variables spécifiques. À partir de là, vous pouvez créer d’autres images en installant différentes versions de PostgreSQL sur exactement le même système d’exploitation sous-jacent. Cela vous permettrait de tester uniquement les
- 3. 3/9 modifications apportées aux versions de PostgreSQL. À l’aide du Dockerfile, vous créez votre propre image, tout comme celles que vous pouvez extraire du hub Docker. Et en utilisant cette image, vous exécutez un conteneur. Images Alors, construisons une image basée sur l’image postgres que nous avons regardée la dernière fois. Créez un fichier texte appelé Dockerfile. Par défaut, Docker recherche le Dockerfile dans le répertoire de travail actuel (appelé contexte de génération). Vous pouvez, bien sûr, exécuter des commandes Docker à partir d’une invite de commandes ou d’une fenêtre PowerShell, pas seulement le programme Docker Terminal. Et vous pouvez stocker vos Dockerfiles dans n’importe quel répertoire qui vous convient, utilisez simplement l’indicateur -f pour spécifier l’emplacement du fichier. Je vais être paresseux et créer un répertoire de test directement dans le répertoire Docker Toolbox. N’oubliez pas que lorsque vous vous déplacez dans la fenêtre Terminal, vous devez utiliser des commandes Linux. Donc, ls au lieu de dir, et pwd au lieu de echo %cd%. Vous avez également accès à l’éditeur vi si vous le souhaitez. Mon Dockerfile se compose de seulement 2 lignes: FROM postgres ENV POSTGRES_PASSWORD=mysecretpassword Pour créer l’image, tapez docker build -t craig/postgres:version1 . N’oubliez pas le point complet (point) à la fin. Cela indique à Docker d’utiliser le fichier Dockerfile dans le répertoire courant. Vous pouvez voir que la construction est un processus en deux étapes. Tout d’abord, il trouve l’image de base. S’il est déjà téléchargé, comme ici, il passe à l’étape suivante, sinon il le tire du Docker Hub pour vous. Ensuite, il ajoute la ligne de commande suivante, dans ce cas en définissant la variable POSTGRES_PASSWORD. Cela implique un conteneur intermédiaire, qui est automatiquement retiré pour vous. Une fois que la génération a réussi et que l’image reçoit un ID d’image, vous obtenez un avertissement de sécurité. Important si vous envisagez de le faire pour un système réel, mais pour l’instant, vous pouvez l’ignorer en toute sécurité. Si je construis la version2 de mon image sans changer le Dockerfile, Docker est assez intelligent pour savoir que rien n’a besoin d’être changé. Il créera une nouvelle image, appelée craig/postgres:version2, mais l’ID de l’image sera le même que pour craig/postgres:version1. Vous pouvez voir la possibilité de créer plusieurs
- 4. 4/9 niveaux de dépendances ici. Malheureusement, il n’existe pas de méthode facile pour afficher les dépendances à moins de Scripts et outils tiers. La chose la plus proche d’une commande Docker est: docker inspect --format='{{.Id}} {{.Parent}} {{.RepoTags}}' $(docker images --quiet) Cela répertoriera le sha256 d’une image (dont les 12 premiers chiffres sont utilisés comme ID d’image) suivi du parent immédiat de l’image, le cas échéant. Pour plus d’informations sur la commande de mise en forme, reportez-vous à la section Ce blog. Lorsque vient le temps de supprimer des images, vous ne pourrez pas le faire s’il a une image enfant, vous devrez donc peut-être y recourir pour vous débarrasser des images dont vous n’avez plus besoin. Vous pouvez également utiliser : docker history postgres qui répertorie toutes les commandes utilisées pour créer l’image, toutes les images créées en cours de route et la taille de chaque étape individuelle. Pour répertorier toutes les images sur notre machine, utilisez la commande docker image ls: docker image ls
- 5. 5/9 Il y a un certain nombre de choses à examiner ici. Tout d’abord, la convention de nommage. Les images sont souvent stockées dans des registres (Docker a même sa propre image de registre) et vous utilisez des commandes de type git pour extraire et pousser des images vers les registres. La première partie du nom est le nom d’hôte du registre. Si vous avez un compte sur Docker Hub, ce sera votre nom d’hôte de registre lorsque vous pousserez l’image. Certaines images n’ont pas de nom d’hôte de registre, ce sont principalement des images officielles. La partie après la barre oblique est le nom de votre image. Et enfin, la partie tag permet de marquer différentes versions d’une image. Comme je n’ai pas l’intention de pousser ces images dans un registre, je ne fais que suivre la convention de nommage pour garder tout beau et bien rangé. Notez que l’image officielle de postgres est étiquetée avec la dernière version. Si vous ne spécifiez pas de balise lors de la création de l’image, la dernière est ajoutée. Je n’ai pas spécifié de balise pour l’image postgres dans mon Dockerfile, donc il a utilisé la dernière version. Si je veux une version précédente de PostgreSQL, je peux utiliser par exemple : FROM postgres:9.6 et il tirera cette version de postgres du Docker Hub. Bien sûr, je suppose que postgres:9.6 est un conteneur construit avec PostgreSQL v9.6, mais comme il s’agit d’une image officielle, c’est une valeur assez sûre. Vous pouvez généralement vérifier les balises sur la page Docker hub de l’image que vous utilisez. Si je le souhaite, je peux également consulter les métadonnées de l’image que j’ai tirée vers le bas (ou de tout objet Docker sur ma machine) à l’aide de la commande docker inspect . Première utilisation : docker pull postgres:9.6 pour extraire l’image postgres spécifique du hub Docker. Ensuite, exécutez : docker inspect postgres:9.6 et vous verrez un document JSON volumineux. Si je crée une autre image qui utilise la même version de postgres, Docker ne la télécharge plus, il utilise l’image qu’elle possède. Si j’utilise à la fois l’image postgres par défaut et la version 9.6, Docker tire également l’ancienne image vers le bas, et j’aurai postgres:latest et postgres:9.6 stockés sur ma machine. Si vous construisez quelques images, gardez un œil sur la quantité d’espace utilisée par la VirtualBox par défaut, car c’est là qu’elles sont stockées. Certaines images sont construites avec le minimum d’outils pour être aussi légères que possible. La dernière image postgres est v11. Si je tire une image postgres v11 construite sur Alpine Linux : docker pull postgres:11-alpine puis comparez les tailles docker image ls
- 6. 6/9 Vous verrez que la dernière version est 313Mb, puis la version 9.6 est 230Mb et la version légère 11-alpine est 71.9Mb. C’est quelque chose à considérer si vous construisez vos propres images. Volumes Les conteneurs Docker sont censés être éphémères, créés et détruits par des outils d’automatisation à tout moment. Mais si votre conteneur est une base de données, qu’advient-il des données ? Vous pouvez créer des volumes de données persistants qui résident sur la machine VirtualBox et sont accessibles par des conteneurs qui ont été créés correctement. Les volumes existent indépendamment des images et des conteneurs, de sorte que vous pouvez utiliser le même volume pour plusieurs conteneurs, même en même temps. Malheureusement, la maintenance des volumes n’est pas aussi facile qu’elle devrait l’être dans Docker. Contrairement aux conteneurs, les volumes ne sont pas nommés automatiquement, et comme il est facile de créer implicitement un volume, vous pouvez vous retrouver avec beaucoup de volumes mystérieusement nommés et aucune idée de l’endroit où ils sont utilisés. Pour éviter ce problème, vous pouvez créer explicitement un volume et lui donner un nom, avant de l’utiliser avec un conteneur. docker volume create postgres_vol_1 Vous pouvez également simplement utiliser l’indicateur -v et spécifier un nom pour le volume lorsque vous exécutez le conteneur et le mapper au répertoire, comme ceci docker run -v postgres_vol_2:/var/lib/postgresql/data --name volume- postgres -p 5433:5432 -d craig/postgres:version1 Le répertoire /var/lib/postgresql/data est le répertoire de données par défaut pour PostgreSQL utilisant l’image officielle, comme indiqué sous PGDATA dans le Comment étendre cette section d’image de leur page Docker Hub. Si vous avez exécuté les deux commandes ci-dessus, lorsque vous tapez docker volume ls
- 7. 7/9 Vous verrez que vous avez 3 volumes: un par défaut avec une longue chaîne de chiffres pour un nom, et les 2 volumes postgres_vol. Comme seule postgres_vol_2 est utilisée, allez-y et retirez postgres_vol_1: docker volume rm postgres_vol_1 Remarquez, même docker system prune ne supprimera pas les volumes. Vous devez utiliser docker volume prune ou docker volume rm Si le volume a un ID au lieu d’un nom, vous devez taper le nom en entier. D’autres commandes fonctionneront avec un ID partiel qui est unique, mais pas celui-ci. Réseau Docker crée 3 réseaux par défaut, que vous pouvez voir en utilisant docker network ls Bridge – le réseau dans lequel les conteneurs sont exécutés par défaut. Le pilote de pont Docker installe automatiquement des règles sur la machine hôte afin que les conteneurs sur différents réseaux de pont ne puissent pas communiquer directement entre eux. Hôte – utilisez directement la mise en réseau de l’hôte Aucun – désactivez tous les réseaux Pour créer votre propre réseau afin que les conteneurs du réseau soient isolés des conteneurs qui ne sont pas sur le réseau, utilisez : docker network create –-driver bridge my_bridge_network Ajoutez ensuite l’indicateur my_bridge_network --network lorsque vous créez le conteneur. Il y a beaucoup plus à dire sur la mise en réseau dans Docker, mais comme il s’agit d’un blog de base de données, je vais simplement vous renvoyer au Didacticiel de mise en réseau chez Docker.
- 8. 8/9 Docker-machine Enfin, examinons brièvement l’un des autres outils fournis avec Docker, à savoir Docker Machine. Docker Machine vous permet de créer et de contrôler des machines virtuelles exécutant Docker, entre autres. Pour le récapitulatif complet, consultez le Pages officielles. Mais pour l’instant, nous allons simplement regarder la création et la suppression d’une machine VirtualBox. Tout d’abord, listez les machines que vous avez déjà, qui devraient être par défaut : docker-machine ls Créez ensuite une nouvelle machine appelée virtual-docker docker-machine create virtual-docker Après un court moment, il devrait se terminer. Répertorier à nouveau les machines à l’aide de docker-machine ls Notice that the default machine is shown as active. Any docker commands you run will be run on that machine. Test this by listing the running containers using docker ps Now change machines by setting the DOCKER_HOST variable to whatever the URL of the virtual-docker machine is, in my case 192.168.99.111:2376 DOCKER_HOST=tcp://192.168.99.111:2376 Again, list both docker machines and running containers docker-machine ls docker ps
- 9. 9/9 You can see that virtual-docker is now shown as active, and no containers are present. You can also open VirtualBox Manager and see that a new machine is running. Any docker commands you now type will be run in the virtual-docker machine. To set the active machine back to default and remove the virtual-docker machine DOCKER_HOST=tcp://192.168.99.105:2376 docker-machine rm virtual-docker As with all the commands, more information can be found using the --help flag. Coming up in part three… This has been quite a wordy blog. In the next part I’ll look at deploying a PostgreSQL cluster, both the easy way (based off someone else’s hard work) and the hard way (creating your own images). How to run Postgres on Docker part 1 How to run Postgres on Docker part 3 Retour à l’aperçu du blog Réagir