36 votes

déploiement continu avec jenkins

Je veux déployer avec jenkins dans l'environnement de test et dans l'environnement de production. Pour ce faire, je dois me connecter au serveur de l'environnement souhaité, quelque chose comme ssh/scp.

J'aimerais savoir quelle est la meilleure façon de procéder.

J'ai trouvé quelques plugins pour faire cela, comme le Jenkins-Deploy-Plug-in ou le Jenkins Publish over SSH Plugin. Le premier a beaucoup de problèmes, ce qui n'est pas vraiment digne de confiance pour déployer en production et pour le second vous devez changer la configuration globale, ce qui est un travail manuel pour chaque déploiement.

Une idée pour résoudre ce problème ? Peut-être avec des scripts ou des plugins ?

La seule idée actuelle que j'ai est : de me connecter avec jenkins à un serveur (peut-être avec le plugin SSH) et d'y exécuter un script qui se connecte à l'environnement souhaité. Mais cela fait deux connexions. Est-ce vraiment nécessaire ? J'espère un moyen plus simple pour cela.

Merci pour tout conseil.

21voto

ben75 Points 11322

Je suggère la procédure suivante :

un seul shell script (stocké quelque part sur le serveur jenkins) fait tout. En gros, le script fait un scp de l'artefact de construction puis se connecte au serveur (ssh) et effectue toutes les tâches nécessaires au déploiement (configuration de la page de maintenance, sauvegarde de l'application actuelle, déploiement de la nouvelle application, ...).

Sur le serveur Jenkins, il y a au moins 2 travaux :

  • le premier fait simplement le build (en utilisant maven, ou tout autre build script)
  • le second job fait le déploiement : donc ce job ne fait que lancer le shell script. (Je suggère un job de déploiement pour chaque environnement cible : test, production, ...)

Aucun plugin "spécial" n'est nécessaire pour réaliser ce "déploiement en un clic". Il suffit que l'utilisateur de jenkins ait un accès ssh au serveur cible.

EDIT

Voici un exemple de shell script pour illustrer mon propos

#This script will copy the last artifact build by the job "MyApp" to test.myserver.com
#and remotely execute the deployment script.

#copy the war to the server
#(the job "MyApp" is using maven, that's why the war can be found at this location)
scp -i <HOME_DIR>/.ssh/id_dsa $HUDSON_HOME/jobs/MyApp_Build/workspace/myapp/target/myapp.war     deployeruser@test.myserver.com:/tmp/

#connect to the server and execute the deployment script
ssh -i <HOME_DIR>/.ssh/id_dsa deployeruser@test.myserver.com 
#The following is just an example of what a deployment script can be.
#of course you must adapt it to your needs and environment
"cd <TOMCAT_DIR>;
#first copy the current war to a backup directory (additionaly, I have a cron task deleting old undeployed apps)
cp -rf myapp-apps/myapp* undeployed/myapp-apps/; 
#execute a script (stored on the server) to properly stop the app
sh bin/myapp.sh stop; 
#delete current app
rm -rf myapp-apps/myapp; 
rm -rf myapp-apps/myapp.war;
#copy the uploaded war in tomcat app directory 
cp /tmp/myapp.war myapp-apps/; 
#execute a script (stored on the server) to start the app
sh bin/myapp.sh start"

8voto

Gonen Points 1855

L'utilisation de SSH compromet la sécurité de votre environnement
et est assez difficile à dépanner.

Il est préférable d'installer un Jenkins-Slave sur la machine distante
et lancer les tests en exécutant un travail sur l'esclave.

L'esclave est surveillé par le serveur, ce qui vous évite bien des soucis.
gérer la connexion.

Vous pouvez déclencher le job à distance à la fin d'une construction réussie.
et lui passer l'artefact de cette construction.
(le premier travail peut également stocker les artefacts sur un disque partagé).
et transmettre l'emplacement de ces artefacts au travail suivant).

Voir ici :

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X