Arrêtez d’écrire des fichiers Docker-Compose médiocres – SkillUp Ed

TLa partie la plus importante de tout fichier docker-compose est la section, qui décrit la manière dont les services doivent démarrer. Alors sans plus tarder, allons-y.

Chaque service commence par un nom, et il est très probable que vous souhaitiez que vos services aient un nom associé à ce qu’ils font. Ils doivent également être uniques dans la portée de tous les services à l’intérieur d’un.

Vous pouvez également exécuter plusieurs fichiers de composition à la fois à l’aide de l’indicateur lors de l’exécution de la commande. mais pour simplifier, nous supposons que tous vos services sont regroupés en un seul.

Donc:

services:
postgres:
...
...
cool_app:
...
...

image

Cet attribut est explicite, et à moins que vous n’utilisiez l’attribut, il est indispensable. Je n’ai pas besoin de te dire TOUJOURS taggez vos images Vous ne voulez jamais exécuter un service à l’aide de la balise (qui est la valeur par défaut, si cela ne vous dérange pas de le dire).

Cet attribut peut également être utilisé pour nommer une image après l’avoir construite (nous en parlerons plus loin dans cet article).

Donc:

services:
postgres:
image: postgres:12.1
...
...

nom_conteneur

Ceci est très utile pour vous-même. Vous est-il déjà arrivé d’interroger les conteneurs d’un système utilisant? Alors je suppose que vous connaissez le nom, ou peut-être etc. Maintenant, laissez-moi vous dire que je ne suis pas raciste, et ce ne sont que les noms qui moteur docker affecté à mes conteneurs quand je n’ai pas spécifié explicitement le nom en utilisant l’attribut. Par conséquent, spécifiez toujours.

Donc:

services:
postgres:
...
container_name: cool_app-postgres
...

Dois-je vous dire que j’ai choisi un nom arbitraire et que vous pouvez également choisir le vôtre? Je ne pense pas.

nom d’hôte

Lorsque vous essayez de créer plusieurs services en un seul, votre principale raison n’est pas parce que vous êtes paresseux pour écrire un nouveau fichier (je l’espère so), mais plutôt parce que les services vont avoir des communications pour accomplir une certaine tâche.

Si tel est le cas, vous avez sûrement besoin de cet attribut, car lorsqu’une application web s’exécutant dans un conteneur essayant de se connecter à une base de données demande le nom, le moteur docker résoudre ce nom en adresse IP affecté au service ci-dessus. Donc, spécifiez toujours ceci si vous voulez que votre connexion à la base de données fonctionne.

Donc:

services:
postgres:
...
hostname: cool_app-database
...

construire

Si vous souhaitez spécifier l’emplacement de votre, vous pouvez certainement le faire, et le moteur docker construire votre image en utilisant les informations de l’attribut, si aucune image de ce type n’est trouvée sur le système. Et le nom de l’image proviendrait de l’attribut mentionné ci-dessus.

Cet attribut a des enfants importants qui doivent être mentionnés ici:

1. : Ceci spécifie l’emplacement dans lequel vous vous feriez autrement avant de l’utiliser.
2. : Ceci est très utile pour les personnes qui utilisent constructions en plusieurs étapes. Vous pouvez spécifier quelle étape vous souhaitez construire avec cela.
3. : Explicite, j’espère, cet attribut est le chemin (absolu ou relatif à) du si son nom n’est pas typique, par exemple . Il est facultatif et utilise par défaut.

Donc:

services:
cool_app:
...
build:
context: .
target: prod
dockerfile: Dockerfile.prod
...

Vous pouvez comprendre que cela est relatif à l’emplacement du.

Si vous souhaitez découvrir les meilleures pratiques de rédaction d’un, jetez un œil à mon autre article sur le sujet:

Il s’agit d’un tableau, comme je suppose que vous le savez, et je vous recommande de vous abstenir de spécifier autre chose que le nom du volume docker. Parce que si vous spécifiez un chemin ici, chaque fichier de ce répertoire changera de permission et l’utilisateur de votre hôte n’y aura plus accès. Et lors d’occasions critiques, vous devrez demander l’aide du superutilisateur pour mettre la main sur les fichiers.

Donc:

services:
postgres:
...
volumes:
- "./db_data:/var/lib/postgresql/data"  # NOT RECOMMENDED
- "cool_app-database:/var/lib/postgresql/data"  # BETTER
...
...
volumes:
cool_app-database:  # just a declaration, nothing more needed

Lorsque vous spécifiez un nom pour votre volume, vous devez également définir vos volumes quelque part à l’extérieur, qui seront discutés plus loin ci-dessous.

Vous pouvez également monter un chemin sur le conteneur avec autorisation en lecture seule, pour empêcher le conteneur de changer le propriétaire des fichiers et donc d’y perdre l’accès, ce qui conduit à demander à nouveau l’aide du superutilisateur.

Donc:

services:
cool_app:
...
volumes:
- "./models:/service/models:ro"  # example AI service
...

redémarrer

Ceci est utile pour dicter la façon dont vous souhaitez que vos conteneurs redémarrent. Les options disponibles incluent «non», «toujours», «en cas d’échec», «sauf arrêt». Le dernier est mon préféré, qui est un super ensemble de «en cas d’échec».

Donc:

services:
postgres:
...
restart: unless-stopped
...

Il y a aussi un sous l’attribut, mais cela n’est utile que si vous exécutez vos services dans un essaim (Je pourrais en parler plus tard).

dépend de

J’utilise beaucoup cet attribut lorsque je veux que l’un de mes conteneurs soit lié à un autre service, d’un point de vue opérationnel et développemental. Cet attribut permet au moteur Docker de distinguer quel conteneur commencer en premier. Vous pouvez l’utiliser pour démarrer votre base de données avant votre application.

Donc:

services:
postgres:
...  cool_app:
...
depends_on:
- postgres
...

environnement

Cela vous aide à transmettre des variables d’environnement au conteneur Docker. Par exemple, lorsque vous souhaitez spécifier la chaîne de connexion d’une base de données pour votre application, ou lorsque vous souhaitez modifier le port par défaut à publier à l’intérieur du conteneur etc. Ceci peut être réalisé de l’une des deux manières suivantes.

1. Utilisation explicite des paires de valeurs:

services:
postgres:
...
environment:
PORT: "8000"
...

Également possible en utilisant cette notation:

environment:
- PORT="8000"

2. Passer les variables environnementales du contexte de l’hôte – ce qui est possible de l’une des deux manières suivantes:

• Si une variable d’environnement est définie dans le shell actuel, par exemple en utilisant la commande.
• Avoir un fichier au même emplacement que le et spécifier les paires clé-valeur à l’intérieur de cela:

# .env
PORT=8000

Et puis vous pouvez simplement passer cela en utilisant le modèle suivant:

services:
cool_app:
...
environment:
- PORT
...

Cela récupérerait la valeur d’une variable nommée soit dans, soit dans les variables du contexte du shell courant.

est une fonctionnalité très cool de docker, assurez-vous de l’utiliser beaucoup.

les ports

Pas besoin d’explications supplémentaires, mais il y a 2 façons de l’utiliser. Soit une syntaxe courte, soit une syntaxe longue. La plupart du temps, vous n’avez besoin de rien de plus qu’une courte syntaxe – elle est concise, élégante et directement à la cible.

Donc:

services:
cool_app:
...
ports:
# either publish on all interfaces:
- "8000:8000"      # or only publish on localhost:
- "127.0.0.1:8000:8000"

Selon le Documentation, Essayez de TOUJOURS spécifiez les ports entre guillemets doubles.

Lorsque vous mappez des ports au format, vous pouvez rencontrer des résultats erronés lorsque vous utilisez un port de conteneur inférieur à 60, car YAML analyse les nombres au format en tant que valeur de base 60. Pour cette raison, nous vous recommandons de toujours spécifier explicitement vos mappages de ports en tant que chaînes.

réseaux

Certaines personnes ignorent l’utilisation de cet attribut, car le docker attribue tous les services à l’intérieur d’un dans le même réseau, et ils ne ressentent pas le besoin de le spécifier explicitement.

Mais cela a ses propres avantages:

1. Aucun nom de réseau laid qui se produit par défaut lorsque vous n’en spécifiez pas un.
2. Vous ne prenez aucune chance et vous ne laissez rien vous surprendre. Ceci est particulièrement souhaitable dans les environnements de production, lorsque vous réduisez au minimum vos paramètres non contrôlés.

Donc:

services:
cool_app:
...
networks:
- cool_app
...

Et voilà, tout ce dont vous avez besoin pour faire passer vos services dans docker-compose au niveau supérieur qui vous est présenté.

Après les services, il y a des volumes et des réseaux.