GG
>программная генерация пайплайнов
да-да-да, конечно
да-да-да, конечно
Size: a a a
2020 September 07
GG
А можно как-то легко понять запросом кем используется сервис/pod в кластере? Типа есть база и надо узнать кто ее юзает перед миграцией...
если ты изначально форсишь сетевые политики - у тебя уже есть карта связности
GG
потом есть штуки типа хабла или сервис мешей - которые могут нарисовать прохождение запросов сейчас
GG
но я в них не очень верю, потому что если у тебя миграции раз в неделю, то по моему разумению они могут с карты трафика пропадать
LB
>программная генерация пайплайнов
да-да-да, конечно
да-да-да, конечно
с чем не согласны?
GG
GG
include, exclude, yaml anchor - это не программная генерация
LB
include, exclude, yaml anchor - это не программная генерация
GG
фигаче ;-o отстал я от жизни - тем не менее - это оставляет проблему, что от каждого прогона пайплайн может меняться
LB
за последний год там ништяков завезли прям очень много. пайплайны как нагенерируешь так и будет
GG
мне что один подход не нравится - когда пайплайны интегрируют с кодом, что когда отрывают. В обоих парадигмах есть проблемы
AL
вот был бы у вас cilium можно было б, а так tcpdump только )
Да, хардкор 😁 Но вот такой тулзы прям не хватает, чтобы могла смотреть трафик и сама рисовала зависимости, или аннотации/прочая метаинформация...
AL
мне что один подход не нравится - когда пайплайны интегрируют с кодом, что когда отрывают. В обоих парадигмах есть проблемы
Пайплайны в коде - это прям по 12-factor
AL
Самый правильный путь, когда разработчики видят все что происходит внутри самой репы и могут это менять.
GG
Самый правильный путь, когда разработчики видят все что происходит внутри самой репы и могут это менять.
это никак не соотносится с тем - есть ли описание пайплайна внутри репы или нет
GG
более того - часть пайплайна очевидно, что часть разработчиков не должна менять, т.к. это риски по ИБ - иначе зачем завозили protected вещи в гитлаб и CODEOWNERS
ST
напомните плиз, CRI же кастомный необязательно на контрол плейне менять, если он нужен только на воркерах?
ST
вроде так оно всегда было но мб что упустил
GG
напомните плиз, CRI же кастомный необязательно на контрол плейне менять, если он нужен только на воркерах?
необязательно
LB
мне что один подход не нравится - когда пайплайны интегрируют с кодом, что когда отрывают. В обоих парадигмах есть проблемы
моя нирвана: все проекты конфигурируются тянуть bootstrap gitlab-ci.yml из внешнего хранилища по http, тот берет переменные окружения вроде имени проекта, ветки и проч и вызывает центральный open policy agent (OPA) , который генерирует пайплайны. при генерации может создавать временные секреты, брать из инвентори в какие кластеры задеплоить, какие ендпоинты юзать для конкретного окружения в конкретном кластере и проч.
если надо дать разработчикам волю чуток покастомизировать что-то, то bootstrap скрипт может взять какие то куски из репозитория и отправить open policy agent, который их интегрирует куда надо.
Любители тектона и прочих CRD тоже могут быть счастливы - OPA может подсасывать любые ресурсы через bundle api в том числе и из кубов
если надо дать разработчикам волю чуток покастомизировать что-то, то bootstrap скрипт может взять какие то куски из репозитория и отправить open policy agent, который их интегрирует куда надо.
Любители тектона и прочих CRD тоже могут быть счастливы - OPA может подсасывать любые ресурсы через bundle api в том числе и из кубов