SharePoint Grib's Lair

IIS et les Applications Web SharePoint : Best Practices

Une des choses que j’aime avec SharePoint, c’est de voir que la frontière exploitation/développeurs est souvent moins marquée qu’ailleurs.

Moins marquée parce que SharePoint fait appel à tellement de systèmes différents qu’un développeur ne pourra pas s’en sortir bien longtemps sans s’intéresser à des problématiques un peu plus connotée infrastructure/système/réseau qu’à son habitude.

Moins marquée également car les admins se mettent à s’intéresser au monde du développement. Et j’insiste sur ce point, car je l’ai vu plusieurs fois : les admins veillent de plus en plus souvent aux fuites mémoire et sont aussi souvent conscient que des Best Practices de développement (l’appel au Dispose) peuvent les réduire considérablement. Mieux que ça : j’en ai vu se mettre à coder, dans Visual Studio (chose plutôt rare), ou via PowerShell  (chose déjà bien plus courante).

Bref, la frontière se réduit par endroit et c’est une très bonne chose. Il n’empêche… certaines vielles habitudes persistent de chaque côté et impliquent des difficultés d’administration et/ou des dysfonctionnement dont je viens parler ici.

Problèmes concrets :

La souplesse de SharePoint fait qu’une batterie de serveurs peut s’élargir facilement, pour mieux tenir la charge par exemple, ou encore pour assurer une continuité de service. Lorsqu’un nouveau serveur est ajouté à la batterie de serveurs, SharePoint réalise automatiquement une série d’opérations sur le nouveau serveur :

• Création des applications pools
• Création des sites IIS
• Déploiement des fichiers de solution contenus dans le magasin de solutions SharePoint (fichiers dans le répertoire 12, déploiement dans le GAC/BIN, …)
• Mise à jour des fichiers web.config en fonction des modifications gérées par SharePoint (SafeControls, SPWebConfigModification, …)

Bref, en théorie un site est opérationnel dès que le serveur est rattaché à la batterie de serveurs. En pratique, ce mécanisme est très souvent insuffisant car les développeurs et/ou les administrateurs ont introduit des changements à faire manuellement : le mécanisme automatique de SharePoint ne les réalise donc pas… et c’est le drame !

Quelques exemples de problèmes vécus :

• Ajout manuel de paramètres dans le fichier web.config :

Les développeurs ont ajouté manuellement des paramètres dans le fichier web.config. Une ConnectionString par exemple, ou encore n'importe quel paramètre, référence à une ressource externe, etc. Lorsque l’utilisateur se connecte à l’Application Web SharePoint, le mécanisme de load balancing détermine quel serveur traite la demande. Dans certain cas le serveur qui répondra aura les bons paramètres… de temps en temps ce sera le serveur à qui il manque des paramètres. Dans le dernier cas, les utilisateurs ont de forte chance de tomber sur une page d’erreur.

• Déploiement manuel de WebParts / Features / Ressources.

Les développeurs ont déployés les WebParts, Features et/ou ressources en les copiant manuellement dans le répertoire 12 puis en utilisant la commande stsadm –o installfeature. Le nouveau serveur sera dépourvu de ces éléments et tout utilisateur dirigé vers ce serveur sera confronté à une page d’erreur SharePoint.

• Modification du port ou changement de host header directement depuis IIS

Qui n’a jamais voulu changer le port ou les host headers après la création d’une application Web SharePoint (pour un changement de DNS par exemple) ? Ces paramètres sont bien connus des admins qui savent les modifier depuis IIS. Lorsque cette opération est réalisée via IIS, elle reste locale. En d’autres termes, SharePoint créé automatiquement les sites IIS sur le nouveau serveur mais les modifications réalisées manuellement sur les autres serveurs ne sont pas propagées. Les utilisateurs peuvent alors tomber sur d’autres sites que ceux demandés ou sur des erreurs 404.

• Paramétrage des pools d’applications

Assez similaire aux sites IIS. Vous pouvez souhaiter les paramétrer pour prendre en compte des modifications sur les comptes de service. Dans ce cas spécifique SharePoint ne vous laissera pas faire… en tout cas pas longtemps. En effet, SharePoint changera automatiquement le compte associé au pool d’application pour lui fixer sa propre valeur. Pour les autres paramètres du pool d’application, toute modification sur IIS reste locale.

Comment éviter ces problèmes / Les Best Practices :

Le fichier Web.Config

Les développeurs ASP.Net ont l’habitude de modifier manuellement le fichier web.config d’une application web pour y ajouter des paramètres. Avec SharePoint il faut cependant privilégier un autre moyen : la classe SPWebConfigModification. J’ai cependant souvenir de propos négatifs concernant cette classe, tels que '”tout le monde sait qu’il ne faut pas l’utiliser”. Et bien pourtant si ! Les détracteurs lui reprochent de compromettre le fichier web.config. Je répond que NON. Ces personnes ont tout simplement rencontré des problèmes avec des fichiers web.config qu’elles avaient modifiés manuellement et qu’elles voulaient modifier, en plus, via la classe SPWebConfigModification. Les problèmes potentiels ne sont à imputer qu’aux modifications manuelles et pas à la classe SPWebConfigModification. Bref, passer par cette classe pour modifier le fichier web.config est un Best Practice. A chaque fois qu’un développeur fait le choix d’une modification manuelle, il induit une difficulté supplémentaire pour les admins (en cas d’ajout ou de restauration d’un serveur SharePoint) et pour les prochains développeurs (qui ne pourront plus utiliser cette classe sans avoir de problème).

Déploiement de WebParts / Features / Ressources.

Les copier/coller sont à proscrire. Utilisez des solutions SharePoint. SharePoint stocke alors vos solutions dans le magasin de solutions et sait quelles sont les opérations à rejouer pour les déployer sur de nouveaux serveurs. En outre, ce procédé évite de toucher aux éléments natifs de SharePoint (je l’ai encore vu récemment).

Modification des paramètres IIS

Ce point est un peu plus délicat. En effet, l’interface d’administration SharePoint n’offre pas la possibilité de modifier ces paramètres sans détruire puis recréer l’application Web à partir d’une base de données existante. Ce mécanisme est (trop) lourd et peu envisageable. Il existe cependant une alternative, discrète : modifier les paramètres IIS depuis le modèle objet SharePoint à l’aide de la classe SPIisSettings. Un petit exemple avec du code ajoutant un host header au site IIS :

System.Uri uri = new Uri("http://localhost");
SPWebApplication webApplication = SPWebApplication.Lookup(uri);
SPIisSettings settings = webApplication.IisSettings[SPUrlZone.Default];
SPServerBinding binding = new SPServerBinding();
binding.Port = 80;
binding.HostHeader = "gribs.virtualdomain.com";
settings.ServerBindings.Add(binding);
webApplication.IisSettings[SPUrlZone.Default] = settings;
webApplication.Update();
webApplication.Unprovision();
webApplication.Provision();

Bref, il reste à passer ce type de code en PowerShell pour ce que soit exploitable plus facilement par des admins (hum… Fabrice ? :-))

Modification de l’Application Pool

Très similaire à IIS avec la classe SPApplicationPool.

Conclusions :

Ces Best Practices se résument facilement : il FAUT passer par les mécanismes natifs SharePoint pour toute modification impactant les déploiements. Je regrette qu'il soit cependant parfois si complexe de les mettre en pratique : pour le SPWebConfigModification, par exemple, dès lors que d’autres développeurs ont fait le choix des modifications manuelles. Pour les modifications IIS également, car il n’y a pas d’interface (ça ne sautait tarder… je suis en train d’en faire une :-)).

Il n’empêche : faire l’impasse sur ces recommandations impliquera obligatoirement des lourdeurs dans les tâches d’exploitation.