Suivant Docker + Laravel =? Je veux parler d'une façon plutôt inhabituelle d'utiliser l'utilitaire de composition de docker.
Pour commencer, pour ceux qui ne savent pas pourquoi le docker-compose est nécessaire. Il s'agit d'un utilitaire qui vous permet d'exécuter sur un hôte distinct un ensemble de services associés emballés dans des conteneurs Docker. La version initiale a été écrite en python et peut être installée de deux manières:
- via le gestionnaire de packages du système d'exploitation (
apt install docker-compose pour Ubuntu et yum install docker-compose.noarch pour Centos) - via le gestionnaire de dépendances python (
pip install docker-compose )
Le problème avec la première méthode est que généralement dans les référentiels du système d'exploitation docker-compose de l'ancienne version. C'est un problème si vous devez utiliser la dernière version du démon docker ou utiliser des fonctionnalités spécifiques à une version spécifique du format de fichier docker-compose.yaml (une matrice des fonctionnalités prises en charge par les versions de format et les versions de l'utilitaire docker-compose se trouve sur le site Web officiel de docker).
Maintenant développeurs Docker réécrit l'utilitaire en cours de route , a fait une erreur, a réellement empaqueté le script python avec l'environnement dans un seul paquet et le fournit sous forme de fichier binaire, ce qui vous permet de l'installer de la manière suivante (c'est la méthode actuellement recommandée):
Nous regardons la dernière version sur https://github.com/docker/compose/releases et la téléchargeons
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
définir les droits d'exécution de l'application
$ sudo chmod +x /usr/local/bin/docker-compose
en outre, vous pouvez définir l' auto-complétion pour les interpréteurs de commandes bash et zsh
vérifier l'installation
$ docker-compose --version docker-compose version 1.22.0, build 1719ceb
Je crois qu'un seul binaire est très cool, car nous n'avons pas besoin de tirer les dépendances de python. Oui, et en général - peut-être que notre environnement python est complètement cassé sur la machine cible, que nous voulons configurer !!!
Exemple de confusion dans un environnement python
Mais il y a encore un 4ème chemin, dont je voulais parler. Il s'agit de la possibilité d'exécuter docker-compose via docker. En effet, il existe déjà des images officielles collectées sur le Docker Hub ( https://hub.docker.com/r/docker/compose/ ). Pourquoi pourraient-ils être nécessaires?
- si nous voulons travailler avec plusieurs versions de docker-compose en même temps (bien que généralement la dernière version stable soit suffisante)
- si nous n'avons pas de python ou si nous ne voulons pas l'utiliser (par exemple, nous avons une distribution légère de CoreOS Container Linux )
- utilisation dans les pipelines CI / CD.
Essayons!
Comme d'habitude, nous lançions des conteneurs:
$ docker-compose up -d
Via un utilitaire emballé dans un conteneur Docker:
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v "$PWD:/rootfs/$PWD" -w="/rootfs/$PWD" docker/compose:1.13.0 up -d
Trop verbeux, hein? Le cerveau peut être brisé pour se souvenir de tous ces paramètres. Par conséquent, nous allons essayer de nous faciliter la vie et d'écrire un wrapper en langage shell. Mais d'abord, regardons les paramètres passés:
--rm - supprime le conteneur temporaire après l'arrêt, c'est-à-dire on ne laisse pas de déchets dans le système-v /var/run/docker.sock:/var/run/docker.sock - sans cela, docker-compose ne pourra pas se connecter au démon docker sur l'hôte-v "$PWD:/rootfs/$PWD" -w="/rootfs/$PWD" - vous permet de transférer le répertoire courant à l'intérieur du conteneur afin que l'utilitaire voit le fichier docker-compose
Nous n'avons toujours pas la possibilité d'interpoler les valeurs dans le fichier docker-compose. Il s'agit du processus par lequel l'utilitaire remplace les variables d'environnement dans un fichier YAML. Par exemple, dans un fragment
version: "2.1" services: pg: image: postgres:9.6 environment: POSTGRES_USER: ${POSTGRES_DB_USER} POSTGRES_PASSWORD: ${POSTGRES_DB_PASSWORD}
les variables POSTGRES_DB_USER et POSTGRES_DB_PASSWORD seront lues dans l'environnement. Cela permet de modèle de fichiers Docker-composer avec un certain degré de commodité. C'est-à-dire nous devons capturer l'environnement de la machine hôte et le transférer à l'intérieur du conteneur.
Résolvons le problème en écrivant un script bash.
#!/bin/sh # TMPFILE=$(mktemp) # env > "${TMPFILE}" # VERSION="1.13.0" # docker-compose docker run \ --rm \ -e PWD="$PWD" \ --env-file "${TMPFILE}" \ -v /var/run/docker.sock:/var/run/docker.sock \ -v "$PWD:/rootfs/$PWD" \ -w="/rootfs/$PWD" \ docker/compose:"${VERSION}" \ "$@" # rm "{$TMPFILE}"
Des lignes supplémentaires sont apparues:
-e PWD="$PWD" - juste au cas où, transférer le répertoire courant--env-file "${TMPFILE}" - ici toutes les autres variables d'environnement sont transférées de la machine hôtedocker/compose:"${VERSION}" - le nom de l'image, prenez la version de la variable"$@" - cette construction vous permet d'utiliser le script comme s'il s'agissait de l'utilitaire docker-compose, c'est-à-dire transmet de manière transparente ses arguments au conteneur Docker.
Nous pouvons enregistrer le script, par exemple, dans /usr/local/bin/docker-compose , définir l'indicateur eXecute dessus et l'utiliser. Le script ci-dessus ne prétend pas être à 100% exempt d'erreurs ou de défauts et est plutôt une illustration de la méthode.
Nous utilisons nous-mêmes les pipelines CI / CD de cette manière. Cela permet même d'économiser du trafic dans une certaine mesure. L'image cible du docker est extraite du cache local.