Retour Atelier Continuous Delivery – Partie 3 – Déploiement continu avec Rundeck

Nous avons vu précédemment comment créer un script de déploiement d’application sur Tomcat et comment l’exploiter avec le plugin JENKINS REMOTE SSH PLUGIN.
Dans cet article, nous allons utiliser le même script, mais avec Rundeck, un outil open-source (http://rundeck.org/), fourni par la société DTO Labs.
Il est résolument orienté pour les exploitants. Dans les grandes lignes, il permet de gérer une liste de machines et d’y exécuter des scripts à distance.
Dans l’outil, chaque machine appartient à un projet. Chaque accès et exécution de script y est tracé. On règle les permissions d’accès de chaque personne par projet, script, en lecture, écriture ou exécution. Autant dire que nous avons là une solution prête pour la production dans une entreprise.

Lors des ateliers, chaque binôme avait à sa disposition 3 VM Linux avec sur chacune d’elle un serveur Tomcat. Pour refaire l’expérience ici, nous nous contenterons de lancer le script en local.

Nous tenons à remercier Vincent Behar pour sa participation active à l’élaboration et animation de cette séance sur Rundeck.

Prérequis

Lors de l’atelier, les différents outils étaient fournis sur des VM sur Amazon EC2. Si vous souhaitez refaire les manipulations suivantes sur votre poste, vous aurez besoin d’installer:

• un JDK
• Apache Maven
• Nexus
• Jenkins
• Apache Tomcat 6
• le script de déploiement que nous avons créé précédemment : tomcat-deploy-petclinic .

Téléchargement du projet exemple

Nous avons mis à disposition un projet d’exemple sous GitHub. Pour tester cet article, vous pouvez cloner ce projet. Nous avons déjà décrit cette partie dans notre précédent article. La partie suivante n’est nécessaire que si vous n’avez pas suivi les deux premiers billets.Rendez-vous sur https://github.com/xebia-france-training/xebia-petclinic
ou alors exécutez :

git clone https://github.com/xebia-france-training/xebia-petclinic-lite.git

Vous devez ensuite changer dans le pom.xml les url des repositories avec vos valeurs (le Nexus des Xebia Tech Events n’est actif que pendant les ateliers).

<distributionManagement>
   <repository>
      <id>xebia-tech-event-nexus-releases</id>
      <name>Xebia Tech Event Nexus Releases</name>
      <url>http://votreNexus/content/repositories/release</url>
   </repository>
   <snapshotRepository>
      <id>xebia-tech-event-nexus-snapshots</id>
      <name>Xebia Tech Event Nexus Snapshots</name>
      <url>http://votreNexus/content/repositories/snapshots</url>
   </snapshotRepository>
</distributionManagement>

Ensuite, un mvn deploy permettra d’avoir un projet fonctionnel déployé dans votre repository.

Installation de Rundeck

Pour installer Rundeck, la façon la plus simple reste de se rendre sur le site, de télécharger le jar, puis une commande java -jar rundeck-launcher-XXX.jar fera l’affaire. Sachez qu’il existe aussi des versions packagées pour des installations plus complètes.

Installation du plugin Rundeck dans Jenkins

Nous allons utiliser ce plugin pour établir la communication Rundeck et Jenkins. Il permet à Jenkins de lancer des jobs Rundeck.
Pour l’installer, rendez-vous dans la partie Administrer Jenkins, Gestion des plugins, puis dans l’onglet Disponible. Cochez la ligne devant le plugin Rundeck Plugin, puis cliquez Installer qui se trouve tout en bas de la page.

Installation du plugin Rundeck dans Nexus

Vincent Behar propose nexus-rundeck-plugin qui permet à Nexus d’exposer par une API REST les versions d’un artifact avec un format supporté par l’option provider de Rundeck. Ce dernier nous permettra de récupérer la liste des versions disponibles de notre artefact.
Pour installer ce plugin Nexus, voici, sous Unix, la liste des commandes (pensez juste à changer le chemin vers votre propre installation de Nexus).

• mkdir -p /opt/nexus/sonatype-work/nexus/plugin-repository
• cd /opt/nexus/sonatype-work/nexus/plugin-repository]
• wget –no-check-certificate « https://github.com/downloads/vbehar/nexus-rundeck-plugin/nexus-rundeck-plugin-1.2.2.2-bundle.zip »
• unzip nexus-rundeck-plugin-1.2.2.2-bundle.zip

Dans les grandes lignes, il suffit de créer un répertoire plugin-repository dans votre installation Nexus, si ce n’est pas déjà le cas, puis de télécharger le bundle et le décompresser.

Initialisation de Rundeck

Création du projet

Après vous être rendu sur Rundeck (par défaut http://localhost:4440/) et vous être authentifié avec le célèbre admin/admin, créez un nouveau projet tomcat-deploy-petclinic. Cette action a créé des répertoires dans Rundeck.
Vous trouverez ces informations dans $RDECK_HOME/projects/tomcat-deploy-petclinic/etc.
Le fichier project.properties contient toutes les propriétés de votre projet, et resources.xml la liste des machines à exploiter.

Déclaration des clés privées

Nous n’en avons pas besoin ici, mais cette déclaration était utile pour Amazon EC2. Nous devions les renseigner dans Rundeck. Pour cela, deux possibilités:

• renseignez la propriété project.ssh-keypath dans le fichier projet.properties
• renseigner l’attribut ssh-keypath au niveau de la déclaration d’un noeud dans le fichier resources.xml

Déclaration des machines

Cette partie n’est pas nécessaire pour lancer un script en local. Si vous avez une machine distante et que vous souhaitez tester, vous pouvez déclarer ici vos machines. Les noeuds représentent votre infrastructure, plus précisément un couple utilisateur/machine.
La première solution consiste à déclarer manuellement les noeuds dans le fichier resources.xml
Voici un example de noeud :

<node 
   name="tomcatDev" 
   type="Node"
   description="Deploy on tomcat Test server" 
   tags="Tomcat,Dev"
   hostname="tomcatDev"
   osArch="x86_64" 
   osFamily="unix"
   osName="Mac OS X"
   osVersion="10.6.2"
   username="xebia-guest"
   editUrl="" 
   remoteUrl=""
/>

Voici la liste des attributs: 

• name : nom du noeud qui sera visible dans les consoles
• type : « Node »
• description : une description de votre serveur
• tags : très important, ces valeurs séparées par des virgules nous permettront ensuite de filtrer les noeuds
• osArch : architecture de votre machine (dont x86 et x86_64, les plus communs)
• osFamily : famille d’OS (unix, windows, cygwin)
• osVersion : version de l’OS installé
• userName : utilisateur SSH qui va être utilisé par Rundeck pour se connecter à la machine
• editUrl : optionnel, permet d’afficher un lien dans la GUI de Rundeck afin d’éditer les caractéristiques du noeud sur une application tierce
• remoteUrl : optionnel, équivalent à la propriété editUrl, sauf que la page s’affiche dans une Frame au sein de la GUI

Il est aussi possible d’ajouter la clé SSH avec la propriété optionnelle suivante ssh-keypath .

Il existe quantité de plugins pour Rundeck qui permettent de maintenir de manière dynamique cette liste. ll est ainsi possible de se connecter à Amazon EC2 via AWS, d’utiliser Puppet ou Chef, ou bien encore de se baser sur source de données propriétaires.

Création du Job

Pour créer un job, il suffit de cliquer sur Jobs puis New Job.

Description du Job

Dans notre cas, nous voulons sauvegarder notre job, donc on peut sélectionner Yes à Save this job? Pour le nom, utilisez tomcat-deploy-petclinc. La notion de groupe permet de regrouper les jobs dans des ensembles logiques, elle n’est pas utile ici.

Options

Chaque job peut avoir plusieurs options. Ces options sont ensuite transmises aux différents scripts exécutés. Il est possible de récupérer une liste de valeurs précises sur des services externes. Nous allons utiliser ici le plugin Rundeck pour Nexus précédemment installé.
Cliquez sur Add new Option.

Voici la description du paramètre:

• Option Name : version
• Default Value : LATEST
• Pour la section Allowed values, renseignez la valeur Remote URL : http://localhost:8081/nexus/service/local/rundeck/options/version?g=fr.xebia.demo.petclinic&a=xebia-petclinic-lite&includeLatest=true
• Selectionnez la restriction suivante : Enforced from Allowed Values
• Requirement : ‘No’
• Multi-valued : ‘No’
  N’oubliez pas de remplacer votre URL locale de Nexus.

 

Cliquez ensuite sur Save pour sauvegarder l’option.

Workflow

Nous n’utiliserons pas ici la notion de workflow. Sachez seulement que, dans le cas où vous avez plusieurs scripts à enchainer, il est possible de le faire séquentiellement, en parallèle, de continuer en cas d’erreur ou pas.

Script

Par défaut, l’interface vous propose de saisir directement une ligne de commande, cliquez sur Cancel puis Add a step.
Quatre choix s’offrent à vous :

• Command : entrez une ligne de commande.
• Script: écrivez directement un script dans votre job. Il sera stocké dans Rundeck.
• Script file : charge un script sur la machine où est installé Rundeck, l’upload puis l’exécute sur la machine distante.
• Job Reference : permet de chaîner l’exécution de job.

Nous allons utiliser ici Script file. Saisissez ensuite le chemin où vous avez stocké le script tomcat-deploy-petclinic ainsi que l’utilisation de l’option de version. Attention, contrairement au billet précédent, le script doit être ici sur la machine de Rundeck (option Script file). Si vous souhaitez laisser le script sur la machine distante, utilisez l’option Script pour lancer votre script à distance.

Dispatch to node

La dernière étape consiste à faire correspondre ce script avec une liste de machines cibles. Pour cela, cliquez sur Dispatch to Nodes.
A l’aide de plusieurs critères, il est possible de filtrer les machines sur lesquelles le script sera exécuté. Ici, nous n’avons rien à faire pour cet exemple car le script doit s’exécuter en local.
On devine toute la force de la gestion par tag. Si vous saisissez dans le champ Tags Tomcat,UAT, en chargeant de façon dynamique votre déclaration de noeuds, via AWS par exemple, Rundeck résoudra la liste de tous les noeuds au moment de l’exécution. Si vous ajoutez demain un noeud dans Amazon avec ce même tag, votre job Rundeck y déploiera automatiquement l’application!

Pour cet exemple, vous devriez voir apparaître en face de Matched nodes, le nom de votre host suivi de .locale.
Décochez l’option DIspatch to Nodes pour lancer le script en local puis cliquez sur Create And Run pour l’exécuter. Vous verrez alors apparaître un écran qui vous permet de choisir le numéro de version de l’application à installer.

Laissez la valeur par défaut de l’option version (LATEST), puis cliquez sur Run Now. Vous verrez alors une barre de défilement illustrant l’avancée de l’exécution, ainsi que la log du job.

Déclencher le Job depuis Jenkins

La dernier étape consiste à faire exécuter ce job dans Rundeck depuis Jenkins.
Pour cela, rendez-vous dans Jenkins, puis Administrer Jenkins, et Configurer le Système. Une section en bas de l’écran permet de paramétrer le plugin. Saisissez l’URL de Rundeck (http://localhost:4440/) puis le login/password (par défaut admin/admin). Cliquez sur Test Connection pour vous assurer du bon fonctionnement de la configuration, puis Enregister pour sauver la configuration.

Nous allons créer une nouvelle tâche dans Jenkins avec pour nom deploy-with-rundeck. Utilisez un projet Freestyle. Dans la vraie vie, vous pouvez modifier votre intégration continue pour ajouter les éléments suivants.
Dans la section, Actions à la suite du build, sélectionnez Rundeck puis cochez Wait for Rundeck job to finish? et Should fail the build?

La version utilisée pendant nos essais nécessitait la saisie de l’identifiant du job dans Jenkins. Les versions récentes du plugin permettent d’interroger Rundeck pour une saisie plus interactive et intuitive.
Une fois la configuration effectuée, il ne vous reste plus qu’à sauver puis lancer le build pour voir ensuite, dans Rundeck, la demande d’exécution s’effectuer.

Conclusion

En étendant ainsi Jenkins, vous passez rapidement de l’intégration continue au déploiement continu. Rundeck a l’avantage de pouvoir être utilisé facilement en production. Il ne nécessite pas d’installation d’agent, se branche facilement à diverses sources de données existantes pour vous proposer les numéros de versions ou encore la cartographie dynamique de votre infrastructure.

Rundeck vous permet de lancer n’importe quel script sur toutes vos machines. Cela ne se limite donc pas au déploiement continu. Il peut aussi servir à mettre à jours les serveurs, installer des environnements… Bref, tout ce que vous savez scripter, Rundeck pourra l’exécuter.

Avez-vous encore besoin d’autres arguments pour l’utiliser ? :-)