La détection de la construction

Quels fichiers comptent comme Dockerfile ou comme fichier Compose, comment le port est trouvé, et ce qui se passe quand il y a plusieurs candidats ou aucun.

Quand vous choisissez un dépôt et une branche, la plateforme lit la liste de tous les fichiers de cette branche et détermine ce qui peut en être déployé. Vous obtenez une liste d'applications à cocher, pas un formulaire à remplir.

Ce qui est lu

  • Chaque Dockerfile, dans n'importe quel répertoire.
  • Les fichiers Compose, et le .env à côté de chacun.
  • Les autres fichiers YAML dont les services nomment des images prêtes à l'emploi. Ceux-là sont proposés à part, comme fichiers de stack.

Les répertoires qui contiennent le code des autres sont ignorés : node_modules, vendor, .venv, venv, site-packages, bower_components, .terraform, __pycache__ et .git.

Ce qui compte comme un Dockerfile

En majuscules ou en minuscules, dans n'importe quel répertoire :

  • Dockerfile et Containerfile.
  • Avec un suffixe : Dockerfile.worker, Dockerfile.prod.
  • Avec un préfixe : api.Dockerfile.
  • Avec les deux : api.Dockerfile.prod, web.Dockerfile.dev.

Le nom est aussi lu pour son sens. Un mot comme dev, local, test, ci, staging, prod, production ou release désigne un environnement : une seconde façon de construire la même application. Tout autre mot désigne un service : Dockerfile.worker et api.Dockerfile sont des applications à part entière.

Ce qui compte comme un fichier Compose

compose.yaml, compose.yml, docker-compose.yaml et docker-compose.yml, dans cet ordre. Un seul est lu par répertoire. Les autres à côté de lui, et les surcharges comme docker-compose.override.yml ou compose.prod.yaml, ne sont pas appliqués, et l'analyse le dit.

Chaque service avec une section build: devient une application, construite à partir du Dockerfile et du répertoire que cette section nomme. Un Dockerfile utilisé par un service Compose n'est pas proposé une seconde fois seul.

D'un tel service, l'analyse reprend aussi son environment, les entrées env_file présentes dans le dépôt, et son port. Les variables qu'il attend de votre machine sont listées pour que vous les définissiez, jamais devinées.

Certaines choses ne sont pas reprises, et chacune est signalée sur le service concerné : les volumes, le contrôle de santé, les arguments de construction, une cible de construction, plus d'une copie, et une surcharge de command ou d'entrypoint. Un service qui ne diffère que par sa commande est laissé décoché pour cette raison.

Un service qui ne fait que nommer une image n'est pas construit. Une image de base de données ou de courtier de messages est listée à part, avec un renvoi vers l'équivalent géré, et toute variable qui pointe vers elle est signalée.

Comment le port est trouvé

Dans cet ordre :

  1. Les ports ou expose du service Compose : le côté conteneur, premier port TCP.
  2. L'EXPOSE du Dockerfile, dans son étape finale.
  3. À défaut des deux, l'image construite est interrogée après la construction. Cela repère aussi un port déclaré par l'image de base.

Un port détecté suit l'image : si une construction ultérieure en expose un autre, l'application y passe. Un port que vous saisissez vous-même n'est jamais modifié par une construction.

Un service sans port dont le nom ou la commande de démarrage dit worker, consumer ou scheduler est importé comme tâche de fond : rien ne lui est acheminé et il ne peut pas être rendu public. Décochez cela s'il sert bien du trafic.

Plusieurs candidats

Les services différents sont tous cochés. Un dépôt avec Dockerfile et Dockerfile.worker, ou avec api/Dockerfile et web/Dockerfile, donne une application pour chacun.

Les variantes d'environnement ne sont pas cochées à côté d'un fichier simple. Avec Dockerfile et Dockerfile.dev, le fichier simple est présélectionné et l'autre est proposé décoché, pour qu'un déploiement ne lance pas une construction de développement à côté de la vraie.

Quand chaque recette nomme un environnement, la production l'emporte. Avec api.Dockerfile.dev et api.Dockerfile.prod et aucun fichier simple, celui nommé prod, production ou release est coché.

Sinon rien n'est coché et vous choisissez. Deux fichiers nommés pour la production, ou seulement dev et staging, ne sont pas une question que le nom peut trancher.

L'agent DevOps, qui traite aussi un projet téléversé en .zip, va un cran plus loin. Il lit ce que chaque recette démarre : un rechargeur, un observateur de fichiers ou le serveur de développement d'un framework est une image de développement quel que soit le nom du fichier, et cela pèse plus que le nom. Quand un service a plus d'une recette, il vous pose la question, avec sa recommandation et la raison, au lieu de choisir.

Monorepos

Une application par Dockerfile et par service Compose construit, jusqu'à 20 par import. Chacune porte le nom de son répertoire, ou celui du dépôt pour un fichier à la racine, suivi de la variante : shop-worker.

Quand il y en a plusieurs, elles sont privées sauf indication contraire : l'unique application d'un dépôt, ce que Compose publie sur l'hôte, et les répertoires nommés comme une interface (web, frontend, ui, app) sont publics par défaut.

Quand il n'y a pas de Dockerfile

Depuis un dépôt, rien n'est proposé. L'analyse indique que rien ne peut encore être déployé et ce qu'il faut ajouter : un Dockerfile, ou un fichier Compose avec une section build:. Rien n'est deviné à partir du langage du code.

Dans l'AI Studio, c'est différent. Quand vous publiez un projet qui n'a pas de Dockerfile, un Dockerfile est écrit pour lui à partir de la liste des fichiers du projet et de son manifeste de dépendances. Il est enregistré dans le projet comme un fichier ordinaire : vous pouvez le lire, le modifier et le commiter. Un Dockerfile que vous avez écrit n'est jamais remplacé. En écrire un compte comme de l'usage d'IA. Si aucun ne peut être écrit, la construction s'arrête et indique qu'il manque un Dockerfile.

Tout peut être remplacé

Cochez ou décochez n'importe quelle application, renommez-la, définissez son port, rendez-la publique ou privée, et ajoutez des variables et des secrets avant de déployer.

Si un Dockerfile a été manqué, ou s'il lui faut un autre répertoire de construction, ajoutez-le par son chemin. Il est lu comme les autres.

Pour continuer