Domaine personnalisé et TLS automatique sur Dockup

Une configuration de domaine personnalisé et de TLS automatique comporte trois couches distinctes : le service Dockup doit être opérationnel, le DNS doit diriger le hostname vers la plateforme et le hostname doit être vérifié avant qu’un certificat puisse être émis. Traiter ces couches séparément rend la bascule prévisible et évite que des erreurs DNS soient confondues avec des problèmes applicatifs.

Dockup fournit également à chaque service une adresse *.dockup.tech. Conservez cette adresse pendant la propagation DNS afin de pouvoir tester l’application indépendamment du hostname personnalisé.

Que faut-il préparer avant d’ajouter un domaine personnalisé Dockup ?

Commencez par un service déjà en cours d’exécution et qui passe son contrôle de readiness :

dockup status production/web --json
dockup health production/web --json

Ouvrez ou testez l’URL *.dockup.tech existante. Si l’application échoue à cette étape, l’ajout d’un domaine ne la réparera pas. Commencez par examiner les logs d’exécution.

Rassemblez les informations suivantes :

Élément	Exemple	Pourquoi c’est important
Cible exacte	production/web	Évite d’associer le domaine au mauvais service
Hostname	app.example.com	Le nom DNS que les utilisateurs visiteront
Accès DNS	Registrar ou fournisseur DNS	Nécessaire pour créer l’enregistrement
TTL actuel	300 secondes	Contrôle la vitesse de propagation et de rollback
URL canonique de l’application	https://app.example.com	Peut avoir un impact sur les redirections et les cookies
Route de health check	/health	Confirme que le service est prêt avant la bascule

Réduisez à l’avance le TTL DNS existant lorsque vous remplacez un fournisseur actif. Ne supprimez pas l’ancien enregistrement tant que la cible Dockup, la configuration de l’application et le plan de rollback ne sont pas définis.

Examinez le comportement de l’application qui dépend du host. Les callbacks d’authentification, les listes d’autorisation CORS, les domaines de cookies, les URLs de redirection OAuth, les destinations des webhooks et les liens absolus générés peuvent nécessiter le nouveau hostname HTTPS.

Comment ajouter et vérifier le domaine ?

Commencez par lister les domaines actuels :

dockup domain list production/web --json

Ajoutez le hostname :

dockup domain add app.example.com production/web --json

La réponse fournit la cible DNS à configurer. Créez l’enregistrement CNAME indiqué chez le fournisseur DNS. N’inventez pas d’adresse IP et ne copiez pas une valeur provenant d’un autre service ; utilisez la cible renvoyée pour ce domaine.

Une fois la propagation DNS terminée, vérifiez le domaine avec l’identifiant renvoyé :

dockup domain verify <domainId> production/web --json

La vérification confirme que l’enregistrement DNS public se résout comme prévu. Un échec s’explique généralement par l’une des quatre causes suivantes :

1. Le nom de l’enregistrement est incorrect.
2. La cible CNAME est incorrecte.
3. Un ancien enregistrement A, AAAA ou CNAME en conflit existe toujours.
4. Les caches des résolveurs n’ont pas encore pris en compte la nouvelle valeur.

Vérifiez le DNS faisant autorité au lieu de supprimer puis de recréer le domaine à répétition. La propagation est un processus de cache distribué, et non un processus de build Dockup.

Comment le certificat HTTPS est-il émis et géré ?

Une fois la vérification réussie, demandez le certificat :

dockup domain ssl <domainId> production/web --json

Dockup gère l’émission du certificat pour le hostname vérifié et sert le domaine personnalisé en HTTPS. La plateforme prend en charge le cycle de vie du TLS ; le container de l’application n’a donc pas besoin de stocker des fichiers de certificat ni d’exécuter un processus de renouvellement.

Validez le résultat depuis l’extérieur de la plateforme :

curl -I https://app.example.com

Vérifiez que :

• Le certificat correspond au hostname.
• La réponse est bien servie en HTTPS.
• Les redirections ne forment pas de boucle.
• L’application renvoie le statut attendu.
• Les flux d’authentification et les callbacks utilisent la nouvelle origin.
• Les ressources statiques se chargent sans erreurs de contenu mixte.

L’émission du certificat peut échouer même lorsque l’application elle-même est saine. Gardez les diagnostics DNS et service séparés. Utilisez domain verify pour la propriété DNS et les logs du service pour le comportement de l’application.

L’article déploiements zero-downtime explique le contrôle indépendant de readiness d’une release.

Comment basculer le trafic sans interruption ?

Une bascule sûre conserve l’ancien chemin disponible jusqu’à ce que le nouveau hostname soit validé.

1. Déployez et vérifiez le service Dockup sur son URL de plateforme.
2. Ajoutez le domaine personnalisé dans Dockup.
3. Créez l’enregistrement DNS.
4. Vérifiez le DNS.
5. Émettez le certificat TLS.
6. Testez directement le HTTPS.
7. Mettez à jour les callbacks, les URLs canoniques et la supervision.
8. Envoyez une petite partie du trafic opérationnel si la configuration DNS le permet.
9. Surveillez les logs et la disponibilité.
10. Retirez l’ancien fournisseur uniquement lorsque le nouveau chemin est stable.

Les checks de disponibilité Dockup s’exécutent chaque minute et fournissent des statistiques de temps de réponse, notamment le p95 :

dockup uptime production/web --hours 24 --json

Conservez une supervision externe indépendante pour les domaines critiques. Une probe de plateforme confirme l’accessibilité publique, tandis qu’un monitor externe vérifie le parcours utilisateur depuis un autre système.

Si le domaine personnalisé remplace un hostname de production actuel, conservez une trace de rollback : valeur DNS précédente, TTL précédent, statut de l’ancien fournisseur et condition déclenchant le retour en arrière.

Comment fonctionnent les domaines associés à des ports supplémentaires ?

Un service peut exposer un second port HTTP pour une interface d’administration, un endpoint de métriques ou un autre processus web. Dockup peut créer un domaine de plateforme supplémentaire sans DNS personnalisé :

dockup port list production/web --json
dockup port add 8080 production/web --name admin --json

Le domaine renvoyé dirige le trafic vers le port du container sélectionné. Il est distinct du domaine personnalisé principal.

N’exposez pas un port simplement parce qu’un processus est en écoute. Demandez-vous si l’endpoint dispose d’une authentification, s’il contient des données de production et s’il doit réellement être public. Une interface d’administration interne ne doit pas devenir accessible depuis Internet par simple commodité.

Supprimez un domaine de port obsolète via l’interface de domaine prise en charge uniquement après avoir vérifié qu’aucun monitor, callback ou workflow opérateur ne l’utilise encore. Les changements de domaines de port sont des mutations et apparaissent dans l’audit log.

Comment résoudre les erreurs DNS, TLS et applicatives ?

Utilisez un diagnostic couche par couche :

Symptôme	Première vérification	Commande Dockup
Le domaine ne se résout pas	Enregistrement DNS et propagation	domain verify
Le certificat n’est pas émis	Statut de vérification du domaine	domain list, domain ssl
Le HTTPS fonctionne, mais l’application renvoie une erreur	Logs d’exécution	logs --json
Boucle de redirection	Configuration du proxy/host de l’application	env list, logs d’exécution
L’URL de plateforme fonctionne, mais pas le hostname personnalisé	Couche DNS/TLS	Commandes de domaine
Les deux URLs échouent	Déploiement et exécution	status, logs de build/exécution
Le port secondaire échoue	Association domaine-port et processus	port list, logs d’exécution

Examinez la sortie du service sans la mélanger avec les conclusions DNS :

dockup logs production/web --json
dockup status production/web --json

Si une modification récente de l’environnement a ajouté l’URL canonique, n’oubliez pas qu’elle nécessite un redeploy :

dockup env set APP_URL=https://app.example.com \
  -s production/web \
  --json

dockup deploy production/web --wait --json

Le guide des variables d’environnement et des secrets détaille ce cycle de vie.

Suppression du domaine et rollback

La suppression de l’association Dockup est destructive pour la route. Commencez donc par déplacer ou supprimer l’enregistrement DNS public et confirmez le remplacement prévu. Supprimez ensuite l’association via l’interface de domaine prise en charge, en utilisant l’identifiant exact du domaine.

Ne supprimez pas le domaine pendant un incident temporaire lié au certificat ou à la propagation, sauf si le plan de reprise l’exige. Conserver la configuration en place permet à la vérification de réussir lorsque les caches sont mis à jour.

Examinez les mutations avec :

dockup audit --search domains --json

L’audit trail doit indiquer qui a ajouté, vérifié, sécurisé ou supprimé le hostname.

Checklist de passation pour la production

Une passation complète d’un domaine personnalisé et du TLS automatique comprend la cible du service, le hostname, l’identifiant du domaine, le type et la cible de l’enregistrement DNS, le résultat de la vérification, le résultat de l’émission du certificat, les changements apportés aux callbacks de l’application, l’URL de monitoring et la valeur DNS de rollback.

Ne stockez aucune clé privée de certificat dans le repository ou le container. La limite de responsabilité du TLS géré par Dockup existe précisément pour que l’équipe applicative puisse gérer le hostname sans distribuer de matériel de certificat.

Pour connaître tous les flags actuels, consultez la référence de la CLI Dockup. Pour le déploiement initial avant la configuration du domaine, suivez Du repository Git à la production.

Planifier les choix entre apex et sous-domaine

Un sous-domaine tel que app.example.com est généralement le hostname applicatif le plus simple, car les fournisseurs DNS peuvent le représenter avec un CNAME. Un apex tel que example.com peut nécessiter un mécanisme de flattening ou d’alias propre au fournisseur. Suivez la cible DNS renvoyée par Dockup ainsi que les fonctionnalités du fournisseur DNS faisant autorité.

Choisissez un hostname canonique et redirigez les variantes au niveau de l’application ou du routage. Servir www et l’apex sans politique canonique peut fragmenter les cookies, les analytics, les entrées de cache et l’indexation par les moteurs de recherche.

Tester les hypothèses liées au renouvellement du certificat

Le TLS géré évite d’exécuter un client de renouvellement dans le container, mais le hostname doit continuer à se résoudre correctement. Une migration DNS ultérieure, une modification du proxy ou la suppression d’un enregistrement peut interrompre la validation.

Incluez le statut du domaine dans les revues courantes :

dockup domain list production/web --json
dockup uptime production/web --hours 24 --json

Le runbook domaine personnalisé et TLS automatique doit indiquer le responsable DNS, le contact chargé du renouvellement et la date du dernier contrôle externe du certificat. Vous éviterez ainsi de rechercher le responsable uniquement lorsqu’un incident de certificat survient.

Protéger les hostnames hors production

Les hostnames de staging et de preview peuvent exposer des fonctionnalités inachevées et des données ressemblant à celles de la production. Utilisez l’authentification applicative lorsque nécessaire, définissez une politique d’indexation au niveau de l’application et limitez la diffusion des URLs hors production.

Les directives destinées aux moteurs de recherche ne constituent pas un contrôle d’accès. Un environnement protégé nécessite toujours une authentification et une gestion appropriée des données.

Revérifier après la propagation

Répétez les tests HTTPS externes et les tests de callbacks une fois le TTL DNS initial entièrement écoulé.

Commencer par un déploiement vérifiable

Associez d’abord un hostname non critique, conservez l’URL de plateforme pendant la propagation et notez la valeur DNS exacte nécessaire au rollback.

Commencez gratuitement sur app.dockup.ai. Le forfait Free coûte 0 $ par mois, inclut un crédit initial de 10 $ et prend en charge un workspace, trois bases de données et trois déploiements.

FAQ

De quel enregistrement DNS un domaine personnalisé Dockup a-t-il besoin ?

Exécutez dockup domain add et créez l’enregistrement DNS indiqué dans sa réponse. Utilisez la cible renvoyée plutôt que de copier une valeur provenant d’un autre service.

Quand Dockup peut-il émettre un certificat TLS pour un domaine personnalisé ?

Une fois que l’enregistrement DNS du hostname a passé la vérification de domaine Dockup, demandez l’émission du certificat avec la commande domain ssl documentée.

Mon container doit-il stocker des certificats TLS ?

Non. Dockup gère le TLS pour le domaine personnalisé vérifié ; le container de l’application n’a donc besoin ni de fichiers de certificat ni d’un processus de renouvellement.

Dockup peut-il exposer un port de container supplémentaire ?

Oui. Les commandes de port peuvent créer un domaine distinct généré automatiquement pour un port public supplémentaire, sans nécessiter de DNS personnalisé.

Que dois-je vérifier lorsque l’URL de plateforme fonctionne, mais pas le domaine personnalisé ?

Concentrez-vous sur les enregistrements DNS, la propagation, la vérification du domaine et le statut du certificat. L’URL de plateforme fonctionnelle indique que la couche applicative fonctionne probablement.