Aller au contenu principal

Gestion des services

Vous trouverez ici décrites les différentes étapes du cycle de vie d'un service, de la décision de sa création à sa fermeture en passant par sa maintenance.

Création, installation, déploiement​

Conditions d'ouverture​

Avant de penser à ouvrir un nouveau service, il faut s'assurer d'avoir un objet unique et précis qui corresponde à un besoin très concret. Il faut donc vérifier que le service auquel on pense ne fasse pas entièrement ou en partie doublon avec un autre, ou qu'il ne puisse pas être intégré à une autre unité existante, ou inversement. Une fois ces conditions vérifiées, il faut effectuer les étapes suivantes dans l'ordre :

protocole
  1. Ouvrir une issue dans https://git.felinn.org/FELINN/asso en utilisant le modèle « création de service ». Le titre doit adopter le format « [service : création] {{ nom de l'unité concernée }} » et la description doit détailler le besoin et l'objectif.
  2. L'issue doit être approuvée au niveau CC-CP-V dans le cas d'un service en production et CC-CV-V dans le cas d'un service en test ou d'un VPS.
  3. Si approuvée, l'issue doit donner lieu à la création de l'unité. L'issue ne peut être fermée que lorsque les décisions suivantes ont été prises :
  • un·e ou des membres responsables de son administration
  • mise place des permissions
  • domaine à appliquer au service :
    • {{ service }}.felinn.org pour les services en production (FELINN core)
    • {{ service }}.labs.felinn.org pour les services en test (FELINN labs)
    • {{ nom }}.{{ domaine }} pour les VPS
  • type de virtualisation :
    • LXC par défaut pour les services de la FELINN
    • KVM uniquement s'il y a besoin d'isoler le noyau (par exemple en cas d'accès root pour des personnes extérieures)
  • ressources allouées
  • logiciel pour le service en question:
    • libre de préférence, open source au minimum (la différence est notamment expliquée ici)
    • bien maintenu
    • avec une communauté active
    • léger
  • dans le cas d'une KVM, le nom d'hôte (hostname) et le login (nom d'utilisateurice régulier) désirés

Création de l'unité​

remarque

En complément du protocole ci-dessous, ne pas hésiter à consulter la documentation officielle de notre hyperviseur Proxmox.

protocole
  1. Se loguer en @(ssh) sur felinn.org et mettre à jour les images disponibles avec pveam update (ou vérifier que les images sont à jour).
  2. Télécharger la dernière image disponible et stable de Debian (ou de la distribution désirée), visible sur l'interface PVE dans storage (local) ou avec la commande pveam available | grep debian. Les images sont enregistrées dans /var/lib/vz/template/cache/. S'il y a une version plus à jour, télécharger l'image system avec pveam download local debian-{{ version }}.tar.gz et pensez à supprimer les images obsolètes.
  3. Créer un container (Create CT) sur l'interface PVE (ou en ssh avec la commande pct) avec les paramètres suivants (laisser par défaut ce qui n'est pas précisé) :
  • General
    • CT-ID par défaut (le plus bas disponible). À partir de 100 pour les services FELINN et 200 pour les autres.
    • Hostname nom du service complet (avec URL) tel que décidé dans l'issue dédiée
    • Ressource pool FELINN-core, FELINN-labs ou VPS en fonction du type de service choisi
    • Password le créer dans le répertoire pass de la FELINN (voir la documentation dédiée) avec pass generate -c FELINN/{{ hostname }}/root. Cette commande génère et copie dans le presse papier pendant 45sec.
  • Template : choisir le dernier template debian (ou autre OS téléchargé) stable
  • Root disk
    • local-zfs
    • capacité en fonction de ce qui a été décidé (utiliser des puissances de 2, c'est la tradition 😆)
  • CPU : en fonction de ce qui a été décidé (il est possible de mettre plus de cœurs juste le temps de l'installation pour aller plus vite )
  • Memoire
    • en fonction de ce qui a été décidé (il est possible de mettre plus de mémoire juste le temps de l'installation pour aller plus vite !)
    • SWAP = RAM
  • Network
    • IPv4
    • 192.168.10.{{ pct_id }}/24 si c'est un service FELINN core
    • 192.168.20.{{ pct_id }}/24 si c'est un service VPS pour isoler les deux sous-réseaux
  • Gateway: 192.168.10.1 ou 192.168.20.1 en fonction de si c'est un service FELINN core ou VPS
  • Confirmation, bien relire et vérifier !
  • vous pouvez lancer le container
  1. Entrer dans le container en ssh avec la commande pct enter {{ pct_id }}.
  2. Nettoyer l'installation debian et installer les outils cool de base avec ce snippet.
  • Vérifier que la TMZ est bien paramétrée sur Europe/Paris
  • Vérifier que les locales par défaut sont bien paramétrées en EN_US.utf8
  • De préférence, activer zsh avec chsh : choisir /bin/zsh

Installation du service​

remarque

Cette section et les suivantes ne sont obligatoires que pour les services de la FELINN. Pour les VPS, chacun·e est responsable de la gestion de son service. Mais nous vous encourageons tout de même à vous inspirer de ce qui suit !

attention

RTFM pour être sûr d'installer uniquement ce qui est nécessaire ! Si besoin, suivre des tutoriels non officiels. Ceux de DigitalOcean par exemple sont souvent des références pertinentes. Quelques bonnes pratiques en vrac :

Permissions​

Pour les services web, il faut bien faire attention à les faire tourner en user:group www-data ou équivalent et jamais en root, ainsi que l'installation dans la mesure du possible.

Arborescence​

  • Par convention, l'installation des services web se fait dans /var/www/{{ hostname }}.
  • Si le code est téléchargé à la main, il est possible de faire un lien symbolique : /var/www/foo.felinn.org -> /var/www/code-v1.23, ça permet de simplifier les mises à jour.

Base de données​

  • utiliser postgresql de préférence pour les performance, mariadb sinon, sqlite3 en dernier recours s'il s'agit d'un service très léger et statique
  • mysql est remplacé par mariadb
  • penser à changer le mot de passe root et à créer un user dédié avec des mots de passe générés avec pass

Cache​

  • Le proxy gère une partie du cache pour les ressources web.
  • Si l'utilisation d'une instance de Redis est possible, utiliser le container dédié 110 avec les paramètres suivants :
  • IP : 192.168.10.110
  • port : 6379
  • password : tel que généré avec [pass]

Courriel​

  • SMTP : container 105, pas d'authentification pour le même sous-réseau
    • IP : 192.168.10.105
    • port : 25
    • tls : True
  • IMAP : container 105, créer un compte sur mail.felinn.org/admin et stocker les identifiants dans pass
    • IP : 192.168.10.105
    • port : 993
    • ssl/tls : True
    • user/password : pass

Proxy​

  • notre reverse proxy gère les connexions depuis l'extérieur ainsi que les certificats SSL
  • si besoin d'un serveur web local, utiliser nginx avec un certificat auto signé (ou des copies de ceux du proxy), nul besoin de les renouveler puisqu'ils servent uniquement à chiffrer les connexion internes
  • si besoin de générer un certificat et une clé SSL : mkdir /etc/nginx/ssl && openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/ssl/{{ hostname }}.felinn.org.key -out /etc/nginx/ssl/{{ hostname }}.felinn.org.crt
  • pour homogénéiser, on crée le fichier de conf /etc/nginx/sites-available/{{ hostname }}.felinn.org.conf puis un lien symbolique ln -s /etc/nginx/sites-{available,enabled}/{{ hostname }}.felinn.org.conf
  • le nom des logs : {{ hostname }}.felinn.org-access.log {{ hostname }}.felinn.org-error.log
  • pour tester la configuration nginx et recharger le service : nginx -t && nginx -s reload

Configuration​

Dans la mesure du possible, stocker les fichiers de configuration des services dans /etc/{{ service }}/{{ foo }}.conf afin qu'ils puissent être versionnés par git.

Reverse proxy​

Le reverse proxy est installé dans le container 100. Il permet de router le trafic depuis l'extérieur vers les bons CT/VM en fonction du nom de domaine. Voici les étapes à suivre afin de configurer le nouveau CT ou la nouvelle VM sur le reverse proxy :

protocole
  1. entrer dans le container avec pct enter 100 depuis l'hôte
  2. utiliser le script nginx-new-host pour créer le service
  3. vérifier et recharger nginx avec nginx -t && nginx -s reload
  4. visiter le site et adapter les paramètres SCP dans nginx en fonction des erreurs de la console du navigateur

Versionnage du /etc​

Le versionnage des fichiers de configuration permet :

  • la traçabilité des changements dans la vie d'un service
  • de documenter la résolution des problèmes avec Gitlab
  • de récupérer une configuration en cas de disparition, migration ou duplication d'un service
attention

Pour mettre en place le versionnage des configurations, il faut configurer votre connexion SSH de sorte à transmettre vos variables GIT au serveur, afin que Git enregistre l'auteurice des modifications. Pour cela, merci de suivre le tutoriel dédié à la gestion de la traçabilité avec git et ssh.

protocole
  • Une fois le service configuré, installer Etckeeper (dans les dépôts Debian stable par défaut). Par défaut, un répertoire git est alors automatiquement créé dans /etc.
  • Créer un nouveau projet privé dans Gitlab, dans le groupe approprié (FELINN core, Labs, Friends) portant le nom du domaine complet, ex: {{ service }}.felinn.org et commiter les changements locaux si besoin.
  • Ajouter l'upstream au répertoire git local et pousser les modifications :
# ajouter le `remote` dans le repo git du service
git remote origin set-url "https://git.felinn.org/{{ group }}/{{ service }}.git"

# /!\ Si aucun remote n'a préalablement été configuré, ce qui est probable lors de l'installation, préférez la commande suivante
git remote add origin "https://git.felinn.org/{{ group }}/{{ service }}.git"

# pousser les modifications, notez que l'option -U ne semble pas être forcément reconnue
git push -U origin master
  • Vérifier que tout les fichiers sont bien présents dans le projet Gitlab.
  • Pour pouvoir ouvrir un projet Gitlab de la FELINN au public, il faut configurer les permissions comme suit :
    • Issues : « Everyone With Access »
    • Repository : « Only Project Members »
    • Wiki : « Only Project Members »

Sécurisation​

protocole
  1. supprimer les logiciels inutilisés (ceux qui auraient été installés par mégarde ou qui sont inutiles de fait, comme Apache)
  2. vérifier que les paquets sont à jour : apt update && apt full-upgrade
  3. vérifier que les services web tournent avec un user autre que root : ps aux | grep <service> ou top
  4. vérifier que seuls les ports nécessaires sont ouverts et vérifier les interfaces d'écoute depuis l'extérieur : ss -tunlp
  5. des outils comme wapiti peuvent aider à vérifier la santé d'un service web
  6. en cas de problème venant du reverse proxy, ouvrir une issue sur le projet

Documentation​

Si. Il faut la faire. Voir la [documentation de la documentation](lien vers la doc de la doc) pour pouvoir bien la faire.

Publication de l'état de fonctionnement​

attention

Voir l'issue à ce sujet.

Maintenance​

La personne qui a installé le service en est de fait la principale responsable.

attention

Voir l'issue à ce sujet.

Durée de vie & fin de vie​

Tous les services sont maintenus à durée indéterminée par défaut. Ils peuvent être fermés dans les cas suivants :

  • le service n'est plus utilisé ou ne répond à plus aucun besoin
  • le ou les logiciels utilisés par le service changent de statut et sont incompatibles avec la charte de la FELINN
  • le service induit des failles de sécurité incorrigibles
  • le service utilise trop de ressource par rapport à ce qu'il offre

Pour fermer un service il faut respecter la démarche suivante :

protocole
  1. Ouvrir une issue dans https://git.felinn.org/FELINN/asso en utilisant le modèle « suppression de service ». Le titre doit adopter le format « [service : suppression] {{ nom de l'unité concernée }} » et la description doit détailler les raisons de la suppression.
  2. L'issue doit être approuvée au niveau CC-CP-V dans le cas d'un service en production et CC-CV-V dans le cas d'un service en test ou d'un VPS.
  3. Si approuvée, l'issue doit donner lieu au choix d'un délai, à une annonce de la fermeture de l'unité auprès des utilisateurices et/ou de la communauté concernée, ainsi qu'à la désignation des membres qui seront responsables de la suppression.
  4. Une fois le délai de fermeture écoulé, éteindre le CT ou la VM.
  5. Si aucun problème n'est survenu dans la semaine suivante, nettoyer les traces du service :
  6. supprimer les fichiers de configuration sur le proxy
  7. supprimer le container ou la machine virtuelle du service en purgeant les fichiers de configuration dans PVE
  8. supprimer les volumes ZFS et les snapshots associés
  9. archiver le projet Gitlab associé pour garder la trace de la vie du service (peut servir à d'autres et évite de refaire certaines erreurs)