Remarque: il s'agit d'une traduction de mon article (en anglais), décrivant la mise en œuvre du serveur de commentaires utilisé sur le même site où se trouve l'original.
Version TL; DR: J'ai développé la configuration du serveur Commento, qui se déploie facilement et simplement en mode semi-automatique. Copiez ce référentiel à partir de GitHub et suivez les instructions du fichier README .
Il y a quelque temps, je voulais irrésistiblement changer Disqus - qui est peut-être le système le plus courant pour ajouter des commentaires aux pages - en un Commento gratuit et ouvert.
Le problème avec Disqus, comme beaucoup d'autres produits "gratuits", c'est que le produit dans ce cas est l'utilisateur - c'est-à-dire vous. De plus, Disqus «enrichit» chaque page où il est utilisé avec des mégaoctets de scripts et plus d'une centaine de requêtes HTTP supplémentaires.
De plus, sa version gratuite affiche des publicités à partir desquelles vous pouvez payer "seulement" pour 9 $ par mois (plan Plus). Cela suffit à lui seul pour vouloir trouver quelque chose de mieux.
À un moment donné, je suis tombé sur ce post et j'ai découvert l'existence d'un serveur de commentaires gratuit appelé Commento . Par une heureuse coïncidence, Commento est récemment devenu complètement ouvert - avant qu'il ne soit disponible en deux versions, Communauté gratuite et Entreprise commerciale. Merci à son développeur Adhityaa Chandrasekar.
Commento est des ordres de grandeur plus efficaces que Disqus, la taille typique de la charge supplémentaire est d'environ 11 Ko , plus les commentaires eux-mêmes, bien sûr. Environ la même situation avec les requêtes HTTP requises.
Un autre avantage du serveur Commento est qu'il est très rapide, car il est écrit en Go.
Eh bien, cerise sur le gâteau, il a une importation de commentaires de Disqus, de quoi d'autre pourrait-il rêver?
Pour les utilisateurs non avancés (techniquement), Commento dispose d'un service cloud prêt à l'emploi sur commento.io . L'auteur vous propose de choisir vous-même le tarif mensuel, mais il ne peut être inférieur à 3 $ "pour des raisons techniques".
M. Chandrasekar offre également généreusement un compte gratuit sur Commento.io en échange de «correctifs non triviaux» pour le produit.
Eh bien, j'ai choisi la troisième option: augmenter moi-même le serveur Commento. Dans ce cas, vous ne dépendez de personne (à part l'hébergeur, bien sûr), et j'aime l'indépendance.
Des difficultés
Je suis un grand fan des conteneurs Docker et j'utilise aussi souvent Docker Compose , un outil pour gérer des groupes de plusieurs conteneurs associés. Commento a une image Docker prête à l'emploi dans le registre des conteneurs GitLab.
Par conséquent, la décision d'utiliser des conteneurs a mûri par elle-même - mais d'abord quelques choses ont dû être décidées.
Difficulté n ° 1: PostgreSQL
Commento nécessite une version assez récente du serveur PostgreSQL, malheureusement aucun autre serveur SQL n'est pris en charge.
Eh bien, nous exécutons toujours tout dans des conteneurs, c'est donc assez simple.
Difficulté n ° 2: pas de support HTTPS
Commento lui-même est un serveur Web, mais il ne prend en charge que le protocole HTTP non sécurisé.
Il convient de noter que cette pratique est assez courante de nos jours: dans ce cas, le serveur est caché derrière le proxy inverse , qui effectue également le déchargement SSL. Le fait est que le support SSL / HTTPS est absolument nécessaire dans ce cas, après tout, dans la cour 2019 et examiner les tentatives d'autorisation d'un utilisateur à l'aide d'un protocole Internet non sécurisé sera très ironique.
J'ai décidé d'utiliser le serveur Nginx , d'une part, j'avais une grande expérience de travail avec lui, et d'autre part, il est très rapide, économique et stable. Et publie les versions officielles des images Docker .
Le deuxième ingrédient de la recette HTTPS est le certificat SSL du domaine. Je suis éternellement reconnaissant à EFF et Mozilla d'avoir créé l' Autorité de certification Let's Encrypt , qui émet des millions de certificats gratuits chaque mois.
Let's Encrypt fournit également un utilitaire de ligne de commande gratuit appelé certbot , qui simplifie considérablement le processus d'obtention et de mise à jour d'un certificat. Eh bien, et - bien sûr - une image Docker pour lui!
Difficulté n ° 3: Problème d'oeufs de poulet Certbot
Mais cette astuce est plus délicate.
Nous voulons faire référence au certificat SSL dans la configuration de notre proxy inverse sur Nginx, ce qui signifie que sans certificat, il refuse simplement de démarrer. Dans le même temps, pour obtenir un certificat SSL pour un domaine, vous avez besoin d'un serveur HTTP fonctionnel, qui Let's Encrypt prouvera votre propriété de ce domaine.
J'ai réussi à résoudre ce problème et, il me semble, assez élégamment:
- Tout d'abord, un certificat factice non valide est généré, dont le seul but est de laisser Nginx démarrer.
- Nginx et certbot reçoivent conjointement un nouveau certificat, désormais valide.
- Dès réception du certificat, certbot passe en «mode veille», se réveillant toutes les 12 heures pour vérifier s'il doit être mis à jour - selon les recommandations de Let's Encrypt.
- Lorsque le moment est venu et que le certificat a été renouvelé, certbot signalera à Nginx de redémarrer.
Difficulté n ° 4: quelque chose doit être préservé
Je soupçonne fortement que vous souhaitez que les commentaires des utilisateurs soient enregistrés après un redémarrage ou une mise à jour du système.
De plus, afin que Let's Encrypt ne vous interdise pas en raison de demandes trop fréquentes, il serait bon de conserver les certificats reçus pour toute la date d'expiration.
Les deux points ont été résolus dans la configuration proposée en utilisant les volumes du Docker, créés automatiquement par systemd lors du premier lancement de Commento. Les volumes sont marqués comme external , donc Docker les ignore lors de la suppression des conteneurs à l'aide de docker-compose down -v .
Rassemblez tout
Vous pouvez maintenant voir comment tout cela fonctionne ensemble.
La figure ci-dessous montre l'interaction et le trafic entre les quatre conteneurs:
J'ai appliqué l'option depends_on Docker Compose depends_on pour garantir que les conteneurs démarrent dans le bon ordre.
Si vous souhaitez uniquement démarrer votre propre serveur Commento, vous pouvez ignorer le reste de l'article et accéder directement au code sur GitHub .
Eh bien, je parlerai plus en détail de cette implémentation plus tard.
Comment ça marche
Composer un fichier
Comme vous pouvez le voir sur l'image ci-dessus, ma «composition» se compose de quatre services:
certbot - utilitaire certbot d'EFFnginx - proxy inverse implémentant le déchargement SSLapp - serveur Commentopostgres - Base de données PostgreSQL
Le docker-compose.yml contient des déclarations de son propre réseau Docker, appelé commento_network , et trois volumes, dont deux externes (c'est-à-dire qu'ils doivent être créés en dehors de Compose):
commento_postgres_volume stocke les données du serveur PostgreSQL pour Commento: utilisateurs, modérateurs, commentaires, etc.certbot_etc_volume contient les certificats reçus par certbot .
Nginx
Le conteneur Nginx est basé sur une image officielle légère basée sur Alpine et utilise le script suivant pour s'exécuter:
- Ligne 3 ( ARRGHHH, Habr ne prend pas en charge l'affichage des numéros de ligne dans le code - environ la traduction ) . Un gestionnaire d'interruption est enregistré afin que Nginx et le processus de surveillance en arrière-plan terminent avec succès le travail lorsque le conteneur s'arrête.
- La ligne 27 appelle la fonction d'attente, qui suspend le processus de démarrage de Nginx jusqu'à ce que les fichiers de configuration SSL créés par le conteneur
certbot . Sans cela, Nginx refuserait de commencer. - La ligne 30 crée un processus d'arrière-plan qui vérifie régulièrement, toutes les dix secondes, la présence d'un fichier indicateur avec le nom
.nginx-reload , et dès qu'il le détecte, demande à Nginx de recharger la configuration. Ce fichier crée également certbot lorsque le certificat est mis à jour. - La ligne 34 démarre Nginx en mode normal. Dans ce cas,
exec signifie que le processus shell actuel est remplacé par le processus Nginx.
Un autre fichier important de cette image est la configuration du serveur virtuel Commento, qui force Nginx à transmettre les requêtes HTTPS au conteneur commento :
server { listen [::]:443 ssl ipv6only=on; listen 443 ssl; server_tokens off; root /var/www/html; index index.html index.htm index.nginx-debian.html; server_name __DOMAIN__; location / { proxy_pass http://app:8080/; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } ssl_certificate /etc/letsencrypt/live/__DOMAIN__/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/__DOMAIN__/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; } server { listen 80 default_server; listen [::]:80 default_server; server_tokens off; server_name __DOMAIN__; location /.well-known/acme-challenge/ { root /var/www/certbot; }
Le premier bloc serveur (lignes 1-21 ) décrit comment travailler avec HTTPS et la règle de transfert. C'est là que les fichiers de certificat Let's Encrypt sont mentionnés (ou les talons utilisés à la place).
Le domaine servi par le serveur est passé en argument lors de la construction de l'image; il remplace la ligne __DOMAIN__ dans la configuration du serveur.
Le deuxième bloc (lignes 23-38 ) est la configuration du serveur HTTP, qui est utilisé par le certbot pour confirmer la propriété du domaine (le soi-disant «défi ACME»). Toutes les autres demandes entraînent une redirection vers l'adresse correspondante via HTTPS.
certbot
Notre image certbot est basée sur la version officielle avec le script suivant:
Un bref tour d'horizon de ses lignes:
- La ligne 3 , comme dans le script précédent, est requise pour l'achèvement régulier du conteneur.
- Les lignes 17-19 vérifient les variables requises.
- Et dans les lignes 22-25 - que les répertoires nécessaires au fonctionnement de certbot sont montés correctement.
- La fourche suit:
- Les lignes 30-50 sont exécutées uniquement au premier démarrage du conteneur:
- Un certificat factice est copié, permettant à Nginx de démarrer normalement.
- Nginx, quant à lui, attend la fin de ce processus, après quoi il continue de se télécharger.
- Une fois Nginx démarré, certbot lance le processus d'obtention d'un certificat valide auprès de Let's Encrypt.
- Et enfin, dès que le certificat est reçu, le fichier
.nginx-reload est créé, .nginx-reload entendre à Nginx qu'il est temps de recharger la configuration.
- La ligne 54 attend le démarrage de Nginx - dans le cas où un certificat complet est déjà disponible.
- Après tout cela (lignes 58-63 ), il continue de faire du vélo, une fois toutes les 12 heures vérifiant la nécessité de renouveler le certificat et signalant à Nginx de redémarrer.
L' app et les conteneurs postgres utilisent les images originales fournies par les développeurs sans aucune modification.
Service Systemd
La dernière pièce de ce puzzle est le fichier d'unité systemd commento.service , sur lequel vous devez créer un lien symbolique dans /etc/systemd/system/commento.service pour qu'il démarre au bon moment au démarrage du système:
[Unit] Description=Commento server [Service] TimeoutStopSec=30 WorkingDirectory=/opt/commento ExecStartPre=-/usr/bin/docker volume create commento_postgres_volume ExecStartPre=-/usr/bin/docker volume create certbot_etc_volume ExecStartPre=-/usr/local/bin/docker-compose -p commento down -v ExecStart=/usr/local/bin/docker-compose -p commento up --abort-on-container-exit ExecStop=/usr/local/bin/docker-compose -p commento down -v [Install] WantedBy=multi-user.target
Rangées:
- La ligne 6 implique que le code du projet est cloné dans le répertoire
/opt/commento - c'est beaucoup plus simple. - Les lignes 7 à 8 créent des volumes externes, s'ils ne le sont pas déjà.
- À la ligne 9 , les restes éventuels des conteneurs précédents sont supprimés. Les volumes extérieurs sont conservés.
- La ligne 10 marque le lancement réel de Docker Compose. L'
--abort-on-container-exit tout le troupeau de conteneurs lorsque l'un d'eux est --abort-on-container-exit . Grâce à cela, systemd sera au moins conscient que le service est arrêté. - La ligne 11 nettoie et supprime à nouveau les conteneurs, les réseaux et les volumes.
Code source
Une implémentation pleinement fonctionnelle, ne nécessitant que la configuration des variables dans docker-compose.yml , est disponible sur GitHub . Il vous suffit de suivre attentivement les étapes décrites dans le fichier README .
Le code est soumis à la licence MIT .
Merci d'avoir lu cet endroit, les commentaires sont frénétiquement les bienvenus!