Déploiement de plusieurs rôles Web et rôles de travailleur sur un seul service cloud Azure

Question

Ce n'est peut-être pas nouveau, mais j'espère que quelqu'un pourra me mettre sur la bonne voie car c'est un peu confus lors du déploiement d'Azure. Je suis en train de planifier un déploiement sur Azure. Voici ce que j'ai

1. Une application MVC ASP.Net (web-role) tournée vers le public + un service WCF (web-role) accessible uniquement à cette application asp.net + un service WCF (worker-role) à nouveau accessible à 1. par la file d'attente de messages.
2. Un STS personnalisé, c'est-à-dire une application ASP.NET MVC (rôle web) agissant en tant que fournisseur d'identité (pour 1. qui est une partie utilisatrice) + un service WCF (rôle web) pour exposer certaines fonctionnalités du STS à des parties utilisatrices comme 1.
3. SQL Azure : accessible par 1 et 2 Note : 1. deviendra éventuellement un portail, avec de multiples services wcf hébergés sur le web et des rôles de travailleur pour un accès interne et externe.

Ma question est la suivante : si l'application 1. va être exposée au public, et que l'application 2. est destinée à la fédération de la sécurité (interne), comment dois-je planifier mon déploiement sur Azure en gardant à l'esprit que l'application 1. nécessitera une extension un peu plus tard, ainsi que les deux services wcf ? Dois-je publier sur un service de cloud ou comment ? Si j'ai bien compris, un service cloud est un conteneur logique pour les rôles n-web/worker. Mais lorsque vous avez deux serveurs web, comme dans ce cas les deux applications asp.net, lequel devient le serveur par défaut ?

Meilleures salutations Satish

Answer 1

Par défaut, tous les rôles web de la solution sont publics. Vous pouvez changer cela en allant dans la définition du service et en supprimant les points de terminaison HTTP, si vous le souhaitez ; vous pouvez également définir des points de terminaison HTTP internes qui seront uniquement disponibles pour les services en nuage, rien ne sera exposé à l'équilibreur de charge. L'avantage d'avoir tous les rôles Web dans le même projet est qu'il est facile d'inspecter dynamiquement le RoleEnvironment et chaque rôle Web -- en d'autres termes, tous les rôles dans une solution sont "conscients" des autres rôles et de leurs ports disponibles. Il est également facile de déployer un seul paquet.

Tous les rôles partagent le même nom DNS (.cloudapp.net) (vous pouvez toutefois utiliser des en-têtes d'hôte pour les différencier), mais ils sont généralement exposés en utilisant différents ports via l'équilibreur de charge de votre service .cloudapp.net. Vous pouvez voir cela lorsque le service est exécuté dans le nuage, il y a des liens dans le portail qui pointent vers chaque rôle qui a un point de terminaison HTTP public qui spécifie le port. Celui qui a le port 80 (tel que défini par le point de terminaison HTTP externe) est le site "par défaut".

Vous pouvez également créer plusieurs projets de cloud et les déployer séparément. Dans ce cas, chacun aura son propre nom DNS et sera géré séparément. Le fait que ce soit une bonne chose ou non dépend de l'étroitesse du couplage des applications et du fait que vous déployez généralement la solution entière ou que vous mettez simplement à jour des rôles individuels au sein de cette solution. Mais il n'y a aucune différence de coût ou d'évolutivité.

Si vous avez l'intention de redéployer fréquemment un seul des rôles, je préférerais les séparer.

Answer 2

Pour déployer plusieurs rôles Web sous la même instance de nuage, voyez ce qui suit : Meilleure pratique pour le déploiement d'un site Web dans un service en nuage (cloud)

Les rôles multiples des travailleurs seront plus difficiles à mettre en œuvre : Exécuter plusieurs WorkerRoles par instance