Fichiers Compose et fichiers de stack

Déployer un fichier Docker Compose ou un fichier de stack Swarm - ce qui est appliqué, ce qui ne l'est pas, et ce que fait une nouvelle application du fichier.

Un fichier Compose décrit plusieurs programmes à la fois. ISOGrid le lit et fait de chaque service une application à part entière : le même genre d'application que vous créeriez à la main, avec sa taille, son adresse, ses journaux et son historique. Un fichier docker stack est lu de la même façon.

Le fichier sert à créer et à mettre à jour des applications. Ce n'est pas quelque chose qui continue ensuite de tourner comme un groupe.

Deux sortes de service, deux chemins

Un service qui nomme une image est téléchargé et exécuté. C'est le sujet de cette page.

Un service avec une section build: est construit à partir de son Dockerfile quand vous importez le dépôt. Ce chemin lit le fichier autrement, et la détection de la construction le décrit.

Un fichier peut contenir les deux. Chaque service prend le chemin qui lui correspond.

D'où vient le fichier

Collé ou téléversé. Applications, puis Depuis un fichier de stack : collez le YAML ou téléversez-le.

D'un dépôt connecté. Quand vous choisissez un dépôt, les fichiers YAML dont les services nomment des images sont listés comme fichiers de stack. La plateforme lit elle-même le fichier, vous montre ce qu'elle a lu et à quel commit, et applique ce même commit même si quelqu'un pousse entre-temps.

Depuis la ligne de commande. isogrid stack preview -f compose.yml --stack shop et isogrid stack apply, avec un fichier local, un dossier de fichiers, ou --repo et --path pour un fichier d'un dépôt connecté. C'est celle qu'il faut lancer depuis la CI.

Un fichier peut peser jusqu'à 256 Ko et contenir jusqu'à 60 services.

L'aperçu d'abord

Un aperçu ne modifie rien. Pour chaque service, il indique si une application serait créée, mise à jour ou ignorée et pourquoi, lequel de vos registres télécharge l'image, et tout ce qui, dans le fichier, ne sera pas appliqué.

Vous décidez ensuite, service par service : la taille (la plus petite qui respecte les limites du fichier est proposée), le réseau, le registre quand plusieurs correspondent, le port, où il peut tourner, ou de le laisser de côté.

${TAG} et ${TAG:-1.4} sont remplis à partir des variables que vous donnez. Une variable utilisée par le fichier et fournie par personne est listée, et bloque l'application du fichier.

Ce qui est appliqué

image, qui est obligatoire.
deploy.replicas, de 1 à 10.
environment.
command, entrypoint, user, healthcheck et stop_grace_period.
deploy.update_config, rollback_config et restart_policy.
logging avec le pilote json-file : max-size et max-file activent la conservation des journaux pour cette application.
ports et expose, uniquement pour savoir sur quel port le programme écoute.
deploy.resources.limits, uniquement pour proposer une taille.
networks, rapprochés par leur nom de l'un de vos réseaux. Une application rejoint un seul réseau ; le premier de la liste est utilisé.
Les ancres et les clés de fusion <<:.

Ce qui ne l'est pas, et pourquoi

build: sans image. Le service est ignoré ici. Importez le dépôt pour le construire, ou poussez l'image et nommez-la.

Bases de données, caches, courtiers de messages et serveurs de stockage. Une image de PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, Kafka, Keycloak, MinIO ou équivalent est ignorée, avec un renvoi vers l'équivalent géré. Exécutée comme une application ordinaire, elle n'aurait pas de sauvegardes et perdrait ses données au premier déplacement. Voir Bases de données et Services gérés.

env_file. Non lu sur ce chemin. Ajoutez ensuite ces variables sur l'application, et les secrets comme secrets.

volumes. Non montés, qu'ils soient nommés ou liés à un chemin. Un service ne peut pas choisir de chemins sur des machines partagées. Attachez du stockage sur la page de l'application après avoir appliqué le fichier.

secrets et configs. Non créés. Enregistrez les valeurs comme secrets et liez-les à l'application.

Ports publiés sur l'hôte. "80:8080" n'ouvre rien sur une machine. L'application est privée jusqu'à ce que vous la rendiez publique depuis ses paramètres d'exposition, et elle reçoit alors une adresse.

cap_add, privileged, devices, network_mode et similaires. Non accordés. L'aperçu liste chaque clé qu'il n'a pas appliquée.

depends_on, container_name, hostname, labels, restart au premier niveau. Ignorés sans avertissement. Rien n'est démarré dans un ordre donné : une application qui a besoin d'une autre doit réessayer jusqu'à ce qu'elle réponde.

Contraintes de placement. Elles nomment les machines de quelqu'un d'autre. Une contrainte n'est conservée que si elle correspond à un choix proposé par la région.

Détails. mode: global s'exécute comme des copies ordinaires, les réservations de ressources viennent de la taille, et les pilotes de journaux autres que json-file ne sont pas disponibles.

Les noms, et comment les services se trouvent

Chaque application s'appelle <stack>-<service>. Sur son réseau privé, elle répond aussi au simple nom du service dans le fichier : http://api:8000 continue donc de fonctionner entre services du même réseau.

Une application qui porte déjà ce nom et qui n'a pas été créée par cette stack est laissée telle quelle.

Un exemple que la plateforme accepte

services:
  api:
    image: ghcr.io/acme/api:${TAG:-1.4}
    command: ["node", "server.js"]
    environment:
      LOG_LEVEL: info
    ports:
      - "8000"
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:8000/health"]
      interval: 30s
      timeout: 5s
      retries: 3
    deploy:
      replicas: 2
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
      update_config:
        parallelism: 1
        order: start-first
        failure_action: rollback
        monitor: 30s
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"
  worker:
    image: ghcr.io/acme/api:${TAG:-1.4}
    command: ["node", "worker.js"]

L'appliquer de nouveau

Appliquer le même fichier sous le même nom de stack met à jour les applications au lieu d'en créer de nouvelles.

Le fichier l'emporte pour ce qu'il définit. L'image, le nombre de copies, la commande, le contrôle de santé, les paramètres de déploiement et de journaux sont remplacés par ceux du fichier.

L'environnement est fusionné. Les variables du fichier écrasent celles du même nom ; les variables ajoutées à la main sont conservées.

Le nombre de copies revient à celui du fichier. Si vous avez mis une application à l'échelle à la main, la prochaine application du fichier l'annule.

La taille est celle que choisit cette application du fichier. En ligne de commande, passez --size à chaque fois, sinon l'application revient à la taille proposée.

Rien n'est supprimé. Un service retiré du fichier laisse son application en service. Supprimez-la vous-même.

Chaque application créée ou mise à jour est ensuite déployée, même si rien n'a changé, sauf si vous désactivez le déploiement. L'échec d'un service n'arrête pas les autres ; chacun est signalé.

Déployer et lire les journaux

Chaque application se déploie de son côté, selon les paramètres que le fichier lui a donnés. failure_action: rollback revient automatiquement à la version précédente, pause vous laisse la décision, et continue ne fait ni l'un ni l'autre. monitor est la durée pendant laquelle une nouvelle version doit rester saine, entre 5 et 300 secondes.

isogrid stack apply --wait attend chaque déploiement et échoue si l'un d'eux a échoué ou a été annulé, ce dont une tâche de CI a besoin. --follow affiche les journaux de déploiement au fur et à mesure.

Les journaux se lisent par application, pas par stack : sur la page de l'application, ou avec isogrid apps logs <application>. Sans conservation des journaux, seule la partie que les copies en cours détiennent encore peut être recherchée.