16
Automatisation du lancement des applications et automatisation de l’infrastructure Présentation de la proposition de valeur de ces deux options Par Julian Fish, Director of Product Management, Serena Software (désormais membre de Micro Focus) Livre blanc

Automatisation du lancement des applications et

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Automatisation du lancement des applications et

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

Page 2: Automatisation du lancement des applications et

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

Page 3: Automatisation du lancement des applications et

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

Page 4: Automatisation du lancement des applications et

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

Page 5: Automatisation du lancement des applications et

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

_______________________________________________________________

Page 6: Automatisation du lancement des applications et

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 .

Page 7: Automatisation du lancement des applications et

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

_______________________________________________________________

Page 8: Automatisation du lancement des applications et

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

_______________________________________________________________

Page 9: Automatisation du lancement des applications et

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

_______________________________________________________________

Page 10: Automatisation du lancement des applications et

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.

Page 11: Automatisation du lancement des applications et

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

_______________________________________________________________

Page 12: Automatisation du lancement des applications et

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.

Page 13: Automatisation du lancement des applications et

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.

Page 14: Automatisation du lancement des applications et

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.

Page 15: Automatisation du lancement des applications et

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.

Page 16: Automatisation du lancement des applications et

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