Rechercher
  • Jacky Montiel

DevOps d'entreprise - Enjeux et solutions (partie 2/2)


Le DevOps d'entreprise pose la question de l'harmonisation des pratiques et des outils DevOps à l'échelle de l'entreprise.

Dans un 1er article, nous sommes revenus sur la notion de DevOps d'entreprise et les enjeux qu'il représente. Nous avons conclu sur les 3 piliers d'une stratégie DevOps à l'échelle de l'entreprise :

  1. une méthodologie DevOps applicable à l'ensemble des projets de l’entreprise,

  2. un référentiel outils DevOps

  3. une gouvernance DevOps au sein de l'entreprise, s'appuyant sur une communauté interne DevOps.

Dans cet article nous allons développer une solution possible pour appliquer une telle stratégie.


1- Une méthodologie projet pour cadrer le DevOps

La méthodologie DevOps va établir le cadre de définition et de mise en place du DevOps dans un projet.

Voici la méthodologie en 6 étapes que nous conseillons :

  • Contexte et Objectifs Dans cette étape, on clarifie le contexte projet et les objectifs DevOps à atteindre en répondant à quelques questions clés : - est-ce un nouveau projet ou une évolution de projet existant ? - quels sont les équipes en jeu ? - y-t'il une approche DevOps déjà en place ? - quel est le niveau d'automatisation des tests déjà en place ? - que veut-on mettre en place ou améliorer au niveau DevOps pour ce projet ? - quel est le rythme des mises en production et le niveau d'automatisation des tests envisagé pour l'atteindre ? - y-a-t'il des contraintes réglementaires ? - quelle est la politique de sécurité à respecter ? - y-a-t'il des procédures ISO 9001 et ITIL à respecter ?

  • Définition du processus DevOps Le pipeline de traitements CI/CD est schématisé comme suit :

Cette étape consiste à décomposer le pipeline des traitements CI/CD (build, test, deploy), le pipeline de gestion de l'infrastructure en IaC (Create/Update/Delete) et la

coordinations des traitements (points de contrôles liés à la gouvernance). Le détail des actions des pipelines prend en compte : - le type d'application (100% spécifiques, application basée sur un framework externe, progiciel externe configurable) - le/les langage(s) (comment se fait le build), le type de tests ou de vérification de code dans le pipeline CI - l'architecture de run (monolithe sur serveur d'application, microservices containérisés déployés avec/sans orchestrateur, ....) dans le pipeline CD - les environnements de déploiement - le respect des contraintes identifiées dans l'étape 'Contexte & Objectifs' (sécurité,

obligation réglementaires ou normes d'entreprise).

  • Choix des outils Dans cette étape on fixera la stack d'outils(qu'on appellera Stack DevOps) qui va permettre de faire fonctionner le/les pipeline(s) définis précédemment et la coordination/communication entre équipe s'il y a plusieurs pipelines à orchestrer. Une stack DevOps comprend : - un orchestrateur de pipeline - des outils intégrés à l’orchestrateur pour réaliser les traitements des pipelines CI/CD/IaC. Le catalogue Outils Pour définir la stack DevOps, on s'appuiera sur un catalogue prédéfini par l'entreprise comprenant une liste d’orchestrateurs, et pour chaque orchestrateur un liste d'outils intégrables et des patterns d'usage selon la cible IaaS ou CaaS. Le catalogue a pour objectif d'harmoniser les outils déjà en place et de limiter les patterns d'usage. Chaque outil dans le catalogue possède un descriptif : - fournisseur - modes de gestion et d'exploitation : self-managé, PaaS, cloud, SaaS - coût (licence, support, ...) - mode de mise en place : packaging de l'installation.

  • Evaluation/Ajustement Dans cette étape on évalue, - le coût de mise en place et d'exploitation de la stack DevOps - le coût de prise en main des outils - le coût de développement des tests automatisés aux divers niveaux. On peut ainsi intégrer le coût du DevOps dans le coût global projet et procéder si besoin à des ajustements, voire adopter une approche incrémentale pour lisser les coûts.On définira aussi les KPI DevOps à suivre (cf ci-dessous). C'est là que l'usage d'un catalogue outils et de services de mise en place/support mutualisés va réduire le coût de mise en place.

  • Mise en place Cette étape consiste à installer la stack DevOps du projet sur la base des options retenues en phases 'Outil', puis à la configurer.

  • Monitoring de KPI DevOps Les KPI DevOps principales sont les temps de build, test, deploy, et la fréquence des déploiements ; ils peuvent être fournis par l'orchestrateur de pipelines, par des outils personnalisés intégrés à l'orchestrateur, ou encore recueillis manuellement à partir des données de l'orchestrateur.


2- Le référentiel outils

Le référentiel outils est organisé autour des orchestrateurs : en effet, l'orchestrateur va piloter le pipeline et doit s'intégrer avec des VCS (gestion du code application ou IaC), des outils de build/test/scan, s'interfacer éventuellement avec un service de stockage d'artefacts, et piloter l'outil de déploiement.


De même, les outils de monitoring et gestion des log pour surveiller à la fois l’infrastructure mais aussi l’application (métriques applicatives, logs pour le debug) sont essentiels dans l'approche DevOps feront partie du catalogue en tant qu'outils auxiliaires complémentaires à la stack DevOps.


La stack DevOps peut être basée sur 3 types de solutions :

  1. Implantée en cloud public avec une suite intégrée PaaS : AWS Codexxx suite, Azure DevOps, GCP Tools for DevOps, ... Ces suites disposent de nombreuses intégrations avec des outils externes mais ont certaines limites ; par exemple la suite AWS-Codexxx ne permet pas des déploiements sur EKS mais seulement sur ECS, et a fortiori pas sur des clusters Kubernetes autres. Un des avantages avec ces suites est qu'elle intègrent la partie IaC.

  2. En mode semi-intégré avec des stacks d'éditeurs/intégrateur comme CloudBees, XebiaLabs Ces solutions intégrées permettent de construire rapidement une stack DevOps sur la base d'options d'outils ; elles peuvent être self-managées avec support ou exploitées en mode SaaS ; l’avantage c'est qu'elle sont déployable dans tous types d’infrastructure ou en mode SaaS ; l'inconvénient est qu'elles introduisant une dépendance plus ou moins forte à l'intégrateur

  3. Avec un outil étendu : GitHub, GitLab, Jenkins peuvent couvrir aujourd'hui le pipeline CI/CD et pour les 2 premiers intègrent le VCS, et même d'une certaine manière le stockage d'artefacts. Ces outils nécessitent cependant une partie intégration d'outils de test et de vérification de code à réaliser soit-même.

  4. En mode intégration full DIY : assemblage personnalisé autour de multiples outils existant Ce choix permet de construire une stack sur mesure et peut être intéressant dans certains cas (notamment pour la cible Kubernetes où l'écosystème de solution est très riche).

Dans tous les cas, à l'échelle de l'entreprise il sera bon de proposer une stack 'standard' la plus ouverte possible sur laquelle les nouveaux projets pourront par défaut s'appuyer. Une telle stack permet de capitaliser sur sa maîtrise, améliorer ses usages à travers des retours d’expérience intrenes à l'entreprise.


Pour l'IaC, on doit combiner intégration de Git, un pipeline mettant en oeuvre un outil d'IaC (Terraform, CloudFormation, ARM Templates, Google CDM, ....).


Pour les tests les plus classiques on doit les intégrer dans le pipeline général comme illustré ci-dessus :

  • Test-Unitaires (TU) : ils sont réalisés avec les packages du language (ex: JUnit), des bibliothèques de mock du language ou de mock des services cloud (ex: localstack) ; ils sont déclenchés dans le Build

  • Tests automatisés validation : il sont en général réalisés sur un environnement de déploiement HorsProd

  • fonctionnels Web : Selenium,, Squash-TM/Robot-Framework, ...

  • pour les tests API : Newman ; ils sont opérés après le build ou en validation sur environnement de HorsProd

D'autres types de tests comme les test de performance ou de sécurité sont réalisés de manière spécifique et n'entrent généralement pas dans le pipeline DevOps. Il sont mis en oeuvre dans l'environnement HorsProd qui convient, avec les outils adaptés.


3- Une organisation et une gouvernance DevOps

Le dernier pilier de la méthodologie est l’organisation,indispensable pour que les outils soient utilisés efficacement.


Fédérer des équipes déjà autonomes et habituées à travailler sans contraintes au niveau DevOps, peut s'avérer délicat. Une approche collaborative pour la définition du catalogue process/outils décrit ci-dessus pourra faciliter cette opération.


La création d'une commission de validation des choix projet est essentielle pour échanger en groupe et garantir la cohérence DevOps d'entreprise.

Deux modèles d'organisation sont conseillés selon le contexte de l'entreprise :

  • Entreprise avec peu de projets (applications/produits) : une cellule DevOps transverse suffira pour définir et opérer le DevOps dans les divers projets

  • Entreprise avec de nombreux regroupés (par exemple en domaines métier) : chaque domaine dispose de sa cellule DevOps transverse, et une cellule transverse Méthodes/Outils au niveau entreprise est en charge de

  • produire/maintenir la méthodologie et le catalogue process/outils

  • fournir les stacks DevOps en s'appuyant sur une des 3 solutions citées ci-dessus (solution cloud, solution intégrateur, ou solution DIY)

  • conseiller les cellules devops de domaine pour le choix des stack DevOps dans les projets

  • valider les choix DevOps projets en commission s'ils sortent du cadre méthodologique/catalogue de l'entreprise

  • anime la communauté DevOps dans l'entreprise


4- Conclusion

Adopter une approche DevOps d'entreprise accroît la performance globale et réduit les coûts de la chaîne de déploiement des applications/produits. Elle passe par la mutualisation d'une méthodologie, d'un catalogue d'outils et d'une gouvernance entreprise/projet. Une cellule d'expertise DevOps est au cœur de ce dispositif. Son externalisation permet de démarrer rapidement en réduisant le coût de la transformation.


Pour mettre en oeuvre le dispositif décrit ci-dessus, CirrusLine propose un ensemble de des services externalisés de conseil/assistance DevOps à la carte.


Par ailleurs, Cirrusline propose aussi une stack DevOps pré-pakagée autour de GitLab : CirrusStack. Il s'agit d'un solution packagée 'légère' à faible dépendance avec l'intégrateur comprenant :

  • l'outil GitLab : utilisable en mode self-managé on-premise ou managée en cloud, servant à la fois de gestionnaire de source applicatif ou IaC, et d'orchestrateur de pipeline

  • un kit de runners conteneurisés intégrant des outils courants pour traiter des opérations de build, test, deploy, check, scan d'images dans les pipelines CI et CD

  • des templates de pipelines pour divers patterns de build (CI pour Java/JavaEE, Node, Python, JavaEE, ...), des déploiements applicatifs avec Ansible (cible VM ou containers non orchestrés) ou Helm pour les déploiement K8s, des templates Terraform pour le pipeline IaC.

  • en option : le couplage à un service de stockage d’artefacts Nexus, notamment des Images Docker, des charts Helm pour Kubernetes. Le service Nexus peut servir aussi de proxy sécurisé de bibliothèque, d'outils et d'images et de charts Helm publics.

Pour plus d'information sur CirrusStack nous consulter.

40 vues0 commentaire

Posts récents

Voir tout