Можно ли развернуть несколько веб-приложений на одном экземпляре Windows Azure?
Возможно ли иметь несколько веб-приложений, работающих в одном небольшом вычислительном экземпляре Windows Azure?
Я рассматриваю использование Azure в качестве места для размещения множества проектов (веб-приложений), которые находятся в разработке и не готовы к работе. Некоторые на самом деле заболели молью, но я бы хотел, чтобы где-то был их активный экземпляр. Я не хочу платить за отдельные часы вычислений для каждого приложения, которое просто сидит там 90 % времени.
Другой вариант, который я рассматриваю, чтобы получить общий хостинг для этих проектов.
6 ответов
Да, теперь это возможно благодаря последним обновлениям платформы Azure, выпущенным в конце 2010 года.
Необходимо внести соответствующие изменения конфигурации в файл определения службы проекта Azure. Ниже приведен пример нескольких сайтов в одном домене. Сайт регистрации использует конечную точку https (вы также должны настроить свой сертификат), а остальные используют http. Публичный сайт не указывает заголовок хоста и будет ловить все, что не указано. Это замечательно, когда у вас есть одно приложение, которое должно обрабатывать несколько поддоменов (например, shopify). Для того, чтобы эта работа работала, вам нужно иметь днс, который разрешает подстановочные имена (а GoDaddy нет). Очевидно, вам также нужна запись cname, которая указывает на лазурь для каждого из других поддоменов. В этом примере следует отметить еще одну вещь: физический каталог для приложений относится к проекту Azure. Надеюсь это поможет!
Вот ссылка, которая может помочь: http://msdn.microsoft.com/en-us/library/gg433110.aspx
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="SampleAzureProject" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="RegisterSite_WebRole">
<Sites>
<Site name="RegisterSite" physicalDirectory="..\RegisterSite">
<Bindings>
<Binding name="RegisterBinding" endpointName="Endpoint1" hostHeader="register.sample.com" />
</Bindings>
</Site>
<Site name="PublicSite" physicalDirectory="..\PublicSite">
<Bindings>
<Binding name="PublicBinding" endpointName="Endpoint2" hostHeader="" />
</Bindings>
</Site>
<Site name="ManageSite" physicalDirectory="..\ManageSite">
<Bindings>
<Binding name="ManageBinding" endpointName="Endpoint2" hostHeader="manage.sample.com" />
</Bindings>
</Site>
<Site name="MarketingSite" physicalDirectory="..\MarketingSite">
<Bindings>
<Binding name="MarketingBinding" endpointName="Endpoint2" hostHeader="www.sample.com" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="https" port="443" certificate="SampleReg" />
<InputEndpoint name="Endpoint2" protocol="http" port="80" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
<Certificates>
<Certificate name="SampleReg" storeLocation="LocalMachine" storeName="My" />
</Certificates>
</WebRole>
</ServiceDefinition>
Это зависит от того, что вы подразумеваете под экземпляром Windows Azure.
Одна учетная запись Azure может содержать несколько служб и развертываний. Развертывание (на момент написания) может содержать несколько рабочих и веб-ролей (по сути, проектов).
Одна веб-роль может быть развернута в нескольких экземплярах.
Учитывая все это, вы можете легко разместить несколько веб-приложений в одной учетной записи Windows Azure или даже в одном развертывании.
Если вы заинтересованы в минимизации затрат и хранении нескольких тестовых веб-приложений в одном экземпляре веб-роли, это будет непросто - вам нужно собрать их в один проект и развернуть сразу.
Примечание: в последнем сценарии могут произойти радикальные улучшения довольно скоро, поэтому Windows Azure - довольно безопасная ставка.
Единственный способ запустить несколько веб-приложений в одном экземпляре Azure - это объединить несколько приложений в один проект WebRole. Для Azure требуется одно веб-приложение на экземпляр веб-роли.
Это может быть не сложно, если ваши веб-приложения довольно простые или просто генерируют aspx html-страницы - поместите каждое приложение в свой собственный подкаталог URL, чтобы отделить имена страниц от других приложений. Поскольку ссылки между страницами в одном приложении обычно относятся к домашнему каталогу, это не должно сильно расстраивать ваши ссылки. Вы можете получить доступ к каждому "subapp", используя URL-адреса: http://mydomain.com/app1/default.html
, http://mydomain.com/app2/...
и т.п.
Вы увидите уменьшение прибыли по мере увеличения сложности каждого веб-приложения. Будет сложнее поместить несколько сложных приложений в общее мастер-приложение.
Но для экспериментов и доказательства работы с концептуальными типами, как только вы запустите шаблон основного приложения, будет довольно легко сохранить его для дальнейшей работы. Вы будете использовать свой экземпляр веб-роли Azure в качестве набора работ вместо одноразового блокнота для любого последнего эксперимента.
В текущем состоянии Azure (август 2010 г.) будет запускаться только одно приложение ("служба", "роль") на экземпляр виртуальной машины.
Итак, простой ответ на ваш вопрос - нет, на данный момент.
Теперь, учитывая все возможности платформы, вы можете придумать несколько креативных способов предоставления такой песочницы. С помощью API управления службами можно развернуть развертывание в хранилище Azure и перевести роли в оперативный режим в момент их запроса, а затем отключить их ("удалить развертывание"), когда они больше не нужны. Развертывание может привести к некоторой задержке, так как структура переводит виртуальные машины в оперативный режим... но в зависимости от варианта использования это может принести вам существенную экономию.
Azure может быть не лучшим вариантом для этого варианта использования - одна виртуальная машина допускает только одно приложение, а все остальные варианты несколько сложны для реализации (например, наличие нескольких приложений в одной веб-роли или развертывание и разборка по требованию) - также обратите внимание, что Azure взимает плату за время часов, поэтому я не уверен, что произойдет, если вы вызовете экземпляр, приведете его в действие, а затем снова включите его в течение часа).
Может быть лучше другой облачный провайдер, такой как rackspace или Amazon, вы можете создавать виртуальные машины Windows и размещать свои приложения на IIS, как на обычном сервере. Единственным преимуществом в этом случае будет более простое предоставление этого сервера и отсутствие управления инфраструктурой (хотя вам все равно придется управлять ОС и другими зависимостями, в отличие от Azure).
В основном вы ограничены одним приложением на роль.
Не уверен, что это изменится, так как существуют причины для хостинга Windows Azure таким образом.
После прочтения вашего вопроса, кажется, что облако может быть не идеальным для вас в настоящее время. Особенно, если у вас есть то, что "90%" не используется. Это потраченное впустую время процесса, чтобы роль бездействовала, платя при этом $$.
Мой совет - использовать виртуальный хостинг или что-то подобное, пока сайт не потребует увеличения времени безотказной работы, масштабируемости и других облачных функций такого рода.