Publier une application Docker

Dans [[Docker Level 2 - Dockerfile et Compose|l’exercice de Dockerfile]], vous avez construit une image et lancé l’application avec docker run. Si vous avez effectué le [[App with Compose Level 1 - Lancez et mettez à jour l’app|exercice facultatif sur Compose]], vous pouvez utiliser Compose à la place. Ici, il s’agit de faire répondre cette même application via un nom DNS et un proxy accessible. Vous pouvez utiliser votre propre application ou celle d’essai issue de l’exercice de Dockerfile.

Effectuez d’abord le test direct, puis le test HTTP via le proxy. Le parcours principal est terminé lorsque le nom fournit la réponse attendue de l’application et que vous êtes capable d’expliquer les différentes étapes. L’utilisation du HTTPS et l’installation d’un proxy dédié sont des options avancées ayant leurs propres prérequis.

Lorsque l’application Flask fonctionne sur un serveur avec un port, un reverse proxy peut recevoir les requêtes au nom de l’application et les transmettre vers le bon conteneur. Ainsi, l’utilisateur peut utiliser un nom de domaine plutôt qu’une adresse IP et un numéro de port. Il vous faut un nom DNS et un proxy auquel vous avez accès pour sa configuration, ainsi qu’un certificat si le service doit utiliser le HTTPS.

Le DNS répond avec une adresse mais ne transporte pas la page Web. Dans ce schéma, le proxy met fin à la connexion HTTPS et utilise ensuite le HTTP dans un réseau interne délimité. Le navigateur reçoit la réponse via le proxy.

Avant de commencer

Vous avez besoin d’un conteneur fonctionnel issu de l’exercice sur le Dockerfile (ou de l’exercice sur Compose) ainsi que des informations suivantes provenant de l’environnement de test :

• APP-VM-IP : l’adresse de la machine virtuelle qui exécute l’application ; ici, le port 5000 est utilisé.
• PROXY-IP : l’adresse à laquelle le client doit accéder au proxy, avec HTTP sur le port 80.
• APP-NOM : un nom DNS pointant vers le proxy. L’application et le proxy peuvent se trouver sur différentes machines virtuelles.

Vous devez avoir accès pour créer une entrée Hôte de proxy dans Nginx Proxy Manager et autoriser la connexion depuis le proxy vers l’application. Les valeurs ci-dessus doivent être remplacées par vos propres valeurs. Si le DNS ou l’accès au proxy n’est pas disponible, effectuez le test local et expliquez le diagramme. Cela ne constitue pas un test de publication terminé.

1. Vérifier l’application localement

Travaillez dans le répertoire du projet sur la machine virtuelle de l’application. Les commandes ci-dessous utilisent le nom de conteneur min-app issu de l’exercice Dockerfile. Avec le mappage des ports effectué à partir de cet exercice, ce test doit afficher la page d’accueil :

docker ps
curl --fail --show-error http://127.0.0.1:5000/

Vous pouvez utiliser /status comme point de contrôle fixe. Si cette route n’existe pas déjà, ajoutez-la après les autres fonctions de route complètes et avant if __name__ == "__main__": dans app.py :

@app.route("/status")
def status():
    return {"status": "ok"}

Construire, démarrer et tester à nouveau :

The provided code block contains no comments to translate; therefore, it is returned unchanged as per instructions.

docker build -t min-app .
docker rm -f min-app
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app
curl --fail --show-error http://127.0.0.1:5000/status

Si vous utilisez Compose, remplacez les trois premières commandes par docker compose up -d --build.

Attendez-vous à recevoir un code HTTP 200 et une réponse JSON avec "status": "ok". Si l’application possède déjà la route /status, utilisez sa réponse documentée au lieu de créer une nouvelle route portant le même nom. Cette vérification contrôle uniquement cette route, pas toutes les fonctionnalités de l’application.

2. Rendre l’application accessible au proxy

La suite de la recette utilise l’adresse réseau de la machine virtuelle de l’application. Si le port n’est lié qu’à 127.0.0.1, redémarrez le conteneur avec l’adresse réelle de la machine virtuelle dans la liaison des ports. Limitez l’accès au réseau aux sources nécessaires ; une simple liaison d’adresse ne restreint pas les clients autorisés à se connecter.

docker rm -f min-app
docker run -d --name min-app -p APP-VM-IP:5000:5000 min-app
curl --fail --show-error http://APP-VM-IP:5000/status

Si vous utilisez Compose, remplacez plutôt la ligne de ports sous app dans compose.yaml par "APP-VM-IP:5000:5000" et exécutez docker compose up -d.

Exécutez le test sur la machine virtuelle de l’application ainsi que depuis l’environnement réseau du proxy, ou à partir d’un client de test ayant les mêmes autorisations d’accès. La connexion réelle du proxy est également vérifiée avec le nom mentionné dans la section suivante. Après avoir modifié le bind, testez l’adresse IP de la machine virtuelle, et non 127.0.0.1. N’exposez pas ce port à tout Internet. [[Segmentation Niveau 1 – VLAN et segmentation réseau | Segmentation]] fournit un support pour cette règle d’accès.

Du domaine au conteneur

Plusieurs choses se produisent lorsqu’un utilisateur ouvre un nom tel que https://app.example.test. Il s’agit d’un exemple de nom ; remplacez-le par le nom effectivement configuré dans votre environnement de test :

sequenceDiagram
    participant B as Navigateur
    participant D as DNS
    participant P as Nginx Proxy Manager
    participant F as Conteneur Flask

    B->>D: Trouver l'adresse IP du domaine
    D-->>B: Adresse IP de la passerelle
    B->>P: Demande vers le domaine
    P->>P: Trouver le bon hôte proxy
    P->>F: Transmettre au port interne 5000
    F-->>P: Retourner la page HTML
    P-->>B: Retourner la réponse

Il est donc judicieux de tester une couche à la fois plutôt que de déboguer simultanément le DNS, le proxy et Flask.

Nginx Proxy Manager

Nginx Proxy Manager est une interface web pour Nginx. Ici, vous utilisez une installation disponible et créez un seul hôte de proxy. Vous n’avez pas besoin d’installer un nouveau proxy pour chaque application.

Créez un hôte de proxy :

1. Saisissez APP-NAME, le nom réellement configuré pour le service.
2. Sélectionnez http comme schéma pour la connexion depuis Nginx Proxy Manager vers le conteneur.
3. Saisissez l’adresse IP du VM de l’application (APP-VM-IP) en tant que nom d’hôte de redirection (forward hostname). L’adresse 127.0.0.1 à l’intérieur d’un conteneur de proxy désigne le conteneur de proxy lui-même.
4. Saisissez le port publié du conteneur, par exemple 5000.
5. Enregistrez les modifications et ouvrez http://APP-NOM/status depuis le client.

Le nom doit résoudre vers PROXY-IP. Vous pouvez vérifier la résolution avec nslookup APP-NOM sur le client. Le test HTTP doit donner la même réponse de statut que le test direct. Obtenir la page par défaut du proxy ne montre pas que la requête a atteint l’application.

Renouvellement : HTTPS

Une fois que le protocole HTTP fonctionne et que vous disposez d’un certificat valide pour le nom de domaine, ouvrez l’onglet SSL, sélectionnez le certificat et testez https://NOM-DU-NOM-DHÔTE/status. Un nom interne tel que app.example.test ne peut pas obtenir un certificat public auprès de Let’s Encrypt ; dans ce cas, il faut utiliser un certificat émis par une autorité interne à laquelle le client fait confiance. La résolution DNS seule n’établit pas la connexion HTTPS. Le chemin local basé sur HTTP est un exercice ; lors du traitement des connexions ou d’autres données sensibles, HTTPS est requis.

Le proxy doit pouvoir accéder au port du serveur. Si le conteneur s’exécute sur une autre machine virtuelle (VM), le réseau et le pare-feu doivent permettre le trafic entre les VMs. Il n’est pas nécessaire d’exposer directement le port Flask à Internet si Nginx Proxy Manager sert de point d’accès principal ; restreignez l’accès via le pare-feu selon la configuration de l’établissement scolaire.

Réélection : Proxy dédié

Installez un proxy dédié uniquement si vous en avez réellement besoin et que vous disposez d’un environnement de test indépendant. Utilisez le guide d’installation de Nginx Proxy Manager. Ensuite, revenez à la création du hôte proxifié ci-dessus. Il s’agit d’une configuration distincte, non d’un prérequis pour utiliser un proxy existant.

Dépannage

docker ps
docker logs -f min-app
ss -tulpn

Si vous utilisez Compose, les deux premières commandes sont docker compose ps et docker compose logs -f. Exécutez ces commandes une par une sur le VM de l’application. Arrêtez logs -f avec Ctrl+C. La commande ps affiche l’état des conteneurs, les journaux affichent les messages de l’application, et la commande ss peut aider à examiner les ports d’écoute. Utilisez le résultat du test HTTP spécifique pour vérifier l’accès.

Testez dans cet ordre :

1. Sur le VM de l’application après modification du binding : curl --fail --show-error http://IP-VM-APP:5000/status.
2. Depuis l’environnement réseau du proxy : même adresse, port et route. Un client arbitraire peut avoir des règles d’accès différentes.
3. Depuis le client via le nom : nslookup NOM_APP, puis http://NOM_APP/status. Testez HTTPS séparément s’il est configuré.

Si le point 1 échoue, examinez l’application, l’état du conteneur, l’adresse et le binding du port. Si le point 1 fonctionne mais que le point 2 échoue, examinez la connexion et les règles d’accès depuis le proxy. Si le point 2 fonctionne mais que le point 3 échoue, examinez DNS, Proxy Host et le protocole choisi. Une erreur HTTP 404 signifie qu’un serveur HTTP a répondu, mais la route peut être incorrecte ; une erreur 502 provenant du proxy indique un problème avec la connexion ou la réponse de l’application. Notez ce que le test délimite avant toute modification.

Étapes suivantes

Affichez la réponse de statut via le nom et expliquez la différence entre l’interrogation DNS et la redirection dans le proxy. Pointez également le client, le proxy et l’application sur la figure ou un schéma séparé. Vous pouvez expliquer à l’oral ou par écrit. Indiquez l’adresse de test, la réponse attendue/réelle et si vous avez essayé HTTP ou HTTPS. En cas d’écart, utilisez la séquence de tests ci-dessus avant de poursuivre.

Une fois que le chemin principal fonctionne, vous pouvez utiliser cette configuration plus loin dans le projet. [[Docker Level 4 - Publier un conteneur avec un flux de travail | Docker - Publier un conteneur avec un flux de travail]] est une formation supplémentaire pour automatiser la construction et la publication de l’image.

Sources : Docker : liaison de ports, Nginx Proxy Manager et Flask : routes et réponses.