VPN при CI runner: оцелява ли тунелът след билда?
Споделеният CI runner запазва маршрути и процеси между задачите. Планирайте състоянията на VPN преди, по време и след работата и почиствайте само връзката, която задачата притежава.
Задача за внедряване се свързва, копира артефакта си и отчита успех. Тунелът, който е отворила, може да е все още активен, когато започне следващата задача, а маршрутът, който е променила, принадлежи на целия хост. Резултатът от билда описва командата, а не състоянието, което е оставила след себе си. Отнасяйте се към VPN като към ресурс с живот, а не като към един ред в началото на етап.
Какво друго работи на този хост
Възел на Jenkins може да изпълнява няколко изпълнителя едновременно и задача, която променя маршрутите на хоста, настройките на резолвера или системна връзка, ги променя за всички. Дали друга задача ще го забележи, зависи от политиката за маршрутизиране и филтриране, а не от общо правило за VPN. Достъпът до хранилището, достъпът до артефактите и каналът за управление са отделни изисквания, от които runner-ът все още се нуждае. Добавете ги към списъка с дестинации за внедряване, преди да изберете пълен тунел.
Ако каналът за управление ще минава през тунела, дизайнът трябва да го заяви съзнателно. Откриването му по време на връщане назад не е план. Запишете двата списъка: до какво задачата трябва да достига частно и до какво runner-ът трябва да достига независимо от всичко.
Нуждае ли се тази задача въобще от частен достъп?
Питайте преди добавянето на тунела дали етапът на билда се нуждае от него. Частен агент за внедряване може да изтегли одобрен артефакт и да извърши внедряването, което държи общия етап на билда извън частната мрежа. Такова разделяне обикновено е по-евтино от това да учите всяка стъпка на билда да маршрутизира през тунел.
Избирайте границата от работния поток, а не от навика. Ако отговорът е не, останалата част от тази страница е ненужна и това е най-добрият наличен изход.
Състоянието, което наследява следващата задача
Опишете какво трябва да е вярно преди задачата, докато тя държи частен достъп, и след като приключи, включително при отмяна. Крайното състояние е това, което най-често остава подразбиращо се, и то е това, което наследява следващата задача. Запишете го до 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 |
Отделен или изхвърляем агент прави тези граници по-лесни за налагане. Контейнер или namespace помага само ако мрежовото и привилегированото му устройство наистина изолира промяната.
Спрете връзката, а не програмата
Използвайте пътя за финализиране на pipeline-а, за да затворите връзката, която тази задача е започнала, и да премахнете временните ѝ идентификационни данни. Не съпоставяйте процеси по име на програма на хост, който други задачи използват; спрете конкретната връзка. Двете команди по-долу са цялото почистване и нито една от тях не зависи от намирането на процес.
vpn-cli disconnect --profile "$PROFILE"
rm -f "$RUNNER_TEMP/client.key"Финализирането не е изолация: runner, който умира, запазва отворения тунел, а процес, спрян насила, пропуска блока напълно. Затова командата за почистване сама по себе си не може да бъде целият дизайн. Ето как се проваля на практика: задача за внедряване се отменя на стъпката по копиране, блокът за финализиране никога не се изпълнява и следващата задача на същия хост започва с жив тунел и маршрут, който сочи към мрежа, до която не може да достигне. Повредата изглежда като проблем с 'DNS' в следващия билд, часове след като задачата, която я е причинила, е приключила.
Записвайте името на профила и пътя до идентификационните данни в изхода на задачата. Гола команда за прекъсване без идентификатор е трудна за одит по-късно. Редът в лога също е това, което доказва, че блокът е работил, когато по-късно разследване го поиска.
Дайте на задачата хост, който никой друг не използва
Изхвърляемата инфраструктура премахва проблема с наследяването, вместо да го управлява. Нов агент за всяка задача започва без маршрут, без профил и без чужди идентификационни данни, а унищожаването му почиства каквото задачата е оставила. Това струва повече на билд и това е честната цена на граница, която не зависи от код за почистване. За задачи, които докосват производствени мрежи, обикновено това е по-евтиният вариант, след като се преброят инцидентите.
Там, където споделен runner трябва да остане, тествайте отказа и отмяната толкова внимателно, колкото успешното копиране. Тестът трябва да покаже какво би видяла следващата задача, ако тази бъде отменена по средата. Една задача е готова, когато достъпът и временното ѝ състояние са приключили, а не когато командата за копиране върне нула.