Pelisse Romain

Si les outils comme Ansible permettent d’aller très loin dans l’automatisation d’un déploiement logiciel, ils sont souvent limités dans leurs capacités de réglage fin d’un outil aussi complexe et avancé qu’un serveur Java EE tel que Wildfly (ou son pendant commercial, JBoss EAP). Afin de résoudre cette problématique, l’outil JCliff a été développé pour permettre à Puppet (un concurrent d’Ansible) de s’intégrer sans difficulté avec ce serveur applicatif. Cet outil est maintenant aussi intégré avec Ansible sous la forme d’une collection et cet article propose un tour exhaustif des capacités d’automatisation du déploiement et de la configuration des sous-systèmes de Wildfly à l’aide de cette nouvelle extension.

On attribue souvent au succès de Java la relative simplicité de sa syntaxe et surtout son vaste écosystème. C’est oublier un point essentiel dans son adoption : son débogueur et ses fonctionnalités qui simplifient tant le travail d’analyse et de résolution d’une erreur à l’exécution.

Dans ce premier chapitre, nous allons aborder de nombreux sujets, allant du respect des conditions d’utilisation de « Red Hat Enterprise Linux » (RHEL), de l’installation du système, de sa connexion au réseau « Red Hat » jusqu’à la description de notre cas d’étude. Une fois ces prérequis évoqués et ces étapes préliminaires étudiées, nous passerons au vif du sujet en installant Ansible, que nous utiliserons dans le prochain chapitre afin de commencer à mettre en place notre serveur.

Notre serveur est en place et notre intranet est entièrement fonctionnel ! Il est temps, maintenant, d’aller plus loin et de s’assurer qu’il fonctionne aussi efficacement que possible et de se faciliter, autant que possible aussi, sa maintenance. Dans la même idée, nous allons aussi en profiter pour mettre en place des sauvegardes afin de nous prémunir d’une éventuelle perte des données du wiki.

Nous allons ici documenter l’installation et la configuration de notre serveur RHEL à l’aide du fichier de configuration Ansible (que l’on nomme « playbook »). Afin de nous assurer que le lecteur dispose de tous les éléments nécessaires à la bonne compréhension du contenu de ce numéro spécial, nous allons donc commencer par un rapide tour d’horizon de cet outil.

Notre serveur RHEL est désormais fin prêt à être utilisé et maintenu, sans peine et de manière confortable. Cependant, notre travail n’est pas terminé. Il nous reste encore un élément crucial à valider : nous assurer que le serveur est aussi sûr et protégé que possible face à un éventuel assaillant mal attentionné.

Bienvenue dans ce numéro spécial dédié à la mise en place d’un intranet à l’aide de Red Hat Enterprise Linux (RHEL) ! Comme vous allez vite le voir, l’utilisation de la distribution au chapeau rouge ne change que peu de choses et tout ce que nous allons aborder dans ce dossier (ou presque) pourra être utilisé ou reproduit sur des distributions similaires, telles que CentOS ou encore simplement Fedora.

Le précédent chapitre a présenté, de manière sommaire et limitée aux besoins de ce dossier, les fonctionnalités d’Ansible. Nous allons donc maintenant revenir au cas d’étude en tant que tel et continuer la configuration de notre serveur RHEL, en utilisant désormais un playbook Ansible.

L’innovant projet Quarkus a déjà été évoqué dans plusieurs précédents articles depuis sa sortie en mai 2019. Ces publications ont détaillé à quel point il est un excellent cadre d’exécution, très performant et très adapté à la réalisation de microservices HTTP. Néanmoins, ces différents articles n’ont pas, pour le moment, abordé le thème de la programmation « réactive ». Or, comme nous allons le voir aujourd’hui, la programmation « réactive » est en fait au cœur de Quarkus !