Devcontainer - Nommer son container et le regrouper dans Docker Desktop

Ouvrez la liste des containers de Docker Desktop après quelques jours de travail en devcontainer et vous obtenez quelque chose comme serene_ganguly, objective_hopper, vigilant_tesla... Lequel est mon blog ? Lequel est mon projet PHP ?

Un nom aléatoire est aussi un vrai problème dès que vous voulez être générique : un script, un alias ou une commande docker exec ne peuvent pas cibler un container dont le nom change à chaque rebuild.

Avec un fichier compose.yaml, il suffirait de définir container_name: pour le container et la clé name: de premier niveau pour regrouper les services — voir Docker - Comment regrouper vos containers. Un devcontainer construit depuis un simple Dockerfile n'a ni l'une ni l'autre.

Il a mieux : runArgs.

Les deux lignes​

runArgs est un tableau d'arguments supplémentaires que VS Code passe à docker run au moment de créer le container. N'importe quel flag de docker run y fonctionne, donc :

{
  "name": "Docusaurus",
  "build": {
    "dockerfile": "../Dockerfile"?
  },
  "runArgs": [?
    "--name=docusaurus-devcontainer",?
    "--label=com.docker.compose.project=blog-devcontainer"?
  ]
}

Reconstruisez le container (Dev Containers: Rebuild Container depuis la palette de commandes) et regardez à nouveau Docker Desktop.

--name : un nom de container stable​

--name=docusaurus-devcontainer est l'équivalent, côté docker run, du container_name: d'un fichier compose. Le container s'appelle désormais toujours docusaurus-devcontainer, donc ceci fonctionne depuis n'importe quel terminal, à chaque rebuild :

docker exec -it docusaurus-devcontainer bash
docker logs --follow docusaurus-devcontainer

--label : le regroupement dans Docker Desktop​

Docker Desktop ne regroupe pas les containers par magie : il lit le label com.docker.compose.project que Docker Compose pose sur chaque container qu'il crée. La clé name: d'un fichier compose.yaml n'est rien d'autre que la valeur de ce label.

Rien ne vous empêche de définir ce label vous-même. Avec --label=com.docker.compose.project=blog-devcontainer, le devcontainer rejoint le groupe blog-devcontainer dans Docker Desktop — et peut être arrêté en même temps que tout autre container portant le même label.

Choisissez la même valeur pour tout ce qui va ensemble, et gardez le suffixe -devcontainer : sur un vrai projet, le groupe blog contient les containers qui font tourner les services (une base de données, un reverse proxy, ...) tandis que blog-devcontainer contient les environnements dans lesquels vous codez. Un coup d'œil à Docker Desktop vous dit qui est qui, et arrêter un groupe n'arrête jamais l'autre.

Et si mon devcontainer utilise compose.yaml ?​

Alors vous n'avez pas besoin de runArgs du tout (VS Code l'ignore dans ce mode de toute façon) : définissez container_name: sur le service et la clé name: de premier niveau dans le fichier compose, comme expliqué dans Docker - Comment regrouper vos containers.

runArgs est la réponse pour la configuration la plus courante : un devcontainer.json qui pointe vers une image ou un Dockerfile, comme dans Développement PHP dans un devcontainer avec des outils de qualité de code préinstallés.

Conclusion​

Deux lignes dans devcontainer.json, et le serene_ganguly aléatoire devient docusaurus-devcontainer, bien rangé sous blog-devcontainer dans Docker Desktop. Je les ajoute maintenant à chaque nouveau devcontainer, juste après la clé name.