Configurer un cloud privé sur Windows Server 2008 R2

Ce maudit Cloud mot

Gardez à l'esprit qu'un cloud privé n'est pas vraiment différent de la plupart de vos serveurs web internes et applications d'aujourd'hui. L'article que vous avez fourni va plus loin en permettant essentiellement à votre équipe de développement de créer, de mettre à l'échelle et de contrôler leurs propres machines virtuelles. À la fin cependant, avec les informations que vous avez fournies, tout ce que vous cherchez vraiment, c'est à ce que IIS exécute l'application que vous avez.

Y a-t-il une différence entre Azure et IIS?

La principale différence entre une application web Azure et une qui s'exécute sur IIS est assez simple, l'une a le conteneur d'application Azure ajouté à la solution et l'autre non. L'offre d'Azure s'est étendue et vous avez désormais plus de contrôle sur les machines virtuelles sous-jacentes et même vos propres machines virtuelles, mais j'aborderai cela du point de vue le plus basique, en utilisant Azure comme modèle PaaS ou Platform as a Service.

Configuration de Visual Studio

C'est assez facile dans Visual Studio de générer plusieurs configurations de build, une spécifiquement pour IIS et l'autre pour Azure. Cela définit simplement les mécanismes de build qui préparent soit l'application en configurant un package de déploiement Azure, soit un autre qui crée simplement un package IIS.

Rappelez-vous qu'Azure est essentiellement IIS mais avec des fichiers de configuration et de paramètres qui doivent accompagner l'application.

Configuration IIS

Il n'y a vraiment pas grand chose au-dessus et au-delà de la configuration standard requise pour le serveur web ici. Vous pouvez avoir des exigences supplémentaires telles que le stockage de fichiers et même le caching (voir Server et Azure AppFabric/Caching). Vous devrez travailler avec votre équipe de développement pour déterminer quelles sont les exigences et mettre en place les systèmes nécessaires pour les soutenir.

Considérations de Solution

Votre équipe de développement doit également comprendre quelque chose d'important ici : concevoir et construire l'application pour fonctionner dans n'importe quel environnement. Ce que je veux dire par là c'est qu'indépendamment du support de déploiement final et du chemin, l'application devrait fonctionner normalement. Ainsi, dans votre situation, ils voudront très probablement utiliser l'injection de dépendance pour le stockage de fichiers afin que l'API de stockage Azure puisse être appelée ou qu'elle puisse revenir à un mécanisme de stockage de fichiers System.IO standard. De toute façon, simplement configurer le matériel pour soutenir l'application ne suffit pas, elle doit être conçue pour prendre en charge plusieurs environnements également.

Ceci est un tas de conneries marketing. "Le Cloud" n'est pas une seule chose qui peut être facilement définie. C'est un ensemble de stockage redondant et hautement disponible ainsi que de matériel de serveur, habituellement géographiquement disparate, qui permet aux gens de scaler rapidement et en toute sécurité leur opération selon leurs besoins.

Un "cloud privé" n'est que des conneries marketing pour un environnement de serveur virtualisé qui peut être abstrait par un ensemble d'APIs et automatisé pour scaler comme un "cloud public".

Azure est l'offre de cloud public de Microsoft. Un "cloud privé" peut s'en rapprocher, mais ce n'est pas la même chose.

Je vous recommanderais d'avoir deux instances Azure. Obtenez-en une pour le développement/test et une pour la production si c'est le service que vous choisissez d'utiliser. De cette façon, vous saurez exactement ce que votre application fera lorsque vous la déplacerez en production, car elle est déjà sur Azure.