diaspote in backstage
Rédigé par dada / 27 janvier 2016 / 10 commentaires
Le FOSDEM, c'est à la fin de la semaine, déjà ! C'est pour moi l'occasion de vous partager le fonctionnement de diaspote.org, notre pod diaspora avec Augier. Parce que oui, même si les utilisateurs s'en cognent royalement la plupart du temps, j'ose espérer que ceux de diaspora* seront un peu plus curieux. Les autres, vous pouvez venir flooder avec nous, c'est open bar !
Ce billet est un peu technique mais je vais essayer de faire simple, promis.
Debian powered
Diaspote.org tourne sur une Debian Jessie 8.3. Ceux qui me lisent depuis un moment savent que c'est mon système d'exploitation libre de prédilection, c'est donc un choix classique. Ce serveur est automatiquement mis à jour via ce qu'on appelle les unattended-upgrades. C'est une configuration que je croyais classique mais je peux vous certifier que ce n'est pas toujours le cas dans le milieu professionnel.
Ça permet de ne plus se soucier des mises à jour de sécurité, les plus critiques : elles se font toutes seules la nuit, quand les utilisateurs dorment, et moi aussi. Un mail me prévient quand c'est fait, histoire de me rassurer, mais je n’hésite jamais à accélérer le processus quand c'est une faille sévère, autant dire rarement.
Scaleway to heaven
Déjà dit mais voici la configuration matériel du serveur :- 2 Go de RAM
- 60 Go d'espace disque
- ARMv7 4 cores
À votre service
C'est un truc assez récent, il date de cette semaine. Avant, nous avions un screen dans lequel le processus diaspora tournait, mais ça, c’était avant. Maintenant, nous avons un script qui nous simplifie la vie. Plus besoin de lutter avec un screen encombrant : nous voici capables de faire un start et stop proprement, en passant par systemd.Juste après cette configuration, pour des raisons de gestion des faibles ressources dont nous disposons et à cause de la consommation mémoire de diaspora*, nous avons une tache planifiée, un cron dans le jargon, qui relance diaspote toutes les nuits à 4h20 du matin. Ça vide la mémoire, ça soulage et ça n'affecte en rien l'utilisation du pod.
Pour les curieux, il existe un système d'auto-protection dans les OS libres : l'OOMKiller. Ce petit nom est plus clair quand on dit Out Of Memory Killer, je ne sais pas trop comment le traduire en français, mais c'est assez clair, non ? Quand un processus, genre diaspora, se met à consommer assez de mémoire vive pour mettre en danger le fonctionnement du serveur en entier, l'OOMK dézingue ce qu'il peut autour pour essayer de sauver la situation. En général, ça finit mal.
Statistiques à Facette
C'est toujours chouette de voir, réellement, ce qu'il se passe sur son serveur avec des graphiques. Un mail de temps en temps, c'est mignon mais loin d’être sexy. Facette s'occupe de ça pour nous. Il s'occupe d'organiser toutes les informations sur l’état du réseau, de la charge serveur, du CPU et de la RAM en superbes graphiques. C'est beau, c'est efficace et ça permet de connaître exactement l'heure d'un incident et de donner les premières indications, comme un souci de mémoire. Au hasard.En parlant d'incidents, je suis en train de mettre en place un Cachet. C'est un outil de suivi. Il va nous permettre d'annoncer les futures opérations et de garder une trace de tout ce qui a pu se passer. Une mémoire des crashs, en gros. Il sera rapidement disponible à l'adresse suivante : status.diaspote.org.
Le reste des opérations consiste à mettre à jour le pod avec les dernières améliorations tirées du dépôt Github. Avec ce que nous avons là, l'installation est bien stable et ne plante plus. Ça reste à confirmer, on n'est jamais 100% couvert et il suffit d'en parler pour se prendre une mauvaise blague en pleine figure.
