Sommaire

Configurer un service dans le Cloud sans HTTPS

Toujours une histoire

(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 a 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écider 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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
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.

Info
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 :

1
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 port 3002 de mon serveur.

Du coup, en ouvrant un page Web vers http://localhost:8080, je me retrouve sur l’interface Web d’Uptime Kuma !

/2022/10-24-config-cloud-service-without-https/img/Screenshot_1.webp
Interface Web via tunnel SSH

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.

/2022/10-24-config-cloud-service-without-https/img/Screenshot_2.webp
Autorisation d’utiliser un Reverse Proxy

Ainsi, j’édite la configuration de mon conteneur afin d’utiliser Traefik, mon reverse proxy :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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. 😉