Як розгорнути додаток ASP.NET з нульовим простоєм

Для розгортання нової версії нашого веб-сайту ми робимо наступне:

1. Створіть новий код та завантажте його на сервер.
2. На поточному сервері видаліть увесь код живого з каталогу веб-сайтів IIS.
3. Витягніть новий код zipfile в тепер порожній каталог IIS

Цей процес все сценарій і відбувається досить швидко, але все ж може бути 10-20 секунд простою, коли старі файли видаляються, а нові файли розгортаються.

Будь-які пропозиції щодо методу простою 0 секунд?

Вам потрібні 2 сервери та балансир навантаження. Ось в кроках:

1. Увімкніть увесь трафік на сервері 2
2. Розгортання на сервері 1
3. Тестовий сервер 1
4. Увімкніть увесь трафік на сервері 1
5. Розгортання на сервері 2
6. Тестовий сервер 2
7. Поверніть трафік на обох серверах

Річ у тому, що навіть у цьому випадку у вас все ще будуть перезавантаження програми та втрата сеансів, якщо ви використовуєте "липкі сесії". Якщо у вас є сесії з базами даних або державний сервер, тоді все повинно бути добре.

Інструмент веб-розгортання Microsoft певною мірою підтримує це:

Вмикає підтримку транзакційної файлової системи Windows (TxF). Коли підтримка TxF включена, файлові операції є атомними; тобто вони або вдається, або повністю провалюються. Це забезпечує цілісність даних і запобігає існуванню даних або файлів у "напівповерховому" або пошкодженому стані. У MS Deploy TxF за умовчанням вимкнено.

Здається, транзакція призначена для всієї синхронізації. Також TxF є функцією Windows Server 2008, тому ця транзакційна функція не працюватиме з більш ранніми версіями.

Я вважаю, що можливо змінити ваш сценарій на час простою, використовуючи папки як версії та метабазу IIS:

• для існуючого шляху / URL-адреси:
  • шлях : \ web \ app \ v2.0 \
  • url : http: // додаток
• Скопіюйте новий (або модифікований) веб-сайт на сервер під
  • \ web \ app \ v2.1 \
• Змініть метабазу IIS, щоб змінити шлях до веб-сайту
  • від \ web \ app \ 2.0 \
  • до \ web \ app \ v2.1 \

Цей метод пропонує наступні переваги:

• Якщо нова версія має проблему, ви можете легко відкатати версію до версії 2.0
• Для розгортання на декількох фізичних або віртуальних серверах ви можете використовувати свій сценарій для розгортання файлів. Після того, як всі сервери отримають нову версію, ви можете одночасно змінювати метабази всіх серверів, використовуючи інструмент веб-розгортання Microsoft.

Ви можете домогтися розгортання нульового простою на одному сервері, використовуючи маршрутизацію запитів додатків в IIS як балансир завантаження програмного забезпечення між двома локальними веб-сайтами IIS в різних портах. Ця стратегія відома як синьо-зелена стратегія розгортання, де лише один із двох сайтів є доступним в балансирі навантаження в будь-який момент. Розгорніть на "знищеному" сайті, прогрійте його та введіть його в балансир завантаження (зазвичай, пройшовши перевірку стану заявки на запит про подання заявки), а потім вийдіть із "пулу" оригінальний веб-сайт, який був вгору зробивши його перевірку здоров'я).

Повний підручник можна знайти тут.

Я нещодавно пережив це, і рішення, до якого я придумав, було створити два сайти, створені в IIS, і переключитися між ними.

Для моєї конфігурації у мене був веб-каталог для кожного сайту A і B, наприклад: c: \ Intranet \ Live A \ Interface c: \ Intranet \ Live B \ Interface

У IIS у мене є два однакових сайти (однакові порти, аутентифікація тощо), кожен з яких має власний пул додатків. Один із сайтів працює (A), а інший зупиняється (B). також у прямому ефірі є заголовок живого хоста.

Якщо мова йде про розгортання в реальному часі, я просто публікую його на місці STOPPED. Оскільки я можу отримати доступ до сайту B за допомогою його порту, я можу попередньо розігріти його, щоб перший користувач не спричинив запуск програми. Потім за допомогою пакетного файлу я копіюю заголовок живого хоста в B, зупиняю A і запускаю B.

За допомогою класу ServerManager Microsoft.Web.Administration ви можете розробити власний агент розгортання.

Трюк полягає в зміні PhysicalPath VirtualDirectory, що призводить до атомного перемикання в Інтернеті між старими та новими веб-додатками.

Майте на увазі, що це може призвести до того, що старі та нові додатки виконуватимуться паралельно!

Проблема полягає в тому, як синхронізувати зміни до баз даних тощо.

Опитуючи існування AppDomains зі старими або новими PhysicalPaths, можна виявити, коли припиняються старі AppDomain (ів) і якщо запускаються нові AppDomain.

Щоб змусити запустити AppDomain, ви повинні зробити HTTP-запит (IIS 7.5 підтримує функцію автоматичного запуску)

Тепер вам потрібен спосіб блокувати запити на новий AppDomain. Я використовую іменований mutex - який створений та належить агенту розгортання, чекав Application_Start нового веб-додатка, а потім випускається агентом розгортання після того, як буде зроблено оновлення бази даних.

(Я використовую файл маркера у веб-додатку, щоб активувати функцію очікування mutex). Після запуску нового веб-додатка я видаляю файл маркера.

Добре, тому що всі хочуть відповісти, яку я написав ще в 2008 році * ...

Я розповім, як ми це робимо зараз у 2014 році. Ми вже не використовуємо веб-сайти, оскільки зараз ми використовуємо ASP.NET MVC.

Нам, звичайно, не потрібен балансир завантаження і два сервери для цього, це добре, якщо у вас є 3 сервери для кожного веб-сайту, який ви підтримуєте, але це загальний перевибір для більшості веб-сайтів.

Крім того, ми не покладаємось на останнього майстра від Microsoft - занадто повільне і занадто приховане магія і занадто схильне до зміни його імені.

Ось як ми це робимо:

1. У нас є крок створення повідомлення, який копіює згенеровані DLL-файли у папку "bin-pub".

2. Ми використовуємо програму Beyond Compare (яка є чудовою **) для перевірки та синхронізації змінених файлів (через FTP, оскільки це широко підтримується) аж до виробничого сервера

3. На веб-сайті у нас є захищена URL-адреса, яка містить кнопку, яка копіює все, що знаходиться у «bin-pub», на «bin» (спочатку робимо резервну копію, щоб увімкнути швидкий відкат). У цей момент додаток перезавантажується. Тоді наша ORM перевіряє, чи є якісь таблиці чи стовпці, які потрібно додати та створює їх.

Це всього лише мілісекунд простою. Перезапуск програми може зайняти секунду або дві, але під час перезавантаження запити буферизовані, тому фактично просто нульовий час простою.

Весь процес розгортання займає від 5 секунд до 30 хвилин, залежно від того, скільки файлів змінено і скільки змін потрібно переглянути.

Таким чином, вам не потрібно копіювати весь веб-сайт у інший каталог, а лише папку бін. Ви також маєте повний контроль над процесом і точно знаєте, що змінюється.

** Ми завжди робимо очне яблуко змін, які ми впроваджуємо - як подвійна перевірка в останню хвилину, тому ми знаємо, що перевірити і чи готові щось зламати. Ми використовуємо програму "Більше порівняння", оскільки вона дозволяє легко відрізняти файли через FTP. Я б ніколи не робив цього без BC, ви не маєте поняття, що ви переписуєте.

* Прокрутіть донизу, щоб побачити це :( BTW я більше не рекомендую веб-сайти, оскільки вони повільніше будуватись і можуть погано працювати з половиною складених тимчасових файлів. Ми використовували їх у минулому, оскільки вони дозволяли більш спритний файл-за-файлом розгортання. Дуже швидко виправити незначну проблему, і ви зможете точно побачити, що ви розгортаєте (якщо ви, звичайно, використовуєте "Більше порівняння" - інакше забудьте це).

Єдиний метод нульового простою, який я можу припустити, передбачає хостинг на щонайменше двох серверах.

Я хотів би трохи уточнити відповідь Джорджа для одного сервера:

1. Використовуйте проект веб-розгортання, щоб попередньо скласти сайт в єдину DLL
2. Створіть новий сайт та завантажте його на сервер
3. Розпакуйте її в нову папку, розташовану в папці з правильними дозволами для сайту, тому розпаковані файли правильно успадковують дозволи (можливо, e: \ web, з папками v20090901, v20090916 тощо)
4. Використовуйте IIS Manager для зміни назви папки, що містить сайт
5. Зберігайте стару папку деякий час, щоб ви могли повернутися до неї у разі проблем

Етап 4 призведе до повторної переробки робочого процесу IIS.

Це просто нульовий час простою, якщо ви не використовуєте сеанси InProc; замість цього скористайтеся режимом SQL (ще краще, повністю уникайте стану сеансу).

Звичайно, це дещо більше, якщо є декілька серверів та / або змін у базі даних ....

Щоб розширити відповідь sklivvz, яка покладалася на те, що якийсь балансир завантаження (або просто резервна копія на одному сервері)

1. Спрямуйте весь трафік на Сайт / сервер 2
2. За бажанням зачекайте трохи, щоб гарантувати, що якомога менше користувачів має відкладені робочі процеси у розгорнутій версії
3. Розгорніть на Site / Server 1 і максимально розігрійте його
4. Виконувати міграції бази даних трансакційно (прагніть зробити це можливим)
5. Негайно направляйте весь трафік на Сайт / Сервер 1
6. Розгортання на сайті / сервері 2
7. Прямий трафік на обидва сайти / сервери

Можна ввести трохи тестування димом, створивши знімок / копію бази даних, але це не завжди можливо.

Якщо можливо і потрібно, використовуйте "різниці маршрутів", такі як різні URL-адреси орендаря: s (customerX.myapp.net) або різні користувачі, щоб спочатку розгорнутись до групи невідомих морських свинок. Якщо нічого не виходить, відпустіть усіх.

Оскільки відбувається міграція баз даних, відкат до попередньої версії часто неможливий.

Існують способи зробити додатки грати приємніше в таких сценаріях, як-от використання черг подій та механізми відтворення, але оскільки ми говоримо про розгортання змін у тому, що використовується, насправді немає дурного способу підтвердження.

Ось як я це роблю:

Абсолютні мінімальні системні вимоги:
1 сервер з

• 1 балансир завантаження / зворотний проксі (наприклад, nginx), що працює на порт 80
• 2 ASP.NET-Core / моно-зворотний-проксі / fastcgi-chroot-jails або докер-контейнери, які прослуховують два різних порти TCP
  (або навіть лише два додатки з реверс-проксі на 2 різних портах TCP без жодної пісочної скриньки)

Робочий процес:

почати myupdate транзакції

try
    Web-Service: Tell all applications on all web-servers to go into primary read-only mode 
    Application switch to primary read-only mode, and responds 
    Web sockets begin notifying all clients 
    Wait for all applications to respond

    wait (custom short interval)

    Web-Service: Tell all applications on all web-servers to go into secondary read-only mode 
    Application switch to secondary read-only mode (data-entry fuse)
    Updatedb - secondary read-only mode (switches database to read-only)

    Web-Service: Create backup of database 
    Web-Service: Restore backup to new database
    Web-Service: Update new database with new schema 

    Deploy new application to apt-repository 
    (for windows, you will have to write your own custom deployment web-service)
    ssh into every machine in array_of_new_webapps
    run apt-get update
    then either 
    apt-get dist-upgrade
    OR
    apt-get install <packagename>
    OR 
    apt-get install --only-upgrade <packagename>
    depending on what you need
    -- This deploys the new application to all new chroots (or servers/VMs)

    Test: Test new application under test.domain.xxx
    -- everything that fails should throw an exception here
    commit myupdate;

    Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
    @client: notify of reload and that this causes loss of unsafed data, with option to abort 

    @ time x:  Switch load balancer from array_of_old_webapps to array_of_new_webapps 
    Decomission/Recycle array_of_old_webapps, etc.

catch
        rollback myupdate 
        switch to read-write mode
        Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try 

Я б запропонував зберегти старі файли там і просто перезаписати їх. Таким чином час простою обмежується часом перезапису однофайлів, і одночасно не вистачає лише одного файлу.

Не впевнений, що це допомагає у "веб-додатку", хоча (я думаю, ви говорите, що це ви використовуєте), саме тому ми завжди використовуємо "веб-сайти". Також при розгортанні "веб-сайтів" не перезапускається ваш сайт і не припиняються всі користувацькі сеанси.