De nombreuses instructions provenant d'Internet décrivent un certain minimum d'actions et, par conséquent, un minimum de commandes et d'opportunités.
J'ai décidé de faire une sélection de fonctionnalités un peu éclairées, de fonctionnalités. L'article ne prétend pas être unique, il m'aidera pour rappel, et peut-être qu'il aidera certains Padawans à commencer leur voyage avec docker-compose.
Utilisation de plusieurs fichiers docker-compose.yml
Il existe des configurations complexes, où il existe une certaine couche de base de conteneurs, qui, par exemple, est toujours nécessaire. Et généralement, il arrive que nous prenions de l'équipe voisine \ un autre projet \ Internet et le terminions à vos besoins. Mais s'il existe plusieurs commandes, la partie de base peut être déplacée vers un référentiel interne commun. Et nous obtenons une pièce de base identique pour la plupart des projets, qui est également versionnée.
Décrivons un exemple d'un docker-compose-base.yml de base.
Supposons qu'il s'agit d'une image nginx personnalisée avec des certificats, des réglages et des métriques dites. Et exportateur pour prometheus:
version: '2' services: nginx: image: nginx nginx-exporter: image: nginx/nginx-prometheus-exporter
Nous décrivons maintenant un exemple de notre application docker-compose-app.yml:
version: '2' services: backend: image: internal.local/super-app:0.1.2
Pour commencer, nous avons besoin de l'équipe habituelle avec une différence. Nous indiquerons 2 fichiers de composition de docker:
docker-compose up -d -f docker-compose-base.yml -f docker-compose-app.yml
Et le tour est joué, nous obtenons un ensemble de services, comme s'ils étaient décrits dans un seul fichier docker-compose!
Il existe également une deuxième option pour l'utilisation de plusieurs fichiers, grâce à l'utilisation de la directive extend.
docker-compose-base.yml:
version: '2' services: nginx: image: nginx nginx-exporter: image: nginx/nginx-prometheus-exporter
docker-compose-app.yml:
version: '2' services: backend: image: internal.local/super-app:0.1.2 ### web: extends: # ( ) file: docker-compose-base.yml # service: nginx web-exporter: extends: file: docker-compose-base.yml service: nginx-exporter
Module complémentaire d' iSlava :
Vous pouvez décrire tous les fichiers de composition dans des variables d'environnement et utiliser docker-compose up -d sans spécifier manuellement les fichiers:
COMPOSE_PATH_SEPARATOR=: COMPOSE_FILE=docker-compose-base.yml:docker-compose-app.yml
Quelle option choisir - vous choisissez. Tout individuellement, je voulais juste montrer les options =)
Héritage dans docker-compose
L'exemple suivant nécessite la version docker-compose > = 2.4
C'est aussi une fonctionnalité assez intéressante, et en fait, peu sont mentionnés.
Cette fonctionnalité nous permet de décrire plusieurs services du même type dans le fichier docker-compose, sans dupliquer leur description, à savoir l'héritage.
Par exemple, nous avons un fichier comme celui-ci:
version: '2.4' services: backend: image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro
Et il était nécessaire de soulever plusieurs conteneurs, mais avec quelques différences, nous pouvons bien sûr "économiser" et changer, mais nous pouvons le faire:
version: '2.4' services: backend: &base-app # image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro backend-2: <<: *base-app # ports: # - 8081:8080
Ainsi, nous avons la possibilité de changer en un seul endroit, que d'éditer dans la description de chaque conteneur.
Il existe une autre option pour passer à la zone racine, par exemple:
version: '2.4' services: x-backend: # "x-" , . &base-app image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro backend: <<: *base-app # backend-2: <<: *base-app # ports: # - 8081:8080
Limites des ressources
À partir de la version 2.2, vous pouvez utiliser les limites de ressources pour les conteneurs, en fait, à partir de la version 2.1, mais il n'y en a toujours pas tous livrés =)
Il y a une nuance! Dans la version 3, ces fonctionnalités sont supprimées! L'accent est déjà mis sur l'essaim de dockers.
L'exemple le plus simple de limitation des ressources CPU, MEM:
version: '2.2' services: backend: cpus: 1.5 # . cpuset: '0,3' # . mem_limit: 1gb # 1 memswap_limit: 2gb # SWAP . oom_kill_disable: true # , OOM Killer , . image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro
Emballage d'images dans une archive
Malheureusement, il n'est pas toujours possible de pousser des images dans votre propre registre ou dans le registre de docker cloud. Parfois, il est nécessaire de collecter des images à partir d'un fichier de composition de docker et d'envoyer, par exemple, une archive de fichiers. Les mains le font parfois longtemps, alors j'ai esquissé un script simple, tout à coup quelqu'un est utile:
#!/bin/bash dc=${1} if [ ! -z ${dc} ] && [ -f ${dc} ]; then echo "Saving docker images from file ${dc}..." images=`grep image: ${dc} | awk '{print $2}'` docker save ${images} | gzip > docker-images.gz echo "Success!" else echo "ERROR! You must set path to docker-compose.yml as argument!" fi
Enregistrer dans le fichier, par exemple docker-compose-images-save.sh
Nous donnons le droit d'exécuter:
chmod +x docker-compose-images-save.sh
Nous le démarrons et passons le chemin vers le fichier docker-compose comme argument:
./docker-compose-images-save.sh /home/some_user/docker-compose-app.yml
À la sortie, nous obtenons dans le dossier d'où l'archive de script avec des images a été appelée - docker-images.gz
De toute façon, nous pouvons envoyer à un serveur distant.
Maintenant sur le serveur distant il suffit d'exécuter:
gzip -cd docker-images.gz | docker load
Toutes les images seront téléchargées dans le registre local, après quoi vous pouvez exécuter en toute sécurité ici
docker-compose up -d , puisque toutes les images sont dans le registre local sur Internet, docker n'y entrera pas.
IPv6 vers l'avant
Dans certaines tâches, ipv6 peut être extrêmement utile, prenez au moins la nuance selon laquelle Roskomnadzor fait passer tout le trafic via ipv6 sans problème, et le même bot de télégramme fonctionne sans problème.
Je considérerai une situation où ipv6 n'est pas sur votre machine, que ce soit une machine virtuelle ou un serveur sur Internet.
Assurez-vous que le niveau système ipv6 est activé:
sysctl net.ipv6.conf.all.disable_ipv6
La valeur doit être 0, sinon, changez:
sysctl -w net.ipv6.conf.all.disable_ipv6=0
Installer miredo (Ceci est un service avec un VPN intégré au serveur qui nous donnera ipv6 public)
apt-get install miredo -y
Vérifiez que le service est en cours d'exécution:
systemctl status miredo
Nous vérifions que nous avons bien reçu l'adresse ipv6:
ifconfig teredo
Nous écrivons dans /etc/docker/daemon.json
{ "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64" }
Redémarrez le docker:
systemctl restart docker
Eh bien, il reste à activer NAT pour ipv6 afin que les adresses internes de notre conteneur puissent atteindre le monde extérieur via notre interface teredo:
ip6tables -t nat -A POSTROUTING -o teredo -j MASQUERADE
Nous élevons le conteneur docker dont nous avons besoin, et il peut être publié via l'adresse ipv6.
L'exemple ci-dessus avec sysctl et iptables fonctionnera jusqu'au redémarrage, si vous devez le faire sur une base continue, vous devriez regarder les instructions pour votre distribution, il y a des différences.
J'espère que quelqu'un a fourni les informations ici seront utiles.