A propos des montées de version des services de cloud computing
Ce billet est co-écrit avec mon collègue Stéphane Goudeau, architecte Cloud au sein de la division DX de Microsoft France. Stéphane est le co-auteur des excellents livre-blancs Le Cloud et le développeur – Comment le cloud révolutionne le développement ? et DevOps pour le Cloud… et réciproquement que je vous invite à lire si ce n’est déjà fait. Vous trouverez plus d'informations ici à ce sujet.
Je vous en souhaite une bonne lecture.
--Philippe
La solution Open Data Clé en main sous licence libre Microsoft Public License (Ms-PL) utilise les services de cloud computing de Microsoft Azure pour les accélérateurs suivants :
 |
|
 |
|
 |
|
 |
Le portail Citoyen Open Data utilise pour sa part par défaut les sites Web de Microsoft Azure, un service d’hébergement permettant la construction rapide de sites Web avec la possibilité d’utiliser des gestionnaires de contenus (CMS) populaires tels que Drupal, Joomla, etc. |
En termes de mise en œuvre, ces services de cloud computing sont déployés et exécutés sur des machines virtuelles sous un système d'exploitation Windows Server optimisé pour fonctionner au sein de votre abonnement dans l’environnement Azure.
Ce système d’exploitation évolue régulièrement et fait donc l’objet de mises à jour globalisées. Celles-ci sont nécessaires pour s’assurer que les solutions développées à destination de la plateforme Azure sont adossées à des systèmes fiables et sécurisés, intégrant les dernières innovations.
C’est un sujet que nous avons abordé dans le billet précédent pour OGDI DataLab et que nous souhaitons compléter avec billet. Compte tenu de ces évolutions continues, il est en effet impératif tant pour le développeur que pour le responsable système de disposer d’une bonne compréhension de la façon dont ces mises à jour sont appliquées, et de la façon dont ces dernières peuvent impacter la disponibilité et la facilité de maintenance des solutions dont ils ont la charge. Il s’agit dans le contexte présent des accélérateurs de la solution Open Data Clé en main utilisés pour votre projet Open Data.
Dans la pratique, le modèle sur lequel repose les services de cloud computing délègue à Microsoft la responsabilité de gérer l’infrastructure sous-jacente et notamment les mises à jour. Cette délégation ne dispense pas de se préoccuper des mises à niveau des systèmes d'exploitation hébergés.
Comme vous le savez déjà, et ce éventuellement à la lumière du billet précédent, vous avez la possibilité de contrôler la version de Windows Server déployée dans vos services de cloud computing, en utilisant l'attribut osFamily dans le fichier de configuration de service (fichier ServiceConfiguration.cscfg). A cet attribut osFamily s’ajoute l’attribut osVersion :
<ServiceConfiguration serviceName="service-name" osFamily="osfamily-number" osVersion="os-version" schemaVersion="schema-version">
…
</ServiceConfiguration>
La configuration du service de cloud computing permet de choisir la mise à jour automatique des versions du système d’exploitation hébergé en spécifiant l’attribut osVersion avec un astérisque « * » (mais pas la mise à jour automatique de la « famille » du système d’exploitation).
Suivant la nature du service de cloud computing, un simple changement de version (par exemple un correctif de sécurité) peut induire une incompatibilité avec le code qui s'exécute dans la solution déployée sur la machine virtuelle.
Si vos (bonnes) pratiques de sécurité vous conduisent à déployer les correctifs de sécurité sur des systèmes de test ou de pré-production avant de les appliquer en production, vous aurez très certainement une préférence pour définir manuellement l’attribut osVersion en correspondance avec vos processus internes de validation de version.
Le développeur est également directement concerné par cette gestion des versions du système d'exploitation des machines virtuelles hébergées. En effet, une correspondance est établie entre le la version du kit de développement (SDK) Azure utilisé et certaines des versions du système d'exploitation invité. C’est donc à lui qu’incombe la responsabilité de choisir un niveau de version du SDK compatible avec la cible de déploiement. Ce travail est effectué dans le cadre des évolutions des accélérateurs précédents sur la forge GitHub.
Fort heureusement, la probabilité qu’une prochaine version de système d'exploitation hébergé (et potentiellement automatiquement mis à jour) ne supporte pas le SDK avec lequel le code a été compilé reste extrêmement faible ;-)
Chaque nouveau système d’exploitation est testé, lors de sa publication, avec les deux dernières versions du SDK Azure : à ce jour les versions 2.3 d’avril 2014 et 2.2 d’octobre 2013.
Les compatibilités des familles de système d’exploitation et de SDK sont référencées ici dans la documentation en ligne. Lorsqu’une nouvelle version du SDK est publiée, vous avez jusqu'à un an pour moderniser vos solutions en la recompilant avec une version de SDK supporté. (A ce propos, nous allons profiter de l’été pour passer au dernier niveau de version sur l’ensemble des accélérateurs de la solution Open Data Clé en main).
Les montées de versions manuelles imposent le suivi et le test des versions de système d'exploitation hébergées qui doivent être « ciblées » avant d'être appliquées. Les montées de versions automatiques ne permettent pas le contrôle avant publication, mais doivent être accompagnées de tests systématiques pour mieux les anticiper.
Dans les deux cas, cette démarche sera facilitée par la mise en place d'un environnement permettant de faire évoluer l’application à chaque nouvelle version de SDK, et de la tester pour chaque mise à niveau de système d’exploitation hébergé. D’où l’intérêt de l’automatisation des tests de non régression sur un environnement dont on maîtrise la configuration.
Un processus type qui permet d’effectuer cette validation comprend les étapes suivantes :
- Recompilation de la solution avec la dernière version du SDK Azure.
- Exécution des tests unitaires (s’il y en a :)).
- Déploiement de la solution déployée dans un environnement de test dans Azure.
- Exécution de tests supplémentaires (d’interfaces Web automatisées).
Un tel processus se doit d’être déclenché à chaque nouvelle publication de version.
Une façon de se tenir à jour consiste à s'abonner ici au flux RSS d’information sur les versions de système d’exploitation.
Pour la validation du fonctionnement d’un service de cloud computing, il est préférable d’aller au-delà du simple démarrage de l’instance de chaque rôle. Par exemple, dans le cas d’un service de cloud computing hébergeant un rôle Web comme pour OGDI DataLab ou ODAF Openturf, il sera utile de mettre en place un test permettant de reproduire le scénario de navigation sur l’application Web ou le service Web à l’image de ce qui pourrait être réalisé dans ce contexte avec le service de données OData de la plateforme OGDI DataLab.