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 la technologie Xen dès 2007 afin de créer des machines virtuelles 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 tels que SVN puis Git 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 maintinir des systèmes informatiques fiables.

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

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" 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 (avec ses outils) qui permet d'apporter des preuves de la fiabilité d'une application dans ses différents environnements d'exploitation.

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 peut être particulièrement utile:

• 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.

Mais tous les projets n’ont pas vocation à être conteneurisés en production, notamment les projets qui n’évoluent pas souvent, pourtant 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évelopper: Pour le développement, 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égrer: Afin de valider l'intégration de l'application dans un environnement système, la CI va reproduire les étapes d'installation des composants, et lancer les services de l'application directement sur la CI. C'est le rôle du fichier .gitlab-ci d'enchaîner ces différentes étapes, puis d'ajouter les tests puis le déploiement. 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

• Tester: 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éployer: Le déploiement suit la phase des tests. Il va s'appuyer sur les variables (d'environnement et personnalisées) transmises par Gitlab, et exécuter les phases d'installation des éléments construits 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:
    • sites statiques (Jamstack ...)
    • sites LAMP (Wordpress ...)
  • 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. Il s'appuie sur des procédés écrits en shell ou sur des recettes Ansible.

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

Déploiement de conteneurs

Le workflow de Bearstech permet de lever une bonne partie de la fragilité des conteneurs 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 (Traefik) qui s'occupe de la couche TLS
• les services sensibles comme les BDD sont déployés de manière native, elles 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, sans avoir besoin de builder des images Docker (mais on peut aussi mixer les 2 modèles).

• 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.
• La CI s’occupe de compiler les assets, si besoin, et de les mettre à disposition dans les packages de Gitlab.
• Ensuite, 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.

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 avant leur livraison, et permet ensuite de les déployer selon les besoins :

• 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 2 points bloquants, 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.

A noter que le serveur de CI infogéré par Bearstech bénéficie également d'une infogérance. C'est un serveur qui doit être sécurisé car il peut être soumi à des opérations sensibles notamment si il utilise des conteneurs peu respectueux des règles de sécurité. C'est pourquoi nos serveurs de CI intègrent la technologie LXC (Linux Conteneurs) afin d'isoler les environnements d'exécution du reste de l'infrastructure du workflow.

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, mais 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). En choisissant cette option avec le workflow, pour un ou plusieurs services, 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 ...).

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’accéssibilité 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é afin de vous aider à valider la compatiblité 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 à dispostion 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 compatiblité des dépendances système et logicielles entre elles par une procédure de conteneurisation de l'application ou 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.