La nouvelle infrastructure du JMMC

La nouvelle infrastructure est basée sur un ensemble de vm, faisant tourner des services indépendants les uns des autres

infos projet

• Wiki : http://www.jmmc.fr/twiki/bin/view/Jmmc/Software/JmmcInfra
• Gestion code source : Forge gitlab gricad : https://gricad-gitlab.univ-grenoble-alpes.fr/OSUG/JMMC/jmmc-srv-infra
• Tickets : trac

Note 15 oct. 2024: Les informations ci-dessous bien que parfois correctes ne sont plus d'actualité.

acces et administration de l'infrastructure

Philosophie

l'idée sous-jacente est de permettre a chaque développeur / mainteneur de pouvoir tester ses modifications de config avant la mise en production, il est donc fourni plusieurs scripts de lancement, un par environnement.

• un script kvm-dev, permettant de déployer la solution sur un ensemble de machines virtuelles locales a la machine du développeur
• d'autres scripts vmw-* permettant la mise en production.

TODO: le script kvm-dev ne nécessite pas de pousser le source dans le repository

une fois le nouveau script testé sur la plateforme de développement, il est alors temps de pousser le source dans le repository, et de lancer le script de déploiement vmw-*

la doc sur le fonctionnement des scripts est dispo dans le repo ici : https://github.com/sxpert/jmmc/blob/master/README.md

implémentation

L'infrastructure repose sur les 3 catégories de machines:

• 1 controleur (administration centralisée)
• 1 frontal (interface avec l'exterieur) extensible à plusieurs dans le futur si besoin
• N noeuds de services

• La configuration se fait uniquement à travers un ensemble de scripts ansible, qui reconfigurent entierement l'infrastructure, en fonction de ce qu'il est nécessaire de modifier.
  • pour reconfigurer les services, il suffit de lancer le script ansible qui effectuera toutes les taches nécessaires à partir de la machine controlleur
    ces scripts ansible réalisent les operations suivantes :
    • installation de la vm / container
    • configuration d'un compte de service avec la clé publique ssh du controlleur, ce compte a les acces sudo nécessaires, afin que le compte de service du controlleur puisse lancer des scripts sur la nouvelle machine
    • installation / compilation des logiciels a utiliser dans le container pour offir le service
    • configuration du service a proposer
    • ajout du service dans la configuration du frontal haproxy
  • afin d'assurer la cohérence de la configuration a tout moment, il est recommandé de ne pas modifier les configurations des machines ou containers portant les applications a la main.

configuration de service supplémentaires

• écrire les scripts ansible nécessaires au déploiement de la nouvelle application
• des roles sont fournis (...) afin de permettre de générer les parties communes entre toutes les applis (notamment la génération automatique du conteneur de l'appli)
• une fois testé le script ansible, mettre a jour le repository sur le compte de service du controlleur avec git pull
• lancer le script ansible, l'application sera automatiquement déployée

Méthodologie

• Le developpement en équipe se fait par une étape d'étude qui passe par une revue de design avant l'implémentation
• la documentation doit être la plus légère possible:
  • ne pas paraphraser le code
  • mentionner toute logique non explicite (par ex. justifier une configuration avec des valeurs de priorités différentes - pourquoi - )
• Les distributions linux sont à retenir en fonction des préférences des acteurs OSUG : debian
  • avec une version stable la plus récente possible
  • TBD indiquer comment on procéde dès que les configurations / versions ne suivent plus des exigences fonctionnelles
  • les paquets seront limités à ceux fournit en standard par la distribution
    • en cas de version non suffisante, une nouvelle version peut-être installée, mais la justification devra être mentionnée dans la documentation (au minimum un commentaire WARNING ou TODO )
  • statuer sur la politique de mise a jour : auto ou manuelle, sécurité seulement ...

Ce que l'on souhaite:

• automatiser les deploiements suivant des conventions existantes
• pouvoir créer des miroirs de l'infrastructure pour assurer une redondance géographique de certains services

Ce que l'on craint:

• perdre l'accès et le contrôle des services à comparer d'intervention plus manuelles sur des serveurs bien identifiés
• limiter le champ d'intervention aux seuls experts des techniques employées (lecture d'un script vs d'une configuration style pom.xml)

mise en oeuvre pratique dans le cadre de l'osugdc (préprod)

en attendant que les services de l'osugdc soient en mesure de proposer une infrastructure suffisamment souple, un prototype a 3 machines virtuelles a été mis en place

machines virtuelles

• trois machines virtuelles ont été créées a la main
  • jmmc-ctrl-1.ujf-grenoble.fr
    machine virtuelle faisant office de controlleur
  • jmmc-fe-1.ujf-grenoble.fr
    machine virtuelle faisant office de front end
  • jmmc-host-1.ujf-grenoble.fr
    machine virtuelle faisant office d'hote pour les applications
• des comptes de service "sysjmmc" ont été créés par l'équipe de l'osugdc. ces comptes de service ont l'acces sudo adéquat
• une clé ssh a été créée sur le controlleur et installée sur le compte de service des deux autres machines.

utilisation de l'infrastructure

• pour effectuer le déploiement de nouvelles applications, ou la mise a jour d'une application existante, se connecter sur le compte de service controlleur , mettre a jour le repository git, et lancer le script adéquat

Controleur

• host: jmmc-ctrl-1.jmmc.fr
• accés: ssh
• compte de service: sysjmmc

Remarque

chaque utilisateur ayant nécessité d'accès à cette machine doit fournir la partie publique de sa clé ssh à jmmc-tech-group (de préférence ed25519)

Frontal

• a base de HAProxy
  l'installation sur la debian wheezy nécessite l'ajout de la ligne
  deb http://ftp.fr.debian.org/debian wheezy-backports main
  deb http://ftp.fr.debian.org/debian wheezy-backports-sloppy main
  au fichier /etc/apt/sources.list
• la configuration

Les noeuds de services

Site Web

• Rajouter ici le point d'entrée vers le code ansible...

le site du JMMC fait l'objet d'une vaste opération de réécriture d'URLs afin de rediriger les utilisateurs vers les bonnes pages en fonction du sens ou l'utilisateur a écrit l'url...
ces instructions initialement contenues dans des fichiers .htaccess seront déplacées dans la configuration du front end haproxy.
un systeme est mis en place pour tester le fonctionnement de toutes ces redirections.

à compléter...

compilation des softs

gestionnaire de documents

scénario de migration

Références / tuto / documentation

• • Episode #43 - 19 Minutes With Ansible (Part 1/4)
  • Episode #45 - Learning Ansible with Vagrant (Part 2/4)
  • Episode #46 - Configuration Management with Ansible (Part 3/4)
  • Episode #47 - Zero-downtime Deployments with Ansible (Part 4/4)
• Debobs de très nombreuses contributions ansibles
• un peu vieux, mais propose un agencement docker + ELK
• generation graphique d'inventory
• Multistage environments with Ansible et Setting up Ansible for multiple environment deployments
• Generation de doc:
  • https://github.com/shirou/sphinxcontrib-ansibleautodoc
  • https://github.com/starboarder2001/ansible-docgen
• https://blog.codeship.com/ensuring-containers-are-always-running-with-dockers-restart-policy/

-- RaphaelJacquot - 01 Mar 2016