[Docker] Introduction à docker compose Résumé de base de docker-compose.yml

En mémoire

Je voulais organiser comment écrire docker-compose.yml et son contour une fois, donc je vais l'écrire.

environnement

-OS hôte: Windows 10 Famille ・ OS invité: wsl2 Ubuntu 20.04 ・ Docker ver 19.03 ・ Docker Compose ver1.25.0

Structure du répertoire / contenu du fichier

Dans cet article, nous prendrons la structure de répertoires suivante comme exemple. (Cet article a été utilisé comme référence.)

.
|
├── infra
│   ├── mysql
│   │   ├── Dockerfile
│   │   └── my.cnf
│   ├── nginx
│   │   └── default.conf
│   └── php
│       ├── Dockerfile
│       └── php.ini
├── docker-compose.yml
└── backend
└── Répertoire pour installer Laravel

· Serveur d'application · Serveur Web ・ Serveur Db

Il s'agit d'une configuration pour construire une architecture LEMP composée de trois couches. Dans l'article original, laravel est adopté comme cadre de PHP, mais cette fois, il n'est pas traité car le but est d'organiser la connaissance de docker-compose.yml.

Le contenu de docker-compose.yml est le suivant.

version: "3"
services:
  app:
    build: ./infra/php
    volumes:
      - ./backend:/work
    depends_on:
      - web
  web:
    image: nginx:1.18-alpine
    ports:
      - "10080:80"
    volumes:
      - ./backend:/work
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - db
    working_dir: /work

  db:
    build: ./infra/mysql
    volumes:
      - db-store:/var/lib/mysql

volumes:
  db-store:

docker-compose.yml est écrit dans un format de fichier appelé yml (yaml). Pour yml, les points suivants doivent être gardés à l'esprit.

-Exprimez la structure hiérarchique avec indentation. Afin de garantir la lisibilité, une hiérarchie est souvent représentée par deux retraits. -Le - au début de la ligne représente un tableau. --Dans la même hiérarchie se trouvent des éléments du même tableau. -Descriptions telles que clé: valeur représentent un hachage. Il faut mettre un espace demi-largeur après le:.

Clés fréquemment utilisées

build: Défini lors de la génération d'une image à partir d'un Dockerfile. .. Décrivez le chemin du fichier Dockerfile en valeur. (Peu importe qu'il s'agisse d'un chemin relatif ou d'un chemin absolu. De plus, docker compose recherche un fichier nommé Dockerfile dans le chemin de fichier décrit, vous pouvez donc omettre le Dockerfile.)

app:
  build: ./infra/php

Dans ce cas, l'image qui est à la base du conteneur d'application est créée à partir du Dockerfile dans ./infra/php.

image: Spécifie l'image de base sur laquelle le conteneur est basé. Par exemple, si vous souhaitez utiliser l'image officielle telle quelle, définissez-la au lieu de build.

 web:
   image: nginx:1.18-alpine

Ici, un conteneur Web est généré à partir de l'image officielle de nginx.

• D'après ce qui précède, la construction et l'image ne sont pas compatibles pour un conteneur. Cependant, il est possible d'utiliser les deux pour des conteneurs différents dans un même docker-compose.yml.

ports: Spécifie le port que le conteneur expose. Le format est "Numéro de port côté hôte: numéro de port côté conteneur".

• Dans les fichiers yaml, les formats tels que aa :: bb peuvent être interprétés comme du temps, il est donc prudent de mettre la chaîne de caractères entre guillemets.

web:
  image: nginx:1.18-alpine
  ports:
    - "10080:80"

Dans cet exemple, le port 10080 côté hôte et le port 80 côté conteneur sont associés. (Le port 80 est le numéro de port par défaut pour nginx)

expose:

Bien que non défini cette fois-ci, si vous ne souhaitez pas exposer le port du conteneur du côté hôte et l'ouvrir uniquement vers un autre conteneur lié, utilisez exposer au lieu de ports.

depends_on:

Définit les dépendances de conteneur.

web:
    image: nginx:1.18-alpine
    ports:
      - "10080:80"
    volumes:
      - ./backend:/work
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - db

L'exemple ci-dessus définit que le conteneur Web dépend du conteneur db. Plus précisément, l'ordre est défini que le conteneur db est activé, puis le conteneur Web est activé.

Cependant, il ne contrôle que l'ordre de démarrage du conteneur et le serveur Web n'attend pas que le serveur de base de données du conteneur soit prêt.

Si vous souhaitez faire de telles spécifications, vous devez prendre des mesures côté application.

volumes

Montez le volume sur le conteneur. Je pense que c'est un terme que beaucoup de gens ne comprennent pas, ce qui suit est une brève explication.

-Volume: Une zone de stockage de données pour conserver les données même après la destruction du conteneur. En termes simples, le répertoire qui stocke les données dans le conteneur -Mount: pour charger un fichier externe dans Linux.

En gros, il s'agit de Shioume, "Parce que les conteneurs ne sont pas adaptés au stockage à long terme, stockons-les dans un OS externe." (Je pense que ce n'est pas pratique d'entrer dans le conteneur et d'éditer php avec vim ...)

volumes est défini au format "répertoire de montage côté hôte: répertoire côté conteneur".

app:
  build: ./infra/php
  volumes:
    - ./backend:/work

Ici, le répertoire de travail (ainsi que les fichiers et répertoires sous celui-ci) dans le conteneur d'application est monté sur le répertoire ./backend côté hôte.

Résumé / Supplément

Il existe de nombreuses autres clés qui peuvent être définies, mais pour l'instant, j'ai résumé les clés de base. Tout d'abord, je veux comprendre la construction et les volumes.