Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Les fichiers *.config sous Azure

Poster un commentaire

C’est mon 100ème article! Mais ce sera sa seule particularité.

Au moins deux ressources Azure utilisent *.config:

  1. les web site
  2. les rôles

En tout cas si elles sont créées via ASP.NET.

Si le fichier est le même, il y a pourtant des différences intéressantes sur la façon dont est gérée la section <appSettings> que je vais développer ici.

Les web site

Expérimenter est la base. On créée un projet MVC dans lequel on place ceci dans la configuration:

<add key="toto" value="toto est sur web.config" />

On complète le formulaire avec ceci quelque part:

<p>@System.Configuration.ConfigurationManager.AppSettings["toto"]</p>
<p>@System.Configuration.ConfigurationManager.AppSettings["tutu"]</p>
<p>@Microsoft.WindowsAzure.CloudConfigurationManager.GetSetting("titi")</p>
<p>@Microsoft.WindowsAzure.CloudConfigurationManager.GetSetting("tutu")</p>
<p>@Microsoft.WindowsAzure.CloudConfigurationManager.GetSetting("toto")</p>

On accède au fichier de configuration de deux manières:

  • Via ConfigurationManager qui est la méthode classique on premises que nous connaissons bien
  • Via CloudConfigurationManager qui fait partie du SDK Azure

Cette classe accède aux éléments de configuration Azure. Elle n’est donc en rien spécifique à .Net et c’est l’existence de ce genre de classe qui permet de pousser dans Azure des applications venues de divers langages. Si cela fonctionne c’est parce que Azure maintient une table de paramètres quelque part dans un stockage purement Azure ce qui n’est pas le cas de web.config ou app.config.

La classe CloudConfigurationManager sait rechercher des informations dans cette table Azure (attention, je ne connais rien de la nature exacte de ce stockage, je sais juste qu’il existe forcément) si votre application tourne sous Azure. Autrement il va rechercher dans les fichiers de configuration habituel.

Nous allons étudier ce qui se passe lorsque l’on modifie le fichier de config traditionnel, lorsque l’on créée ou modifie les paramètre dans la configuration Azure.

Déployez donc le web site et touchez à rien d’autre.

L’affichage de la page ressemble à celui-ci:

2014-10-29_08-59-11

La première ligne est ce à quoi on s’attendait, le paramètre est trouvé dans web.config puis affiché. On remarque que si le paramètre n’existe pas rien ne s’affiche.

On est sous Azure, mais j’ai pour l’instant pas définit de paramètre toto, CloudConfigurationManager va donc lire le fichier web.config d’où l’affichage.

Revenons au portail et ajoutons les paramètres suivants:

2014-10-29_09-03-11

On recharge la page est maintenant tout est sous Azure:

2014-10-29_09-04-28

CloudConfigurationManager fait ce que l’on attend de lui: il regarde si le paramètre demandé est sur Azure. Si c’est le cas il le charge, autrement il regarde dans les autres configuration.

Plus intéressant est ConfigurationManager qui, surprise, fonctionne de la même façon que CloudConfigurationManager. On a pas modifié la moindre ligne de code.

Ce comportement est caractéristique de l’effort que fait MS pour permettre à des développeurs de développer des applications Web Site sans rien connaître d’Azure. C’est quelque chose que nous avions déjà rencontré avec les WebJobs qui proposent la même expérience développeur.

Le point intéressant est qu’il est possible à un administrateur de modifier des données sensibles une fois le déploiement effectué sans qu’elles soient accessibles à l’équipe de dev ou de maintenance. Il a juste besoin de modifier des paramètres Azure.

 

Avons nous le même comportement avec les Web Role? Le plus simple est d’essayer.

Les Web Role

On va également créer un Web Role MVC avec exactement le même code et paramétrage que le WebSite précédent. On le publie et on lance.

2014-10-29_08-59-11L’analyse n’a pas variée par rapport au Web Site.

Si vous vous rendez dans le panneau de configuration une première surprise nous attend:

2014-10-29_13-54-36

Une différence de taille est qu’il n’est pas possible de définir dynamiquement les paramètres. Il faut revenir au projet VS et charger la fenêtre de propriétés du WebRole:

2014-10-29_14-10-31

Il faut redéployer maintenant. Cette fois nos paramètres sont là, ils sont éditables.

2014-10-29_14-15-23

Si je recharge le site:

2014-10-29_21-40-00

Contrairement aux WebSite, ConfigurationManager ne lit que le fichier *.config.

 

 

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