Niveau 🟡 intermédiaire
Durée estimée : 20 min · Prérequis : Fiche service : Portainer
Uptime Kuma, c'est une équipe de veille qui appelle chaque service à intervalle régulier pour
vérifier qu'il répond toujours, et qui prévient dès qu'un appel reste sans réponse. Contrairement
Ă toi qui remarquerais une panne en tentant d'utiliser le service, cette veille tourne en
continu, mĂŞme quand personne ne regarde.
Ce qu'Uptime Kuma apporte : une interface web pour créer des moniteurs — des vérifications
périodiques (HTTP, TCP, ping, et d'autres types) qui contrôlent qu'un service répond toujours,
avec un historique de disponibilité et des alertes configurables en cas de panne détectée.
Le piège central de cette fiche : un conteneur n'est pas la machine qui l'héberge. Un moniteur
Uptime Kuma s'exécute depuis l'intérieur du conteneur, pas depuis la machine hôte — une
distinction qui semble abstraite jusqu'à ce qu'elle casse concrètement deux choses :
Piège 1 — la résolution .internal échoue. Si la résolution des noms .internal repose sur
le fichier /etc/hosts d'une machine cliente (vue en M2) plutĂ´t que sur
un vrai DNS local, un moniteur configuré avec un nom .internal échoue avec une erreur de
résolution — le conteneur Uptime Kuma n'a tout simplement pas accès à ce fichier, qui vit sur une
tout autre machine.
Piège 2 — le certificat n'est pas reconnu. Même en résolvant l'adresse autrement (par exemple
en surveillant directement le nom d'un conteneur cible sur un réseau Docker partagé, vu en
M2), un second problème peut survenir : le magasin de confiance
à l'intérieur du conteneur Uptime Kuma ne contient pas nécessairement l'autorité locale
mkcert installée sur les machines clientes — la vérification du certificat échoue alors, même si
le service surveillé fonctionne parfaitement pour un humain devant un navigateur.
La solution retenue face au piège 1 : surveiller les services par leur nom de conteneur
sur le réseau Docker partagé, plutôt que par leur nom .internal — une résolution qui fonctionne
nativement entre conteneurs (vue en M4),
sans dépendre d'un fichier /etc/hosts externe.
⚠️ Face au piège 2, une décision consciente, pas un contournement aveugle. Uptime Kuma
propose une option pour ignorer les erreurs de certificat TLS sur un moniteur précis. L'activer
sans réfléchir masquerait un vrai problème de sécurité sur un service exposé publiquement. Mais
quand le trafic entre le moniteur et le service surveillé reste entièrement interne à un
réseau Docker partagé — jamais visible depuis l'extérieur — le risque réel que cette option
couvre est nul : le compromis est assumé consciemment, service par service, jamais activé « par
défaut » sur l'ensemble des moniteurs.
🧪 Concrètement, sur notre exemple : quatre moniteurs surveillent aujourd'hui les services
principaux (reverse proxy, administration Docker, tableau de bord de supervision, accès SSH de
la machine). Chacun surveille sa cible par nom de conteneur sur le réseau partagé — sauf
l'accès SSH, vérifié directement en TCP sur le port dédié. L'option d'ignorer les erreurs de
certificat n'est cochée que sur le seul moniteur dont le certificat n'est pas signé par
l'autorité locale mkcert (un certificat auto-signé propre à un des services), et seulement
parce que ce trafic reste interne au réseau partagé — pas activée par défaut ailleurs.
Le conteneur Uptime Kuma vit dans son propre monde : ni le /etc/hosts d'une machine cliente, ni
son magasin de certificats de confiance ne lui sont automatiquement accessibles.
docker compose up -d
# DĂ©marre Uptime Kuma
docker exec uptime-kuma nslookup nom-du-conteneur
# Vérifie, DEPUIS L'INTÉRIEUR du conteneur, que le nom cible se
# résout -- confirme ou infirme le piège 1
docker exec uptime-kuma curl -vk https://nom-du-conteneur:port
# Teste la connexion HTTPS depuis le conteneur -- -k ignore
# volontairement l'erreur de certificat pour ce test de diagnostic,
# afin d'isoler s'il s'agit bien du piège 2
Dans l'interface Uptime Kuma, chaque moniteur configuré doit afficher un statut « Up » (vert)
après quelques cycles de vérification. Un statut « Pending » ou « Down » persistant, avec une
erreur explicite dans le détail du moniteur, indique lequel des deux pièges de cette page est en
jeu.
| SymptĂ´me | Cause probable | Solution |
|---|---|---|
getaddrinfo ENOTFOUND sur un moniteur configuré avec un nom .internal |
Le conteneur Uptime Kuma n'a pas accès au /etc/hosts d'une machine cliente |
Surveiller par nom de conteneur sur le réseau Docker partagé plutôt que par nom .internal |
unable to verify the first certificate sur un moniteur HTTPS pourtant fonctionnel dans un navigateur |
Le magasin de confiance du conteneur ne connaît pas l'autorité locale, ou le certificat cible est auto-signé | Vérifier au cas par cas si le trafic reste interne (option « ignorer » assumée) ou s'il faut propager l'autorité locale dans le conteneur |
| Option « ignorer les erreurs de certificat » cochée par défaut sur tous les moniteurs | Contournement du piège 2 sans distinction du contexte | Réserver cette option aux seuls moniteurs dont le trafic reste strictement interne, jamais comme réglage global |
.internal.Parce que la résolution .internal repose sur le fichier /etc/hosts de la machine cliente, que
le conteneur Uptime Kuma n'a jamais eu accès — il vit dans un environnement isolé, sans ce
fichier.
Surveiller le service par le nom de son conteneur sur le réseau Docker partagé, une résolution
qui fonctionne nativement entre conteneurs, sans dépendre d'un fichier externe au conteneur
surveillant.
Quand le trafic entre le moniteur et le service surveillé reste entièrement interne à un réseau
non exposé publiquement — jamais comme réglage par défaut sur l'ensemble des moniteurs.
Sur une machine avec Docker, déploie Uptime Kuma et un service HTTPS local de test avec un
certificat non reconnu. Crée un moniteur pointant vers ce service par son nom de conteneur, puis
observe l'erreur de certificat et décide, en justifiant ta réponse, s'il est raisonnable de
l'ignorer sur ce moniteur précis.
moniteur ·
magasin de confiance
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.