В любой команде, где ведется разработка приложений, будут и приложения, написанные не вами, но без которых никак нельзя. Вспомогательные приложения, они же «тулы», нужны в основном для утилитарных целей, мониторинга либо как контроллер того или иного процесса.

И эти приложения надо обновлять на протяжении всего жизненного цикла. Процесс поддержки таких приложений это часть работы с техническим долгом. По другому можно это назвать налогом на инфраструктуру. И иногда налог получается довольно большой!

Думаю все знают в какой ад может превратиться обновление приложений и их зависимостей.

Технический долг это не только «плохой код». Это любая работа, которую нужно сделать сейчас, чтобы избежать больших затрат в будущем.

Мотивы

Вот основные мотивы обновляться часто:

Накопление долгов: Если вы пропустите одну версию, обновиться будет легко. Если пропустите пять версий (например, с Prometheus 2.30 до 3.x), вам придется исправлять десятки несовместимостей. Дальше — больше: если не контролировать количество тулов, весь бюджет команды может уйти просто на выплату «процента по долгу». То есть при пересечении определенного порога вся команда начнет заниматься только поддержкой чужих тулов, постоянно что‑то будет сломано — вечный цейтнот не позволит быстро выкатить новый релиз или нормально протестировать его.
Риски безопасности: Старые версии перестают получать патчи безопасности.
Остановка развития: Новые функции (например, поддержка новых типов метрик в Prometheus или новых триггеров в KEDA) будут недоступны. Команде придется придумывать «костыли», чтобы реализовать то, что в новых версиях уже есть «из коробки».
Стандартный ответ любого саппорта всегда будет: «Обновитесь до актуальной версии».
Новые версии приложений часто оптимизируют потребление ресурсов и снизить расходы на инфраструктуру.
Иногда тулы привязаны к версии Кубернетеса — если обновлять его, все равно придется обновлять и остальные тулы.
Я считаю эту активность частью Infrastructure as Data подхода(вот здесь я немного писал про подход). Если процесс автоматизирован и инженер может видеть в Git какая версия приложения установлена и историю обновлний приложения, то это делает инфраструктуру более прозрачной и поддерживаемой.
Смешная, но резонная причина регулярно обновляться которую я слышал от коллег — обновления это часть инфраструктурной гигиены, если инфраструктуру регулярно не «мыть», то она будет болеть.

И способы

Чтобы обновления не превращались в бесконечный но неэффективный процесс, нужны правила, установленные внутри команды. В нашем случае это:

Главное правило: не плоди сущностей без необходимости — мы очень консервативно подходим к добавлению новых тулов в нашу инфраструктуру. Если можно обойтись без новой тулы или без тулы, которая уже есть — мы ее выкидываем. У нас есть кладбище тулов, где мы им рисуем им могилки, и еще мы ведем список, где записываем, почему мы решили не использовать ту или иную тулу.
Временные рамки: мы выделили специальное время для апгрейдов, после различных оптимизаций нам хватает делать их 3 раза в год, чаще нам не нужно, а если есть критические обновления, тогда мы обновляем сразу.
Но по мере все большей автоматизации процесса обновления и тестирования — мелкие тулы и незначительные изменения применяются полностью автоматически — сразу, как становятся доступны.
Автоматизация — процесс небыстрый, но в итоге, когда для всех тулов были написаны тесты — стало возможным обновлять девелопмент энвы автоматически, что сняло 90 процентов ручной работы. Она также экономит время на администрирование — надо провести митинг, и обсудить, будем или нет обновлять тулы; создать таски, прочитать release notes, попробовать обновить чарт или тулу в тестовом энвайроменте и понять, что все не так просто — это отнимало времени не меньше, чем само обновление.
Важность приложения — Prometheus или, например, ArgoCD — с этими приложениямимы не хотим набивать шишки первыми, очень часто мажорные версии могут быть сырыми и иметь баги; потому для таких тулов мы стараемся придерживаться правила n-1 или хотя бы n.0.2 — то есть либо ставить предпоследнюю версию, либо ставить новую версию только после нескольких патчей.
Тесты. Наша инфраструктура имеет инфраструктурные тесты, которые каждый день полностью удаляют и создают точную копию инфраструктуры в отдельном кластере и запускают тесты для каждого приложения. Это помогло нам найти пару очень неприятных изменений, которые мы пропустили бы или о которых узнали бы довольно поздно. Тесты продолжают помогать нам искать ошибки, и также оптимизировать код инфраструктуры, например чтобы ее ресурсы можно было быстрее развернуть или более безопасно удалить.
Учет. В самом начале мы использовали простенькую табличку, где писали последнюю версию тулы и версию, используемую нами. Во время митингов мы обсуждали, что стоит обновить, и в принципе это работало, но занимало довольно много времени. И еще часто можно было случайно пропустить обновление или забыть создать задачу на обновление. Теперь же мы используем GitOps подход, и всеми приложениями управляет ArgoCD, а обновляет их аналог Renovate Bot в полуавтоматическом режиме.

Вот так выглядит апгрейд одного приложения

Да, Kubernetes не простая тула, и мы не апгрейдим его автоматически, но общий процесс обновления похож. И как видите автоматизация делает все за нас, надо только указываем версии(но даже версии уже для многих тулов комитаются в git автоматически после тестов).

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

Боремся с энтропией в рядах инфраструктуры через регулярные обновления