Récemment, j'ai migré Peef vers un nouvel hébergeur afin de résoudre un problème de DNS. En effet, l'adresse www.peef.dev fonctionnait correctement et possédait un certificat SSL. Pourtant, lorsque les visiteurs essayaient de se connecter en utilisant l'adresse peef.dev, les navigateurs renvoyaient une erreur SSL. Malheureusement, j'étais confronté à une limitation de mon ancien hébergeur qui ne me permettait pas de modifier les configurations de mon serveur HTTP ni d'obtenir mon propre certificat SSL. Cette contrainte m'a poussée à rechercher une solution alternative. C'est pourquoi j'ai décidé de migrer vers un autre hébergeur qui me proposait un VPS que je pouvais gérer moi-même. Dans cet article, je vais vous expliquer les trois étapes que j'ai suivies pour effectuer cette migration en utilisant Nginx, Docker, Certbot et Let's Encrypt.

J’ai commencé par préparer un environnement Docker intégrant Nginx comme serveur HTTP

La première étape consistait à ajouter un environnement Docker et un serveur HTTP pour le serveur de production. Mon ancien hébergeur ne me permettait pas de déployer Peef en utilisant Docker ; je devais plutôt faire l’installation dans un environnement virtuel utilisant virtualenv et connecter l’application au serveur de base de données. Docker était utilisé uniquement pendant les dev sur mon PC. Si vous voulez comprendre les bases de docker ou savoir ce que c'est, je vous invite sur cet article que j'ai rédigé il y a quelque temps.

Pour créer ce nouvel environnement avec Docker et Nginx, j'ai effectué une recherche sur Google et suis tombé sur un article très utile de testdriven.io qui expliquait comment le faire, tout en fournissant un repo sur GitHub. J'ai utilisé ce repo comme point de départ pour obtenir l'environnement que j'utilise aujourd'hui : un environnement de dev sur mon PC et un environnement de prod intégrant Nginx comme serveur HTTP et Gunicorn pour démarrer l'application. J’étais très content.

Ensuite, j’ai créé mon VPS

Après avoir effectué la migration et réalisé plusieurs tests pour garantir le bon fonctionnement de tous les aspects, tels que la migration de la base de données, la mise à jour des tables, les sauvegardes et les restaurations, ainsi que les fichiers médias tels que les photos de profil, j'ai décidé de prendre un VPS chez mon nouvel hébergeur. Pendant ces tests, j'ai vraiment compris l'importance des CDN pour les fichiers médias ou statiques, ainsi que la nécessité d'avoir une tâche de sauvegarde automatique des données.

Ensuite, j'ai migré l'application vers mon VPS et j'ai effectué des tests pour restaurer les données de la base de données et les fichiers médias. Si tout se passait bien, j'étais prêt à modifier mes enregistrements DNS, ce que j'ai finalement fait. J'étais prêt à continuer, mais un événement imprévu est survenu et m'a ouvert les yeux sur une réalité inattendue.

Tout d'abord, j'ai effectué des modifications au niveau des serveurs de noms chez mon registrar de nom de domaine afin de les remplacer par ceux de mon nouvel hébergeur. Une fois cette opération terminée, j'ai attendu environ 4 heures pour que la propagation DNS soit complète. Pendant tout ce temps, j'ai surveillé attentivement le site DNS Checker, et comme vous pouvez l'imaginer, mon site n'était plus accessible sur mon ancien hébergeur. Une fois la propagation DNS terminée, le site était toujours inaccessible, malgré le fait que tout semblait parfait, à une exception près : j'utilise le domaine .dev, qui présente des particularités, comme vous allez le découvrir dans la suite.

J'ai essayé d'accéder au site en utilisant Chrome en mode navigation privée, Mozilla, Chrome sur Android, j'ai vidé le cache DNS sur mon Ubuntu, et j'ai même demandé de l'aide à ChatGPT, mais rien ne fonctionnait. Le site ne passait pas. J'ai alors effectué une nouvelle recherche sur Google et je suis tombé sur une question similaire dans le forum de DigitalOcean. La réponse était la suivante : par défaut, les domaines en .dev sont accessibles sur le port 443. Pour me rassurer que c’était vrai, je suis allé sur Mozilla et j’ai désactivé l’accès sécurisé en suivant les étapes décrites ici sur Stackoverflow. Après avoir désactivé ce paramètre de sécurité, Peef était parfaitement accessible.

J’avais trouvé la solution à mon problème. Il était donc absolument nécessaire que je génère un certificat SSL pour Peef.

Génération sur certificat SSL

Sincèrement, je ne savais pas par où commencer. Cependant, j'étais certain d'une chose : j'allais utiliser Let's Encrypt. Je me suis donc rendu sur le site de Let's Encrypt pour voir s'il y avait un tutoriel qui pourrait m'aider. Après avoir compris le fonctionnement, j'ai effectué une recherche sur Google afin de trouver un dépôt sur GitHub que je pourrais utiliser. J'ai lu cet article et suivi la procédure qui y était expliquée, mais malheureusement, je me suis retrouvé confronté au dilemme de l'œuf et de la poule, qui avait pourtant été clairement expliqué.

En résumé, après avoir ajouté un conteneur certbot dans mon fichier docker-compose.yml, il fallait démarrer l'application. Cependant, Nginx cherchait un certificat pour rediriger la connexion de HTTP vers HTTPS, ce qui posait problème, car le certificat n'était pas encore généré. En même temps, certbot cherchait un serveur Nginx pour générer le certificat, mais cela échouait également car le conteneur Nginx s'arrêtait peu de temps après le démarrage.

J'ai alors ajouté le script présent dans l'article que je suivais. Son principe était de générer un faux certificat pour lancer Nginx, puis une fois que Nginx était lancé, certbot prenait le relais pour générer le certificat réel. Malheureusement, toutes mes tentatives ont échoué car, pour une raison inconnue, Nginx ne trouvait pas le certificat. Le fichier challenge généré par certbot était immédiatement supprimé, rendant ainsi impossible la vérification du certificat.

Face à ce problème, j'ai pensé qu'IL SERAIT PLUS SIMPLE DE GÉNÉRER LE CERTIFICAT SSL SUR LA MACHINE HÔTE ET DE LE LIER EN MONTANT UN VOLUME SUR MON CONTENEUR NGINX. J'ai effectivement procédé de cette manière et tout s'est bien passé.

Voici en résumé les commandes que j’ai utilisées pour installer le certificat SSL sur mon VPS Ubuntu.

1. Accès SSH au serveur et installation de snapd

ssh user@addresse.ip.serveur

# Installation du gestionnaire de paquet snapd

sudo apt update
sudo apt install snapd

# S’assurer que snapd est à jour

sudo snap install core; sudo snap refresh core

2. Installation de certbot et nginx

sudo snap install --classic certbot

# S’assurer que cetrbot va s’exécuter en ligne de commande

sudo ln -s /snap/bin/certbot /usr/bin/certbot

# Installer Nginx

sudo apt install nginx

3. Générer le certificat pour les 2 domaines. Il faut aussi vous rassurer que les enregistrements DNS sur exemple.com et www.exemple.com existent

certbot certonly --nginx -d exemple.com -d www.exemple.com

# Une fois le certificat installé sur la machine hôte, il faut monter le volume sur le docker-compose.yml comme suis

nginx:
    build: ./nginx
    volumes:
      - /etc/letsencrypt:/etc/letsencrypt
    ports:
      - 80:80
      - 443:443
    depends_on:
      - web_app
    restart: unless-stopped

# Configurer Nginx comme dans cet exemple

…

server {
    listen 80;
    server_name exemple.com www.exemple.com;
    return 301 https://exemple.com$request_uri;
}

server {
    listen 443 ssl;
    server_name exemple.com;

    ssl_certificate /etc/letsencrypt/live/exemple.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemple.com/privkey.pem;

    …

    }

server {
    listen 443 ssl;
    server_name www.exemple.com;

    ssl_certificate /etc/letsencrypt/live/exemple.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemple.com/privkey.pem;

    return 301 https://exemple.com$request_uri;
}

Enfin, l'application était accessible sur peef.dev avec un certificat SSL valide. Comme je voulais que www.peef.dev ait aussi son certificat, j’ai ajouté dans mes config Nginx un compartiment server pour ce domaine et régénéré le certificat pour les 2 domaines peef.dev et www.peef.dev

C’est ainsi que s’achève mon histoire palpitante de la migration de Peef. Je suis impatient de vous retrouver bientôt. Si vous avez des questions et commentaires, n’hésitez surtout pas à les partager dans les commentaires.

Peef vous permet de développer votre potentiel : connectez-vous, collaborez, créez votre cluster et vendez vos produits et services

3 étapes simples que j’ai suivie pour configurer HTTPS avec Nginx et Docker