zestedesavoir / ansible-zestedesavoir

Script Ansible pour déployer Zeste de Savoir sur un serveur de production

Qu'est-ce que Zeste de Savoir ?

Zeste de Savoir est un site internet communautaire dédié au partage de la connaissance pour tous. Il est propulsé par le framework Django et Python 3.

Zeste de Savoir était à l'origine un fork de Progdupeupl (voir le dépôt Git).

Notre projet technique

Notre projet technique est constitué de plusieurs éléments :

• zds-site, le cœur du projet technique ;
• zmarkdown, notre moteur Markdown amélioré pour les besoins du site ;
• ansible-zestedesavoir, notre outil pour déployer Zeste de Savoir sur un serveur de production ;
• latex-template, notre gabarit LaTeX pour générer des fichiers PDF ;
• extensions-notificateurs, nos extensions de navigateur pour recevoir des notifications.

Contribuer à Zeste de Savoir

Notre documentation technique devrait vous être utile pour bien appréhender notre projet.

Merci de prendre connaissance du Code de Conduite de Contributeurs et de le respecter pour garder ce projet ouvert et accueillant !

Nous contacter

N'hésitez pas à discuter avec nous sur le forum Dev Zone de Zeste de Savoir ou sur le canal #dev-de-zds de notre Discord !

Installation

Cette procédure détaillée devrait vous permettre d'installer le projet en autonomie. Si vous rencontrez des difficultés, n'hésitez pas à nous contacter !

Conseils pour débuter

• Contribuer à Zeste de Savoir
• Workflow et détails pratiques
• Un mélange des deux

ansible-zestedesavoir's Issues

Utiliser Molecule pour tester le playbook ?

Molecule

• Il semble maintenu par la communauté d'Ansible et beaucoup mieux maintenu que kitchen-ansible
• Il a l'air d'être utilisable à la fois pour la CI et pour les essais en local, donc remplacerait Vagrant et Kitchen
• Il est écrit en Python donc pas besoin d'installer Ruby

Édition Après m'être renseigné un peu plus je ne sais pas si c'est fait pour tester un playbook entier, ça a l'air d'avoir été pensé pour tester des rôles Ansible surtout.

(11 janvier 2021) Vérifier que les nouveaux certificats sont bien issus avec le certificat DST Root X3

Extrait du billet Standing on Our Own Two Feet de Let's Encrypt

As of January 11, 2021, we’re planning to make a change to our API so that ACME clients will, by default, serve a certificate chain that leads to ISRG Root X1. However, it will also be possible to serve an alternate certificate chain for the same certificate that leads to DST Root X3 and offers broader compatibility. This is implemented via the ACME “alternate” link relation. This is supported by Certbot from version 1.6.0 onwards. If you use a different ACME client, please check your client’s documentation to see if the “alternate” link relation is supported.

Mettre à jour et documenter Munin-node

• Mettre à jour la configuration de Munin sur la bêta puis sur la prod
• Documenter cette documentation
• Si possible, ajouter un rôle Ansible

Utiliser la même version de zmarkdown que zds-site

Actuellement, il y a deux soucis :

• on utilise une version de pm2 installée globalement, ce qui fait qu'elle n'est pas mise à jour au fur et à mesure ;
• on installe zmarkdown avec un package.json utilisé dans ce dépôt au lieu d'utiliser celui de zds-site.

Il faut :

• supprimer ce bout de code
  

  ansible-zestedesavoir/roles/zmd/tasks/main.yml

  Lines 7 to 12 in b23a84a

  	- name: install pm2 globally
  	npm:
  	name: pm2
  	global: yes
  	tags:
  	- bootstrap

• remplacer /usr/lib/node_modules/pm2/bin/pm2 par /opt/zmd/node_modules/pm2/bin/pm2 dans roles/zmd/templates/zmd.service.j2
• supprimer roles/zmd/templates/package.json.j2
• remplacer ceci par cela :
  

  ansible-zestedesavoir/roles/zmd/tasks/main.yml

  Lines 24 to 32 in b23a84a

  	- name: add server package.json
  	template:
  	src: package.json.j2
  	dest: /opt/zmd/package.json
  	register: zmd_package
  	notify: restart zmd
  	tags:
  	- bootstrap
  	- upgrade

  - name: copy server package.json
    copy:
      src: "{{ appdir }}/zmd/package.json"
      dest: /opt/zmd/package.json
    register: zmd_package
    notify: restart zmd
    tags:
      - bootstrap
      - upgrade
  

Installer et documenter Munin-master

• Ajouter un rôle Ansible pour installer et configurer Munin-master
• Documenter
• Installer Munin-master en bêta et en prod

L'env zmd est toujours 'beta'

Sur la prod: https://github.com/zestedesavoir/ansible-zestedesavoir/blob/master/roles/zmd/templates/zmd.service.j2#L16

Je sais pas quelle variable on a déjà pour différencier les environnements. :)

Documenter les scripts de sauvegarde

Il faudrait documenter :

• les scripts de sauvegarde de la base de données qui sont dans /var/backups/mysql
• le script de @sandhose qui transfère une copie des sauvegardes de la base de données (/var/backups/mysql) et des données (/opt/zds/data) vers son serveur

Mettre en place une deuxième sauvegarde sur la bêta

Actuellement il n'y a qu'une seule sauvegarde de la base de données et des données mise en place sur le serveur de @sandhose. Il y a sur la bêta un volume de 50 Go non utilisé inclut dans l'abonnement du serveur (on ne peut pas l'enlever). Je propose donc d'utiliser ces 50 Go pour avoir une deuxième sauvegarde de la production en cas de soucis sur le serveur de @sandhose.

(juin 2021) Utiliser certbot au lieu de acmetool sur le serveur de production

Actuellement acmetool est utilisé sur le serveur de production au lieu de certbot pour générer et renouveler les certificats TLS de zestedesavoir.com, www.zestedesavoir.com et docs.zestedesavoir.com. Malheureusement cet outil n'est pas compatible avec ACMEv2 et Let's Encrypt a décidé d'arrêter de renouveler des certificats avec ACMEv1 à partir de juin 2021, donc il nous faut donc passer à certbot. Ce dernier est déjà utilisé sur le serveur de bêta et fonctionne très bien. Il va néanmoins falloir trouver une manière de passer de acmetool à certbot en gardant le même certificat TLS pour que les utilisateurs n'aient pas de soucis à cause de HSTS.

Le tag upgrade ne lance pas les migrations et la construction du front

En déployant la prod j'ai remarqué que les migrations n'avaient pas été lancées, et que le front n'était pas à jour.

Documenter la configuration ssh

• Vérifier que la configuration ssh est unforme entre la bêta et la prof
• Vérifier que la configuration est à jour
• Documenter la configuration
• Si possible, ajouter un rôle Ansible

Mettre à jour la compression des backups de MariaDB

Actuellement, les backups sont compressées et décompressées avec les options --compress et --decompress de mariabackup. Ce n'est plus la solution recommandée par MariaDB qui propose d'utiliser ces deux commandes :

# Compression
mariabackup --user=root --backup --stream=xbstream | gzip > backupstream.gz
# Décompression
gunzip -c backupstream.gz | mbstream -x

Il faut donc modifier les scripts de backups pour utiliser la nouvelle façon de faire et vérifier que tout fonctionne bien !

Configurer Ansible pour utiliser Python 3 sur Debian ?

• Mettre interpreter_python = /usr/bin/python3 dans ansible.cfg
• Installer Python 3 et Pip 3 dans le rôle common
• Modifier la tâche « install MySQLdb-python » pour installer PyMySQL avec Pip car MySQLdb-python n'est pas compatible Python 2 et n'est pas mis à jour depuis plusieurs années

Roadmap, aka le Masterplan.

Voici en vrac ce que j'aimerais à terme pour l'infra de Zeste de Savoir.

L'objectif est 1. d'avoir une infra la plus déclarative, reproductible et automatisée possible, et 2. pouvoir déployer dynamiquement plusieurs environnements de beta.

Dans infra, j'entends:

• les machines qu'on a (1 VPS chez Gandi pour la prod, 1 VPS chez Scaleway pour la beta)
• les deux noms de domaines avec la zone associé (c'est Gandi notre registrar et DNS)
• les secrets de login social (clé d'API Facebook et Google)
• plusieurs projets avec DSN associé dans Sentry (backend|zmd / prod|beta)
• un projet Google Cloud avec les services accounts ayant accès à Google Analytics
• divers clés/certificats genre compte LetsEncrypt, clé DKIM pour les mails…

Là dedans, les seuls trucs qui sont pas gérable via une API sont les clés d'API de login sociaux (y'a une issue chez Google pour ça), et les VPS chez Gandi ('fin, l'API est très vieille et manque d'un vrai SDK)

---

J'ai pas mal expérimenté avec Terraform, qui est un outil permettant de décrire et déployer une infra via des fichiers de config.

Mes expérimentations pour Zeste de Savoir se trouvent sur sandhose/terraform-zestedesavoir.

Ce qu'il y a dans ces fichiers de config:

• la déclaration de la zone zestedesavoir.com
• une paire de clé générée pour DKIM, dont la clé publique est ajoutée en record TXT dans la zone
• un certificat Let's Encrypt wildcard
• plusieurs instances chez Scaleway, avec des records DNS A/AAAA pointant sur ces instances

L'idée, c'est qu'ensuite, on peut faire générer un certain nombre de sorties à Terraform, qu'on pourrait ensuite utiliser dans le playbook Ansible.

Ce qui serait aussi possible de gérer via Terraform:

• le service account pour les credentials d'API Google Analytics
• les "projets" Sentry pour récupérer ensuite les différents DSN
• les différents records DNS genre SPF, DMARC…

---

Les betas multiples

J'ai aussi dans ce dépôt un PoC de plusieurs beta. L'idée est la suivante:

• on construit avec l'outil Packer des images pour Scaleway à partir du playbook Ansible (j'ai le fichier de conf. Packer fonctionnel en local)
• on stocke dans un stockage clé-valeur quelconque (dans mes tests, Consul) une association nom de beta -> ID d'image scaleway
• Terraform déploie autant d'instances chez Scaleway qu'il faut…
• …puis ajoute les records DNS [clé].zestedesavoir.com avec les IPs des instances

Les exécutions de Terraform et de Packer peuvent se faire en CI. Pour déployer une nouvelle beta, il suffirait d'ajouter l'entrée dans le stockage clé-valeur et trigger la CI ; pour en enlever une, il suffirait de supprimer la clé correspondante.

---

Autres infos en vrac:

• l'état de Terraform doit être partagé d'une manière ou d'une autre. Le stocker dans Consul est envisageable
• le fait de gérer le certificat ACME dans terraform permet de générer un certificat wildcard réutilisable (pas besoin de faire un nouveau compte + certificat pour chaque instance), et évite de laisser traîner les credentials Gandi sur le serveur
• l'ajout d'une nouvelle instance dans le clé-valeur peut très bien se faire automatiquement en CI, et on peut faire remonter l'info à GitHub pour l'afficher dans les PR. On peut aussi trigger des pipelines Travis entre plusieurs dépôts via leur API
• je suis tombé sur Atlantis pour lancer Terraform à chaque PR, afficher le plan et auto-appliquer au merge de la PR

Les questions qui restent à résoudre en vrac:

• je ne sais pas comment enregistrer auprès du munin de @vhf les nouvelles instances. De ce que je sais, c'est compliqué de faire de l'ajout dynamique d'hôte sur munin.
• je ne sais pas comment on va faire pour restaurer les données sur une nouvelle beta. J'ai un script presque fonctionnel pour ça, mais il doit être exécuté depuis mon serveur
• quid de la rétention des images Scaleway ? On build à chaque commit ? Chaque tag ? Manuellement ?

Je me permet de ping @Situphen et @artragis, puisque c'est susceptible de vous intéresser.

Mise à jour de BorgBackup

Actuellement on utilise BorgBackup 1.1.9 qui est une assez vieille version. Il faudrait passer rapidement à la version 1.1.17 puis un peu plus tard à la version 1.2.x quand elle aura été éprouvée. Il faudra probablement installer les binaires directement depuis le site web de BorgBackup étant donné que les dépôts de Debian ne proposent pas les versions à jour et ce, à la fois sur la bêta et la prod.

Binaires de BorgBackup
Changelog de BorgBackup

Installer les paquets LaTeX à partir de la liste de latex-template

Il serait bien d'installer les paquets LaTeX à partir de la liste du dépôt latex-template au lieu d'utiliser une copie sur ce dépôt. Il va néanmoins falloir faire attention car TeXLive 2018 est utilisé en production alors que TeXLive 2019 est utilisé lors du développement de latex-template !

Améliorer globalement la documentation

Améliorer globalement la documentation

• Dans un premier temps, mettre la documentation dans les fichiers Markdown dans un sous-dossier
• Dans un deuxième temps, mettre en place un Github Pages ?

Ajouter un rôle test

Il faudrait créer un rôle test qui ne se serait pas lancé en bêta ou en prod mais seulement en local ou en CI. Celui-ci contiendrait des tâches pour ajouter des donnés factices en base de données ainsi que des tests pour vérifier que les pages principales ne retournent pas d'erreur interne, signe d'une mauvaise configuration quelque part.

Mettre en place ECH

Lorsque ECH (Encrypted Client Hello) sera supporté par OpenSSL, Nginx et les navigateurs, mettre en place cette fonctionnalité pour éviter de faire fuiter le nom de domaine dans la négociation TLS quand on accède aux serveurs de ZdS.

Discuté ici.

Correction du rôle LaTeX

Le rôle LaTeX actuellement installe les paquets texlive de base, télécharges les polices qu'il faut, et clone latex-template dans /usr/local/share/texmf/latex-template. Sauf que:

• on dirait qu'il manque des paquets (asmsymb par exemple ?)
• il trouve pas zmdocument.cls (un mauvais path ?)

Il me faudrait plus d'info pour régler proprement ces deux problèmes. cc @Heziode @artragis

Ajouter Ansible Lint

Ansible Lint

• Modifier le code pour qu'il soit cohérent et qu'il respecte les bonnes pratiques
• Utiliser Pre-Commit pour simplifier l'installation
• Ajouter la vérification du linter au Github Actions

Télécharger et installer les données GeoLite2 automatiquement

Une PR sur le dépôt principal vise à retirer les données GeoLite2 du dépôt. Il faudra donc les télécharger et les installer dans le cadre du déploiement.

Bien que ce soit faisable manuellement, le mieux est de l'automatiser. Il y a différentes options :

• un updater proposé par l'éditeur,
• du téléchargement direct, toujours depuis le site de l'éditeur.

La documentation raconte tous les détails.

Voir aussi #6384.

Corriger la déclaration de http2 dans les sites Nginx

Vu sur Twitter :

/!\ à partir de la version 1.25 de nginx, celui refusera de valider la config et démarrer, si un de vos virtual hosts en https a la ligne
listen ip:443 ssl http2;

il faut désormais mettre:
listen ip:443 ssl;
http2 on;

En effet, le changelog de la version 1.26 nous indique :

Feature: the "http2" directive, which enables HTTP/2 on a per-server basis; the "http2" parameter of the "listen" directive is now deprecated.

Nginx 1.26 sera disponible avec la prochaine version de Debian, sans doute qu'on peut déjà adapter les fichiers de configuration, non on a actuellement Nginx 1.22 où la directive http2 on n'est pas reconnue.

Uniformiser et documenter le parefeu

• Uniformiser le pare-feu entre la bêta et la prod
• Documenter sa configuration
• Si possible, ajouter un rôle Ansible