Pelisse Romain

Automatiser intégralement l’installation du serveur d’application Wildfly et la mise en place de son « cluster » est aujourd’hui devenu une réalité, pour peu bien sûr qu’on utilise un outil approprié à la tâche, tel qu’Ansible. Démonstration, dans cet article, avec le déploiement d’un « cluster » de trois nœuds au sein d’un conteneur Docker.

La supervision d’un système en production demeure un enjeu aussi complexe qu’essentiel. Il existe de nombreuses solutions, très complètes, de supervision, mais la plupart adoptent une approche centralisée, qui demande l’utilisation de ressources dédiées. Aujourd’hui, nous étudierons une approche alternative, une solution de supervision décentralisée, nommée Monit.

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.