Automatisation du lancement des applications et automatisation de l’infrastructure Présentation de la proposition de valeur de ces deux optionsPar Julian Fish, Director of Product Management, Serena Software (désormais membre de Micro Focus)
Livre blanc
Table des matières page
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Pourquoi opter pour l’automatisation ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Bref historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Le progrès n’est pas forcément une gageure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Qu’est-ce que l’automatisation de l’infrastructure ? . . . . . . . . . . . . . . . . . . . . . . 4Qu’est-ce que l’automatisation du lancement des applications ? . . . . . . . . . . . . 5Caractéristiques communes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Automatisation de l’infrastructure via Deployment Automation ou Puppet . . . 8Automatisation du lancement des applications via Deployment Automation ou Puppet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Valeur ajoutée des pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Déploiements basés sur des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
La question de l’extensibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Le meilleur des deux mondes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1www.microfocus.com
Résumé
Les entreprises ayant entamé leur transformation DevOps, ou recherchant simplement le
moyen d’automatiser l’installation et la configuration de leurs environnements, sont souvent
dubitatives quant à la valeur de l’automatisation du lancement des applications par rapport
aux outils d’automatisation de l’infrastructure . Il existe une pléthore d’outils, dont certains
remplissent, semble-t-il, les mêmes fonctions . Le présent document aborde deux leaders
du marché : la solution Micro Focus Deployment Automation1, dédiée à l’automatisation du
lancement des applications, et le logiciel Puppet2, qui gère l’automatisation de l’infrastructure .
Il détaille également les propositions de valeur de chaque produit, ainsi que le domaine principal
qu’il couvre et les avantages qu’il peut proposer au sein d’une chaîne d’outils DevOps intégrée .
Pourquoi opter pour l’automatisation ?
De nombreuses entreprises s’efforcent de simplifier le déploiement de leurs applications,
tout en garantissant la stabilité des opérations, dans le respect des SLA, et en vérifiant
que les objectifs en matière de réactivité des applications sont atteints . Pour assurer sa
survie, une société doit être capable de réagir plus efficacement aux aléas de l’activité et
de se « développer rapidement et sans heurt » . Pour atteindre ses objectifs en matière de
concurrence, elle a de plus en plus besoin d’automatiser la pile d’applications complète .
Malheureusement, la notion de « pile complète » tend à prendre un sens différent selon le
secteur d’activité du service .
Ainsi, le service des opérations considère souvent la « pile complète » comme l’infrastructure
requise pour héberger les applications hôtes et les systèmes sous-jacents, l’application jouant
le rôle de petit composant de la pile . Le service de développement, quant à lui, voit en elle
l’ensemble des niveaux de l’application, qui fonctionnent de concert, harmonieusement, sans
s’intéresser particulièrement à l’infrastructure sous-jacente . Du point de vue DevOps, tout
particulièrement, il s’avère que l’ensemble des composantes doivent collaborer étroitement
pour garantir une prise en charge efficace des ressources désormais considérées comme
critiques pour l’entreprise . Depuis une dizaine d’années, le service informatique n’est plus
perçu comme un facteur de différenciation commerciale . Ainsi, le fait de maintenir les systèmes
métiers en conditions opérationnelles n’est plus une valeur ajoutée : il s’agit désormais d’une
obligation . Pour les entreprises, l’application est reine . La différenciation commerciale et
la valeur métier dérivent des modifications apportées aux applications. Il est impératif de
mettre en oeuvre autant de changements métiers que possible et ce, très rapidement, tout en
maintenant des niveaux élevés en termes de qualité, de stabilité et de fonctionnalités . Or, les
processus de déploiement manuels des applications sont incapables de répondre à ces exigences
cruciales . L’automatisation est donc une étape obligatoire, et non facultative .
Le présent document aborde deux leaders du marché : la solution Micro Focus Deployment Automation, dédiée à l’automatisation du lancement des applications, et le logiciel Puppet, qui gère l’automatisation de l’infrastructure. Il détaille également les propositions de valeur de chaque produit, ainsi que le domaine principal qu’il couvre et les avantages qu’il peut proposer au sein d’une chaîne d’outils DevOps intégrée.
__________
1 Deployment Automation (SDA) est un outil leader du marché conçu pour assurer l’automatisation des applications. Il peut s’intégrer dans les outils de provisioning de l’infrastructure et les gérer. www.serena.com/sda
2 Puppet est un outil leader du marché conçu pour assurer l’automatisation de l’infrastructure. Il peut également gérer l’automatisation du lancement des applications, même si cela nécessite un codage et des manipulations supplémentaires. https://puppetlabs.com/
Table des matières page
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Pourquoi opter pour l’automatisation ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Bref historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Le progrès n’est pas forcément une gageure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Qu’est-ce que l’automatisation de l’infrastructure ? . . . . . . . . . . . . . . . . . . . . . . 4Qu’est-ce que l’automatisation du lancement des applications ? . . . . . . . . . . . . 5Caractéristiques communes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Automatisation de l’infrastructure via Deployment Automation ou Puppet . . . 8Automatisation du lancement des applications via Deployment Automation ou Puppet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Valeur ajoutée des pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Déploiements basés sur des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
La question de l’extensibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Le meilleur des deux mondes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2
Livre blancAutomatisation du lancement des applications et automatisation de l'infrastructure
Bref historique
Au cours des 15 dernières années, l’évolution dans le secteur de l’industrie du logiciel a
connu un net essor, qui a conduit à ce que l’analyste Glenn O’Donnell de Forrester qualifie
d’« industrialisation de l’informatique »3 . Cette évolution a d’abord été favorisée par une
réduction des dépenses informatiques au début des années 2000, puis par la récession du
secteur point-com et le développement massif d’Internet, en parallèle avec une approche
métier reposant sur le maintien des activités en continu . Ainsi, elle a fortement affecté
l’informatique en entreprise . Les entreprises qui, quinze ans auparavant, ne voyaient pas la
nécessité de créer un site Web d’entreprise, voire d’assurer aux clients un accès 24 heures
sur 24 à ce dernier, ont dû repenser entièrement leur stratégie . La réduction des dépenses
informatiques a poussé les services à faire toujours plus avec moins de moyens, en réduisant
les effectifs et en demandant plus d’efforts à l’infrastructure informatique de l’entreprise .
L’adoption de fonctionnalités permettant un accès en tout lieu à Internet nécessite un niveau
élevé d’efficacité opérationnelle, mais aussi une réactivité et une disponibilité des systèmes
encore inégalées . Du fait de la complexité de nombreuses applications d’entreprise, il n’est
plus aussi simple d’assurer une diffusion efficace et reproductible des changements métiers.
Le service informatique ne peut pas se contenter d’accélérer la diffusion de ces changements,
car l’entreprise court le risque d’exposer les applications à des tiers susceptibles de
rechercher des faiblesses ou un accès non autorisé à des systèmes back-office stratégiques.
Il est désormais nécessaire de déployer les applications rapidement, tout en assurant un
niveau de qualité et de sécurité élevé et en proposant la nouvelle fonctionnalité phare
attendue. Il n’est plus possible de garantir la fiabilité, la traçabilité et la reproductibilité
des opérations au moyen de processus manuels . En effet, une fourniture manuelle des
applications risque de compromettre la réussite de l’entreprise face à la concurrence .
Le progrès n’est pas forcément une gageure
Par tradition, les équipes de développement sont ouvertes au changement, par exemple à la
transition depuis les langages de programmation « hérités » comme COBOL vers d’autres
langages plus récents, tels que C et Java et .Net. Elles ont modifié leurs applications et
processus pour soutenir ces changements, même si, de prime abord, les coûts de cette
transition ont semblé plus importants que les avantages obtenus . Ainsi, le remplacement
des disciplines de gestion de projet Waterfall par Agile, l’adoption des pratiques LEAN et la
prévalence de l’adoption de logiciels Open Source illustrent bien la volonté des équipes de
développement d’encourager le changement . Comme les services de développement sont
plus efficaces et proposent des fonctionnalités métiers plus rapidement et plus efficacement,
les équipes dédiées aux opérations sont contraintes de fournir plus rapidement ces nouvelles
fonctionnalités .
Les entreprises qui, quinze ans auparavant, ne voyaient pas la nécessité de créer un site Web d’entreprise, voire d’assurer aux clients un accès 24 heures sur 24 à ce dernier, ont dû repenser entièrement leur stratégie.
__________
3 O’Donnell, Glenn. IT Is Industrializing—What Does That Mean To Me? (Effet et conséquences de l’industrialisation de l’informatique), blogue de 2010, visionnage du 24 février 2015 : http://blogs.forrester.com/glenn_odonnell/10-04-21-it_industrializing_%E2%80%93_what_does_mean_me
3www.microfocus.com
Depuis toujours, ces équipes gèrent les environnements opérationnels ou de production via
une approche axée sur le « risque zéro », comme leur activité le demande . Cette pratique
est parfaitement légitime, car l’entreprise requiert des systèmes stables et disponibles . En
effet, la gestion du fonctionnement d’un système de commande ou commercial ou le fait de
s’assurer qu’un système bancaire fournit des informations précises à ses clients représentent
une lourde responsabilité . Les systèmes opérationnels font l’objet de toutes les attentions,
comme en témoignent les différents investissements en matière de procédures, pratiques et
processus ITIL effectués par de nombreux services . Pour que l’entreprise puisse assurer un
suivi efficace des procédures et pratiques communes, il est impératif que toutes les parties
prenantes s’accordent .
Alors que les entreprises s’efforcent de se démarquer de la concurrence en proposant aux
clients la meilleure expérience possible, en parallèle avec de nouvelles fonctionnalités
attractives, l’accent est mis sur l’augmentation des modifications apportées aux applications
et ce, aussi rapidement et efficacement que possible. La question se pose alors : comment
réconcilier deux besoins apparemment contradictoires ? Est-il possible d’accélérer la
fourniture d’applications, comme l’exige le service de développement, tout en proposant les
niveaux de stabilité, de traçabilité, de contrôle et de rigueur que requiert le service dédié aux
opérations, et en respectant les exigences réglementaires, de l’entreprise ou du secteur ?
_______________________________________________________________
Alors que les entreprises s’efforcent de se démarquer de la concurrence en proposant aux clients la meilleure expérience possible, en parallèle avec de nouvelles fonctionnalités attractives, l’accent est mis sur l’augmentation des modifications apportées aux applications et ce, aussi rapidement et efficacement que possible.
Fig. 1
Défis liés au développement et défis liés aux opérations
_______________________________________________________________
4
Livre blancAutomatisation du lancement des applications et automatisation de l'infrastructure
L’automatisation du déploiement et de l’installation des applications ainsi que des configurations système permet de garantir le respect de la cohérence à tous les niveaux de l’environnement, la reproductibilité éventuelle des déploiements et la possibilité de mettre en place et d’effectuer un suivi d’audits complets, dans le but d’identifier la version des artefacts déployés dans un environnement spécifique, à un moment donné.
Grâce aux avancées technologiques, il est désormais beaucoup plus simple d’automatiser
la fourniture d’applications, ainsi que l’infrastructure sous-jacente . En effet, le recours à
l’automatisation ne peut que favoriser le mouvement DevOps, qui s’efforce de gérer les
principaux défis liés aux communications, aux processus et au personnel au sein de deux unités
organisationnelles (développement et opérations) . Auparavant, les services se sont rendu compte
que la recompilation de code dans des environnements différents donnait lieu à des sorties de build
différentes et entraînait de nombreux problèmes dans les environnements suivants . De la même
manière, ils prennent de plus en plus conscience que le manque de cohérence d’un déploiement
dans des environnements différents est également source de difficultés et de défis majeurs.
L’automatisation du déploiement et de l’installation des applications ainsi que des configurations
système permet de garantir le respect de la cohérence à tous les niveaux de l’environnement, la
reproductibilité éventuelle des déploiements et la possibilité de mettre en place et d’effectuer
un suivi d’audits complets, dans le but d’identifier la version des artefacts déployés dans un
environnement spécifique, à un moment donné. Par ailleurs, le recours à l’automatisation permet
généralement de réduire le temps passé à exécuter un déploiement, à renforcer la qualité des
produits fournis (une machine ne commet pas d’erreur et n’oublie pas d’exécuter une commande)
et d’apporter la preuve que les opérations exécutées correspondent exactement à ce qui était prévu .
Ainsi, les livrables clés en matière de conformité des audits sont disponibles .
Toutefois, pour déployer une application, il ne suffit pas de déplacer des fichiers d’un système
vers un autre. Il peut être nécessaire de créer ou d’étendre l’infrastructure afin qu’elle puisse
prendre en charge de nouvelles fonctionnalités et une capacité de stockage supérieure, ou
mettre en oeuvre les nouvelles fonctionnalités de l’application . Tout cela peut nécessiter des
routines d’installation complexes . Les fonctions d’automatisation de l’infrastructure et du
lancement d’applications sont légèrement différentes, comme nous allons le voir .
Qu’est-ce que l’automatisation de l’infrastructure ?
Ce type d’automatisation porte sur la création et la gestion des environnements,
depuis les opérations d’installation des systèmes d’exploitation et d’installation et de
configuration des serveurs sur des instances physiques, virtuelles ou cloud jusqu’à la
configuration des communications entre les instances et les logiciels. On parle également
de « provisioning », d’« infrastructure avec scripts », d’« infrastructure as code » ou de
« gestion de la configuration » (expression ayant différentes significations selon l’étape
du cycle de vie abordée). Le principe est simple : définir une configuration système via un
script ou un ensemble de scripts, afin de permettre aux utilisateurs de créer ou de recréer
un environnement aussi aisément et rapidement que possible, tout en limitant le nombre
d’erreurs et en proposant des délais raccourcis .
5www.microfocus.com
Qu’est-ce que l’automatisation du lancement des applications ?
Il s’agit de la gestion avec scripts des applications au sein des environnements . Cela inclut
l’installation, la configuration et le déploiement des applications sur des environnements
physiques, virtuels ou cloud . Il se peut que les environnements cibles aient été créés via
l’automatisation de l’infrastructure . L’automatisation du lancement des applications
inclut la définition du mode d’installation et de déploiement des applications et des
interactions entre les différentes couches d’une application lors de l’exécution . On parle
également d’« automatisation des applications », d’« automatisation du déploiement »,
L’automatisation du lancement des applications inclut la définition du mode d’installation et de déploiement des applications et des interactions entre les différentes couches d’une application lors de l’exécution.
Fig. 2
Automatisation de l’infrastructure
_______________________________________________________________
6
Livre blancAutomatisation du lancement des applications et automatisation de l'infrastructure
de « déploiement agile », voire de « gestion des versions » . Le terme « script » porte
généralement sur les outils axés sur les processus, personnalisés, déclaratifs et de package,
avec ou sans fonction de définition d’interface utilisateur. Le principe est simple : définir un
modèle via un script ou un ensemble de scripts, afin de permettre aux utilisateurs de créer ou
de déployer des applications aussi aisément et rapidement que possible, tout en limitant le
nombre d’erreurs et en proposant des délais raccourcis .
_______________________________________________________________
L’automatisation du lancement des applications est également qualifiée d’« automatisation des applications », d’« automatisation du déploiement », de « déploiement agile », voire de « gestion des versions ».
Fig. 3
Automatisation du lancement des applications
_______________________________________________________________
7www.microfocus.com
L’automatisation du lancement des applications et l’automatisation de l’infrastructure peuvent être considérées comme complémentaires dans les contextes plus vastes de DevOps et de la distribution continue ou du déploiement continu.
__________
4 Le principe de la livraison continue a pour objectif de maintenir votre application dans un état permettant son déploiement en production et ce, à tout moment. Blogue de Martin Fowler, visionnage du 24 février 2015 : http://martinfowler.com/delivery.html
5 Dans le cadre du déploiement continu, chaque modification est déployée dans l’environnement de production, chaque jour, voire plus souvent. Blogue de Martin Fowler, visionnage du 24 février 2015 : http://martinfowler.com/delivery.html
Caractéristiques communes
Ces deux approches peuvent être considérées comme complémentaires dans les contextes
plus vastes de DevOps (processus et pratiques visant à aligner les opérations des équipes de
développement et dédiées aux opérations) et de la distribution continue4 ou du déploiement
continu5 . Ces deux types d’outils partagent des buts communs, à savoir l’optimisation de la
réactivité, la réduction du nombre d’erreurs, l’amélioration des audits, de la responsabilité
et de la traçabilité, ainsi que la volonté de proposer des scripts pour toutes les opérations .
Ainsi, ils sont souvent perçus comme étant en concurrence, ou interchangeables, le cas
échéant. En réalité, ces deux outils présentent leur propre objectif, clairement défini, ainsi
que leur propre domaine de prédilection . Certes, vous pouvez sans doute utiliser l’un de ces
outils pour effectuer certaines des fonctions de l’autre, mais il est préférable de choisir l’outil
adapté à la tâche .
_______________________________________________________________
Automatisation du lancement des applications
Automatisation de l’infrastructure
Déploiements axés sur les processus ● ● Déploiement d’applications ● ● Installation d’applications ● ● Prise en charge du pipeline ● ● Gestion de l’environnement ● ● Provisioning de l’infrastructure ● ● Modification de l’infrastructure ● ● Provisioning des environnements sans système d’exploitation
● ● Automatisation de la pile complète (basée sur une chaîne d’outils)
● ●
Fig. 4
Automatisation du lancement des applications et automatisation de l’infrastructure
_______________________________________________________________
8
Livre blancAutomatisation du lancement des applications et automatisation de l'infrastructure
Automatisation de l’infrastructure via Deployment Automation ou Puppet
Deployment Automation peut permettre d’exécuter un sous-ensemble des tâches
d’automatisation de l’infrastructure, au moyen de scripts ou de plug-in existants pour des
outils tiers. Dans certains cas, cela peut suffire à assurer l’automatisation de l’infrastructure.
Parmi ces activités, citons le provisioning virtuel ou basé sur le cloud, qui permet l’ajout de
capacité virtuelle ou cloud supplémentaire au moyen d’une image prédéfinie et configurée.
La pratique consistant à créer une infrastructure basée sur une image prédéfinie et
configurée est généralement qualifiée de « provisionnement de Gold Image ». En effet, la
configuration supplémentaire requise une fois l’infrastructure créée est réduite. Ce modèle
de provisioning d’infrastructure est adapté lorsque les services souhaitent étendre leur
infrastructure d’applications existante horizontalement ou verticalement, afin de proposer
une capacité ou des fonctionnalités supplémentaires . Dans cet exemple, le provisioning de
l’infrastructure virtuelle peut être confié aux plug-in VMware ESX/ESXi ou Workstation,
les nouvelles images virtuelles étant provisionnées . Une fois l’instanciation effectuée,
les nouvelles images mettent à jour les paramètres des propriétés des agents, afin de
permettre aux nouveaux agents de s’enregistrer automatiquement auprès des groupes de
réserve corrects sur le serveur Deployment Automation . Le provisioning de l’infrastructure
cloud peut être effectué via des plug-in Amazon, Azure ou vCloud, les nouvelles images
cloud étant provisionnées . Une fois l’instanciation effectuée, les nouvelles images
mettent à jour les paramètres des propriétés des agents, afin de permettre aux nouveaux
agents de s’enregistrer automatiquement auprès des groupes de réserve corrects sur le
serveur Deployment Automation .
Par contre, l’automatisation de l’infrastructure au niveau de la machine physique
ou sans système d’exploitation nécessite des fonctionnalités plus approfondies . Or,
Deployment Automation est un outil d’automatisation des applications qui n’est pas conçu
pour cela . Dans ce cas, l’utilisation d’un outil tiers du type Puppet est recommandée, l’outil
Deployment Automation contrôlant le provisioning de l’infrastructure . Un ensemble de
compétences spécifique est requis pour l’utilisation d’un outil de provisioning tel que Puppet.
Même si la communauté dédiée au développement propose certains modules et manifestes
prédéfinis, les compétences requises pour créer, modifier et mettre à jour ces manifestes sont
souvent l’apanage de spécialistes ayant évolué dans le secteur des opérations . Pour offrir une
infrastructure de base adaptée sur laquelle déployer les applications, il est impératif de savoir
quels paramètres de configuration, de mémoire, de kernel ou système doivent être définis lors
de l’instanciation, et comment déployer un système d’exploitation de manière efficace, avec
les paramètres de mise en réseau et de sécurité . Il faut également connaître les exigences des
ensembles de stockage des données connectés en termes d’E/S disque lors de l’instanciation
de la nouvelle infrastructure au sein d’un datacenter beaucoup plus volumineux .
Un ensemble de compétences spécifique est requis pour l’utilisation d’un outil de provisioning tel que Puppet. Même si la communauté dédiée au développement propose certains modules et manifestes prédéfinis, les compétences requises pour créer, modifier et mettre à jour ces manifestes sont souvent l’apanage de spécialistes ayant évolué dans le secteur des opérations.
9www.microfocus.com
Les recettes, livres de recettes et autres scripts de définition sont généralement écrits
dans un langage spécifique au domaine, l’installation et la configuration des déploiements
d’infrastructure nécessitant certaines connaissances en matière de création de scripts . Le
déploiement d’applications sur cette « pile » prédéfinie ou personnalisée représente l’extension
logique du provisioning de l’infrastructure ; après tout, vous déployez votre matériel flambant
neuf pour une bonne raison. L’objectif final est d’être capable de définir le processus de
déploiement pour le provisioning de l’infrastructure, et de faire appel aux modules et
manifestes adéquats pour créer l’infrastructure physique, déployer la nouvelle infrastructure
virtuelle et garantir la configuration correcte des applications sur la nouvelle pile. Grâce à
des plug-in destinés aux outils de provisionnement tels que Puppet, les services bénéficient
d’un outil best-of-breed pour créer l’infrastructure, de fonctionnalités de traitement pour
l’outil d’automatisation, mais aussi de la possibilité de déployer les applications de manière
transparente dans le nouvel environnement, via un processus convivial et défini de manière
graphique, qui dispose de fonctions complètes d’audit et de traçabilité .
_______________________________________________________________
Grâce à des plug-in destinés aux outils de provisionnement tels que Puppet, les services bénéficient d’un outil best-of-breed pour créer l’infrastructure, de fonctionnalités de traitement pour l’outil d’automatisation, mais aussi de la possibilité de déployer les applications de manière transparente dans le nouvel environnement, via un processus convivial et défini de manière graphique, qui dispose de fonctions complètes d’audit et de traçabilité.
Fig. 5
Provisioning de la pile complète
_______________________________________________________________
10
Livre blancAutomatisation du lancement des applications et automatisation de l'infrastructure
Automatisation du lancement des applications via Deployment Automation ou Puppet
Comme nous l’avons vu lorsque nous avons abordé l’automatisation de l’infrastructure,
les deux domaines d’automatisation associés fournissent les fonctionnalités requises pour
mettre en oeuvre les principes DevOps au sein d’un service . Toutefois, comme nous l’avons
vu, il est préférable de se concentrer sur certains aspects clés lors de l’automatisation des
applications. Si, pour déployer votre application, il suffit d’exécuter un script shell ou batch
afin de copier les fichiers et de les coller à l’emplacement correct, il se peut que les outils
d’automatisation de l’infrastructure fournissent la fonction (voire la traçabilité) qu’il vous faut .
Malheureusement, ce type de déploiement simple est extrêmement rare dans le secteur des
logiciels d’entreprise. En général, il ne suffit pas de copier un fichier et d’exécuter un script
pour déployer une application n-tier, qui peut inclure des dépendances reliant différents
niveaux de composants au sein de cette application et nécessiter l’utilisation de plusieurs
systèmes d’exploitation dans différents environnements, ainsi que l’exécution d’étapes
manuelles en plus des scripts . Lorsque plusieurs composants d’une application ou plusieurs
applications doivent être déployés, en série ou en parallèle, les fonctionnalités des outils
d’automatisation de l’infrastructure sont très sollicitées, et vous êtes contraint d’utiliser
des scripts de chaîne d’une incroyable complexité, qui s’avèrent aussi difficiles à gérer qu’à
comprendre . Même un déploiement d’application simple sur des serveurs d’applications
couramment utilisés (comme Tomcat) nécessite des scripts détaillés et complexes . Ainsi, pour
déployer un fichier WAR sur Tomcat via Puppet, il est nécessaire d’exécuter plus de 800 lignes
de code. L’actualisation ou la modification de ces scripts en fonction des besoins de l’entreprise
peut devenir une préoccupation constante pour un spécialiste hautement qualifié et bien
payé. Par contraste, le déploiement d’un fichier WAR sur un serveur d’applications Tomcat au
moyen de Deployment Automation est un processus en une seule étape, représenté de manière
graphique sur l’écran de l’utilisateur final. Les éventuelles personnalisations ou modifications
apportées à la configuration lors du passage d’un environnement à un autre sont transmises
en tant que paramètres à cette étape, ce qui assure la reproductibilité complète du processus,
depuis l’environnement de développement jusqu’à l’environnement de production .
Valeur ajoutée des pipelines
Quel que soit son type, le processus d’automatisation repose sur un principe clé : l’état
final est connu et peut être obtenu de manière reproductible. Pour éviter les erreurs lors
d’un déploiement, il est crucial d’assurer la cohérence entre les différents environnements .
Il arrive souvent que les responsables des versions et les ingénieurs d’exploitation et
qualité aient des difficultés à déployer des applications dans l’environnement choisi et se
voient répondre par leurs homologues du service d’ingénierie, quelque peu moqueurs, que
En général, il ne suffit pas de copier un fichier et d’exécuter un script pour déployer une application n-tier, qui peut inclure des dépendances reliant différents niveaux de composants au sein de cette application et nécessiter l’utilisation de plusieurs systèmes d’exploitation dans différents environnements, ainsi que l’exécution d’étapes manuelles en plus des scripts.
11www.microfocus.com
l’opération a parfaitement abouti dans leur environnement. Sans objectif ou état final cible
cohérent, l’automatisation s’avère futile et ne propose aucune valeur ajoutée durable . Bien
sûr, l’état final cible de toute initiative de distribution continue ou DevOps consiste à être
capable de fournir des applications à un environnement de production à tout moment, via
une méthode simple, reproductible, automatisée et conforme aux audits . Toutefois, tout
comme une activité de planification préalable assure la réussite et l’exécution dans les temps
des opérations, il est impératif de bien connaître les mécanismes, étapes et niveaux de
validation requis pour fournir l’application à l’environnement de production . Il est de plus
en plus optimiste d’espérer que le code créé dans des environnements de développement
fonctionnera en toute transparence dans un environnement de production présentant
des configurations, paramètres d’exécution et d’infrastructure et ensembles de données
différents . C’est tout particulièrement vrai lorsque le processus de déploiement doit gérer
des applications (et des dépendances entre ces dernières) extrêmement complexes . Pour
de nombreuses entreprises, le simple fait de définir des dépendances entre les applications
et de connaître l’impact d’une modification apportée à une application sur une autre
application s’avère aussi compliqué que fastidieux . De nombreuses entreprises de fourniture
d’applications ont pour objectif final de garantir un déploiement réussi dans le bon
environnement et ce, en temps et en heure .
Pour vérifier que cet objectif est atteint, le principe du chemin vers la production ou pipeline
de déploiement joue un rôle crucial . Les pipelines de déploiement ont pris différentes formes
au cours des années, depuis le cycle de vie traditionnel du développement logiciel (dans le
cadre duquel le développement est suivi de tests, puis d’une mise en production) jusqu’aux
chemins vers la production, dynamiques et définis de manière visuelle, qui peuvent varier en
fonction de l’application et du risque éventuel associé à son déploiement .
Lors de la définition d’un ou de plusieurs pipelines, les clients posent de nombreuses
questions, notamment celle-ci : « Mes applications requièrent-elles toutes le même
pipeline ? » Vous pouvez tout simplement étudier toutes les applications en question
et définir les exigences de chacune en termes de conformité et d’audit. Un site intranet
nécessite-t-il le même degré de rigueur et de validation qu’un système commercial ou
bancaire en ligne, orienté client ? Pour la plupart des services, la réponse est clairement
« non » . Si la mise en place de mécanismes de rigueur et de contrôle est nécessaire pour les
applications orientées client à haute visibilité et très utilisées, il n’en va pas de même pour
les applications de test internes, les sites intranet ou les applications non prioritaires . Pour
garantir une adoption réussie de l’automatisation, il est impératif d’associer des pipelines
différents aux diverses applications .
Il est de plus en plus optimiste d’espérer que le code créé dans des environnements de développement fonctionnera en toute transparence dans un environnement de production présentant des configurations, paramètres d’exécution et d’infrastructure et ensembles de données différents. C’est tout particulièrement vrai lorsque le processus de déploiement doit gérer des applications (et des dépendances entre ces dernières) extrêmement complexes.
12
Livre blancAutomatisation du lancement des applications et automatisation de l'infrastructure
Lorsque vous définissez la reproductibilité des déploiements dans plusieurs environnements,
ainsi que la vérification de la conformité et du respect des normes, les pipelines jouent
un rôle clé . Vous pouvez aisément déployer les mêmes applications au moyen des mêmes
processus, dans plusieurs environnements, en définissant un pipeline et en le mettant en
oeuvre. Grâce à eux, il est possible d’identifier les écarts entre les environnements.
Deployment Automation inclut une fonction de pipeline graphique complète . Vous avez
la possibilité d’imposer l’utilisation de ce pipeline, voire de promouvoir automatiquement
les applications d’un environnement à l’autre (si le déploiement précédent s’est terminé
correctement) . Or, Puppet ne propose aucun pipeline . Cependant, grâce aux scripts de
chaîne, les tâches d’automatisation peuvent être liées . Pour ce scénario, il est conseillé de
faire passer les tâches Puppet via un processus graphique, par voie graphique, dans SDA,
et de suivre le processus graphique défini pour le pipeline de déploiement .
Déploiements basés sur des modèles
Une bonne compréhension du mode de déploiement réel des applications cibles joue un
rôle critique dans l’adoption d’un outil d’automatisation, quel qu’il soit . Vous ne pouvez
pas automatiser les déploiements d’applications si vous ne connaissez pas les étapes
requises à cette fin. Grâce aux déploiements basés sur des modèles (comme ceux qu’utilise
Deployment Automation), les utilisateurs finaux peuvent définir de manière graphique le
processus de déploiement d’application dans son ensemble, y compris les dépendances
d’application et les interactions entre les systèmes . Le fait de pouvoir modéliser de manière
graphique les processus de déploiement et les pipelines associés s’avère particulièrement
avantageux par rapport à l’utilisation d’applications de type déclaratif . En effet, ces dernières
nécessitent une bonne connaissance des processus et une compréhension étendue du code
utilisé pour effectuer un déploiement . Prenons un exemple simple, dans lequel un utilisateur
souhaite déployer une application sur un serveur d’applications tel que Tomcat . Dans un
système basé sur des modèles, la définition de l’activité à effectuer est tracée de manière
graphique sur un plan, qui indique l’étape et le processus à effectuer . Dans un système
déclaratif, cette même activité nécessite la modification du code. Dans le cas présent, il
est nécessaire de modifier un artefact contenant près de 1 000 lignes de code. Bien sûr,
un nouvel utilisateur appréhendera plus aisément une définition de processus graphique
qu’un nouveau langage de programmation associé à des centaines de lignes de code . Les
modifications ultérieures seront également plus simples, car les personnalisations seront
faciles à afficher lors du processus de déploiement ; inutile de parcourir des bases de codes
complexes .
Vous ne pouvez pas automatiser les déploiements d’applications si vous ne connaissez pas les étapes requises à cette fin.
13www.microfocus.com
La question de l’extensibilité
Les environnements des entreprises sont complexes . L’exécution de la version la plus récente
et la plus avancée d’un logiciel sur la version la plus évoluée d’une infrastructure n’est
jamais chose aisée . Dans la plupart des services d’entreprise existant depuis longtemps, les
applications héritées doivent coexister avec les nouveaux systèmes, ainsi que diverses versions
de langages de programmation, de composants d’exécution et de couches d’abstraction .
Pour nombre de ces services, une migration vers une version plus récente d’une application
nécessite également la migration de l’infrastructure et des postes de travail des utilisateurs,
ainsi que la mise à jour des interfaces de données existantes . Comme les applications à mettre
à jour lors du déploiement présentent des versions différentes, vous devez gérer l’interface
entre la technologie d’automatisation et le système tiers . Or, cette interface s’avère complexe et
difficile à mettre à jour, ce qui vous met en fâcheuse posture. Deployment Automation propose
un grand nombre d’intégrations prêtes à l’emploi dans plusieurs systèmes tiers courants,
qu’il s’agisse de bases de données, de middleware ou de serveurs d’applications, voire d’outils
de test . Le modèle de plug-in extensible utilisé par l’application permet la création rapide de
plug-in pour des systèmes tiers, ce qui permet à la plate-forme d’automatisation d’atteindre
tous les niveaux de l’entreprise. Les manifestes Puppet sont un excellent moyen de définir
votre infrastructure sous forme de code (« infrastructure as code ») et de piloter la génération,
la mise à jour et la destruction de l’infrastructure dans le cadre d’un processus de déploiement
ou de provisioning prédéfini de la pile complète .
Le meilleur des deux mondes
Comme nous l’avons vu, le provisioning de la pile complète peut impliquer toute la pile
d’infrastructure et d’applications . Pour les services cherchant à tirer parti de la distribution
continue et de la technologie de transition, ainsi que des ressources et processus de mise
en place de DevOps, le déploiement d’applications, le provisioning de l’infrastructure et
les processus visant à assurer leur synchronisation sont des composants clés . Grâce aux
outils de provisioning de l’infrastructure, il est possible de s’assurer que l’infrastructure
de base est correctement configurée pour les déploiements d’applications à venir. Le
recours à des processus cohérents lors du déploiement d’applications et d’infrastructures
garantit le respect de la conformité et des audits, mais aussi la reproductibilité et la création
d’informations exploitables . Cela permet également de réduire la durée du déploiement,
tout en supprimant les risques associés aux opérations manuelles . L’automatisation de
l’infrastructure via Deployment Automation est la première étape vers la transformation des
services, la simplification des processus et l’accélération des délais de commercialisation.
Move Fast, Without Breaking Things (Pour un développement rapide et sans heurt) .
Pour les services cherchant à tirer parti de la distribution continue et de la technologie de transition, ainsi que des ressources et processus de mise en place de DevOps, le déploiement d’applications, le provisioning de l’infrastructure et les processus visant à assurer leur synchronisation sont des composants clés.
162-FR0085-002 | S | 04/17 | © 2017 Micro Focus. Tous droits réservés. Micro Focus et le logo Micro Focus, entre autres, sont des marques ou des marques déposées de Micro Focus ou de ses filiales et sociétés affiliées au Royaume-Uni, aux États-Unis et dans d’autres pays. Toutes les autres marques sont la propriété de leurs détenteurs respectifs.
www.microfocus.com
Micro FocusFrance+33 (0) 1 55 70 30 13
Micro FocusSiège social au Royaume-UniRoyaume-Uni+44 (0) 1635 565200
www.microfocus.com