Démarrer une machine Windows sur AWS est très simple : c’est l’affaire d’une seule ligne de commande … c’est automatisé ! Mais telle quelle, cette machine est inutilisable, elle n’est pas configurée pour répondre aux besoins d’une application. Automatiser la mise à disposition de serveurs Windows devrait répondre à des besoins plus spécifiques, apporter plus de contenu … et disposer d’une certaine forme d’intelligence.

De quelles informations a besoin une machine Windows pour être exploitable ? Active Directory, règles de nommage, software… toutes les normes et standards définis par le client doivent pouvoir être configurées de façon automatisée.

C’est dans le cadre de l’un de nos projets de mise en place d’infrastructure Citrix que nous avons pris soin de traiter la question de l’automatisation de la stack Microsoft. Dans le contexte du client, les serveurs Windows étaient déployés manuellement : pour nous, installer des composants Citrix par dessus un processus manuel n’avait pas grand sens. Nous avons donc commencer à envisager une solution d’automatisation qui permettrait d’adresser des cas d’usage Citrix, et de façon plus large Microsoft.

Aujourd’hui les applications cloud natives sont encore relativement rares, et l’immense majorité des projets cloud des DSI consiste à migrer leurs applications historiques depuis leurs datacenters vers le cloud. C’est un cas d’usage fréquent, mais qui sort du cadre pour lequel le cloud fonctionne de façon efficiente (infrastructure agile). Or toutes les applications d’entreprises ne fonctionnent pas encore sur ce mode agile, cloud ready, et la plupart des applications Microsoft ont des dépendances fortes avec l’infrastructure.

Actuellement, les outils proposés par les fournisseurs de cloud ne permettent pas de répondre à ces besoins d’automatisation des composants Microsoft. Nous avons donc pris l’initiative de développer une solution spécifique D2SI, qui s’appuie sur des produits open source comme Boxstarter, Chocolatey, Packer et Terraform afin de permettre l’installation d’applications en mode séquentiel sur des serveurs windows, et de configurer les environnements de façon automatisée.

Principales difficultés : automatiser tout ce qui existe dans une production , prévoir la haute disponibilité des serveurs SQL, des serveurs Web, etc. Globalement, nous avons choisi de construire un socle à partir duquel il devient possible déployer les machines plus rapidement : une image dupliquée N fois, et que l’on peut provisionner automatiquement. Sur cette base, on déploie ensuite de façon automatisée les applications et les configurations. Manuellement ce processus peut être relativement long parce qu’il fait intervenir différents profils; sur le Cloud, on sort de cette logique de silos et le gain de temps est évident, mais cela demande de faire appel à des profils généralistes, avec des compétences transverses.

Pour nos client, le bénéfice est évident : ils disposent sur le Cloud d’un niveau d’automatisation bien supérieur à ce qu’il pourrait bénéficier en interne. Notre méthodologie a été appliquée sur AWS, mais elle n’est pas spécifique à cette plateforme : elle est applicable sur Azure ou Google Cloud.