Déployer une image Docker

Si ce que vous déployez est déjà une image construite plutôt qu'un dépôt à builder, la carte Docker dans le lanceur (cherchez « docker ») saute la sélection de dépôt, la détection de stack, et toute l'étape de build.

La carte Docker dans les résultats de recherche « What do you want to launch? » — « Connect your repo with a Dockerfile and deploy in under 60 seconds » — malgré le libellé, ce chemin est pour une image pré-construite, pas un dépôt (c'est le réglage Builder couvert dans Déployer depuis un dépôt Git).

Le formulaire de déploiement

Un seul champ : la référence de l'image, sous n'importe quelle forme acceptée par un registre — un nom simple avec tag (nginx:alpine), un nom avec namespace (user/app:v2), ou un nom complet sur un registre autre que Docker Hub (ghcr.io/owner/app:tag). Le champ port est par défaut à 80, correspondant à la convention la plus courante, mais devrait correspondre à ce sur quoi le serveur de l'image écoute réellement.

Le formulaire « Deploy a Docker image », avec un champ image, des tags à essayer rapidement, et un champ port — Les tags à essayer rapidement (nginx:alpine, ghost:5, redis:7…) servent à tester le flux sans risque avant de pointer sur une vraie image.

Attention. Les images privées ne sont pas encore prises en charge — l'image doit être publiquement récupérable. Une image privée sur Docker Hub ou GHCR a besoin d'un tag public, ou d'un déploiement Git du Dockerfile qui la construit à la place.

Vérification & déploiement

Cliquer sur « Deploy image » vérifie d'abord que la référence résout bien vers quelque chose de récupérable, puis provisionne le service — il n'y a pas d'étape de build à surveiller, puisque rien n'est compilé.

Le formulaire de déploiement en cours de soumission, montrant un état « Verifying & deploying... » sur le bouton — Pas de logs de build à suivre ici — la vérification est la seule étape entre cliquer sur Deploy et l'existence du service.

Le nouveau service atterrit immédiatement sur le canevas du projet, nommé d'après l'image et étiqueté avec le runtime que Qeda a reconnu (Nginx, Redis, etc. ont leur propre icône ; le reste retombe sur une icône générique).

Le canevas du projet montrant une nouvelle carte de service « nginx » en cours de déploiement — Le même canevas, la même carte de service, les mêmes onglets Observability/Variables/Settings qu'un service déployé depuis Git à partir de là.