Quel est le défi de l'industrialisation pour Nuabee ?
Cette année 2019 est chargée pour Nuabee :
- Une nouvelle version du logiciel Nuabee Backup 5.6 avec de nouvelles fonctionnalités
- De nouveaux processus d'industrialisation.
Toutefois, nous allons nous concentrer pour le moment sur le défi des nouveaux processus d'industrialisation. Cette méthode, l'IAC (Infrastructure As a Code), est souvent utilisée dans le domaine du Cloud, et est utilisée pour nos solutions.
Mais qu'est ce que l'IAC ?
Cachez les ruminants velus, cet acronyme signifie "Infrastructure As Code" : c'est un modèle de représentation des différents composants de l'infrastructure qui doit être déployée, on parle également "d'infrastructure programmable".
Dans ce paradigme, les opérationels ("ops") ne déploient plus de machines, ne créent plus de réseaux, ne vont pas quitter leur éditeur pour effectuer des opérations, mais exécuter du code, qui va se charger de réaliser les opérations nécessaires tout seul.
On dépasse ici le cadre de la simple automatisation d'infrastructure, mais on va traiter l'infrastructure elle même comme du code.
Programmation et gestion d'infrastructure, on est en plein dans le paradigme DevOps.
L'IAC, n'est ce pas se compliquer le travail ?
Si, mais uniquement au départ. Des bénefices directs sur l'assurance qualité et le coût se font rapidement sentir :
- Un test échoué ? c'est une exception levée ou une condition dans laquelle le code rentre et propose une solution ou averti la personne appropriée.
- Qui plus est, combiné au fait que l'utilisation du cloud est facturée à la minute, le coût de ces tests automatisés (et donc plus rapides) est très faible.
Ah, ça rappelle Ansible, Chef et Puppet, non?!
À peu près, comme ces outils, on spécifie un résultat à obtenir et le logiciel se charge d'effectuer les bonnes opérations et de valider que tout s'est bien déroulé. Par exemple pour Ansible, on peut lui demander de créer un serveur Postgresql, avec un nouvel utilisateur et des droits particuliers, quelques secondes plus tard, le rôle est déployé et vous avez accès à la DB.
Cependant ces outils ne conviennent pas à notre usage à cause d'un contexte particulier :
- nous ne cherchons pas à déployer des logiciels depuis un environnement d'intégration continu ou bien des fonctions d'un logiciel sur des images de systèmes linux, mais bien à restaurer un parc informatique, en prenant en compte machine par machine les contraintes auquelles l'environnement d'origine pouvait être confronté.
Nous n'avons pas la problématique de déploiement d'un développeur, mais celle d'administrateurs systèmes qui œuvrent dans le cadre d'une "migration" de machines vers le cloud, Il nous faut donc décrire cet environnement technique des machines du système d'information d'une manière spécifique. Chaque partie des informations sur l'infrastructure est interprétée par du code pour produire un résultat, que ce soit un simple OK en passant par un rapport dans le terminal jusqu'a l'infrastructure complète ronronnante dans le Cloud.
Notre boite à outils
Donc vous l'avez compris, nous avons notre propore système d'interpretation d'infrastructure... mais sur quoi repose t'il? Les liens suivant vous renvoient vers les projets en question. Nous nous appuyons pour réaliser nos opérations sur des SDK développés en python :
- Le plus important est celui d'OpenStack.
- Un ORM (Object Relation Mapper) vers MariaDB nommé "PeeWee" nous permet de gérer la structure de données du IAC dans la BDD
- Le couple powershell / bash pour le scripting système
- CloudInit, un outil de gestion de machine spécialement imaginé pour utilisation dans le cloud.
Les données chargées par l'ORM sont interprétées par notre logiciel, transformant celle-ci en appel au fournisseur de cloud via le SDK OpenStack et remplissant les scripts exécutés pour la restauration des machines ou leur tests.
Utiliser l'IAC pour répondre au besoin d'industrialisation
Nous utilisons ces éléments de gestion de l'infrastructure de nos clients dans le cadre de l'automatisation des remontées d'infrastructure et de l'assurance qualité des processus de restauration. Le processus résultant est décliné en 3 modes, augmentant progressivement la couverture fonctionelle des tests :
- Le "Dry Run" (ou galop d'essai) : Ce mode est utilisé uniquement pour nos besoins internes, il sert à vérifier notre capacité à restaurer l'infrastructure de nos clients à partir de ses sauvegardes. Si la restauration se lance proprement et s'execute jusqu'au point de validation, le test est réussi et les ressources liberées. Ce test n'aboutit pas au lancement d'une instance de machine et ne sert qu'à nous assurer de notre capacité à éxecuter la restauration des machines enregistrées. D'une certaine manière, ce test ne vise qu'à vérifier la validité de notre code.
- Le test de restauration : Chaque machine est restaurée jusqu'à son redémarrage, appliquant les modifications finales nécessaires à chaque disques après leur restaurations, cependant aucune contrainte externe à la machine n'est gérée, si la machine redémarre, nous validons la remontée correcte de la machine par un scan de ports. Si celui-ci se révèle positif, la sauvegarde est considérée comme valide. Ce mode permet un test unitaire de chaque machine, qu'elle soit ou non couverte dans le PRA.
- Le lancement d'un test de Plan de Reprise d'Activité : Dans ce dernier mode toutes les contraintes sont gérées, les dépendences entre machines (par exemple le serveur de fichier ayant besoin du contrôleur de domaine pour pouvoir démarrer), la remontée de la passerelle vers le cloud (Gateway NCA), ainsi que la remontée des machines en elle-memes. Nous avons le test global d'une infrastructure couverte par un plan de reprise d'activité. Ce mode est semblable à celui utilisé lors de l'activation réelle du PRA afin de pouvoir simuler efficacement.
En synthèse : l'utilisation de l'Infrastructure As a Code chez Nuabee
Gérer son infrastructure comme un code permet d'apporter des principes de programmation comme le contrôle de version, les tests unitaires et de non régression au monde de l'administration système.