• Liste des sujets neutritons
• liste des pads
• Pad de la réunion

Présences :

• HgO
• Tharyrok
• niko
• célo
• Liberfix
• Channel
• tierce

Jitsi : https://jitsi.belnet.be/neutriton

Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion. Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire

Heure de fin : 16h (pour liberfix)

Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.

Tuto pour Caddy2: https://caddyserver.com/docs/caddyfile-tutorial

Caddy : orienté sécurité et simplicité. On installe on a déjà quelque chose qui fonctionne, qu'on peut modifier pour faire une configuration plus fine mais on a déjà quelque chose.

Si on est en local, on peut lui demander de se passer des certificats en précisant http://.

Un file server est intégré dans caddy qui permet d'afficher les répertoires (exemple avec le répertoire de caddy). On a une fonction de recherche. Cette config se fait uniquement avec deux lignes.

En indiquant deux hosts dans la config (noms de domaines où ports), Caddy comprend directement qu'on veut faire du loadbalancing et en fait. On peut choisir la load balancing policy (lp), round_robin fait qu'une fois sur deux on tombe sur l'un et une fois sur deux sur l'autre. Mais on peut mettre d'autres paramètres.

Au niveau des performances, il y a actuellement peu de test parce que caddy2 vient de sortir. Un test montre que Caddy est plus lent, mais il ne considère pas la charge du processeur. Et ce sont des situations où il y a un très grand nombre de requête, ce qui ne sera pas le cas de Neutrinet.

Mode API : pas forcément facile pour des personnes qui ne connaissent pas de connaître l'état de caddy. Contrairement à un fichier de configuration par exemple. Mais pas sûr, c'est à voir.

Intérêt de l'API, quand on commence à avoir plusieurs sites. Dans le cas de petites configs, plutôt fichiers de configs.

Caddy fournit des metrics pour prometheus directement intégrées dans le logiciel.

snippet.shell

curl -H "Content-Type: text/caddyfile" http://localhost:2019/config/

Caddy parait pertinent mais des questions se posent quand même :

Quid si quelqu'un a modifié la config sur le serveur ? Est-ce qu'il faut tout supprimer et repartir de zéro quand on repasse via Ansible ?

Comment on s'assure d'être averti si la config live est differnate de ce qu'il y a dans ansible.

Beaucoup d'interrogations sur l'API, qui est différente de ce qu'on utilise d'habitude

snippet.conf

cloud.yourhost.com {
  header / Strict-Transport-Security "max-age=31536000;"
  root /var/www/html
  fastcgi / nextcloud:9000 php {
    connect_timeout 1h
    read_timeout    10m
    send_timeout    30m
  }
  redir 301 {
    /.well-known/webfinger /public.php?service=webfinger
    /.well-known/caldav    /remote.php/dav
    /.well-known/carddav   /remote.php/dav
  }
  status 403 {
      /.htaccess
      /data
      /config
      /db_structure
      /.xml
      /README
  }
}

On ne trouve pas vraiment de comparatifs.

Un avantage d'avoir HAProxy est que la gestion des certificats est un peu plus libre : on peut vraiment faire ce qu'on veut. Tandis qu'avec Caddy2, c'est plus compliqué si on veut utiliser un truc bien précis.

snippet.conf

frontend lb-default
	bind 10.50.20.20:80
	bind 10.50.20.20:443 ssl alpn h2,http/1.1 crt-list /etc/haproxy/ssl.txt allow-0rtt
	mode http
 
	http-request redirect scheme https code 301
 
	# Neutrinet
	use_backend neutrinet-backend if hdr(host) neutrinet.be
 
	# Wiki Neutrinet
	use_backend wiki-neutrinet-backend if hdr(host) wiki.neutrinet.be
 
backend neutrinet-backend
	mode http
	option httpchk GET /healthcheck
	option forwardfor
	option http-server-close
	server neutrinet-01 10.0.10.50:80 check cookie sl
 
backend wiki-neutrinet-backend
	mode http
	option httpchk GET /healthcheck
	option forwardfor
	option http-server-close
	server neutrinet-02 10.0.10.50:80 check cookie sl send-proxy

Caddy2 : courbe d'apprentissage qui semble moins importante que nginx. Quoiqu'à voir avec l'API.

Nginx : lorsqu'on installe, il faut écrire la config de 0 (contrairement à Caddy, voir ci-dessus)

Pertinant de se fixer dessus, s'il y a une forte volonté de d'utiliser caddy alors il est aussi intérésant de l'avoir en load-balencer.

Caddy : écrit en Go, qui est un langage créé par Google au départ et pas sous licence copyleft (licence BSD) https://fr.wikipedia.org/wiki/Proxy_inverset. Note que c'est au même titre que Rust (licence MIT / Apache) poussé par Mozilla.

Ce sont deux outils qui sont très bons dans leur domaine. HAProxy pour du load balancing et Nginx pour du web server. Et de toute façon, HAProxy ne fait pas web serveur.

On va faire un tour de table dans le but d'avoir une proposition pour le Hub infra.

• Les trois solutions ont l'air possible à prendre en main, avec de l'apprentissage. Pour Caddy2, il y a une interrogation sur l'API, mais ce n'est pas insurmontable. Au final compliqué de se prononcer.
• Argument des licences, mais pas facile d'en connaître l'impact (ex: projet développé par Google). Ce serait plus dans la logique de Neutrinet de rester sur du libre.
• Caddy2 a l'air super sympa, et peut permettre d'avoir un seul truc pour load balencer et web server. Mais question des licences, de la modernité, le tout poussé par des entreprises du « cloud » et pas vraiment pas des organisations qui encourageraient l'autonomie.
• Pour la question des licences et de la gouvernance (deux points tout aussi importants), il n'y en a pas vraiment un pour rattraper l'autre. Sauf peut-être HAProxy (GPL \o/, pour la gouvernance on sait pas).
• Haproxy pour plus de souplesse pour les certif.
• Caddy pour l'accessibilité, la doc et la communauté vivante qui est autour.
• Haproxy en frontal et Caddy pour les services web. La config de Haproxy qui serait isolée de celle de Caddy, comme ça on a pas de problème de collision que ce soit avec ansible ou en utilisant l'api de Caddy.
• Sur la question des licences c'est quelque chose qui ajoute beaucoup de travail d'évaluation qui va du hardware à chaque couche / outil logiciel. On est pas assez nombreux·ses pour répondre à toutes ces questions / enjeux. Mais peut-être plus tard quand on aura avancé et qu'on serait plus nombreux·ses.

Est-ce qu'il y aurait une objection pour aller vers Haproxy sur le frontend et Caddy pour les services web ?

• Pas pour le moment et pas parmis les personnes présentes.
• On fera cette proposition au Hub infra ce 23 mars.

Pour rappel, tous les outils qu'on utilise actuellement et qui ont besoin d'une DB peuvent se reposer sur PgSQL, d'où le souhait d'y réfléchir en tant que cluster / HA.

Note: Je (HgO) n'ai pas encore lu tout ça

• https://medium.com/searce/design-a-highly-available-postgresql-cluster-with-patroni-in-gcp-part-1-dfb6ed277806 (patroni uniquement)
• https://scalegrid.io/blog/managing-high-availability-in-postgresql-part-1/
• https://medium.com/@kristi.anderson/whats-the-best-postgresql-high-availability-framework-paf-vs-repmgr-vs-patroni-infographic-8f11f3972ef3

Résumé des différents modes de HA: https://www.postgresql.org/docs/13/different-replication-solutions.html#HIGH-AVAILABILITY-MATRIX

Il y a un HAproxy devant avec un port ouvert pour la lecture et un pour l'écriture. Patronni expose une api rest pour decouvrir quel est le serveur en primary et quel sont les serveurs secondary.

Pour la prochaine fois.

Prochain Neutriton : 27/03/2021 @ 14H

Lieu : https://jitsi.belnet.be/neutriton et/ou Caldarium https://caldarium.be/fr:contact

Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif. Si une ou plusieurs tension est née durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.