Pourquoi notre workflow Devops est le plus efficace et rentable que vous puissiez trouver aujourd'hui ?

Chez Bearstech, nous utilisons des procédés "devops" depuis toujours, déjà motivés par une approche éco-responsable pour l'optimisation des ressources allouées sur de nombreuses infrastructures cloud dont nous assurons l'infogérance, nous avons opté pour les technologies de virtualisation dès 2007 afin de créer des environnements qui fonctionnent au plus près des besoins des applications. Petit à petit notre démarche a évolué pour stocker les rôles d'installation et la définition de notre infrastructure sur des dépôts de version dans une approche "GitOps"  qui nous a permis de consolider l'automatisation du déploiement d'une partie de notre infrastructure, en respectant les principes qui ont été décrits par RedHat:

• Un workflow standard pour le développement d'applications
• Une sécurité renforcée avec la définition des besoins de l'application dès le départ
• Une meilleure fiabilité grâce à la visibilité et au contrôle de versions via Git
• La cohérence entre tous les clusters, clouds et environnements sur site

Bearstech est donc une société qui a su industrialiser son infrastructure afin de concevoir, sécuriser, déployer, et maintenir des systèmes informatiques fiables.

Mais alors pourquoi proposer un workflow devops  pour le déploiement d’applications ?

Pour y répondre, revenons déjà sur ce que propose la mouvance devops.

Le devops, c'est quoi ?

D’un point de vue business, la mouvance "devops" est un moyen de rentabiliser les projets informatiques en intégrant la qualité dans le processus de développement. 

C'est un mouvement qui vise à optimiser les indicateurs clés de l’avancement des projets informatiques:

• “lead time” : vise à réduire le délai de mise en œuvre
• “process time” : vise améliorer le temps de traitement des demandes
• “percent complete and accurate” : vise à augmenter le taux des fonctionnalités finalisées dans un cycle de développement.

Pour tenir ces objectifs, il faut réduire la fragilité des applications.

La dette technique

La fragilité des applications, c’est ce qu’on appelle la "dette technique". Elle peut être causée par l'accumulation de code dupliqué qui multiplie les risques de bugs, ou par des régressions : le code de librairies / modules / dépendances qui n'est pas à jour ou qui est obsolète. Pour ça, il "suffit" de faire face au problème en factorisant le code et en augmentant la couverture de code par les tests.

Ensuite il y a aussi le fait que l'environnement de développement est difficilement reproductible pour le rendre compatible avec ce qui sera utilisé en production, surtout quand on travaille à plusieurs: mon environnement est-il bien à jour ? mes dépendances sont-elles bien toutes installées ? bénéficient-elles de la bonne version ? et mes collègues aussi ? etc...

Tester dans un environnement reproductible, et qui soit commun à tout le monde, et à chaque étape du développement, n'est pas aussi simple que cela peut paraître, et c'est là que Bearstech intervient afin de mettre à disposition son expertise pour déterminer un cadre méthodologique et des outils qui permettent d'apporter des preuves de la fiabilité d'une application dans ses différents environnements d'exploitation.

Avantages et limites de la conteneurisation

Docker a l'avantage de définir un langage commun entre les devs et les admins pour régler la question des dépendances logicielles pour une application donnée, et assurer un environnement prévisible et reproductible sur toute la chaîne d'intégration de l'application, jusqu'à son déploiement en production.

Toutefois, la reproductibilité a ses limites et on n'est jamais à l'abri d'une différence de version mineure entre 2 images Docker et cela peut entraîner quelques effets de bords. C'est pourquoi l'utilisation d'un serveur de CI qui va builder l'image contenant l'application afin d'y effectuer des tests d'intégration devient nécessaire :

• gain de temps puisque cette tâche est automatisée
• historique des tests consultable pour tous les membres du projet
• systématisation des tests d'intégration

En conteneurisant une application on peut facilement définir un environnement stable, et même de manière temporaire pour valider la fiabilité de l’application en faisant jouer des tests unitaires ou des tests fonctionnels, avant la publication en production.

SI tous les projets n’ont pas vocation à être conteneurisés en production, notamment les projets qui n’évoluent pas souvent, ce travail d’empaquetage des dépendances a un intérêt: les devs et les admins se mettent d'accord sur les dépendances, leurs versions, et le tout est décrit dans des fichiers. C'est une sorte de contrat.

Infrastructure As Code

Les technologies utilisées par le workflow devops de Bearstech sont toutes open-source et exploitent ce qu’on appelle l’Infrastructure As Code.

Bearstech utilise ces outils depuis de nombreuses années, dès lors que nous nous sommes mis à écrire des rôles Xen pour provisionner des machines virtuelles.

Notre workflow devops est centré sur un Gitlab , avec sa facilité pour versionner le code, créer des demandes, valider des merge-request, jouer avec les branches … Et avec son serveur de CI, nous définissons des runners pour les projets qui lancent des traitements automatiques sur le code des applications dans un environnement shell ou docker.

A chaque étape du workflow, nous utilisons des procédés spécifiques d'IaC.

• Développement de l'application : il est probable que les développeurs préféreront travailler dans un environnement Docker. Les dépendances logicielles peuvent ainsi être gravées (dans le silicium) de fichiers (Dockerfile et docker-compose) afin de permettre à la CI de reproduire l'environnement applicatif utilisé par les développeurs.
• Intégration : Afin de valider l'intégration de l'application dans son environnement d'exploitation, la CI va reproduire les étapes d'installation des composants, et lancer les services de l'application directement sur la CI. Le workflow se sert de la registry Gitlab qui permet de stocker les éléments construits dans la CI. Chacun des éléments est lié au job d'une pipeline dont il est originaire. On peut y stocker:
  • des images Docker
  • des artefacts
  • des assets packagés
• Tests unitaires et fonctionnels : Une fois l'application intégrée et instanciée sur la CI, il est possible de définir des tests fonctionnels sur l'application qui seront joués grâce à des images Docker qui embarquent des navigateurs headless (voir notre article sur les tests fonctionnels avancés )

• Déploiement : il suit la phase des tests et va s'appuyer sur les variables d'environnement  transmises par Gitlab pour exécuter les phases d'installation et configuration des éléments définis durant l'intégration (images Docker, assets, artefacts ...) à partir du code contenu dans le projet Gitlab. Notre workflow prévoit plusieurs modes de déploiements selon les besoins des projets:

  • applications exploitées nativement
  • applications conteneurisées

  Le système de déploiement prévu par notre workflow peut s'adapter aux besoins les plus fréquents des applications web. 

Profiter des bonnes pratiques

Échouer tôt

Échouer tôt pour réduire le temps et les coûts de réparation : il est moins coûteux de corriger un défaut au fur et à mesure qu'il est détecté tôt dans le cycle. Dans notre workflow, le procédé du "Shift Left" s'appuie sur l'utilisation des pipelines de Gitlab et le retour d'information qu'elles apportent lors du build de l'application, ou lors des tests, ou lors de la phase de déploiement facilitent la vie du développeur. Il peut ainsi déterminer les points bloquants à mettre en place lors des tests d'intégration ou des tests fonctionnels pour valider ou non le déploiement de l'application.

Un scénario d'intégration et de déploiement simple

Le test d'intégration dans la CI permet de valider le bon fonctionnement des dépendances logicielles. Si le test ne passe pas, le push de l'image Docker et le déploiement ne se lancent pas:

Déployer sereinement

Le déploiement se fait depuis un serveur Gitlab dédié au projet et infogéré par Bearstech, il utilise un compte Unix qui correspond au nom de votre projet.

Déploiement de conteneurs

Le déploiement de conteneur permet de lever une bonne partie de leur fragilité en exploitation :

• Dans le workflow, les conteneurs ne bénéficient jamais de super-privilèges: il est obligatoire de spécifier un utilisateur non root dans les images de vos applications
• il est interdit de définir des volumes dans les images, ils sont créés au déploiement par le workflow, et correctement partagés sur la machine hôte
• les services publiés dans les conteneurs ne sont jamais exposés publiquement, ils sont derrière un reverse-proxy qui s'occupe de la couche TLS
• afin de bénéficier des dernières mises à jour de sécurité pour vos conteneurs, nous maintenons à jour des images Docker de base que vos applications devront utiliser en priorité
• les services sensibles comme les bases de données sont déployés de manière native, ils ne tournent pas dans des conteneurs
• les logs de vos applications sont centralisés et accessibles directement depuis le conteneur en cours d'exploitation

Déploiement d'applications natives

Tous les projets n’ont pas vocation à être conteneurisés, c’est pourquoi notre workflow n’impose aucune règle prédéfinie, et s’adapte aussi aux modes de déploiement natifs

• le projet sera déployé et instancié vers une machine cible de manière native, en utilisant les ressources d'une VM derrière un serveur web.
• si besoin, la CI s’occupe de compiler les assets, et de les mettre à disposition dans les packages de Gitlab.
• le workflow s'occupe de récupérer le code et les packages, puis de les déployer en configurant convenablement l'environnement d’exploitation. Il s’occupe aussi des certificats via LetsEncrypt
• en plus du déploiement des sources, le workflow permet l'exécution de traitements "post-deploy" (vidange des caches, installation des tâches automatisées ...) avant l'instanciation de l'application

Un workflow qui couvre toutes les étapes du cycle de développement

Du développement à la mise en production, le workflow enchaîne les tâches nécessaires à la validation des applications :

• en staging, il peut être utile d'utiliser les conteneurs pour réaliser des déploiements différentiables selon les branches, pour faire de l'app-review.
• en production, on pourra opter pour un déploiement de l'application en natif pour bénéficier d'une infogérance qui privilégie la stabilité et la sécurité du système .

Dans cet exemple de pipeline qui contient un point bloquant, une application est intégrée, testée, puis déployée en staging puis en production, depuis un serveur de CI infogéré, en utilisant les services de déploiement fournis par Bearstech.

Services infogérés en production

La stabilité de l'environnement d'exploitation est une condition nécessaire pour améliorer la fiabilité des applications .

Il est pratique de développer (et de tester) avec des services directement fournis par les images Docker. Mais pour la production, les contraintes sont différentes: il est vivement conseillé de profiter de réglages fins du service, du backup, d’une potentielle réplication, et surtout de métrologie et d’une astreinte.

Les services pris en charge par Bearstech bénéficient d'infogérance et d'hébergement (mise à jour, maintenance, astreinte). Il est alors possible d'ordonner à l’infrastructure et à nos outils de créer les ressources nécessaires pour permettre aux applications de consommer le service infogéré (routage, authentification, base de données ...), et d'être alerté quand l'image Docker de l'application doit être re-buildée afin de bénéficier des dernières mises à jour de sécurité.

La supervision et le monitoring sont fournis par les outils de Bearstech.

Analyser pour s'améliorer

Le workflow devops de Bearstech est trans-disciplinaire, il apporte des outils d'analyse aux développeurs front et back pour améliorer leur code, aux administrateurs pour obtenir des mesures et tracer les logs, aux devops pour ajouter librement des étapes dans les procédures d'intégration, et aux chefs de projets pour pouvoir déployer plus fréquemment et sereinement.

Voici quelques exemples de services qui peuvent être ajoutés au workflow et qui peuvent aider à l'amélioration des applications.

Pa11y

Pa11y est un service d’analyse d’accessibilité de votre site web. Il génère un rapport en se basant sur le respect des directives fournies par le Web Content Accessibility Guidelines (WCAG). Bearstech peut intégrer dans le workflow un accès à Pa11y afin de générer un rapport d'accessibilité pour vous aider à valider la compatibilité du code produit avec ses directives.

Sitespeed

Bearstech peut mettre à dispostion un accès au service Sitespeed qui analyse la performance de votre site web côté client. La génération du rapport Sitespeed peut être intégré à la CI du projet en invoquant un script qui sera joué à chaque déploiement, et vous donner ensuite à la performance de chargement des pages web, et un indice de bilan carbone calculé par rapport à une évaluation de la consommation énergétique de l’application.

Les métriques récoltées par Sitespeed peuvent aussi être reportées dans notre outil de supervision sous Grafana.

Sonarqube

Sonarqube est un service d’analyse de qualité de code. L’outil analyse et fournit des indices sur la détection de bugs, de vulnérabilités, le taux de couverture des tests, le taux de duplication de code. Beartech peut mettre à disposition un service Sonarqube pour lancer une analyse du code de l'application par l'intermédiaire de la CI. Par exemple après la validation de la recette, au moment de passer sur un serveur d'homologation, il peut être judicieux de finaliser les développements en s'aidant du rapport de vulnérabilités produit par Sonarqube.

Conclusion

Les principes du workflow  reposent donc sur la reproductibilité des applications dans des environnements conformes à ce qui sera déployé en production afin de pouvoir mesurer leur fiabilité par des tests. La conformité des environnements doit valider la compatibilité des dépendances système et logicielles entre elles par une procédure automatisée et reproductible d'intégration de l'application et la mise à disposition d'un environnement de recette. Notre workflow permet de déployer les applications de manière native ou sous la forme de conteneurs. Les environnements d'exploitation bénéficient tous de l'infogérance de Bearstech , et en y adjoignant des services d'analyse de performance, notre workflow vous permet le suivi en continu de la qualité de service de vos applications.

Pour approfondir, accédez à la 2ème partie de l'article de présentation de notre workflow devops : "Fonctionnement d'un workflow DevOps idéal"