Voici un résumé en français, en texte et en images de l’épisode 127 du Cloud Cover Show, que je vous engage à regarder. L’épisode est disponible à cette adresse: http://channel9.msdn.com/Shows/Cloud+Cover/Episode-127-Windows-Azure-Scheduler.

 

NDT: j’ai ajouté des notes précédées de NDT comme Note Du Traducteur.

 

Dans cet épisode, Chris Risner (http://chrisrisner.com/) parle avec Kevin Kam (@kevinlam_msft) Principal Program Manager sur le Windows Azure Scheduler (panificateur dans la traduction française du portail).

Il y a un mois, une version préliminaire publique des API est sortie mais la semaine dernière (NDT: voir annonce de Scott Guthrie sur son blog le 12 DEC 2013, il peut y avoir un décalage entre l’enregistrement et la diffusion, puis la traduction de l’épisode Winking smile), l’interface graphique a fait son apparition dans le portail. Il est nécessaire de demander l’accès à cette fonctionnalité préliminaire pour pouvoir y accéder depuis le portail.

Ce service est disponible pour les utilisateurs de Windows Azure, ainsi que pour des services internes comme Windows Azure Mobile Services, Skype et XBOX video par exemple.

On voit ensuite comment créer un nouveau job depuis le portail. Un “Job Collection” est un ensemble de travaux qui vont s’exécuter dans une région particulière. Le service assure une haute disponibilité des jobs. Par exemple, en cas d’indisponibilité d’un datacenter, le job (tâche dans la traduction française du portail) s’exécutera ailleurs (sur le même continent). L’intérêt de choisir une région est de pouvoir avoir une latence faible. En effet, un job va typiquement appeler des points de terminaison et cela peut être nécessaire de faire ces appels depuis un endroit proche de la destination.

L’action est ce qui se passe à chaque itération du job. Il existe plusieurs types d’actions: HTTP, HTTPS, Storage Queue. Pour HTTP, on exécutera une des méthodes GET, PUT, POST, DELETE (depuis le portail). Il y en a plus que ces quatre dans l’API. La destination du GET n’est pas nécessairement hébergée dans Windows Azure.

Pour une action de type queue de stockage (“storage queue”), c’est typiquement pour du traitement asynchrone soit parce que le traitement est long soit parce que l’application qui devra traiter le message n’est pas nécessairement disponible au moment ou l’action du scheduler se lance.

Enfin, dans le cas d’HTTPS, ce sont les mêmes principes qu’HTTP, mais la requête est faite avec SSL.

Après avoir défini l’action, il faut définir quand cela se passe, i.e. de façon récurrente ou une seule fois. Pour une action qui a lieu une seule fois, cela peut être maintenant, ou à un moment précis dans le futur. En récurrent, cela peut être toutes les minutes, heures, jours, semaines, et mois. Mois n’est pas encore dans le portail au moment de l’enregistrement, mais disponible dans les API: image. NDT: depuis, cela a été ajouté:image.

Les détails du paramétrage sont ensuite montrés, comme le fait de choisir les lundi et mardi toutes les deux semaines à partir du mois prochain.

Il y a également une date de fin, obligatoire dans le portail, facultative dans l’API.

 

Dans les buts du service “Windows Azure Sheduler”, il y avait: haute disponibilité et simplicité.

 

Dans le portail, le tableau de bord d’une collection de jobs montre le nombre de jobs que l’on a (max: 50), le nombre de jobs terminés, en échec, activés ou désactivés. On a également le nombre d’exécution dans les dernières 24 h à peu près, dont le nombre en échec. On dispose également de quelques informations complémentaires sur la droite du tableau de bord.

L’onglet de mise à l’échelle permet de choisir entre deux modes:

- Gratuit permet d’avoir jusqu’à 5 jobs par collection, et une fréquence maximum d’une heure.

- Standard permet d’avoir jusqu’à 50 jobs par collection et un fréquence maximum d’une minute.

On peut créer depuis un abonnement Windows Azure une collection de jobs, renseigner les contraintes dans cette collection (comme la fréquence maximale), et ensuite avoir d’autres personnes qui créent des jobs dans cette collection, via les API.

l’onglet jobs (tâches en français) montre la configuration du job et les dates de dernière et prochaine exécution.

Le job “historique” permet de voir le détail de ce qui s’est passé à chaque exécution.

 

Il existe une SDK que l’on peut récupérer depuis NuGet. Le portail aura de plus en plus de fonctionnalités. Bien sûr les API permettent un peu plus de choses. Par exemple, on peut définir une “error action” dans les API qui après 5 tentatives infructueuses d’exécution de la tâche va s’exécuter.

Kevin montre cela avec Fiddler, à partir de la 15ème minute de la vidéo. Il faut d’abord récupérer l’URI dans tableau le tableau de bord de la collection de jobs.

L’API de gestion des services, avec les derniers fournisseurs de ressources (resource providers ou RP), il y a une notion d’appel de RP du backend. Pour dire au front end que c’est le backend qu’on veut appeler, on ajoute un ~ comme dans l’exemple ci-dessous:

image

NDT: Il s’agit cependant d’un détail d’implémentation et les URI à utiliser sont documentées ici: http://msdn.microsoft.com/en-us/library/windowsazure/dn528946.aspx pour chaque type d’appel. On retrouve par exemple le ~ ici: http://msdn.microsoft.com/en-us/library/windowsazure/dn528948.aspx.

 

NDT: En essayant, j’obtiens une demande d’authentification

image

Il faut configurer un certificat de gestion dans Fiddler en suivant les étapes ci-après:

1) Créer un certificat de gestion pour votre abonnement Windows Azure et uploader la partie publique CER dans le portail

2) Installer la partie privée PFX dans le store de certificats local sur la machine

3) Mettre une copie de la partie publique CER dans %USERPROFILE%\My Documents\Fiddler2\ClientCertificate.cer

 

L’exécution du GET donne un  résultat comme demandé avec le header Accept en JSON, très lisible.

 

Pour avoir la liste des jobs, il suffit d’ajouter /jobs à la fin de l’URI sur laquelle on fait un GET. On voit également comment créer un nouveau job avec PUT. Les données du job peuvent être confidentielles (elles peuvent par exemple contenir un jeton d’authentification); c’est pour cela que les données du job au sein du service sont chiffrées. On voit également comment on crée une error action qui permet typiquement d’être notifié quand il y a une erreur.

On voit ensuite dans le portail le résultat de l’exécution du job qui échoue (GET vers boing.com) puis l’exécution de l’error action qui résussit (GET vers bing.com).

 

Si vous souhaitez tester cela par vous-mêmes et que vous n’avez pas encore de compte Windows Azure ni d’abonnement MSDN ? Ouvrez un compte de test gratuit: 150 € de ressources pendant 1 mois.

 

Vous trouverez ci-après quelques images de l’épisode.

 

Smile

Benjamin (@benjguin)

 

image

image_thumb

image_thumb[1]

image_thumb[2]

image_thumb[3]

image_thumb[4]

image_thumb[5]

image_thumb[6]

image_thumb[7]

image_thumb[8]

image_thumb[9]

image_thumb[10]

image_thumb[12]

image_thumb[11]

image_thumb[13]

image_thumb[14]

image_thumb[15]

image_thumb[16]

image_thumb[17]