ArgoCD Image Updater: чому ручне оновлення образів ламає релізи
Збірка завершилася успішно, образ із новим тегом лежить у реєстрі, звіти зелені. А в кластері продовжує крутитися попередня збірка: маніфест у Git, як і раніше, вказує на старий тег, і кластер із цим маніфестом повністю синхронізований.
Інструмент безперервної доставки чесно показує стан «в порядку», бо порівнює Git із кластером, а не реєстр із Git. Розрив виникає саме на цьому стику і живе непоміченим, поки хтось не загляне до реєстру вручну.
Ціна проявляється на проді. Баг, який уже виправили, відтворюється знову; на тестовому контурі версія свіжіша, ніж на бойовому; відкат нічого не дає, бо відкочувати нічого — тег у маніфесті не змінювався з минулого разу.
Ручний викат зводиться до правки тегу в репозиторії по кожному сервісу окремо, і кожен такий коміт стає окремою точкою відмови: забули сервіс, помилилися в тегу, виправили не в тій гілці. Розсинхрон версій між середовищами накопичується релізами, а не хвилинами.
На контурі з десятками сервісів і частими релізами це переходить у системну проблему.
Оновлення образів перетворюється на завдання, яке відкладають до інциденту, і застаріла збірка в кластері з'ясовується вже під час розбору аварії, коли потрібно швидко зрозуміти, який код взагалі відповідав на запити. Відновити картину за логами деплою при цьому складно — в історії немає події «версія змінилася».
ArgoCD Image Updater закриває саме цей розрив: він стежить за реєстром, порівнює актуальний тег із тим, що записано в маніфесті, і записує новий туди ж, звідки інструмент доставки бере бажаний стан.
Далі розбираємо, як це налаштовується — політики оновлення, фільтри за тегами, права на запис до репозиторію та поведінка під час відкату.
Що дає автооновлення образів: швидкість, стабільність, контроль
Ручне оновлення образу — найчастіше джерело затримки між готовою зміною та робочим контуром. Збірка проходить, образ потрапляє до реєстру, а далі починається очікування: черговий має згадати про сервіс, підставити новий тег в опис стану та запустити синхронізацію. Вікно легко розтягується на години, а за щільного потоку релізів черга просто не розгрібається.
ArgoCD Image Updater закриває цю ланку: він відстежує реєстр, порівнює тег і дайджест із тим, що розгорнуто, і сам ініціює оновлення. Час доставки змін вимірюється хвилинами і перестає залежати від того, хто сьогодні на зміні.
Друга метрика — частка ручних операцій. Правка тегу руками несе цілий клас відмов: помилка в імені, оновлення не того контуру, забута синхронізація після аварії.
Політика оновлення задає правило один раз — за маскою тегу, за зростанням версії або строго за дайджестом — і далі оновлення йде без участі людини. Людський фактор залишається тільки там, де справді потрібне рішення.
Стабільність викатів тримається на тому, що оновлення змінює декларативний стан, а не живий кластер.
Якщо новий образ не проходить перевірки готовності, розкатка зупиняється сама, черговий бачить розходження і повертає попередню ревізію однією командою — без ручної правки і без пошуку «а що там було раніше».
На виході виходить передбачуваність: у будь-який момент видно, який образ працює в кожному контурі, скільки часу зайняла доставка і скільки операцій залишилося ручними. Це вже не разові зусилля, а керований процес із зрозумілими точками контролю.
Режими роботи Image Updater: варіанти автоматичного оновлення
Image Updater підтримує два режими оновлення — за змінним тегом і за незмінним дайджестом. Від цього вибору залежить, що вважається новим образом, як відпрацьовує політика синхронізації і чи можна повторити вчорашній викат, не перезбираючи артефакт.
При оновленні за тегом інструмент порівнює значення в маніфесті з тим, що віддає реєстр, і при появі нової збірки або править маніфест у git, або відразу оновлює навантаження в кластері — залежно від того, як налаштована політика синхронізації.
Дайджест фіксує конкретний артефакт: тег при цьому не перезаписується, тому залишається однозначне посилання на те, що саме розгорнуто.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Змінний тег | тестові контури, де тег завжди вказує на останню збірку гілки | немає гарантії відтворюваності: тег перезаписується, старий образ губиться |
| Незмінний дайджест | бойові контури та аудит, де потрібне точне посилання на артефакт | у маніфесті видно хеш, а не версію; потрібен реєстр, що віддає дайджест |
| Ручний викат | рідкісні релізи та жорсткий контроль змін | затримка між збіркою та викатом, людський фактор |
| Гібрид: автооновлення на тестових, дайджест у бойовому контурі | типовий випадок, коли ціна помилки на контурах різна | потрібні роздільні правила та дисципліна в іменуванні тегів |
У автооновлення є загальна межа: інструмент змінює лише посилання на образ.
Правка конфігурації або секрету не перезапустить навантаження, а невдалий старт не відкотиться сам — без проб готовності та продуманої політики синхронізації зламана версія доїде до бойового контуру і залишиться в історії комітів.
Впровадження за кроками: від аудиту репозиторіїв до передачі регламентів
ArgoCD Image Updater знімає рутину, але помилка тут проявляється не в збірці, а в робочому контурі, що поїхав на неперевірений тег. Тому порядок робіт зафіксований: спочатку інвентаризація та узгоджена схема, тільки потім увімкнення.
- Аудит репозиторіїв. Розбираємо сервіси: де лежать маніфести, як публікуються теги, хто власник. На виході — карта сервісів із поточними стратегіями та позначкою, де автоматика безпечна.
- Схема оновлення. Для кожного сервісу визначаємо, на що підписуватися: стабільна гілка тегів, незмінний digest або окремий канал на середовище. Узгоджуємо, які середовища оновлюються самі, а які — за рішенням.
- Налаштування правил. Прописуємо правила відбору тегів, права запису до репозиторію конфігурації та поведінку за відсутності відповідного тегу. Сервіси, де автоматика неприпустима, обмежуємо явно.
- Перевірка сценаріїв. Проганяємо не лише успішне оновлення, а й те, що ламається на практиці: недоступний реєстр, конфлікт із ручною правкою маніфесту, повернення на попередній образ, вимкнення автоматики.
- Виведення в робочий контур. Вмикаємо за сервісами: спочатку некритичні, потім решту, звіряючи стан застосунку після кожного оновлення.
Передача регламентів
Віддаємо карту сервісів, схему оновлення, інструкції з відкату та підключення нового сервісу, проводимо навчання команди. Далі сервіси підключаються силами замовника, а оновлення залишаються керованими.
Що передаємо на руки: конфігурації, політики та регламенти
Артефакти збираємо так, щоб автооновлення образів не трималося на одному інженері: налаштування можна передати черговій зміні або новому підряднику без усних пояснень. Нижче — мінімум, який вирушає разом із налаштованим ArgoCD Image Updater.
- Конфігурації. Маніфест правила оновлення: цільовий застосунок, перелік образів, фільтр тегів (ігноруємо
latest, гілки та передрелізні мітки), інтервал опитування реєстру та спосіб запису нової версії до репозиторію. - Схема контурів. Як версія йде dev → stage → prod: де увімкнено автооновлення, де тільки готуються зміни, на якому контурі потрібен ручний перехід.
- Політики доступу. Права сервісних облікових записів: читання реєстру, запис — тільки до каталогу з маніфестами застосунку, без зайвих прав у кластері.
- Регламент відкату. За якими ознаками версія знімається, як фіксується попередній тег або незмінний дайджест, хто підтверджує повернення і скільки воно займає.
- Інструкція черговому. Розбір типових збоїв: новий тег не підхопився, оновлення застосувалося і сервіс не піднявся, стан репозиторію та кластера розійшовся.
- Спостережуваність. Які оповіщення налаштовані — розходження версій, невдала синхронізація, відмова авторизації в реєстрі — і за якими ознаками черговий розуміє, що справа в оновленні.
- Журнал рішень. Чому вибрані такі фільтри, інтервали та порядок контурів: наступна правка не повинна відкочувати усвідомлений компроміс.
Кейс: як команда прибрала ручні релізи в кластері з сотнею сервісів
Кластер на сто з лишком сервісів жив у ручному режимі: тег образу правився у values-файлі, далі рев'ю, злиття, синхронізація. Викат розтягувався на години, виправлення критичного дефекту чекало в загальній черзі, а розходження версій між контурами виявлялося вже за фактом збою.
Підключили Argo CD Image Updater і описали правила за типами сервісів: маски тегів і політика вибору, запис нового тегу назад у git, ліміт одночасних оновлень, щоб реєстр і кластер не штормило.
Для доменних сервісів залишили двоетапну схему — спочатку передрелізний тег на канареечному контурі, потім прод. Усе, що не оновилося за задане вікно, потрапляє в алерт як відсталий образ.
Що змінилося в цифрах
| Метрика | До | Після |
|---|---|---|
| Частка ручних викатів | близько 9 з 10 | менше 1 з 10 |
| Вихід виправлення в прод | години, залежало від чергового | 10–20 хвилин від збірки образу |
| Інциденти через розходження версій | регулярно, по кілька на місяць | поодинокі, ловляться алертом заздалегідь |
| Повернення до попередньої версії | ручна правка маніфесту | один реверт коміту |
Вважали не за відчуттями, а за історією синхронізацій, логом зміни тегів і розборами інцидентів. Люди перестали бути ланкою передачі артефакту: інженер відповідає за правила оновлення та розбір відхилень, а не за перенесення тегу з реєстру в маніфест.
Чим оновлення за тегом відрізняється від оновлення за дайджестом?
Тег — змінна мітка в реєстрі, дайджест — хеш вмісту образу. Контролер оновлення, що стежить за тегом, періодично опитує реєстр, порівнює отриманий дайджест із записаним у маніфесті та править маніфест при розходженні.
При оновленні за дайджестом у маніфесті відразу лежить незмінне посилання: перезапис тегу в реєстрі викат не зрушить.
Різниця проявляється саме при зміні тегу. Зібрали нову збірку під тим самим latest — попередній образ затерто, і відновити, що працювало в минулому релізі, вже нічим. Відкат за таким тегом недостовірний: мітку ви повернете, але не той самий набір шарів.
Дайджест цього недоліку позбавлений — він указує на конкретні шари, які живуть у реєстрі, поки діє політика зберігання.
Друга вісь — перезапуск застосунку. Новий дайджест змінює шаблон поду, тому розгортається новий набір реплік, а старий гаситься за стратегією поступового оновлення; перезапуск тут очікуваний і керований.
Якщо дайджест не змінився, перезапускати нічого: контейнери продовжать працювати на шарах, уже викачаних на вузол, — оновлення проходить без перезапуску.
Небезпечніший зворотний сценарій: реєстр повернув під тим самим тегом інший дайджест, і застосунок перезапустився в незапланований момент.
Практичний вибір очевидний. Для продуктових середовищ — тільки незмінні посилання: ArgoCD Image Updater резолвить тег у дайджест і записує в маніфест уже його, автоматизація зберігається, а викат стає відтворюваним і відкатним.
Тег без резолву доречний там, де потрібен «останній образ із гілки»: стенди розробки, прогони тестів, демо-контури.
Часті технічні сумніви: відкати, права, конфлікти синхронізації
Автооновлення образів знімає ручну рутину, але в інженерів відразу виникають питання про передбачуваність: що буде при недоступності реєстру, як не зачепити промисловий контур, хто може зупинити автоматику.
Нижче — короткі відповіді на сумніви, які спливають майже на кожному проєкті з ArgoCD Image Updater.
Що станеться, якщо реєстр образів недоступний?
Розгорнуті застосунки продовжують працювати на поточних образах, а оновлення маніфестів просто чекає відновлення зв'язку — нові правила не застосовуються до працюючих сервісів.
Окремо обмежуємо кількість повторів опитування, щоб черга не зростала безкінечно, і ставимо повідомлення, якщо реєстр мовчить довше заданого порогу.
Як розвести кілька середовищ, щоб тестова збірка не пішла в робоче?
На кожне середовище — своє правило оновлення: свій фільтр за тегами, своя частота опитування, свій набір застосунків.
У промисловому контурі автоматика або вимкнена, або спрацьовує тільки за окремим тегом-маркером, який проставляє релізний контур після перевірки в тестовому середовищі.
Хто і як може зупинити автооновлення?
Права доступу роздаємо через ролі: інженер вмикає та вимикає автоматику на конкретному застосунку, не отримуючи доступ до всієї інфраструктури.
Зупинка — зняття мітки автооновлення; ручне викладення при цьому продовжує працювати як звичайно, тож аварійний шлях залишається вільним.
Як відкочувати версію і що з конфліктами синхронізації?
Відкат версії — звичайна правка образу в репозиторії: повертаємо попередній тег, синхронізація підхоплює його без ручних дій у кластері.
Якщо автоматика і людина правлять один маніфест одночасно, пріоритет віддаємо версії з репозиторію, а розходження розбираємо за журналом — у робочому контурі конфлікт не залишається.
Обговоримо задачу: зберемо схему автооновлення під ваш контур
<cite> не потрібен. ArgoCD Image Updater згадуємо один раз. --- ArgoCD Image Updater працює поверх реєстру образів і ваших маніфестів, тому точність оцінки залежить не від кількості зустрічей, а від того, наскільки повно описано поточний контур.
Пропонуємо почати з розбору: ви показуєте, як сьогодні збираються та публікуються образи, ми відзначаємо, де автооновлення дасть ефект відразу, а де потребує правок у процесі збірки.
Щоб повернутися з оцінкою та планом, потрібні вхідні дані від замовника:
- схема контурів: скільки кластерів, де тестовий, передпродуктивний і продуктивний, чим вони відрізняються;
- правила тегування образів: які теги вважаються релізними, чи є незмінні, як позначаються hotfix-збірки;
- доступи: читання до реєстру, права на репозиторій маніфестів, роль у кластері для сервісу оновлення;
- вікна оновлення та правила відкату: чи оновлюється продуктив автоматично або за підтвердженням;
- обмеження: сервіси зі станом, міграції схеми даних, компоненти, які не можна чіпати автоматикою;
- цільовий результат: що вважаємо успіхом — швидкість доставки правки, частка ручних операцій, передбачуваність відкату.
Після розмови ми збираємо схему автооновлення під ваш контур і розкладаємо її на етапи впровадження. Зазвичай це пілот на одному сервісі в тестовому контурі, потім розкатка на решту з роздільними політиками за тегами, потім регламент експлуатації та передача команді.
За кожним етапом фіксуємо критерій готовності, тому ви бачите прогрес, а не загальні запевнення. Опишіть задачу — повернемося з оцінкою та планом.
