Découvrir le Hub › Parcours

Parcours · administrateur de la plateforme

Brancher le domaine d'un client

Servir une application sous le domaine du client : enregistrement DNS, certificat TLS, route du proxy, puis cache.

Rejouer tout le parcours dans le Hub

1. Vérifier que le domaine est actif

   L'écran DNS › Enregistrements montre la copie que le Hub tient des zones qu'il sert. Les onglets suivent le registre des domaines : atelier-durand.example y a le sien dès sa déclaration.

   Regardez son badge. Sans badge, le domaine est ACTIVE : on peut continuer. Avec PENDING ou VALIDATING, la propriété n'est pas encore prouvée : le Hub ne demande aucun certificat et refuse les requêtes sur ce nom. Un enregistrement qui « ne marche pas » sous un tel domaine n'y est pour rien.

   L'onglet entouré ici est celui d'un autre client, client-05.example, encore en attente.

   Faire cette étape dans le Hub → Pour aller plus loin : dns.records.onglets dns.records.sous_titre

2. Créer l'enregistrement du nouveau nom

   Le nom doit pointer vers le Hub, qui recevra les requêtes. Ouvrez Nouvel enregistrement :

   • Domaine : la zone de atelier-durand.example. Seuls les domaines du registre qui ont une zone connue sont proposés ; la liste montrée ici est celle d'autres clients ;
   • Type : A ;
   • Nom : outils.atelier-durand.example, en entier sur l'onglet « Tous les domaines ». Sous l'onglet du domaine, outils suffit : le Hub ajoute le suffixe ;
   • Contenu : laissez l'adresse proposée, 203.0.113.10. C'est celle du Hub, résolue à l'ouverture de la page.

   Cliquez sur Créer l'enregistrement. Le Hub écrit la ligne dans sa copie, puis la publie aussitôt chez le fournisseur de la zone. Si le fournisseur ne répond pas, la ligne reste pending et le Hub la repousse seul toutes les 5 minutes, ou tout de suite avec Pousser les changements.

   ⚠ Pour un A, un AAAA ou un CNAME, un nom déjà publié est remplacé sans avertissement.

   ⚠ La case Proxy Cloudflare n'agit que sur une zone servie par Cloudflare. Cochée, c'est Cloudflare qui présente son certificat ; décochée, le Hub présente le sien.

   ⚠ Une ligne publiée par l'écran a le statut synced, qui n'a pas de badge : la colonne Statut reste vide jusqu'à la synchronisation suivante.

   Action du Hub : dns_sync_worker.create_record

   Faire cette étape dans le Hub → Pour aller plus loin : dns.records.creer.zone dns.records.creer.type dns.records.creer.nom dns.records.creer.contenu dns.records.creer.proxied dns.records.creer.valider dns.records.col.statut

3. Obtenir le certificat TLS

   Pour servir outils.atelier-durand.example en HTTPS, le Hub doit présenter un certificat pour ce nom. Il l'obtient par ACME avec une validation DNS-01 :

   1. il ouvre une commande chez Let's Encrypt pour le nom ;
   2. il pose le TXT _acme-challenge.outils.atelier-durand.example dans la zone du client ;
   3. il attend que des résolveurs publics voient ce TXT ;
   4. il récupère le certificat et le range dans Vault ;
   5. il retire le TXT et charge le certificat à chaud, sans redémarrage.

   La page attend la fin de l'échange : de quelques secondes à quelques minutes selon le fournisseur DNS.

   ⚠ D'après le gabarit du Hub 3.77.0, le formulaire envoie deux champs domain, la liste et la saisie libre : la commande part sur un nom invalide. Passez par l'action, qui reçoit un nom propre :

   { "name": "acme_worker__request_certificate",
     "arguments": { "domain": "outils.atelier-durand.example" } }
   

   Le message « Certificate requested for outils.atelier-durand.example. » confirme. En cas d'échec, le motif précis n'est que dans le journal du Hub.

   Action du Hub : acme_worker.request_certificate

   Faire cette étape dans le Hub → Pour aller plus loin : dns.certs.ecran dns.certs.demander.ouvrir dns.certs.demander.domaine_saisie dns.certs.demander.valider

4. Surveiller son échéance

   Le nouveau certificat prend sa ligne dans le tableau, avec ses dates et son compte à rebours : vert au-delà de 30 jours, ambre jusqu'à 7, rouge en dessous.

   Le renouvellement est automatique : une fois par jour, le Hub renouvelle chaque certificat à qui il reste 30 jours ou moins. Une ligne qui reste ambre plusieurs jours signale un renouvellement qui échoue : lisez le journal du Hub, puis essayez Renouveler.

   ⚠ Let's Encrypt limite le nombre de certificats identiques par semaine : ne cliquez pas Renouveler en boucle.

   Faire cette étape dans le Hub → Pour aller plus loin : dns.certs.col.jours dns.certs.col.statut dns.certs.renouveler

5. Faire servir le nom par la route de l'application

   Le DNS amène les visiteurs au Hub, le certificat les accueille en HTTPS. Reste à dire au Hub vers quelle application envoyer ce nom : c'est la route de nextcloud-durand.

   L'écran montré ici est la fiche d'une autre application, agentia : celle de nextcloud-durand est la même page.

   Ouvrez Proxy & SSO. Le Hostname est la clé de la route : le proxy cherche le nom d'hôte de chaque requête dans sa table. Il est prérempli avec outils.atelier-durand.example. Laissez TLS activé coché, puis Sauvegarder les modifications. La règle s'applique à la requête suivante.

   ⚠ Ce champ change seulement la route : il ne crée ni l'enregistrement DNS ni le certificat. D'où l'ordre de ce parcours.

   ⚠ La mise à jour vise toutes les routes de l'application (par app_id). Une application à plusieurs adresses recevrait ce nom sur chacune d'elles.

   Action du Hub : proxy_worker.update_route

   Faire cette étape dans le Hub → Pour aller plus loin : apps.detail.route apps.detail.route.hostname apps.detail.route.tls apps.detail.route.enregistrer

6. Purger le cache après la bascule

   Pour les routes dont le cache est activé, le Hub garde une copie des réponses et la resert lui-même. L'écran Cache montre son efficacité, et la colonne Hostname les noms publics qui ont des réponses en cache.

   Après une bascule, videz le cache de cette seule application : ses visiteurs voient aussitôt le bon contenu, les autres applications gardent le leur. Rien n'est perdu : le cache ne contient que des copies.

   ⚠ Sur le Hub 3.77.0, le bouton Purger de cet écran envoie le nom public au lieu de l'identifiant de l'application, et la purge est refusée. Purgez depuis la fiche de l'application (Proxy & SSO › Purger le cache), ou par l'action :

   { "name": "cache_worker__cache_purge_app", "arguments": { "app_id": "nextcloud-durand" } }
   

   La durée de vie des pages et des fichiers statiques se règle dans la même fiche, bloc Cache HTTP.

   Action du Hub : cache_worker.cache_purge_app

   Faire cette étape dans le Hub → Pour aller plus loin : cache.dashboard.ecran cache.dashboard.col.hostname cache.dashboard.purger_app apps.detail.cache.purger apps.detail.cache.page_ttl

Pièges

• Un domaine PENDING ou VALIDATING ne sert rien : ni certificat, ni trafic. Vérifiez son badge avant de chercher ailleurs.
• Un A ou un CNAME de même nom est écrasé sans avertissement ; un TXT ou un MX s'ajoute à côté.
• Le formulaire de certificat envoie deux noms : demandez le certificat par l'action acme_worker.request_certificate.
• Changer le Hostname ne crée ni DNS ni certificat : faites-les d'abord.
• Le bouton Purger de l'écran Cache est refusé : purgez depuis la fiche de l'application.
• Le menu Proxy n'est pas celui des routes : il montre le proxy de sortie des applications vers Internet. Les routes d'entrée se règlent dans la fiche de chaque application.