В чем разница между веб-сайтом Azure и ролью Azure Web?

Каковы существенные различия между новыми Azure Web Sites и традиционными ролями Azure Web для приложения ASP.NET MVC? Какую причину я бы выбрал "веб-сайт" над "веб-ролью" или наоборот?

Предположим, что мне понадобится равная емкость в любом случае (например, два небольших экземпляра). Цены кажутся сопоставимыми, нежели тот факт, что существует временная скидка для веб-сайтов на 33%, пока они находятся в предварительном периоде.

Есть ли что-то, что я могу сделать с "веб-сайтом", которые трудно или невозможно с помощью веб-роли? Например, становится проще размещать несколько веб-сайтов в одном наборе виртуальных машин с помощью "веб-сайтов"? Я что-то теряю с помощью "веб-сайта" и "роли в Интернете"? Возможность тонкой настройки IIS? Возможность локального использования службы кэширования?

Ответ 1

Роли Web предоставляют вам несколько функций помимо веб-приложений (ранее веб-сайтов):

  • Возможность запуска повышенных сценариев запуска для установки приложений, изменения настроек реестра, установки счетчиков производительности, тонкой настройки IIS и т.д.
  • Возможность разбить приложение на уровни (возможно, веб-роль для внешнего интерфейса, роль рабочего для обработки бэкэнд) и независимо масштабировать
  • Возможность RDP в вашу виртуальную машину для целей отладки
  • Сетевая изоляция
  • Выделенный виртуальный IP-адрес, который позволяет экземплярам веб-роли в облачной службе получать доступ к виртуальным машинам с ограничениями IP.
  • Конечные точки, ограниченные ACL (добавлены в Azure SDK 2.3, апрель 2014 г.)
  • Поддержка любых портов TCP/UDP (веб-узлы ограничены TCP 80/443)

У веб-приложений есть преимущества перед веб-ролями:

  • Почти мгновенное развертывание с историей развертывания/откатами
  • Visual Studio Online, github, локальная поддержка git, ftp, CodePlex, DropBox, BitBucket
  • Возможность развертывания одной из многочисленных CMS и фреймворков (например, WordPress, Joomla, Django, MediaWiki и т.д.).
  • Использование базы данных SQL или MySQL
  • Простая и быстрая масштабирование от свободного уровня до уровня общего уровня до выделенного уровня
  • Веб-задания
  • Резервное копирование содержимого веб-сайта
  • Встроенные средства отладки в Интернете (простая консоль отладки cmd/powershell, проводник процессов, средства диагностики, такие как поток журналов и т.д.).

С развертываниями апреля 2014 года и сентября 2014 года теперь есть некоторые функции, общие как для веб-приложений, так и для ролей в Интернете (и ролей рабочих), в том числе:

  • Развертывание + слоты для производства
  • Подстановочный DNS, сертификаты SSL
  • Интеграция с Visual Studio
  • Поддержка диспетчера трафика
  • Поддержка виртуальной сети.

Здесь screengrab, который я взял из формы выбора галереи веб-сайтов: enter image description here

Я думаю, что Web Apps - отличный способ быстро встать и работать, где вы можете переходить от общих к зарезервированным ресурсам. После того, как вы перерастите это, вы можете перейти к веб-ролям и развернуть по мере необходимости.

Ответ 2

EDIT 2014: для чего это стоит, большая часть информации в этом ответе больше не верна - см. комментарии.

Добавьте еще к ответу @David:

С веб-сайтами Windows Azure у вас нет контроля над IIS или веб-сервером, потому что вы используете срез ресурсов вместе с сотнями других веб-сайтов на одном компьютере, вы делите ресурсы, как и любые другие, поэтому нет контроля над IIS.

Большая разница между общим сайтом и веб-сайтом Azure заключается в том, что веб-сайт считается связанным с процессом, в то время как роли связаны с VM.

Веб-сайты хранятся в доле контента, доступном со всех "веб-серверов" в ферме, поэтому нет никакой репликации или чего-то подобного.

Веб-сайты Windows Azure не могут иметь собственное имя хоста, вместо этого они должны использовать только websitename.azurewebsites.net, и вы можете использовать параметр CNAME в своем DNS-провайдере, чтобы перенаправить ваш запрос точно так же с предыдущей ролью Windows Azure только тогда, когда они запущены в режиме резервирования. Настройка CNAME не поддерживается для общих веб-сайтов.

Ответ 3

Я только что разместил всеобъемлющую запись в блоге по этому вопросу в http://robdmoore.id.au/blog/2012/06/09/windows-azure-web-sites-vs-web-roles/.

Отрывок из моего заключения: если вам нужны огромные массивы данных, SSL, азиатские или западные США, нестандартная конфигурация (IIS, порты, диагностика, сертификаты безопасности или сценарии запуска), RDP или рентабельные Роли рабочих (в сочетании с вашей веб-ролью), то вам сейчас придется придерживаться веб-ролей.

В противном случае веб-сайты - отличный вариант!

Ответ 4

Azure Web Role похожа на виртуальный частный хост. Вы получаете виртуальную машину, которая действует как ваш веб-сервер, и вы владеете этим экземпляром виртуальной машины.

Веб-сайты Azure похожи на виртуальный хостинг. Вы развертываете свое приложение на веб-сервере, который не контролируется вами, а также серверы других сайтов пользователей. Вы можете масштабировать свой сайт вверх и вниз (за дополнительную плату), чтобы сделать его более эластичным, поскольку ваш ресурс нуждается в смене.

Ответ 5

Возникает еще один сценарий: после устранения этих 500 исключений они ничего не сказали о способности веб-сайтов Azure обрабатывать подстановочные CNAME. Некоторые из нас используют Nate Web Role Accelerator в облачных сервисах, потому что однострочный взлом обеспечивает возможность поддомена подстановочных знаков в программном обеспечении Nate. Мы не можем перемещать эти поддомены для подстановочных знаков, пока мы не узнаем, что Azure Websites смогут обрабатывать их. Если он никогда не сможет это сделать, тогда он опустится как положительный на стороне веб-роли уравнения. Также следует отметить, что при установлении цены точно так же (по истечении срока действия скидки на предварительный просмотр), я не уверен, что хочу отказаться от доступа к RDC и Event Viewer (просто чтобы упомянуть две вещи).

Ответ 6

Azure Web Sites позволяет быстро создавать масштабируемые веб-сайты на Azure. Вы можете использовать Azure Portal или инструменты командной строки для настройки веб-сайта с такими популярными языками, как .NET, PHP, Node.js и Python. Поддерживаемые фреймворки уже развернуты и не требуют дополнительных шагов установки. В галерее Azure Web Sites содержится множество сторонних приложений, таких как Drupal и WordPress, а также разработки, такие как Django и CakePHP. После создания сайта вы можете либо перенести существующий веб-сайт, либо создать совершенно новый веб-сайт. Веб-сайты устраняют необходимость управления физическим оборудованием, а также предоставляют несколько вариантов масштабирования. Вы можете перейти от общей модели с несколькими арендаторами к стандартному режиму, когда выделенные машины обслуживают входящий трафик. Веб-сайты также позволяют интегрироваться с другими службами Azure, такими как база данных SQL, служебная шина и хранилище. Используя предварительный просмотр Azure WebJobs SDK, вы можете добавить фоновую обработку. Таким образом, веб-сайты Azure упрощают фокусирование на разработке приложений, поддерживая широкий спектр языков, приложений с открытым исходным кодом и методологий развертывания (FTP, Git, Web Deploy или TFS). Если у вас нет специализированных требований, требующих облачных сервисов или виртуальных машин, лучшим вариантом будет веб-сайт Azure.

Облачные службы позволяют создавать высокодоступные масштабируемые веб-приложения в богатой платформе в качестве службы (PaaS). В отличие от веб-сайтов, облачный сервис создается сначала в среде разработки, например Visual Studio, перед развертыванием в Azure. Для таких фреймворков, как PHP, требуются специальные шаги или задачи развертывания, устанавливающие фреймворк при запуске роли. Основным преимуществом Cloud Services является возможность поддержки более сложных многоуровневых архитектур. Единая служба облака может состоять из роли веб-интерфейса и одной или нескольких рабочих ролей. Каждый уровень можно масштабировать независимо. Существует также повышенный уровень контроля над инфраструктурой вашего веб-приложения. Например, вы можете использовать удаленный рабочий стол на компьютерах, на которых запущены экземпляры роли. Вы также можете использовать script более сложные настройки IIS и конфигурации машины, которые запускаются при запуске роли, включая задачи, требующие управления администратором.

Виртуальные машины позволяют запускать веб-приложения на виртуальных машинах в Azure. Эта возможность также известна как Инфраструктура как услуга (IaaS). Создайте новые серверы Windows Server или Linux через портал или загрузите существующий образ виртуальной машины. Виртуальные машины предоставляют вам максимальный контроль над операционной системой, конфигурацией и установленным программным обеспечением и сервисами. Это хороший вариант для быстрой миграции сложных локальных веб-приложений в облако, поскольку машины могут перемещаться в целом. С помощью Virtual Networks вы также можете подключить эти виртуальные машины к локальным корпоративным сетям. Как и в облачных службах, у вас есть удаленный доступ к этим машинам и возможность выполнять изменения конфигурации на административном уровне. Однако, в отличие от веб-сайтов и облачных служб, вы должны полностью управлять изображениями виртуальной машины и архитектурой приложений на уровне инфраструктуры. Одним из основных примеров является то, что вы должны применять свои собственные исправления к операционной системе.

См. обновленное и полное сравнение по этой ссылке: http://azure.microsoft.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/

Ответ 7

Azure Websites, Web Workers и Virtual Machines - это три разных подхода к вычислению, доступные в Windows Azure. Они отличаются уровнем контроля и ответственности:

  • Azure Website имеют самый низкий уровень контроля, но вам не нужно сохранять в виртуальной машине и IIS работоспособности, потому что Azure делает это для вас.
  • Роли в Интернете дают вам больше контроля (диспетчер трафика, удаленный рабочий стол), но на вашей стороне возможно больше администрирования, что означает, что вы можете что-то сломать с помощью удаленного рабочего стола, например
  • Виртуальные машины дает вам полный контроль над виртуальной машиной, поэтому требуются самые административные усилия.

Нет лучшего выбора, потому что это зависит от того, какой уровень контроля вам нужен, какие функции вам нужны и что вы хотите оставить для работы Azure. И это большая тема.

Пожалуйста, ознакомьтесь с этими статьями для получения дополнительной информации, чтобы сделать более обоснованный выбор:

Это сводится к компромиссу между простотой использования и возможностями.

Ответ 8

Еще две вещи, которые я нашел, это стоимость получения SSL для пользовательских доменных сайтов и конфигураций Multi-tenant.

Для веб-сайта вам нужно ежемесячно оплачивать стандартный экземпляр (малый экземпляр - самый дешевый вариант). Это означает, что для получения пользовательского домена https будет стоить ~ 70/месяц для небольшого экземпляра плюс ~ 41/месяц для SSL, который поддерживает все браузеры.

Для WebRole вы можете получить экземпляр XS и бесплатно добавить свой SSL, что означает ~ 15 долларов США в месяц и у вас есть собственный домен с SSL.

Для веб-сайта с несколькими арендаторами Многоуровневая динамическая подстановочная символика Azure

Ответ 9

Веб-роль - это виртуальная машина, на которой размещаются несколько веб-сайтов.

Ответ 10

Это общий вопрос, и я хотел бы выдать отрывок из msdn.

Доступ к таким сервисам, как кеширование, служебная шина, хранилище, база данных SQL Azure - веб-сайт: да WebRole: да

Поддержка ASP.NET, классического ASP, Node.js, PHP- WebSite: Да WebRole: Да

Общий контент и конфигурация - WebSite: Да WebRole: Нет

Развертывание кода с помощью GIT, FTP-WebSite: Да WebRole: Нет

Near-instant deployment-WebSite: Да WebRole: Нет

Встроенная поддержка MySQL-as-service-WebSite: Да WebRole: Да

Несколько сред развертывания (производство и постановка) -WebSite: нет WebRole: Да

Сетевая изоляция-WebSite: Нет WebRole: Да

Доступ к удаленному рабочему столу для серверов-WebSite: нет WebRole: Да

Возможность запуска программ с повышенными разрешениями - WebSite: Нет WebRole: Да

Возможность определять/выполнять задачи запуска - WebSite: Нет WebRole: Да

Возможность использования неподдерживаемых фреймворков или библиотек - WebSite: Нет WebRole: Да

Поддержка Windows Azure Connect/Windows Azure Network-WebSite: Нет WebRole: Да

Чтобы получить более подробную информацию, перейдите по этой ссылке: http://blogs.msdn.com/b/silverlining/archive/2012/06/27/windows-azure-websites-web-roles-and-vms-when-to-use-which.aspx