Это может показаться очень глупым вопросом, поэтому позвольте мне сначала сказать, чего я хочу достичь, а затем перейду к своему вопросу о том, как я себе представляю, как это работает.
Я пытаюсь добиться полностью плавного развертывания нашего веб-приложения в IIS (без прерывания пользователей или активных подключений).
Я предполагаю, что это будет работать с двумя корневыми виртуальными каталогами, совместно использующими один и тот же сайт. Под корневым виртуальным каталогом я подразумеваю тот, который IIS создает внутри и назначает его корню каждого сайта или веб-приложения; кроме этого, я хочу иметь два таких корневых виртуальных каталога (каждый привязан к собственному пулу приложений, но оба ссылаются на одно и то же приложение из разные папки). Во время нормальной работы один из vdirs будет неактивен.
При развертывании я бы поместил новый код в другую папку, на которую ссылается второй (неактивный) vdir, а затем пометил бы его как активный. Я хочу, чтобы затем IIS начал отправлять все новый соединения (запрашивая тем же site) к этому второму виртуальному каталогу с новым кодом, но сохраняя старый также активным и активным до тех пор, пока все оставшиеся соединения с ним не будут отключены (некоторые, такие как загрузка файлов, могут работать долго). После того, как все устаревшие соединения будут мертвы, старый пул vdir / app становится неактивным, а второй пул с новым кодом становится единственным активным.
Я надеюсь это имеет смысл.
Если это не так, вот моя альтернативная попытка объяснить это на примере.
--- Web Site ("mysite.com")
--- Root VDir#1 (IIS Internal, App Pool: AppPool#1, Virtual Path: /, Physical Path: C:\inetpub\MySite.v1084\). ACTIVE
--- Root VDir#2 (IIS Internal, App Pool: AppPool#2, Virtual Path: /, Physical Path: NONE). INACTIVE
Во время развертывания корневой виртуальный каталог 2 станет активным, а его физический путь изменится на C: \ inetpub \ MySite.v1085. Это будет виртуальный каталог по умолчанию, который IIS будет обслуживать для всех новых подключений. Как только все активные сеансы / подключения к корневому виртуальному каталогу № 1 умирают, он становится неактивным.
Возможно ли что-то подобное? Есть ли альтернативные способы сделать что-то вроде этого (я знаю, что в IIS есть встроенная балансировка нагрузки («веб-фермы»?), Но я не слишком знаком с этим).
То, что вы предлагаете, похоже на обмен A / B. (Аналогичный вопрос)
Есть инструмент надстройки IIS от Microsoft под названием Web Deploy. Он автоматизирует большинство физических действий по развертыванию обновленного кода в IIS, но ваше требование беспрепятственной миграции является проблемой, поскольку у вас есть длительные файловые транзакции. Лучший способ справиться с этим - получить балансировщик нагрузки, запустить одновременно с двумя производственными экземплярами вашего сайта и иметь третий экземпляр для размещения обновлений.
(Кстати, Azure делает что-то подобное с «Cloud Services» - есть команда «Swap», чтобы сделать именно это.)
Возвращаясь к вашей конкретной настройке, рассмотрите эту конфигурацию:
Один компьютер IIS, два веб-сайта. Веб-сайт A и веб-сайт B. Они не указывают на одни и те же файлы. У них есть свои папки. Веб-сайт A находится в сети и обслуживает пользователей в производственной среде, тогда как веб-сайт B отключен. Когда вы будете готовы к обновлению, вы обновите веб-сайт B, а затем включите / выключите веб-сайт A. Теперь B подключен к сети, а A отключен. Это ротация A / B. Позже, когда вы сделаете следующее обновление, вы обновите A, а затем поменяете местами On / Off на B. Теперь A в сети, а B в автономном режиме.
Именно в тот момент, когда вы меняете местами, есть вероятность потери трафика (и вы, вероятно, убьете эти передачи файлов), но если ваше приложение имеет небольшой объем, возможно, никто не заметит (вы решаете). Однако, если это критически важный сайт большого объема - получите балансировщик нагрузки и используйте его, как описано другими.
То, что WebDeploy не будет делать (насколько я знаю), - это поменять местами On / Off сайт A и сайт B. Для этого вам необходимо напишите сценарий и сделайте это в командной строке.
Преимущество сценариев Web Deploy + заключается в том, что в конечном итоге вы можете автоматизировать это и, возможно, связать его с системой непрерывного развертывания.
При такой настройке, вероятно, невозможно сохранить длительные передачи файлов. Еще одна проблема - любое состояние вашего приложения в памяти. Если ваше веб-приложение было разработано с данными в памяти, вы потеряете их, когда произведете замену A / B. Если программисты используют сеанс, вы можете включить службу сеанса. Данные сеанса не будут находиться в том же процессе, что и остальная часть приложения, и могут пережить обмен A / B. Поговорите со своими программистами о том, как приложение управляет данными в памяти. Может, на самом деле его нет. Возможно, его можно легко воссоздать после перезагрузки приложения - (например, восстановление кеша из базы данных)