Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Déploiement continue (ou pas) d’un Web Site

Poster un commentaire

Il existe plusieurs méthodes pour déployer les web site. Nous pouvons les classer dans les catégories suivantes:

  1. Web deploy (MSDeploy)
  2. FTP
  3. Depuis un repository

 

Web deploy est simplement un déploiement depuis Visual Studio ou WebMatrix. Cette possibilité a déjà été étudiée dans les deux articles suivants:

  1. https://amethyste16.wordpress.com/2014/06/01/taches-planifiees-sous-windows-azure-partie-i/
  2. https://amethyste16.wordpress.com/2014/09/10/taches-planifiees-sous-windows-azure-partie-iii/

 

Je n’y reviendrai donc pas si ce n’est pour signaler un outil déployable depuis Chocolatey fait par David Ebbo permettant de simplifier les scripts MsDeploy:

http://blog.davidebbo.com/2014/03/WAWSDeploy.html

On va plutôt s’intéresser aux autres options qui offrent la possibilité de faire du déploiement continue à l’exception de deux d’entre elles.

Donc au programme:

  1. Déploiement FTP
  2. DropBox
  3. Déploiement VS Online (anciennement Team Foundation Service, TFS, histoire de brouiller les esprits!)
  4. Déploiement Github
  5. Repository Git local
  6. External repository
  7. Comparaison des principales méthodes de déploiement
  8. Kudu
  9. Notifications post déploiement
  10. Script post déploiement
  11. Personnaliser son script de déploiement

 

Quelques heures de lecture en perspective. Je pense d’ailleurs que ce tutoriel est le plus complet en français sur ce sujet.

Note: On va encore rester sur l’ancien portail car les opérations présentées ici ne sont pas encore disponibles sur le nouveau portail.

FTP

Commencez par installer un client Ftp de votre choix. En ce qui me concerne il s’agit de FileZilla. Nous avons ensuite besoin de créer un web site depuis le portail ainsi qu’un projet MVC pour avoir quelque chose à déployer!

Côté source c’est facile, on sélectionne le répertoire du projet.

Côté cible? Rendez-vous dans le tableau de bord du site (dashboard). On y trouve toutes les informations utiles:

2015-01-14_23-53-13

Le mot de passe est par défaut celui de l’abonnement. Mais on peut le changer:

2015-01-15_00-08-59

Un clic sur le lien ouvre le formulaire suivant, lisez bien la partie surlignée en jaune:

2015-01-15_00-09-59

 

Il y a plus qu’à, comme on dit.

Une fois connecté, la situation devrait ressembler à celle-ci:

2015-01-14_23-58-19

On navigue dans le bon répertoire:

2015-01-15_00-01-14

Puis on transfère…

2015-01-15_00-23-24

Normalement le site devrait fonctionner.

Dropbox

On a un peu de configuration à faire dans le portail. Allez dans le menu général de l’onglet Web Sites en cliquant sur le petit nuage:

2015-01-20_16-03-52

On se rend ensuite tout en bas et on trouve:

2015-01-15_00-27-25

Un clic sur le lien affiche une liste de repositories supportés par Azure:

2015-01-15_00-29-01

Nous allons sélectionner Dropbox. Un formulaire d’authentification s’ouvre, on le renseigne puis s’ouvre:

2015-01-16_22-50-36

On valide et l’assistant lance la recherche des répertoires DropBox:

2015-01-16_23-00-12

Et enfin:

2015-01-16_23-07-30

Mon DropBox est vide, je ne peux que créer un nouveau répertoire. Je coche aussi l’option de restauration (rollback). On fait NEXT pour autoriser Azure à accéder à notre répertoire DropBox.

On revient alors vers le portail et on découvre un nouvel onglet DEPLOYMENTS:

2015-01-16_23-10-23

Il nous indique que le web site est lié à un repository de déploiement Dropbox. Côté Dropbox on observe:

2015-01-16_23-14-07

Le répertoire /Dropbox/Applications/Azure/DemoAmethyste est apparut.

Nous allons copier le projet dans ce répertoire pour le déployer. Si jamais la copie ne se déclenche pas on clique sur SYNC. Un état d’avancement apparaît:

2015-01-16_23-17-44

Dans notre cas il a échoué.

2015-01-16_23-19-27

On peut avoir des logs. On clique:

 

2015-01-16_23-20-21

J’ai du recompiler le projet en 64 bits. Si on modifie les fichiers dans DropBox, faire SYNC à nouveau et pas RETRY dans la barre des menus sinon ça ne marche pas. Si tout va bien on devrait voir ceci:

2015-01-16_23-45-48

Testez que le site fonctionne comme prévu. Pour tester un peu plus essayer de faire un autre redéploiement comme précédemment:

2015-01-16_23-49-56

Le déploiement actif est indiqué en vert. Le chevron permet d’afficher les logs de déploiement. Le lien en haut à droite permet d’accéder au portail DropBox.

On peut surtout rejouer un ancien déploiement en cliquant sur REDEPLOY:

2015-01-16_23-51-27

Si l’on souhaite ultérieurement se déconnecter de DropBox:

2015-01-17_23-32-38

Et on revient à la situation initiale:

2015-01-15_00-27-25

Visual Studio online

Vous devez disposer d’un compte Visual Studio Online et y pousser votre projet:

2015-01-17_23-30-50

On procède un peu comme pour DropBox:

2015-01-17_23-35-54

Nous arrivons sur l’écran suivant:

2015-01-17_23-36-54

Depuis cet écran on donne à Azure l’autorisation de se connecter à VS Online. On saisit l’url vers notre compte VS Online puis on clique sur Authorize Now.

2015-01-17_23-39-43

On clique sur ACCEPT.

2015-01-17_23-43-51

On sélectionne le repository du projet puis NEXT:

Et on arrive ici:

2015-01-17_23-45-12

Il ne reste plus qu’à valider une modification dans VSO et observer qu’un déploiement se lance automatiquement au bout de quelques minutes.

Tout comme avec DropBox, on dispose d’un historique des déploiements:

2015-01-17_23-53-29

Note: Attention, le déploiement prend quelques minutes pour se déclencher après le commit.

Il est doté des même fonctionnalités bien sûr. On dispose d’un outil similaire dans la console VS Online.

2015-01-17_23-58-06

On peut aussi aller voir le panneau des BUILDS dans Visual Studio Desktop:

2015-01-18_01-04-59

On retrouve en haut la liste des déploiements réalisés, mais également la définition du build tel qu’il a été créé par le portail Azure (CD signifie Continuous Deployment).

Faisons un clic droit pour choisir EDIT BUILD DEFINITION:

2015-01-18_01-09-24

Prenez le temps d’examiner les différentes options. Par exemple le menu Trigger:

2015-01-18_01-11-01

Si vous souhaitez en savoir plus:

http://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/

Github

La procédure n’est pas très différente de Visual Studio Online. Vous devez bien sûr disposer d’un compte Github et y déployer votre projet:

2015-01-19_22-52-00

Puis:

2015-01-19_22-53-03

On clique sur AUTHORIZE:

2015-01-19_22-55-29

On sélectionne le repository puis OK:

2015-01-19_22-56-39

On a plus qu’à vérifier que le déploiement s’est bien passé.

Dans la partie CONFIGURE du portail Azure on trouve:

2015-01-21_00-36-14

Si on se rend dans les paramètres (settings) du repository depuis le portail Github on voit apparaître un webhook:

2015-01-19_23-03-49

L’url que l’on voit apparaître est celle de Kudu, un site compagnon déployé avec chaque web site. Il fera l’objet d’une étude détaillée un peu plus loin.

Vous pouvez éditer le web hook et modifier ses propriétés si vous le souhaitez ou en créer un nouveau:

2015-01-28_09-21-49

Note: pour l’instant seul le support depuis un repository public est supporté.

Repository Git local

Nous pouvons faire un déploiement continue depuis un repository Git local. On parle ici de déployer depuis un repository Git local. Donc rien de très nouveau par rapport au cas précédent, mais on pourra dire l’avoir fait au moins une fois.

Vous aurez donc besoin d’installer Git sur votre machine:

http://git-scm.com/book/en/v2/Getting-Started-Installing-Git

Je me suis largement inspiré de ce tutoriel:

http://azure.microsoft.com/fr-fr/documentation/articles/web-sites-publish-source-control/

Une fois un repository Git créé et un projet installé, on se rend dans le portail où on créé un Web Site selon la procédure habituelle. Il ne reste plus qu’à déployer:

2015-01-26_09-58-30

On fait OK au bout de quelques secondes le message suivant apparaît:

2015-01-26_09-59-46

Tandis que dans l’onglet DEPLOYMENT:

2015-01-29_23-34-47

Recopiez l’url proposée dans la zone GIT URL afin de lancer les deux commandes qui suivent:

git remote add azure https://fmirouze@demolocalgit.scm.azurewebsites.net:443/DemoLocalGit.git
git push azure master

Mais Azure vous simplifie la vie en vous les fournissant toute prête dans le portail:

2015-01-29_23-40-28

Un mot de passe vous sera demandé.

La commande remote ajoute la référence nommée « azure » dans le repository distant.

push azure master envoie la branche master du repository local dans la référence azure

 

Le portail devrait ressembler à:

2015-01-29_23-45-18

Lancez le site pour vérifier son bon fonctionnement.

External repository

Le point commun des méthodes de déploiement qui précèdent est que l’on est propriétaire du repository, c’est à dire admin. C’est indispensable pour mettre les hooks nécessaires au fonctionnement du déploiement continue.

 

Dans certains cas on souhaite déployer une application dont on ne détient pas le source ou que l’on a de toute façon pas l’intention de modifier. C’est plutôt le côté déploiement que continue que l’on recherche.

C’est pour ce type de scénario qu’est fait l’option External Repository.

2015-01-28_23-09-48

On arrive sur ce formulaire:

2015-01-28_23-13-57

On saisit l’url de clonage du repository et la branche que l’on souhaite déployer. On décide ensuite si le repository est Git ou Mercurial, puis OK et c’est terminé!

2015-01-28_23-16-41

Pour que les choses soient claire, il n’est alors pas question de déploiement continue. Just un déploiement à la demande.

2015-01-28_23-18-30

Notez que dans ce scénario également, seuls les repositories Git publics sont supportés.

Comparaison des principales méthodes de déploiement

Je reprends l’idée de ce tableau à Matt Milner:

  GIT TFS FTP Web deploy
Déploiement  2015-01-27_14-58-56  2015-01-27_14-58-56  2015-01-27_14-58-56  2015-01-27_14-58-56
Juste éditer un fichier  2015-01-27_14-58-56  2015-01-27_14-58-56  2015-01-27_14-58-56  2015-01-27_14-58-56
Base de données  2015-01-27_14-57-00  2015-01-27_14-57-00  2015-01-27_14-58-16  2015-01-27_14-58-56
Historique déploiement  2015-01-27_14-58-56  2015-01-27_14-58-56  2015-01-27_14-58-16  2015-01-27_14-58-16

 

2015-01-27_14-58-56 = Inclus

2015-01-27_14-57-00= Scriptable

2015-01-27_14-58-16= Manuel

 

Avis perso: Le déploiement de Web Site est je pense une pub permanente pour les repositories Git. Tout y est plus facile!

Kudu, un secret bien gardé

J’ai déjà évoqué Kudu dans les chapitres précédents, nous allons l’examiner plus en détail ici.

Il s’agit du moteur qui intervient lors des déploiements Git d’un Web Site. Kudu se présente sous la forme d’un site Web.

Kudu étant une application simple tenant, elle est déployée pour chaque Web Site sous Azure. On peut toutefois l’installer localement afin de gérer ses déploiements Git dans son propre IIS. Lire aussi à ce sujet:

http://codebork.com/2012/07/06/project-kudu-git-deployment-all.html

 

Kudu est un projet opensource disponible dans GitHub qui fait partie de l’Outercurve Foundation et est livré sous licence Apache 2.0.

Pour lancer le site déployé sur Azure, la syntaxe de l’url est bâtie sur celle du site de la façon suivante:

https://<NOM WEB SITE>.scm.azurewebsites.net/

Notez bien que l’on est en https.

Allons y donc:

2015-01-18_01-23-46

Kudu fonctionne dans le même contexte de sécurité que le site principal et peut donc accéder aux fichiers du site et à ses variables d’environnement.

2015-01-18_01-24-57

Essayez pour tester d’ajouter un paramètre APPSETTING à votre site:

2015-01-18_21-53-47

Vous le voyez apparaître dans la console:

2015-01-18_21-55-25

Le site Kudu est également toujours authentifié de sorte que le propriétaire du web site est le seul à pouvoir y accéder.

Une partie intéressante est la console:

2015-01-18_14-11-59

Deux interfaces d’accès, choisissons PowerShell:

2015-01-18_14-13-40

On peut entre autre accéder aux fichiers du site si on a besoin de les inspecter. On retrouve en fait l’arborescence que l’on a vu avec FTP.

2015-01-18_14-16-00

Il est très facile d’uploader un fichier depuis votre poste à l’aide d’un drag/drop. Par exemple:

2015-01-18_14-22-25

J’ai créé un répertoire TestDrop pour la démo. On a juste à faire glisser un fichier ou un répertoire depuis le système de fichier n’importe où sur l’écran pour l’uploader sur le site.

2015-01-18_14-24-48

Regardez à nouveau la zone de droite en bleue sur une des images précédentes. cette zone a une propriété spéciale: si vous y déposez un fichier .zip, il ne sera pas juste uploadé, mais aussi dézippé.

Pour finir sachez que Kudu est pilotable via une API REST documentée ici:

https://github.com/projectkudu/kudu/wiki/REST-API

Vous trouverez ici une liste de variables d’environnement qui affectent le fonctionnement de Kudu:

https://github.com/projectkudu/kudu/wiki/Configurable-settings

Notifications post déploiement

En 2006, Jeff Lindsay a définit un pattern destiné à décrire une suite de services faiblement couplés communiquant entre eux via des appels Http. C’est à cette occasion que le terme de webhooks a été définit. Dans la foulée il a créé RequestBin que nous allons utiliser dans cette section.

L’idée pour faire des notifications post-déploiement est la même. Nous allons attacher un appel vers une API REST à un événement du repository comme par exemple la fin d’un déploiement.

Je vais faire une démo avec RequestBin, parce que c’est immédiat à mettre en place. Mais évidemment dans la vie réelle on utilisera des services plus intéressants comme par exemple Zapier qui permet d’automatiser les appels vers de nombreux services exposant une API REST. On pourra ainsi envoyer des mails ou un message sur son compte Twitter si un build échoue.

 

Cette notification peut se mettre en place depuis VSO ou bien Kudu si le repository est Git.

Depuis Kudu

Dans l’interface Kudu, faites Tools/Webhooks:

2015-01-18_22-55-28

Cette interface vous permet de déclarer des url qui seront lancées une fois terminé le déploiement.

On ne va pas se compliquer la vie. Pour des besoins de démo on va donner une url issue du site RequestBin:

2015-01-18_22-57-15

Un clic sur CREATE:

2015-01-18_22-58-25

On peut avoir des détails en cliquant ici sur l’icône verte:

2015-01-18_23-02-46

Qui affiche:

2015-01-18_23-03-45

Nous copions l’url dans l’interface Kudu:

2015-01-18_23-00-24

On redéploie en lançant par exemple une commande REDEPLOY. Et RequestBin affiche:

2015-01-19_23-46-17

Ce qui confirme que l’appel a bien eu lieu.

On peut également se rendre dans le menu principal:

2015-01-20_22-55-48

En cliquant sur le lien Web hooks encadré on affiche le compte rendu précédent:

2015-01-20_22-58-05

Depuis VS Online

On se rend  dans la page d’administration du site:

2015-01-26_19-05-26

On sélectionne le projet concerné et on clique sur l’icône en forme de roue:

2015-01-26_19-08-07

On se rend ensuite dans l’onglet Service Hooks. Nous allons créer notre premier hook en cliquant sur la commande « Create the first subscription for this project« :

Une popin s’ouvre alors:

2015-01-26_19-10-47

On dispose d’une liste de services à gauche et pour chaque service une description de ses possibilités à droite.

Nous allons choisir le service Webhooks et faire NEXT, on renseigne le formulaire qui suit:

2015-01-26_19-23-43

NEXT une fois de plus:

2015-01-26_19-27-17

Il est bien de cliquer sur TEST pour … tester!

2015-01-26_19-28-54

 

Et côté RequestBin tout va bien aussi:

2015-01-26_19-29-53

Il ne reste plus qu’à cliquer sur FINISH pour enregistrer:

2015-01-26_19-31-12

Lancez ensuite un redéploiement du site pour valider que tout va bien de ce côté également.

Côté VSO l’incrément a augmenté:

2015-01-26_19-38-50

Et côté RequestBin on constate que le header X-Request-Id a changé.

Voici un exemple un peu plus élaboré:

http://mattvsts.blogspot.fr/2014/07/visual-studio-online-and-service-hooks.html

Lancer un scrip post déploiement

On peut souhaiter faire des choses plus sophistiquées comme lancer une phase d’initialisation du site. On a pour cela la possibilité de lancer un script shell après le déploiement.

Important: l’usage de scripts post déploiement est extrêmement mal documenté et j’ai ramé plusieurs jours la dessus. Je vais donc essayer de vous faire bénéficier de mon savoir-faire durement acquis!

 

Avant de vous lancer vous aurez besoin d’un script de tests. Le mien contient une seule ligne:

@echo Hello Amethyste

Il a été placé dans le fichier postdeploy.bat.

Vous risquez de rencontrer le message d’erreur suivant dans les logs:

‘@echo’ is not recognized as an internal or external command deploy azure

Cela signifie juste que le fichier a été sauvegardé en Unicode et non pas en ANSI. Le message s’affiche également si le répertoire contenant le script n’a pas les droits en exécution.

 

Déployez le script en FTP dans le répertoire suivant:

/site/deployments/tools/PostDeploymentActions

2015-01-28_16-18-07

Relancez le déploiement. Si tout se passe bien, c’est à dire si le script se termine avec le code de retour 0, vous devriez voir ceci dans les logs:

2015-01-28_16-21-11

On clique sur View Log:

2015-01-28_16-19-48

Si vous déployez plusieurs fichiers, ils seront lancés séquentiellement.

 

En principe on devrait pouvoir personnaliser l’emplacement du script à l’aide des variables d’environnement:

  • POST_DEPLOYMENT_ACTION
  • SCM_POST_DEPLOYMENT_ACTIONS_PATH

 

Malgré de nombreuses tentatives je ne suis pas parvenu à obtenir autre chose que des résultats contradictoires. Bref je ne comprends pas comment cela fonctionne. Il semble juste que POST_DEPLOYMENT_ACTION attende un chemin relatif à /site/wwwroot et exige le nom d’un fichier.

Seule info trouvée ici:

https://github.com/projectkudu/kudu/issues/1154

Si un jour la situation se clarifie je ferai un article!

 

Concernant VS Online TFS, rien ne fonctionne de toute façon.

Personnaliser le script de déploiement

Personnaliser un script de déploiement est un besoin fréquent. Par exemple pour configurer un environnement, lancer des tests, faire un nettoyage ou lancer des initialisations post déploiement…

Comment faire?

Repository Git

La première étape sera donc d’écrire son script de déploiement. Reste ensuite à le déclarer pour qu’il soit utilisé en lieu et place du script par défaut.

Pour cela on ajoute dans la racine du projet un fichier appelé .deployment (ne pas oublier le point) et contenant ceci:

[config]
command = SCRIPT A LANCER

Pour écrire nos scripts on dispose de diverses variables d’environnement:

  • DEPLOYMENT_SOURCE : Chemin de la racine du repository dans Azure
  • DEPLOYMENT_TARGET – Le chemin vers wwwroot où le site est déployé
  • DEPLOYMENT_TEMP – Chemin vers un répertoire temporaire qui sera supprimé après le déploiement
  • MSBUILD_PATH – Chemin vers l’exécutable msbuild

Sous sa forme la plus simple le déploiement ressemble à ceci:

xcopy %DEPLOYMENT_SOURCE% %DEPLOYMENT_TARGET% /Y

Evidemment le script par défaut fait un peu plus de choses et mieux vaut partir de lui. Comment le récupérer?

Depuis Kudu:

2015-02-23_12-23-42

Ou bien avec un client FTP, vous récupérez le fichier /site/deployments/Tools/deploy.cmd:

2015-01-30_22-02-24

Il ressemble à ceci:

2015-01-30_22-05-16

Prenez le temps de le lire au moins une fois. C’est de toute façon indispensable pour le personnaliser.

L’essentiel du script tourne autour de KuduSync qui est l’outil effectuant le déploiement depuis le repository. L’outil fait une copie intelligente, c’est à dire que seuls les fichiers modifiés seront copiés et de même il supprimera les fichiers qui auront disparus.

Comment le sait t’il?

Vous avez du remarquer les deux répertoires avec des noms de guid. Il s’agit des ID de déploiement. Comparez les avec ceci:

2015-01-30_22-14-30

Dans ces répertoire se trouve un fichier de manifeste:

2015-01-30_22-15-48

Qui contient la liste des fichiers déployés dans ce déploiement.

Je vais faire un très modeste essai en ajoutant cette ligne:

2015-01-30_22-22-18

Ajoutez deploy.cmd et .deployment au projet pour mettre à jour .proj et redéployez.

Une fois terminé, le fichier de log devrait ressembler à ceci:

2015-01-30_23-20-39

 

Tout s’est donc bien passé.

Note: Le fichier .deployment doit se trouver dans la racine du repository. Sinon ça ne marchera pas.

2015-01-30_23-23-32

Conclusions

Un très gros article pour un thème qui peut paraître insignifiant. Mais pas tant que cela, car un jour ou l’autre on a besoin de déployer.

D’autres repositories sont supportés: Mercurial, BitBucket, CodePlex. Mais la mise en œuvre n’a rien de très différente. Vous devriez avoir tout ce qu’il faut pour y parvenir.

Le support VSO existe et est honorable, mais certains scénarios ne me paraissent pas possibles. Par conséquent, dans le cadre d’un développement professionnel je préconise largement un repository Git qui peut très bien être TFS Git d’ailleurs. Un simple git push et c’est partit!

Le manque de documentation. C’est critique car les scénarios spéciaux sont précisément ceux que l’on rencontrent dans la vraie vie. Donc clairement un gros axe d’amélioration.

Kudu est encore un peu jeune et rugueux. Mais tout de même bien pratique si vous utilisez des repositories Git.

Bibliographie

 

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s