Infini propose à ses adhérents l’hébergement de sites web non commerciaux, conformes à ses statuts.
Cette rubrique propose des guides d’informations et des conseils pour les usagers.

Résumé de l’hébergement

• Espace disque : non limité (tant qu’il reste de la place pour les autres adhérents)
• Votre domaine (.org, .net, .fr, etc.) et autant de sous-domaines que désiré ; si vous n’avez pas de domaine, vous pouvez utiliser un sous-domaine d’infini.fr
• Serveur Apache2 avec PHP 5.6, 7.4, 8.2, 8.3 et 8.4, MySQL (MariaDB 10.4)
• Compte FTP et possibilités de sous-comptes FTP
• Nombre de bases de données : 5 par défaut (plus sur demande)
• adresses de courriers électronique : 25 boites mails par défaut (plus sur demande) sans limite de taille (tant qu’il reste de la place pour les autres adhérents)
• liste de discussion/diffusion
• cartographie
• hébergement des médias
• diffusion audio/vidéo
• service « cloud » intégré (basé sur Nextcloud) permettant de synchroniser, entre autres :
  • des carnets d’adresses
  • des agendas
  • des tâches
  • des favoris
  • des notes
  • des flux RSS
  • précision : stockage limité à 512Mo sur le cloud

Si vous avez besoin d’autres services, n’hésitez pas à demander !

Infrastructure

Description physique

Les serveurs sont hébergés dans un datacenter situé à Brest auquel nous avons accès et sont reliés au web par une connexion dédiée d’un débit de 20Mbps symétrique fournie par l’entreprise Xankom.

Liste des machines baremetal (physiques)

En résumé, au total 212 cœurs pour 616 G de RAM répartis sur 13 machines physiques.

• tevennec : DELL POWEREDGE R230 /4 x Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz / 16 Go de RAM
• hoedic : DELL POWEREDGE R530 / 24 x Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz / 64 Go de RAM
• houat : DELL POWEREDGE R530 / 24 x Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz / 64 Go de RAM (jumelle de hoedic)
• jument : DELL POWEREDGE 2950 / 8 x Intel(R) Xeon(R) CPU E5420 @ 2.50GHz / 32 Go de RAM
• nividic : DELL POWEREDGE 2950 / 8 x Intel(R) Xeon(R) CPU E5420 @ 2.50GHz / 32 Go de RAM (jumelle de jument)
• creach : DELL POWEREDGE R540 / 20 x Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz / 64 Go de RAM
• kereon : DELL POWEREDGE R540 / 20 x Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz / 64 Go de RAM (jumelle de creach)
• toulinguet : DELL POWEREDGE R630 / 24 x Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz / 128 Go de RAM
• armen : DELL POWEREDGE R720 / 8 x Intel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz / 8 Go de RAM
• kador : DELL POWEREDGE R440 / 40 x Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz / 16 Go de RAM (NFS)
• bmo01 : HPE ProLiant DL360 Gen10 / 16 x Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz / 64 Go de RAM
• bmo02 : HPE ProLiant DL360 Gen10 / 16 x Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz / 64 Go de RAM (jumelle de bmo01)
• bqm03 (local Infini) : EMC

Liste des machines virtuelles

Comme pour les machines baremetal, la plupart des vms sont déployées en mode HA (High Availability), c’est à dire que chacune d’entre elles dispose d’une ou plusieurs machines jumelles afin d’assurer le fonctionnement des services portées lorsqu’une des vms d’un groupe subit une surcharge ou ne fonctionne plus.

Listes des 50 vms classées par groupes :

• api : api01, api02 : consul
• bdd : bdd01, bdd02, bdd03, bdd04 : cluster bdd myqsl
• gre : gre01, gre02 : cluster bdd postgre
• dns : dns01, mel01, mel02 : envoi/réception mails, dns
• dov : dov01, dov02 : mails utilisateurs
• elk : elk01, elk02, elk03 : cluster elasticsearch
• ftp : ftp01, ftp02 : backends ftp
• lvs : lvs01, lvs02 : loadbalancing
• ngx : ngx01, ngx02 : reverse-proxy
• pad : pad03 : pads etherpad
• salt : salt01, salt02 : serveurs de configuration
• srv : srv01, srv02 : outils libres * web : web01, web02, web03, web04, web05, web06 : serveurs web PHP 5.6/7.4/8.2/8.3
• red : red01, red02, red03 : cache PHP
• ssh : ssh01, ssh02 : bastions

Liste des 5 vms hors groupes :

• pan01 : panel alternc
• adm01 : dépôts de dev salt, clustershell, dehydrated
• met01 : metrics (prometheus, grafana)
• mon01 : monitoring (icinga)
• claie : serveur de listes SYMPA

Architecture logicielle

Toutes les machines fonctionnent sous Debian buster ou bullseye à ce jour. Le système de virtualisation utilisé est KVM, une migration vers Proxmox VE est à l’étude. INFINI n’a utilisé, n’utilise et n’utilisera que des logiciels libres. Vous pouvez consulter la liste des paquets Debian GNU/Linux utilisés au 15 mai 2019 (il peut manquer ceux des serveurs en cours de démantèlement ou d’amélioration).

• les données des adhérent⋅es sont stockées sur le serveur NFS hébergé par kador
• le firewall Shorewall est installé sur tevennec
• les vms du groupe api portent l’outil Consul utilisé aussi par le cluster postgre
• les vms du groupe bdd portent le cluster galera mariadb
• les vms du groupe gre portent le cluster postgre basé sur patroni & consul
• les vms du groupe dns portent les serveurs DNS bind et le stack de mails composé de postfix, amavis, clamav, spamassassin & opendmarc pour envoyer et recevoir les mails
• les vms du groupe dov porte les services dovecot et opendkim pour mettre à dispo les mails aux adhérents
• les vms du groupe elk portent le cluster elasticsearch qui permet de centraliser les logs des différents serveurs afin d’alimenter l’outil kibana
• les vms du groupe ftp portent les serveurs FTP proftpd
• les vms du groupe lvs portent les loadbalancers haproxy & keepalived
• les vms du groupe ngx portent le reverse proxy nginx
• les vms du groupe pad portent le logiciel etherpad dont les données sont stockées dans le cluster postgre
• les vms du groupe salt portent les master salt
• les vms du groupe srv portent les outils libre mis à disposition dans le cadre de CHATONS
• les vms du groupe web portent les backend web Apache PHP
• les vms du groupe red portent les clusters de cache Redis & Memcached
• les vms du groupe ssh portent les bastions ssh permettant à l’équipe technique d’accéder à l’infra

Le panel AlternC

Chez Infini AlternC n’est plus qu’un simple frontend qui permet aux adhérents de gérer leur compte, l’interface permet de mettre à jour la base de données, quelques scripts d’AlternC tournent toujours pour faire les changements qui vont bien mais rien de plus.

Le reste de l’intelligence et notamment la gestion des différentes configuration de services fournit par AlternC (conf web, mail, etc...) est gérée par un outil indépendant d’Alternc que nous utilisons aussi pour déployer et configurer la totalité de l’infra, SaltStack.

La mise en place de ce système à principalement consisté à reprendre les requêtes qu’utilisait AlternC pour générer les confs et les exécuter par SaltStack, une fois les datas récupérées par salt il est simple de les exploiter pour poser les confs qui vont bien ou on veut sur l’infra.

Outils de déploiement

L’infrastructure est déployée et configuré à l’aide de Saltstack. Le code de nos recettes salt est stocké dans un dépôt GIT privé hébergé par Framasoft sur https://framagit.org/infini/.

On ne va pas entrer dans les détails du fonctionnement de salt, il y a suffisamment de littérature à ce sujet disponible sur le web, mais pour résumer c’est un outil fonctionnant en mode client-serveur (master/minion) qui permet de définir :

• des pillars, qui contiennent les données de configurations spécifiques
• des states, qui permettent de déployer des fichiers sur les serveurs et les configurations générales des services
• des grains qui permettent de récupérer des informations à propos des minions afin de bien cibler les machines

Procédure pour envoyer une modification sur l’infra

Le principe est le suivant :

1. la personne peut optionnellement tester sa modification "à l’arrache" en production pour valider que les changements sont fonctionnels
2. si la modification correspond à un bug ou une évolution référencée dans un ticket, la personne créée une branche nommée issue_XX dans sont dépôt GIT local (où XX est le numéro du ticket)
3. la personne retranscrit ses modifications afin qu’elle soient appliquées par salt (c’est à cette étape que ça peut être galère quand on ne connaît pas bien salt et le code de l’infra ^^)
4. après avoir commité ses modifications la personne les pousse vers le dépôt GIT hébergé chez framagit
5. à ce moment, la personne peut se connecter à l’infra pour lancer les tests d’application de ses modifications
   1. en se connectant à la machine adm01 afin de basculer sa copie de dev du repo salt sur la branche issue_XX
   2. en se connectant sur une des machines qui sont ciblées par les modifications
   3. en basculant la machine de l'environnement de production vers l'environnement dev (ce qui permet à salt d'utiliser le code de la branche issue_XX et non celui de production)
   4. en appliquant les states concernés par les modifications afin de valider que tout fonctionne
   5. puis en repassant la machine en environnement de production une fois les tests terminés
6. puis la personne pourra enfin proposer ses changements dans une merge request (ou PR) afin que les autres membres de l'équipe la relisent et l'intègrent au code de la branche de production
7. une fois la merge request validée, le code sera mis à jour automatiquement sur les machines de l'infra et il ne restera plus qu'à appliquer les states concernés sur les machines cibles

C’est assez long et fastidieux, mais c’est le prix à payer pour avoir une infra déployable "automagiquement", et cette rigueur permet de bien valider les changements apportés à l’infra afin d’éviter les "boulettes" en production. Et aussi, le fait que le code soit versionné sous GIT permet de bien comprendre qui a apporté telle modification et pourquoi (à condition que toutes les personnes qui contribuent respectent les conventions des logs de commit bien sûr).