Налаштування Deno Deploy для глобальних Edge-додатків: деплой, CI/CD і KV

Deno Deploy налаштування: що ламається під час першого деплою

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

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

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

Локально все зелене, у периферійному середовищі — порожня відповідь, помилка читання й падіння на першому ж зверненні до KV.

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

Відкат у такому процесі перетворюється на повторну ручну викладку попередньої ревізії замість однієї передбачуваної операції.

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

Налаштування Deno Deploy у таких випадках зводиться не до переписування коду, а до кількох рішень: роздільні секрети за контурами, викладка тільки через автоматичний конвеєр із перевірками та явні правила читання й запису для розподіленого сховища. Розбираємо, як це закривається до того, як збій дійде до користувачів.

Налаштування середовищ: що це дає за строками та надійністю

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

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

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

Збірки незмінні, тому повернення до попередньої версії — це перемикання, а не термінова перезбірка в момент аварії.

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

Межі за пам’яттю та часом на запит задані заздалегідь, тому один важкий виклик не тягне за собою сусідні.

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

Варіанти розгортання: порівняння підходів

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

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

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

Вибір робимо від профілю навантаження, а не від моди: якщо дев’яносто відсотків запитів надходять з одного регіону, переплата складністю за периферію не окупається.

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

Порядок впровадження: від аудиту до передачі

Порядок робіт іде етапами так, щоб кожне наступне налаштування спиралося на перевірене попереднє: спочатку знімаємо фактичну картину, потім проєктуємо середовища й лише потім випускаємо трафік.

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

1. Аудит інфраструктури. Збираємо домени, поточні маршрути, змінні середовища та залежності збірки; окремо фіксуємо, що обчислюється під час збірки, а що — під час обробки запиту.
2. Схема середовищ. Розводимо середовище передперегляду під кожну гілку, тестове середовище з окремим набором даних і бойове; описуємо правила, за якими запит потрапляє в кожне з них.
3. Налаштування секретів. Розкладаємо ключі за областями видимості: потрібне лише серверному коду не потрапляє в клієнтську збірку, а заміна ключа відбувається без перевипуску застосунку.
4. Маршрути й кешування. Закріплюємо карту маршрутів, правила кешування статики й відповідей, поведінку в разі відмови найближчого регіону.
5. Перевірка перед публікацією. Проганяємо збірку на бойовому трафіку в режимі дзеркалювання, звіряємо час відповіді з попереднім, перевіряємо відкат на попередній реліз.
6. Передача документації. Віддаємо карту середовищ, регламент заміни секретів, чек-лист випуску та відкату із зазначенням відповідальних.

Комплект артефактів: конфігурації, схеми, регламенти

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

• Файли конфігурації — описи середовищ (основне, тестове, середовище передперегляду) поруч із кодом: змінні, прив’язки сховища ключ-значення, ліміти часу виконання та правила обробки запитів.
• Схема маршрутизації — карта доменів і піддоменів із прив’язкою до проєктів і середовищ, правила перенаправлень, обробка власних заголовків і вибір найближчого регіону.
• Правила доступу та секрети — ролі учасників, області дії токенів розгортання, порядок ротації ключів і зберігання секретів поза репозиторієм.
• Регламент випуску та відкату — що має пройти до викладки, як перемикається трафік між версіями і за яким кроком повертаємося на попередню стабільну збірку.
• Інструкції для чергової зміни — які показники дивитися при зростанні затримок, збоях викладки й недоступності сховища, що лагодиться на місці й коли потрібна ескалація.
• Документація для команди — структура репозиторію, угоди про гілки та типові операції: додати маршрут, підключити домен, завести нову прив’язку сховища.

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

Розбір впровадження: перенесення сервісу на периферію

Що було до перенесення

Сервіс жив на одному сервері в одному регіоні: збірка й публікація виконувалися скриптом, який черговий інженер запускав вручну в нічне вікно. Один випуск займав 40–60 хвилин, з них половина — перевірки «на живу» й лагодження файлів, що не потрапили в артефакт.

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

Відкат був окремою операцією: підняти попередній образ, дочекатися прогріву кешу, звірити логи. На нічні зміни припадало 7 відкатів із 10 — уранці команда розбирала наслідки замість нових завдань.

Що змінили й що отримали

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

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

Час випуску скоротився з 40–60 хвилин до 6–8 за того ж обсягу змін. Частка відкатів, що припадають на ніч, упала з 70% до нуля: тепер відкат робиться вдень, займає десятки секунд і майже не потребує чергового.

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

Чим периферійне KV відрізняється від центральної бази?

Периферійне KV-сховище (Deno KV) відповідає на питання «як прочитати швидко», центральна база даних — «як не втратити й не переплутати». Перше віддає значення за ключем із найближчої точки присутності, друге тримає транзакції, зв’язки та єдину версію правди. Вибір сховища — не про «що сучасніше», а про те, які гарантії потрібні конкретному набору даних.

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

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

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

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

Усе, що пов’язано із зобов’язаннями, правами й обліком, залишається в центральній базі, а KV працює над нею прискорювальним шаром читання.

Часті технічні сумніви перед стартом

Перед стартом інженери й технічні керівники задають майже ті самі питання — і вони не стільки про рантайм, скільки про те, як влаштована робота з Deno Deploy і що залишиться в команди замовника після передачі. Нижче — відповіді по суті.

Що буде, якщо вузол у регіоні недоступний?

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

Як відкочувати публікацію?

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

Кому належать налаштування?

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

Як передається доступ і що залишається після нас?

Доступи відкликаються в один крок у панелі власника. Після передачі залишаються описані змінні середовища, схема KV, конфігурація маршрутизації та регламент випуску; проводимо розбір із вашим інженером, щоб чергування не залежало від нас.

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

Щоб розмова закінчилася планом, а не загальними словами, нам потрібен контур застосунку та те, як він живе зараз.

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

Мінімальний набір, якого достатньо для першої ітерації:

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

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

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