VPN для CI-раннера: чи переживе тунель збірку?
Спільний CI-раннер зберігає маршрути й процеси між завданнями. Плануйте стани VPN до завдання, під час нього й після, і прибирайте лише те з'єднання, яким володіє завдання.
Завдання розгортання підключається, копіює свій артефакт і повідомляє про успіх. Відкритий ним тунель може досі працювати, коли починається наступне завдання, а змінений маршрут належить усьому хосту. Результат збірки описує команду, а не стан, який вона залишила по собі. Ставтеся до VPN як до ресурсу зі строком життя, а не як до одного рядка на початку етапу.
Що ще працює на цьому хості
Вузол Jenkins може запускати кілька виконавців одночасно, а завдання, яке змінює маршрути хоста, налаштування резолвера або загальносистемне з'єднання, змінює їх для всіх. Чи помітить це інше завдання, залежить від політики маршрутів і фільтрації, а не від загального правила про VPN. Доступ до репозиторію, доступ до артефактів і канал керування це окремі вимоги, які раннеру все ще потрібні. Додайте їх до списку призначень розгортання, перш ніж обирати повний тунель.
Якщо канал керування проходитиме через тунель, проєкт має сказати це свідомо. Виявити це під час відкату не план. Запишіть два списки: чого завдання має досягати приватно і чого раннер має досягати за будь-яких умов.
Чи потрібен цьому завданню приватний доступ узагалі?
Запитайте до додавання тунелю, чи потрібен він етапу збірки. Приватний агент розгортання може отримати схвалений артефакт і виконати розгортання, що тримає загальний етап збірки поза приватною мережею. Такий поділ зазвичай дешевший, ніж учити кожен крок збірки маршрутизуватися через тунель.
Обирайте межу з робочого процесу, а не зі звички. Якщо відповідь ні, решта цієї сторінки непотрібна, і це найкращий доступний результат.
Стан, який успадковує наступне завдання
Опишіть, що має бути істинним до завдання, поки воно має приватний доступ, і після його завершення, включно зі скасуванням. Саме кінцевий стан найчастіше залишається невисловленим, і саме його успадковує наступне завдання. Запишіть його поруч із pipeline, а не залишайте в чиїйсь пам'яті.
| Moment | What proves it | What leaks if it is skipped |
|---|---|---|
| Job start: pre-flight route check | The route table shows no tunnel from an earlier job, and the profile list is empty | A stale route sends deployment traffic into a dead tunnel |
| Job end: disconnect and shred | The profile is down and the temporary key file is gone | The next job inherits an open tunnel and a usable credential |
| Cancelled job: reboot or disposal | The host is replaced or rebooted before the next job starts | A killed process leaves the tunnel up with no owner |
Виділений або одноразовий агент робить ці межі простішими для дотримання. Контейнер або простір імен допомагає лише тоді, коли його мережеве та привілейоване налаштування справді ізолює зміну.
Зупиніть з'єднання, а не програму
Використайте шлях завершення pipeline, щоб закрити з'єднання, яке почало це завдання, і видалити його тимчасові облікові дані. Не зіставляйте процеси за назвою програми на хості, який використовують інші завдання; зупиніть конкретне з'єднання. Дві команди нижче це все прибирання, і жодна з них не залежить від пошуку процесу.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"Завершення не ізоляція: раннер, який помирає, зберігає відкритий тунель, а процес, зупинений примусово, повністю пропускає блок. Тому самої команди прибирання не може бути достатньо для всього задуму. Ось як це відмовляє на практиці: завдання розгортання скасовують на кроці копіювання, блок завершення ніколи не виконується, і наступне завдання на тому самому хості починається з живим тунелем і маршрутом, що вказує на мережу, до якої воно не може дістатися. Збій виглядає як проблема з 'DNS' у наступній збірці, через години після завершення завдання, яке його спричинило.
Записуйте назву профілю та шлях до облікових даних у вивід завдання. Гола команда відключення без ідентифікатора погано піддається аудиту потім. Рядок логу також доводить, що блок виконався, коли про це запитає пізніше розслідування.
Дайте завданню хост, який не використовує ніхто інший
Одноразова інфраструктура усуває проблему успадкування, а не керує нею. Свіжий агент на кожне завдання починається без маршруту, без профілю й без чужих облікових даних, а його знищення прибирає все, що завдання залишило. Це дорожче за кожну збірку, і це чесна ціна межі, яка не залежить від коду прибирання. Для завдань, що торкаються виробничих мереж, це зазвичай дешевший варіант, якщо порахувати інциденти.
Там, де спільний раннер має залишитися, перевіряйте збій і скасування так само ретельно, як успішне копіювання. Тест має показати, що побачило б наступне завдання, якби це скасували на півдорозі. Завдання завершене, коли закінчилися його доступ і тимчасовий стан, а не коли команда копіювання повертає нуль.