Il y a 7 années -

Temps de lecture 10 minutes

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:

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:

 

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 ? :-)

Publié par Xavier Bucchiotty

Software Engineer Scala Fanboy FP constant learner Akka trainer

Commentaire

7 réponses pour " Retour Atelier Continuous Delivery – Partie 3 – Déploiement continu avec Rundeck "

  1. Publié par , Il y a 7 années

    Retour d’XP très constructif, je n’avais pas eu l’idée de l’intégration avec nexus grace au remote URL.
    Quid des déploiements de livrables spécifiques à un environnement.
    Est il préférable de le deployer an amont sur nexus avec un classifier ?
    De le générer sous Jenkins et de le déployer grâce à l’intégration des deux outils ?
    De donner à rundeck les moyens de filtrer les sources (dans ce cas reconstruction du livrable à partir d’un numéro de révision ou d’un tag), ou d’un livrable générique (explode du livrable et filtrage du contenu) ?

    Dans le cas 1 :
    Saturation rapide de l’espace disque de nexus en raison de nombreux environnements possibles par livrable : Séparation des déploiements avec classifier dans un dépôt temporaire purgé périodiquement.

    Dans le cas 2 :
    Complexe mais possible en effet il faut donner les moyens à un job de reconstruire un livrable soit par une révision soit par un tag (scripts à développer)

    Dans le cas 3 :
    A la sauce deploitIt je crois, scripting à mettre en place également. Difficultés éventuelles pour les livrables qui encapsulents des artifacts type JAR à filtrer (non recommandés).

  2. Publié par , Il y a 7 années

    Salut,

    en fait ton binaire (livrable) doit être générique et indépendant de l’environnement. Donc la conf spécifique à l’environnement doit être faite à l’extérieur du binaire (typiquement WAR), via JNDI, fichiers properties, variables d’environnements, etc.

    Ensuite il y a plusieurs solutions pour gérer cette conf :
    – un outil de gestion de conf (puppet, chef, etc)
    – packager la conf et la mettre dans nexus, en utilisant un classifier. Cette solution se fait facilement avec du Tomcat/Maven : on met tout le répertoire « conf » de tomcat dans un projet maven, et on génère des .tar.gz avec les bons classifiers via le plugin assembly. Ensuite le script de déploiement récupère à la fois le binaire et la conf correspond au bon environnement avant de tout installer.

    Avoir un binaire unique est à la base du concept de « build pipeline » : tu génère ton binaire au début de la chaine lors de l’intégration continue, puis tu l’installe sur tes différents environnements avant de finir en prod.

    Vincent

  3. Publié par , Il y a 6 années

    merci pour ton super retour d’expérience concernant rundeck.
    en faite je travail sur la mise en place de rundeck et puppet.
    je sais qu’il y a un plugin puppet-rundeck qui permet utilisation des deux outil.
    mais y a pas beaucoup de documentation la dessus. Est-ce qu’il moyen que fassiez un petit tuto la dessus ci possible si vous avez déjà couplé ces 2 outils.

    En plus je voudrais savoir lors de la création de job en choisissant l’option script File (utilisation d’un script externe ) si nous avons de la possibilité de faire l’exécution sur les machines distantes sans avoir utilisé le protocole ssh.

    si quelqu’un à des idées ou des docs clair sur le couplage de rundeck et puppet je serais très ravi de le lire :)

  4. Publié par , Il y a 6 années

    Il existe quelques plugins Rundeck pour puppet:
    http://rundeck.org/plugins/

    * Le premier permet de charger la configuration des noeuds Puppet dans Rundeck
    * Le second pour l’utilisateur avec MCollective

    Je n’ai pas testé ces plugins mais cela a l’air assez simple.

    Pour l’exécution de script Puppet via Rundeck, tu peux regarder la commande puppet apply
    http://docs.puppetlabs.com/man/apply.html

    Cela permet de forcer l’exécution d’un script puppet en mode standealone (sans passer forcément par la liaison master/slave habituelle).

    Par contre, pour ce qui est de l’exécution du script externe sans ssh, je ne vois pas bien? Tu voudrais faire un CRON ?

  5. Publié par , Il y a 6 années

    merci pour ton retour je voudrais faire un cron

  6. Publié par , Il y a 6 années

    En faite je t’explique. On a déjà une configuration de CRON de nos script.
    du coup on aimerais mettre en place outil mettre qui permettrait de le faire de façon automatique. Mais la question qui s’est posée est qu’avec rundeck il faut utilisé ssh pour l’execution des scripts alors qu’il peut arriver qu’il ai coupure de reseaux et ssh ne pourra pas executer la configuration CRON . donc moi je voudrais si possible s’il y a moyen avec rundeck d’executer les configurations CRON sur les machines distantes sans passer par le protocole ssh.
    et si rundeck pourra nous notifié lors du demarrage de l’execution du CRON et après l’execution du CRON pour savoir si reelement il y a eu des erreurs ou pas merci.
    est-ce que ta une idée la dessu

  7. Publié par , Il y a 5 années

    Bonjour à tous ,

    En fait , j’ai installé rundeck sous debian6 et il marche normalement en localhost en configurant un job avec une commande simple. Le probléme est que j’ai pas réçu une notification mail pourtant j’ai mis @mail de destination.
    Merci d’avance..

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.