Quelle est la différence entre un site Web Azure et un rôle Web Azure


241

Quelles sont les différences importantes entre les nouveaux sites Web Azure et les rôles Web Azure traditionnels pour une application ASP.NET MVC? Quelle raison pourrais-je choisir un "site Web" plutôt qu'un "rôle Web" ou vice versa?

Supposons que j'aurais besoin d'une capacité égale dans les deux cas (par exemple, 2 petites instances). Les prix semblent comparables à part le fait qu'il existe une remise temporaire de 33% pour les sites Web pendant leur période de prévisualisation.

Y a-t-il des choses que je peux faire avec un "site web" qui sont difficiles ou impossibles avec un rôle web? Par exemple, devient-il facile de mettre plusieurs sites Web dans un seul ensemble de machines virtuelles en utilisant des "sites Web"? Est-ce que je perds quelque chose avec un "site Web" par rapport à un "rôle Web"? Capacité à affiner IIS? Possibilité d'utiliser le service Cache localement?


avait les mêmes qs. ils devraient vraiment l'indiquer clairement dans leurs documents.
90abyss

Réponses:


213

Les rôles Web vous offrent plusieurs fonctionnalités au-delà des applications Web (anciennement sites Web):

  • Possibilité d'exécuter des scripts de démarrage élevés pour installer des applications, modifier les paramètres du registre, installer des compteurs de performances, affiner IIS, etc.
  • Possibilité de diviser une application en plusieurs niveaux (peut-être un rôle Web pour le frontal, un rôle de travailleur pour le traitement du backend) et une mise à l'échelle indépendante
  • Possibilité de RDP dans votre VM à des fins de débogage
  • Isolement du réseau
  • Adresse IP virtuelle dédiée, qui permet aux instances de rôle Web dans un service cloud d'accéder à des machines virtuelles restreintes IP
  • Points de terminaison restreints aux ACL (ajoutés dans Azure SDK 2.3, avril 2014)
  • Prise en charge de tous les ports TCP / UDP (les sites Web sont limités à TCP 80/443)

Les applications Web présentent cependant des avantages par rapport aux rôles Web:

  • Déploiement presque instantané avec historique de déploiement / annulations
  • Visual Studio Online, github, git local, ftp, CodePlex, DropBox, prise en charge du déploiement BitBucket
  • Possibilité de déployer l'un des nombreux CMS et frameworks (comme WordPress, Joomla, Django, MediaWiki, etc.)
  • Utilisation de SQL Database ou MySQL
  • Évolutivité simple et rapide du niveau gratuit au niveau partagé au niveau dédié
  • Emplois Web
  • Sauvegardes du contenu du site Web
  • Outils de débogage Web intégrés (console de débogage cmd / powershell simple, explorateur de processus, outils de diagnostic comme la diffusion de journaux, etc.)

Avec les déploiements d'avril 2014 et de septembre 2014, certaines fonctionnalités communes aux applications Web et aux rôles Web (et rôles de travail) sont désormais disponibles, notamment:

  • Stages + créneaux de production
  • Certificats DNS, SSL génériques
  • Intégration Visual Studio
  • Prise en charge de Traffic Manager
  • Prise en charge du réseau virtuel

Voici une capture d'écran que j'ai prise du formulaire de sélection de la galerie de sites Web: entrez la description de l'image ici

Je pense que les applications Web sont un excellent moyen d'être rapidement opérationnel et de passer des ressources partagées aux ressources réservées. Une fois que vous avez dépassé ce stade, vous pouvez ensuite passer aux rôles Web et étendre selon vos besoins.


Outre Git + ftp, un autre grand est PublishSettings (peut également être utilisé dans WebMatrix 2 par exemple)
Kris van der Mast

18
La division en niveaux n'est pas un facteur de différenciation. Vous pouvez utiliser des rôles de travailleur avec des sites Web.
RickAndMSFT

4
Concernant les niveaux: avec les sites Web, vous devez vous connecter à un travailleur via un point de terminaison externe, car les sites Web ne prennent pas en charge les réseaux virtuels. De plus: vous devez diviser votre code sur plusieurs déploiements (un pour les sites Web, un pour le service cloud avec rôle de travailleur). Avec Cloud Service, vous pouvez facilement partitionner votre code en niveaux évolutifs, puis dimensionner et mettre à l'échelle chaque niveau indépendamment, tout en ayant une communication interne entre lesdits niveaux. C'est ce que je voulais dire en désignant les niveaux comme un différenciateur des services cloud (web / travailleur).
David Makogon

1
N'est-ce pas un peu dépassé par rapport à stackoverflow.com/a/10960755/56145 ?
Matt Kocaj

2
Avec le rôle Web, vous pouvez également effectuer un traitement en arrière-plan sur les mêmes machines virtuelles
Boris Lipschitz

44

EDIT 2014: Pour ce que ça vaut, une grande partie des informations dans cette réponse n'est plus correcte - voir les commentaires.

Ajoutez plus à la réponse @David:

Avec les sites Web Windows Azure, vous n'avez aucun contrôle sur IIS ou le serveur Web, car vous utilisez une tranche de ressources avec des centaines d'autres sites Web sur la même machine, vous partagez des ressources comme les autres, il n'y a donc aucun contrôle sur IIS.

La grande différence entre un site Web partagé et un rôle Web Azure est qu'un site Web est considéré comme lié au processus tandis que les rôles sont liés à la machine virtuelle.

Les sites Web sont stockés sur un partage de contenu qui est accessible à partir de tous les "serveurs Web" de la batterie de serveurs, il n'y a donc pas de réplication ou quelque chose du genre requis.

Les sites Web Windows Azure ne peuvent pas avoir leur propre nom d'hôte à la place, ils doivent utiliser le nom du site Web site .azurewebsites.net uniquement et vous pouvez certainement utiliser le paramètre CNAME dans votre fournisseur DNS pour acheminer votre demande exactement de la même manière avec le rôle Windows Azure précédent uniquement lorsqu'ils s'exécutent en mode réservé . Le paramètre CNAME n'est pas pris en charge pour les sites Web partagés.


AFAIK WebRoles n'a pas non plus son propre nom d'hôte - ils sont tous rolename.cloudapp.net. À moins qu'il y ait une fonctionnalité que je ne connais pas?
Brian Reischl

Ne pouvez-vous pas utiliser DNS pour créer un alias CNAME pointant de www.votredomaine.com vers websitename.azurewebsites.net?
Bernard Vander Beken

Je crois que pour les sites Web WA, seules les applications exécutées avec des instances réservées (machines virtuelles dédiées) peuvent avoir des domaines personnalisés qui leur sont mappés.
user94559

Je pense que scottgu a récemment mentionné qu'il cherchait également à prendre en charge les domaines personnalisés sur les instances partagées.
jeremy

19
Pour ce que ça vaut, une grande partie des informations de cette réponse ne sont plus correctes (même si c'était en juin 2012): les sites Web peuvent désormais avoir des domaines personnalisés. Les sites Web peuvent fonctionner en mode "réservé", qui est essentiellement une machine virtuelle, mais entièrement géré.
Jay Querido

34

Je viens de publier un article de blog complet sur ce sujet à http://robdmoore.id.au/blog/2012/06/09/windows-azure-web-sites-vs-web-roles/ .

Un extrait de ma conclusion: si vous avez besoin de centres de données à grande échelle, SSL, asiatiques ou ouest-américains, une configuration non standard (d'IIS, de ports, de diagnostics, de certificats de sécurité ou de scripts de démarrage), RDP ou des rôles de travail rentables ( combiné avec votre rôle Web), vous devrez pour l'instant vous en tenir aux rôles Web.

Sinon, les sites Web sont une excellente option!


14

Le rôle Web Azure est comme un hôte privé virtuel. Vous obtenez une machine virtuelle qui agit comme votre serveur Web et vous êtes propriétaire de cette instance de machine virtuelle.

Les sites Web Azure sont comme un service d'hébergement partagé élastique. Vous déployez votre application sur un serveur Web qui n'est pas contrôlé par vous et qui dessert également les sites d'autres utilisateurs. Vous pouvez faire évoluer votre site de haut en bas (moyennant des frais supplémentaires) pour le rendre plus élastique à mesure que vos besoins en ressources évoluent.


6

Il y a un autre scénario qui est en suspens: une fois ces 500 exceptions éliminées, ils n'ont rien dit sur la capacité des sites Web Azure à gérer les CNAME génériques. Plusieurs d'entre nous utilisent l'accélérateur de rôles Web de Nate dans les services cloud, car il s'agit d'une fonction de sous-domaine générique fournie par un hack d'une ligne dans le logiciel de Nate. Nous ne pouvons pas déplacer ces applications de sous-domaine générique tant que nous ne savons pas que les sites Web Azure seront en mesure de les gérer. S'il ne peut jamais le faire, cela devient positif du côté du rôle Web de l'équation. Il convient également de noter que les prix étant exactement les mêmes (après l'expiration de la remise sur l'aperçu), je ne suis pas sûr de vouloir abandonner mon accès à RDC et à l'Observateur d'événements (pour ne mentionner que deux choses).


6

Sites Web Azurevous permet de créer rapidement des sites Web hautement évolutifs sur Azure. Vous pouvez utiliser le portail Azure ou les outils de ligne de commande pour configurer un site Web avec des langages populaires tels que .NET, PHP, Node.js et Python. Les infrastructures prises en charge sont déjà déployées et ne nécessitent pas d'étapes d'installation supplémentaires. La galerie de sites Web Azure contient de nombreuses applications tierces, telles que Drupal et WordPress, ainsi que des cadres de développement tels que Django et CakePHP. Après avoir créé un site, vous pouvez soit migrer un site Web existant, soit créer un tout nouveau site Web. Les sites Web éliminent le besoin de gérer le matériel physique et offrent également plusieurs options de mise à l'échelle. Vous pouvez passer d'un modèle mutualisé partagé à un mode standard où des machines dédiées traitent le trafic entrant. Les sites Web vous permettent également de vous intégrer à d'autres services Azure, tels que SQL Database, Service Bus et Storage. À l'aide de l'aperçu du SDK Azure WebJobs, vous pouvez ajouter un traitement en arrière-plan. En résumé, les sites Web Azure facilitent la concentration sur le développement d'applications en prenant en charge un large éventail de langues, d'applications open source et de méthodologies de déploiement (FTP, Git, Web Deploy ou TFS). Si vous n'avez pas d'exigences spécialisées qui nécessitent des services cloud ou des machines virtuelles, un site Web Azure est probablement le meilleur choix.

Services cloudvous permettent de créer des applications Web hautement disponibles et évolutives dans un environnement Platform as a Service (PaaS) riche. Contrairement aux sites Web, un service cloud est d'abord créé dans un environnement de développement, tel que Visual Studio, avant d'être déployé sur Azure. Les cadres, tels que PHP, nécessitent des étapes ou des tâches de déploiement personnalisées qui installent le cadre au démarrage du rôle. Le principal avantage des services cloud est la capacité à prendre en charge des architectures multiniveaux plus complexes. Un service cloud unique peut consister en un rôle Web frontal et un ou plusieurs rôles de travail. Chaque niveau peut être mis à l'échelle indépendamment. Il existe également un niveau de contrôle accru sur votre infrastructure d'applications Web. Par exemple, vous pouvez éloigner le bureau sur les machines qui exécutent les instances de rôle.

Machines virtuellesvous permettent d'exécuter des applications Web sur des machines virtuelles dans Azure. Cette capacité est également connue sous le nom d'Infrastructure as a Service (IaaS). Créez de nouvelles machines Windows Server ou Linux via le portail ou téléchargez une image de machine virtuelle existante. Les machines virtuelles vous donnent le plus de contrôle sur le système d'exploitation, la configuration et les logiciels et services installés. Il s'agit d'une bonne option pour migrer rapidement des applications Web complexes sur site vers le cloud, car les machines peuvent être déplacées dans leur ensemble. Avec les réseaux virtuels, vous pouvez également connecter ces machines virtuelles aux réseaux d'entreprise locaux. Comme pour les services cloud, vous avez un accès à distance à ces machines et la possibilité d'effectuer des changements de configuration au niveau administratif. Cependant, contrairement aux sites Web et aux services cloud, vous devez gérer complètement les images de votre machine virtuelle et l'architecture de l'application au niveau de l'infrastructure. Un exemple de base est que vous devez appliquer vos propres correctifs au système d'exploitation.

Voir la comparaison mise à jour et complète à partir de ce lien: http://azure.microsoft.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/


4

Les sites Web Azure, les travailleurs Web et les machines virtuelles sont trois approches informatiques différentes disponibles sur Windows Azure. Ils diffèrent par le niveau de contrôle et les responsabilités:

  • Le site Web Azure a le niveau de contrôle le plus bas, mais vous ne vous souciez pas de conserver la santé de la machine virtuelle et d'IIS, car les trucs Azure le font pour vous
  • Les rôles Web vous donnent plus de contrôle (gestionnaire de trafic, bureau à distance), mais plus d'administration est possible de votre côté, ce qui signifie que vous pouvez casser quelque chose via le bureau à distance par exemple
  • Les machines virtuelles vous donnent un contrôle total sur les VM, donc nécessitent le plus d'efforts administratifs.

Il n'y a pas de meilleur choix, car cela dépend du niveau de contrôle dont vous avez besoin, des fonctionnalités dont vous avez besoin et de ce que vous voulez laisser Azure pour maintenir. Et c'est un gros sujet ..

Veuillez consulter ces articles pour plus d'informations afin de faire un choix plus éclairé:

Cela se résume à un compromis entre la facilité d'utilisation et les capacités.


3

Deux autres choses que j'ai trouvées étaient le coût d'obtention de SSL pour un site de domaine personnalisé et des configurations multi-locataires.

Pour le site Web, vous devez payer mensuellement en plus de l'instance standard (la petite instance est l'option la moins chère). Cela signifie que pour obtenir un domaine personnalisé, https vous coûterait ~ 70 / mois pour les petites instances plus ~ 41 / mois pour SSL qui prend en charge tous les navigateurs.

Pour WebRole, vous pouvez obtenir une instance XS et ajouter votre propre SSL gratuitement, ce qui signifie ~ 15 $ par mois et vous avez un domaine personnalisé avec SSL.

Pour le site Web à locataires multiples, consultez CName dynamique Azure multi-locataires


1

Un rôle Web est une machine virtuelle qui héberge plusieurs sites Web


2
Pas tout à fait exact. Vous pouvez héberger plusieurs sites Web dans un rôle Web, mais les rôles Web vont bien au-delà, car ce sont des machines virtuelles Windows Server. Vous pouvez choisir de ne pas exécuter de sites Web du tout et d'exécuter simplement des tâches d'arrière-plan, des points de terminaison REST, des serveurs de base de données, etc. (il n'y a aucune exigence d'utiliser IIS, et vous pouvez même le désactiver). Et n'oubliez pas qu'ils sont apatrides, ce qui les rend très faciles à mettre à l'échelle.
David Makogon

@DavidMakogon Donc, je peux également dire que les rôles Web effectuent en fait certaines tâches, mais comme il utilise le protocole HTTP, il est appelé rôle 'WEB' et puisqu'il prend en charge ce protocole, il prend également en charge les sites Web, mais ce n'est pas son objectif principal En tant que tel?
Aditya Bokade du

@AdityaBokade N'essayez pas d'en savoir plus: le nom est une relique du premier lancement d'Azure, où les rôles Web étaient le seul moyen d'héberger une application externe (les rôles de travail n'avaient pas de points de terminaison externes, et rien d'autre n'existait - pas de VM, pas de Web Apps). Les rôles Web (et de travail) sont des machines virtuelles Windows sans état, avec un emballage spécial pour votre code et vos scripts de démarrage. Il n'est pas défini en prenant en charge http: vous pouvez communiquer avec des ressources externes via http (s), tcp, udp ou même rien du tout. C'est vraiment tout ce qu'il y a à faire.
David Makogon

0

C'est une question courante, et je voudrais donner un extrait de msdn.

Accès à des services tels que la mise en cache, Service Bus, stockage, base de données SQL Azure - Site Web: Oui Rôle Web: Oui

Prise en charge d'ASP.NET, ASP classique, Node.js, PHP - Site Web: Oui WebRole: Oui

Contenu et configuration partagés - Site Web: Oui Rôle Web: Non

Déployer du code avec GIT, FTP - Site Web: Oui Rôle Web: Non

Déploiement presque instantané - Site Web: Oui Rôle Web: Non

Prise en charge intégrée de MySQL-as-a-service-Site Web: Oui Rôle Web: Oui

Environnements de déploiement multiples (production et transfert) -Site Web: Non Rôle Web: Oui

Isolement du réseau-Site Web: Non WebRole: Oui

Accès Bureau à distance aux serveurs-Site Web: Non Rôle Web: Oui

Possibilité d'exécuter des programmes avec des autorisations élevées-Site Web: Non WebRole: Oui

Capacité à définir / exécuter des tâches de démarrage-WebSite: Non WebRole: Oui

Possibilité d'utiliser des cadres ou des bibliothèques non pris en charge-Site Web: Non Rôle Web: Oui

Prise en charge de Windows Azure Connect / Windows Azure Network-WebSite: Non WebRole: Oui

Pour en savoir plus, visitez ce lien: http://blogs.msdn.com/b/silverlining/archive/2012/06/27/windows-azure-websites-web-roles-and-vms-when-to -use-which.aspx

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.