DevOps : transformer le processus de développement en une chaîne de production logicielle - Partie 1

Bénéfices de l’approche DevOps

L’accroissement du nombre de développeurs dans une entreprise s’accompagne souvent d’une diminution de la productivité, due aux difficultés d’intégration, de communication et de validation des composants développés.

DevOps facilite la montée en échelle des organisations.

Combiné à un style d’architecture d’entreprise adaptée, qui promeut l’autonomie des équipes et l’indépendance des applications (cf. style d’architectures micro-services), DevOps permet de continuer à développer, à intégrer, à tester et à déployer en flux continu lorsque la taille de l’entreprise augmente.

Pour cela, les processus de développement sont transformés en chaînes de production logicielle automatisées. Les activités manuelles répétitives des analystes, développeurs, testeurs et opérateurs sont converties, autant que possible, en activités automatiques.

Automatisation du processus de développement

L’automatisation de la chaîne de production logicielle s’accompagne de la mise en œuvre d’une boucle de feedback rapide.

A tous les niveaux du processus de production logicielle, les intervenants doivent contrôler que les modifications apportées n’induisent pas d’anomalies.

A chaque fois qu’une modification est introduite dans le système de gestion de configuration, des tests automatiques s’exécutent rapidement dans un environnement identique à celui utilisé en production et valident le bon fonctionnement du système.

Note : Dans le cas d’architectures micro-services, il n’est pas toujours possible de reproduire un environnement de test complet, compte-tenu du nombre élevé de composants à déployer. Le système étant distribué la problématique des tests automatiques qui permet d’assurer la non-régression prend un nouveau tour.

Les tests E2E (end to end) deviennent encore plus difficiles à réaliser qu’avant et la bonne communication d’un micro-service avec le reste du système (les tests d’interface) prend une importance accrue, cf. approche « Consumer Driven Contract »

 

La chaîne de production logicielle se transforme en une « Pipeline » et fournit une boucle de retour rapide aux équipes à chaque fois qu’une modification est introduite dans le système de gestion des codes source.

Un exemple de pipeline

Un exemple de pipeline

Pratiques liées à la transformation DevOps

La transformation DevOps de l’entreprise nécessite d’adresser de multiples domaines d’activité :

  1. La gestion de la configuration
  2. La gestion des codes sources
  3. La gestion des données de test et de production
  4. Les tests
  5. Les déploiements d’application
  6. La gestion des environnements

Dans chacun de ces domaines, l’organisation peut se révéler plus ou moins mature, avec des processus de travail plus ou moins efficaces, maîtrisés et automatisés.

Docker facilite la construction de la pipeline en permettant d’automatiser la gestion des environnements.

Dans ce domaine, les critères de maturité de l’organisation sont :

  • Les environnements (machines virtuelles) sont provisionnés de façon automatique
  • L’environnement dans lequel le système est déployé est reconstruit de façon rapide et répétable
  • L’état de l’environnement dans lequel le système est déployé est maîtrisé et géré comme du code source (historisation et traçabilité des modifications)

Gérer les environnements d’exécution avec Docker

Docker est un logiciel libre et une plateforme de gestion de conteneurs dont la première version est sortie en mars 2013. Le site web de Docker indique :

“Enterprises use Docker to build agile software delivery pipelines to ship new features faster, more securely and with confidence for both Linux and Windows Server apps.”

Les solutions de containerisation d’applications telles que Docker jouent en effet un rôle essentiel dans la construction de la ligne de production continue.

Docker s’appuie sur les cgroups et les namespaces du noyau Linux pour isoler le système d’exploitation tel que vu par l’application, la plaçant ainsi dans un « conteneur » à l’instar des caissons métalliques utilisés en logistique pour faciliter le transport de marchandises.

Docker permet en particulier :

  • D’économiser l’utilisation des ressources machines : le conteneur n’inclut pas de système d’exploitation à la différence des machines virtuelles
  • De fiabiliser la gestion des environnements, gérés comme du code source
  • De maîtriser les modifications apportées aux environnements à l’aide des outils de gestion de configuration (tel que Git, Mercurial …)
  • De réduire les délais de déploiement : rapidité de construction des images et de démarrage des conteneurs, « build once, deploy anywhere »
  • De réutiliser les environnements publiés par des tiers : Docker HubDocker Store
  • De disposer de registres de versions d’applications prêtes à être livrées en production à partir du Docker registry
  • D’amener l’entreprise à disposer de tout le nécessaire pour reconstruire de zéro l’intégralité d’une application, bénéficiant ainsi d’un plan de reprise sur « désastre »
  • D’accroître la portabilité des applications à l’intérieur du SI et vers le cloud

Il est possible de construire automatiquement les environnements utilisés dans la chaîne de production logicielle ou « Pipeline », rendant le « Continuous Delivery » atteignable plus facilement.

Docker : build once, deploy anywhere

Docker : build once, deploy anywhere

Les « essaims » de conteneurs : Docker Swarm Mode

A partir de la version 1.12, le moteur Docker inclut le « Docker Swarm Mode » qui adresse la gestion de conteneurs en cluster. Docker swarm mode permet de gérer les applications à un plus haut niveau d’abstraction, comme des ensembles de services dont le déploiement, la répartition, la résilience et la scalabilité sont gérés par l’orchestration Docker Swarm.

La suite de cet article illustre la mise en œuvre d’un cluster à travers :

  • Le provisionning d’hôtes Docker avec Docker machine
  • La création du cluster de conteneurs Docker avec « Docker Swarm Mode »
  • Le déploiement de services sur le cluster
docker swarm mode

Docker Swarm Mode : mise en cluster de Docker engines

Fonctionnalités de Docker Swarm Mode

Docker Swarm Mode propose des fonctions de gestion de cluster et d’orchestration de conteneurs :

  • La localisation des services sur le parc des Docker Host grâce à un annuaire de services intégré dans lequel les conteneurs sont automatiquement enregistrés
  • Le chiffrage des communications entre conteneurs par défaut : « automatic TLS keying and signing »
  • Un modèle déclaratif de gestion des services permettant de déléguer au Swarm la gestion des conteneurs (répartition des conteneurs sur la grille des machines, détection des pannes et redémarrage (healthcheck), extensibilité (scaling de conteneurs) …)
  • La gestion réseau multi-host avec la possibilité de créer un réseau « overlay » propre aux services gérés par l’orchestrateur
  • Une répartition de charge automatique entre conteneurs fournissant le même service (load balancing)
  • Des mises à jour roulantes pour assurer des déploiements sans interruption de service (zero-downtime rolling update)
  • La haute disponibilité du service d’orchestration, grâce à l’utilisation du consensus Raft pour l’élection des nœuds maîtres

La deuxième partie de cet article illustre Docker et Docker Swarm mode à travers l’exemple d’une plateforme d’intégration et de déploiement déployée sur un cluster :

  • Jenkins LTS : orchestrateur des activités automatiques
  • Artifactory 5 : gestionnaire d’artefacts
  • SonarQube : analyseur de code source
  • Docker registry : registre d’images Docker

 

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !