Vous venez juste de boucler la première version de votre application, packagée par Maven. Vos intégrateurs ont préparé un environnement de recette et vous ont communiqué les informations de connexion à la console d’administration de votre serveur d’applications. Vous vous connectez, accédez aux fonctionnalités de déploiement et déployez le fichier EAR. Satisfait, vous démarrez votre navigateur pour vérifier que l’application tourne correctement. Mais quand vous essayez de charger la page, vous obtenez l’erreur DNS « Host not found ». C’est donc le moment d’appeler un ami – l’administrateur de cette obscure infrastructure, qu’on appellera Michel. Michel est bien sûr très heureux d’ajouter un enregistrement DNS qui va permettre d’aller sur le serveur Apache à partir de l’URL www.app-in-dev.com. « Quoi ! Un serveur Apache ? » vous exclamez vous, « Mais ça devrait pointer vers notre serveur d’applications, pas du tout vers un quelconque serveur HTTP ! ».

Michel, qui a l’habitude de ce genre d’exclamation vis-à-vis de l’organisation des réseaux d’entreprise, explique calmement que toutes les requêtes partant d’un navigateur doivent d’abord passer par un serveur HTTP avant d’être redirigées vers le serveur d’applications. « Il est donc aussi nécessaire de configurer Apache ! », dit-il. « Mais je développe une application Java, j’ai juste besoin de déployer sur un serveur d’applications et hop, terminé ! » répondez vous. Et Michel d’expliquer sur un ton très sérieux : « Écoute fiston, appuyer sur le bouton de déploiement de ta console d’administration est juste une petite étape parmi toutes celles qui permettent de réaliser un vrai déploiement. »

Rendre l’application accessible à l’utilisateur final

Avant de parler des différentes étapes du déploiement, il est important de comprendre quel est l’objectif d’un déploiement. De façon élémentaire, le but d’un déploiement est de « rendre une application, dans une version donnée, disponible pour les utilisateurs finaux ». En d’autres termes, l’utilisateur ouvre son navigateur, tape www.app.com et voit l’application fonctionner.

Alors, que faut-il faire pour qu’une application fonctionne? Pour comprendre les composantes du déploiement, le plus simple est de suivre la requête depuis le navigateur de l’utilisateur à travers tous les composants matériels et logiciels par lesquels elle transite.
« La destination de la requête est tout d’abord résolue en s’adressant à un serveur DNS (ou à un mécanisme équivalent). La requête est alors routée vers sa destination ; elle est filtrée par un premier firewall, arrive sur le serveur HTTP chargé de la répartition de charge, traverse un nouveau firewall, atteint le serveur d’applications puis enfin l’application à proprement parler, exécutée sur le serveur, qui elle-même interroge une base de données pour récupérer les informations demandées par l’utilisateur. »
Sur cet exemple simple, il y a au moins 5 composants en action pour rendre disponible l’application ; nous devons non seulement configurer ces 5 composants mais aussi y placer certaines données et s’assurer au besoin qu’ils (re-)démarrent dans un ordre correct.

Voici typiquement les étapes nécessaires au premier déploiement d’une telle application sur un environnement de production :

• (a) Exécuter les ordres SQL de création de tables sur la base de données
• (b) Configurer la source de données JDBC dans le serveur d’applications
• (c) Configurer les ports HTTP et les Virtual Hosts dans le serveur d’applications pour que l’application soit accessible par les requêtes HTTP
• (d) Installer l’application sur le serveur d’applications
• (e) Démarrer l’application
• (f) Configurer le firewall, en ouvrant les ports utiles à la communication entre le serveur HTTP et le serveur d’applications
• (g) Configurer le serveur HTTP, pour router vers le serveur d’applications les requêtes arrivant sur www.app.com et qui ne se terminent pas, par exemple, par .js, .html, .jpg
• (h) Déposer le contenu HTML statique (fichiers js, fichiers css, images, etc.) sur le serveur HTTP
• (i) (re-)Démarrer le serveur HTTP pour prendre en compte la nouvelle configuration
• (j) Configurer le firewall externe, pour permettre les accès de www.app.com vers le bon serveur HTTP

Bien sûr, dans un environnement plus complexe, on ajoute quelques étapes à la liste. Par exemple, dans un environnement clusterisé avec haute disponibilité, tout doit être fait au moins deux fois. Pour les déploiements de versions ultérieures de la même application, certaines étapes pourront de surcroît être négligées.

Des tâches nombreuses et variées

Les étapes décrites dans la section précédentes permettent de « mettre à disposition des utilisateurs » une application à l’architecture élémentaire. D’une façon plus générale, on peut distinguer plusieurs grandes catégories d’opérations à réaliser pour finaliser un déploiement :

• Installer l’application (Étape d)
  C’est la partie principale du déploiement, où la logique métier est installée sur le serveur, le plus souvent sous la forme d’un fichier EAR ou WAR.
• Configurer les ressources externes (Étape b)
  L’application peut avoir besoin d’interagir avec d’autres systèmes, comme une base de données, un mainframe ou un middleware de message. Les ressources externes sont le plus souvent utilisées par l’application pour obtenir ou diffuser des données. L’accès à ces ressources est généralement configuré au niveau du serveur d’applications.
• Configurer les composants intermédiaires (Étape a, c, f, g, h, j)
  Ce sont les composants qui permettent d’atteindre l’application, et de l’exécuter (par exemple, un cluster de serveurs d’applications, des instances de serveurs HTTP, des firewalls, etc.).
• Démarrer/Arrêter les composants (Étape e, i)
  Pour s’assurer que chaque composant fonctionne correctement, il peut être nécessaire de le (re-)démarrer.
• Et respecter l’ordre dans les points précédents

Pour être sûr que l’application démarre correctement, sans erreurs, un certain ordre doit être maintenu. Exemple : Si vous installez l’application (Étape d) et la démarrez avant d’avoir configuré la source de données (Étape b), l’application risque de ne pas se lancer correctement. Ceci devient encore plus important lorsque vous déployez une nouvelle version de votre application dans un environnement clusterisé.

Il y a une catégorie supplémentaire pour les organisations qui valident leurs applications successivement sur plusieurs environnements (Développement, Test, Intégration, Production) :

• Configurer l’application installée sur des environnements différents
  Un déploiement doit assurer la configuration spécifique à l’environnement. Exemple : Quand vous installez une application sur l’environnement de développement, il faut récupérer les données de la base de développement. De la même façon, pour l’environnement de tests, il est nécessaire d’avoir les données de tests et ainsi de suite.

L’EAR, la partie émergée de l’iceberg

Beaucoup pensent qu’installer un EAR sur un serveur d’applications équivaut à déployer l’application. Bien sûr, le bouton dans la console d’administration indique : « Déployer l’application », mais il ne s’agit que de la partie concernant le serveur d’applications à proprement parler ; cette vision étroite du déploiement n’est généralement opérationnelle que sur un environnement simplifié, comme celui de développement ou sur le poste de travail du développeur. Dès qu’une application doit être installée sur un environnement plus complexe, cette vision ne suffit plus et il devient nécessaire de réaliser un grand nombre d’opérations complémentaires pour véritablement « mettre l’application à disposition des utilisateurs ».

Parce que de ce point de vue le déploiement n’est pas une opération triviale, beaucoup cherchent à l’automatiser.
Exécuter manuellement toutes les étapes est en effet à la fois complexe et risqué, particulièrement sur les environnements les plus critiques. Et ce, d’autant plus que, souvent, les responsabilités et les gouvernances de chaque module de l’infrastructure reposent entre les mains de personnes, d’équipes, voire de départements différents.
Malheureusement, cet effort d’automatisation aboutit souvent à un ou plusieurs jeux de scripts à la gouvernance floue et dont le coût de maintenance semble souvent prohibitif. Les solutions du marché n’abordent souvent qu’un sous-ensemble de la problématique (on pense à Phurnace ou BuildForge, qui restent concentrés sur le serveur d’applications, ou à d’autres solutions qui sont souvent de simples ordonnanceurs de scripts).
Avec les serveurs d’intégration continue, on peut mettre en œuvre des déploiements automatiques, qui permettent de tester la chaîne complète de la compilation jusqu’aux tests de charge (cf. Build Pipelines). Et si l’on veut aller encore plus loin, c’est-à-dire déployer automatiquement sur l’environnement de production, on peut se pencher sur le logiciel DeployIt, développé par mes collègues Hollandais.

Je parlerai, plus en détail, dans un prochain article du déploiement automatique et nous pourrons déterminer par nous-même si c’est une solution « Insane » comme le pense le livre blanc Enterprise CI Maturity Model de la société anthillpro ou une solution réelle pour améliorer la fiabilité comme le pense DeployIt.

---

Traduction libre du billet « So what is a deployment really? » publié par Robert van Loghem.