copyrights optimata

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