Comment configurer un service Web pas encore chiffré dans le Cloud ?
Toujours une histoire
Remarque
(TL;DR)^(-1)
J’ai eu quelques pertes d’accès à Internet chez moi.
Vu que je ne suis pas tout le temps à la maison,
je prends plus ou moins de temps à m’en rendre compte :
quand je consulte Home Assistant ou que je rentre chez moi…
J’utilise toujours Nagios pour superviser mes équipements (dont mon serveur dans le cloud) mais comme le serveur est chez moi derrière la Box… 😑
Il fallait donc que je trouve un moyen simple de tester si j’ai Internet.
Partant du principe que si j’arrive à attaquer une ressource de chez moi
depuis l’extérieur, c’est que j’ai toujours une connectivité vers l’extérieur.
J’ai donc décidé de mettre en place Uptime Kuma pour cela car c’est assez simple à configurer et que, comme à mon habitude, ce service fonctionne avec Gotify.
Pour utiliser ce service avec un reverse proxy, il faut l’activer dans
les paramètres. Pour accéder aux paramètres, c’est via l’interface Web… 😒
Déployant mon service dans le Cloud, je ne voulais pas faire la configuration
(créer un utilisateur, un mot de passe et autoriser le reverse proxy)
de manière transparente pour Internet (en clair quoi !).
J’ai testé la méthode du tunnel SSH avec de la configuration sur
le fichier Docker Compose et c’est ce que je vais vous partager ici.
Uptime Kuma en HTTP local
version: '3.8'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: always
volumes:
- /var/lib/uptime-kuma:/app/data
ports:
- 127.0.0.1:3002:3001
La configuration du port veut dire que le port interne du conteneur (3001) est mappé sur le port 3002 de la machine hôte (mon serveur). Cette dernière n’est ouverte que sur l’interface de loopback.
De ce fait, seule la machine est capable de communiquer avec ce service.
Mon serveur n’ayant pas de GUI, je ne peux aller sur http://localhost:3002
pour effectuer la configuration.
Information
Ici, j’utilise le port 3002 afin que vous compreniez bien de quel port je parle.
En réalité, j’ai mappé le port 3001 du conteneur sur le 3001 de mon serveur.
Tunnel SSH
Pour pouvoir atteindre mon interface Web, je vais utiliser un tunnel SSH.
Le SSH me permettant “d’être sur mon serveur”, je peux faire en sorte de
rediriger le trafic de ma machine vers mon serveur.
Pour comprendre, le plus simple, c’est de partir de la solution.
Sur une VM Desktop Ubuntu, j’entre la commande suivante dans un terminal :
ssh user@mycloudserver.example.com -L 8080:localhost:3002 -N
Cette commande crée une connexion SSH vers mycloudserver.example.com
avec
la particularité suivante :
Tous ce que j’exécute sur le port
8080
de mon PC (localhost
) se retrouve redirigé sur le port3002
de mon serveur.
Du coup, en ouvrant un page Web vers http://localhost:8080, je me retrouve sur l’interface Web d’Uptime Kuma !
Uptime Kuma en HTTPs
Une fois le proxy autorisé, je peux couper mon tunnel avec un Ctrl+C
dans le terminal et down mon conteneur avec un docker compose down
.
Ainsi, j’édite la configuration de mon conteneur afin d’utiliser Traefik, mon reverse proxy :
version: '3.8'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: always
volumes:
- /var/lib/uptime-kuma:/app/data
#ports:
# - 3001:3001
labels:
- "traefik.enable=true"
- "traefik.http.routers.uptime-kuma.rule=Host(`uptimekuma.example.com`)"
- "traefik.http.routers.uptime-kuma.tls=true"
- "traefik.http.routers.uptime-kuma.tls.certresolver=mycertresolver"
- "traefik.http.services.uptime-kuma.loadBalancer.server.port=3001"
networks:
- kuma-net
networks:
kuma-net:
external: true
name: traefik-net
Et un coup de docker compose up -d
et le tour est joué !
Et maintenant ?
Maintenant que mes services sont supervisés, j’ai enfin de quoi être avertis d’un souci sur ma connexion.
Ce qui n’a pas été mis en évidence ici, c’est que j’ai utilisé Ansible pour le déploiement et plusieurs Docker Compose pour ne pas réécrire mon fichier. J’expliquerais cela dans d’autres articles. 😉