Я не уверен, что это правильный способ задать этот вопрос, но вот в основном то, что я хотел бы сделать:
1.) Отправьте набор изменений на сайт в IIS.
2.) Не перебивайте пользователей.
3.) Уметь откатывать назад без особых усилий.
Итак, я знаю, что должно произойти несколько вещей:
1.) Вне процедуры - обработано
2.) Out of Proc cache - обработано
Итак, остаются вопросы:
1.) Как мне не отвлекать пользователей? Если я просто загружу файлы в корзину, приложение перезапустится и вернется в сеть через 10+ секунд.
2.) Как без усилий откатиться?
Я думал, что возможным решением будет создание двух сайтов в IIS, одного общедоступного и одного частного. Загрузки переходят в приват и нагреваются. После разминки сайты меняются местами. Откат влечет за собой только переход на частный без загрузки.
В теории это кажется здравым, но насчет механики я не уверен. Любые идеи?
Вот как я подхожу к этой проблеме - имейте в виду, что я не делал этого раньше, это просто концепции, которые я немного тестировал в своей среде разработки. Вы должны иметь возможность настроить довольно надежную структуру, используя это и несколько сценариев на выбранном вами языке. В основном мы собираемся настроить среду балансировки нагрузки гетто и использовать ее для переключения между новым сайтом и старым сайтом.
Для его настройки вам потребуются:
Для начала установите ARR.
Настройте 3 веб-сайта в IIS:
http://192.168.1.1/. Это также сайт ARR. Просто настройте пустой каталог, на который он будет указывать, и поместите его в собственный пул приложений. Настройте пул приложений на отключение тайм-аута в соответствии с эти инструкции.http://192.168.1.2:8080 и http://192.168.1.3:8080. Они также должны находиться в своих собственных пулах приложений и указывать на разные каталоги в файловой системе (но оба каталога обычно имеют одинаковое содержимое)После установки ARR в диспетчере IIS появится новая категория под названием «Фермы серверов» - щелкните ее правой кнопкой мыши и создайте новую ферму.
{SERVER_PORT} не соответствует 8080На этом этапе у вас есть основы того, что нам нужно для выполнения вашего запроса. Если вы пойдете в http://192.168.1.1/ вы получите свой веб-сайт либо с веб-сайта 1, либо с веб-сайта 2, но при наличии других сайтов это будет совершенно незаметно.
Теперь, когда вы хотите развернуть новую версию своего приложения, вы можете:
Инструмент веб-развертывания вступает в игру, когда вы говорите о желании написать все это сценарием. Это упрощает создание пакета для вашего приложения и его развертывание из командной строки. Вы также можете легко откатить этот пакет, если возникнут проблемы. ARR также поддерживает скрипт используя Microsoft.Web.Administration dll.
Еще одно - если вы действительно используете Windows 2008 R2 (это IIS 7.5), обратите внимание на Разминка приложения модуль - он также должен облегчить вам разогрев.
MattB выбил его из воды. +1 Я отвечу более подробно, но я не собираюсь брать его очки. Я добавлю к тому, что он сказал.
У меня установка, аналогичная той, что он описал, и она отлично работает. ARR - это правильный выбор, даже на одном сервере.
Однако я бы добавил пару вещей.
Создайте 2 сайта, как рекомендовал Мэтт. Назовите их примерно так: yoursite.com01 и yoursite.com02.
Создайте 2 правила перезаписи URL. Один для www.yourdomain.com и еще один для staging.yourdomain.com. Для производства используйте {HTTP_HOST} со значением (^ www.yourdomain.com $) | (yourIP). (или любое другое связывание, которое вы предпочитаете). Для промежуточной обработки используйте {HTTP_HOST} со значением (^ staging.yourdomain.com $). Назовите правила yoursite.com и staging.yoursite.com.
Привяжите Rule = yoursite.com к site = yoursite.com01 и rule = staging.yoursite.com к site = yoursite.com02.
Настройте FTP на сайте staging.yoursite.com.
Производственный трафик теперь направляется на Rule = staging.yoursite.com и Site = yoursite.com01. Пошатываясь на противоположное.
Вы можете развернуть его в любой момент, протестировать, предварительно раскрутить, попросить других людей протестировать и т. Д. Делайте это в течение дня, это не имеет значения. Каждый раз развертывать в одной и той же учетной записи FTP. Отлично работает с серверами сборки.
Затем, когда вы будете готовы к запуску, просто внесите 3 изменения: - переместите привязку FTP с yoursite.com02 на yoursite.com01 - измените правило перезаписи URL yoursite.com так, чтобы оно указывало на yoursite.com02 - измените постановку правила перезаписи URL. yoursite.com, чтобы указать на yoursite.com01
Теперь у вас есть нулевое время простоя, мгновенное переключение и функция немедленного отката!
Единственная проблема, которую следует учитывать, - это состояние сеанса вне процесса. Убедитесь, что ваш сервер состояний принимает оба идентификатора сайта, чтобы вы не потеряли состояние сеанса во время обмена.
Также обратите внимание, что это только Интернет, а не база данных.
Для написания сценариев используйте Редактор конфигурации. Внесите необходимые изменения и нажмите «Создать сценарий». Он предоставит вам код C #, appcmd или AHAdmin.
У меня это было несколько месяцев с интерфейсом веб-страницы для обмена экземплярами, и я никогда не оглядываюсь назад. Это делает развертывание таким свежим по сравнению с традиционным развертыванием.