Невдала повторна публікація ніколи не видаляє робочий бекенд

25 вересня невдала повторна публікація видалила бекенд застосунку, який був запущений і працював близько двох з половиною годин. Код, що відкочує невдалу публікацію, знищував кожен серверний застосунок, якого торкнулася ця публікація, — включно з тими, що вже обслуговували користувачів до її початку. Тепер видаляються лише застосунки, які створила сама публікація. Застосунок, що вже існував, повертається до точного образу, на якому працював раніше. Ще два виправлення того ж дня гарантували, що відкат спрацьовує й тоді, коли сам інструмент розгортання хостинг-платформи дає збій, і що справний застосунок не позначають як невдалий лише тому, що він спав.

Як публікується бекенд

Коли ваш застосунок Mythex має бекенд — API або сервер, а не лише статичні файли, — публікація збирає його з Dockerfile (рецепта, за яким застосунок пакується в образ) і розгортає цей образ на машинах нашої хостинг-платформи. Потім перевірка працездатності чекає, поки нова версія справді запуститься і стабільно працюватиме, і лише після цього публікацію позначають як активну.

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

Проблема 1: відкат видаляв те, що мав відновити

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

Для повторної публікації це саме неправильно. Застосунок уже існував і обслуговував справжніх відвідувачів. 25 вересня API застосунку, що працював близько двох з половиною годин, був видалений через невдалу повторну публікацію.

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

Виправлення: видаляти лише те, що створено, а решту відновлювати

Тепер кожна публікація записує для кожного серверного застосунку, який вона торкається:

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

При невдачі кожен застосунок отримує одну з трьох дій:

1. Створений цією публікацією: видалити, як і раніше.
2. Уже існував, попередній образ відомий: повторно розгорнути попередній образ з тією самою конфігурацією. Збирання не потрібне — переміщується лише образ.
3. Уже існував, попередній образ невідомий: не чіпати. Існуючий застосунок ніколи не видаляється, навіть якщо його не вдалося відновити.

Ці правила — це невелика чиста функція з власними тестами, тож рішення не зможе повернутися до «видалити все» без того, щоб тест упав.

Проблема 2: інструмент розгортання міг упасти раніше, ніж ми записали, як відкотити

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

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

Виправлення: зареєструвати відкат до початку

Тепер застосунок реєструється для відкату — з позначкою, чи його створено, і з тим, який образ він запускав, — щойно його підготовлено і до того, як щось на нього розгортається. Що б не сталося далі, відкат знає, що повертати. Ми перевірили це локально: зламана повторна публікація провалилася на димових перевірках самого інструмента, а попередня версія далі відповідала на запити.

Проблема 3: сплячий застосунок позначили як «так і не запустився»

Опубліковані застосунки Mythex засинають у простої, щоб заощаджувати ваші кредити. Повторна публікація залишає машину, що спала, зупиненою, тож перевірка працездатності мусить її розбудити. Вона просила платформу запустити машину один раз і ігнорувала відповідь.

25 вересня цей єдиний запит запуску нікуди не потрапив. Справний API стояв зупиненим весь п'ятихвилинний термін перевірки і був позначений як невдалий з повідомленням «1 машина так і не запустилася (останній стан: stopped)».

Платформа іноді справді відмовляє в запуску. Під час відтворення цієї проблеми вона без нашого втручання повернула конфлікт «lease currently held», а також відмовляє в запусках, поки машина оновлюється.

Виправлення: продовжувати питати і постукати у двері

Тепер перевірка працездатності:

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

Ми відтворили це на справжній платформі з тимчасовим застосунком, першому запуску якого відмовили. До виправлення публікація провалювалася через 91 секунду. Після — публікувалася за 20 секунд. Застосунок, який справді падає під час завантаження, як і раніше провалюється, як і має бути.

Що ми з цього взяли

• Відкат має розрізняти нове і існуюче. «Скасувати» для того, що ви створили, означає видалити. «Скасувати» для того, що вже було, означає відновити. Коли з цим поводяться однаково, механізм безпеки видаляє справний застосунок.
• Запишіть, як відкотити, перш ніж діяти. Якщо запис про відкат робиться лише після того, як крок вдався, то крок, що впав на півдорозі, не залишає чим відкотити.
• Ніколи не ігноруйте відповідь на запит, від якого ви залежите. Одна проігнорована відмова перетворила справний застосунок на невдалу публікацію.

Пов'язане виправлення того ж дня: застосунки, що падають одразу після публікації. Про те, що відбувається, коли публікація провалюється з нашого боку, дивіться усунення несправностей публікації у документації.