Kubernetes, десятки configmap и как это готовить?

Question

[lalatop]

Всем привет. Может кто подскажет или расскажет свой кейс, как удобно управлять конфигмапами куба, когда их сотни, и нужно их постоянно редачить, что-то добавлять, что-то удалять, потому что уже голова по швам от косяков с тем, как это все поддерживать
Есть один проект, в котором на данный момент, 35+ микросервисов и постоянно добавляются новые.
Имеется 4 окружения, дев тест релиз прод. Итого 120+ микросервисов
В каждом сервисе подключен бутстрап конфиг, в котором подключены 4-5 конфигмапов дополнительно (Всякие бизнес конфиги, конфиги с адресами, апликейшн и прочее),
разработка решила сделать так, что бы не маунтить все конфиги в апликуху, а только бустрап
При выдаче изменений версионных, в основном, требуется к примеру в 10-и конфигах сделать изменения. Всё вносится вручную, какие-то параметры надо удалить, какие-то добавить и так далее. Kustomize не катит. Автоматизировать изменение не представляю как. Далее конфигмапы деплоятся в куб из гита.
По итогу можно провтыкать изменить на каком-то окружении параметр, и всё..окружения уже не одинаково настроены.
Хранить одну копию конфигов, одного окружения, в ней делать изменения и раскатывать на всё остальное, тоже не получается.
Потому что..dev окружение, в нем в конфигах одни данные.. (адреса параметры и тд)
Тест и релиз находятся в другом кластере, у них тоже разные данные в конфигах.
По итогу раскатка изменений может занимать полтора-два дня. Это с учетом сборки и деплоя приложений.
У кого-то будут варианты как решить проблему с конфигмапами и как это оптимизировать всё?

Answer 1

[mayton2019]

Тут читается не техническая а организационная проблема.

Не очень понятно но попробую дать совет.

Вот ты говоришь что требуется в 10 конфигах сделать изменения.
Какие? Они - взаимосвязаны? - Это должен быть 1 коммит в git.
Эти все изменения должны быть просмотрены глазами хотя-бы несколькими людьми.
Если цена изменения дорого стоит (инфраструктура) то по любому должна
быть бригада девопсов. Они - страхуют друг друга от случайной ошибки.
Если ты будешь брать на себя падения датацентров - то очень скоро
станешь пациентом кардиолога. Бери коллег для подстраховки.

Константы и зависимости - надо объявлять отдельно. Чтоб если меняется hostname
или имя свойства - то это должно быть ровно одно изменение. Как поддержать
константы в конфигах - я щас не помню но была куча всяких штук... толи Puppet
толи Ansible вобщем поищи сам. Я думаю таких много конфигураторов.

Когда несколько environments то на проекте создается просто несколько фолдеров типа

/dev
/qa
/uat

и в каждом фолдере лежит полностью сконфигурированная и оттестированная
копия всех конфигов. Переключение между env тоже должны происходит
изменением ровно 1 свойства.

Если внутри конфигов есть некая базовая конфигурация которая очень похожа
(прототип) то сделайте аналог COC (Convention Over Configuration). Пускай
прототип будет всегда. А наследники dev, qa, uat будут просто изменять
дельту. Пароль поменялся - в конфиге-наследнике - лежит ровно 1 строчка с паролем.
Других строк - не надо. Потому что они наследуются от прототипа.

Как технически реализовать COC - я не скажу. Это надо обсуждать. Я это делал
на Java проектах но это как-бы идея "на подумать". На проектах у меня были
*.properis файлы и эту конвенцию было реализовать несложно. С ЯМЛ ами я не делал.
Ну думаю что это возможно. Почему нет?

Comments

[lalatop]

По поводу какие изменения.
К примеру, разработка выдает версию на тестирование, и говорит, внести новые параметры в конфигмапы
service1-dev.yml
В него нужно добавить строку secret.code.allowed=true
в конфиги service1-reliz.yml, service1-test.yml
добавить строки
secret.code.allowed=false
secret.code.lives=50
В конфигах service2-reliz.yml заменить блок

sleuth:
    sampler:
      probability: 1.0
    baggage:
      remote-fields:

на

sleuth:
    sampler:
      probability: 1.0
    propagation-keys:

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

[mayton2019]

lalatop, а почему тестировщики кричат? Может они хотят тестировать этот параметр?
secret.code.lives=50
Смотри. Хабр может ответить на технические вопросы если информация полна и ясна для ответа.
Но твоя задача - собрать голосовой чят с тестировщиками или с их лидами. И проговорить все сомнения.
Может они в чем-то правы и поведение системы изменилось. Короче твоя проблема - это
коммуникации. Коммуницирй. Разговаривай. Собирай митинги. Семинары. Разьясняй свою работу.
Они должны понимать ПОЧЕМУ ты эти изменения делаешь. Это как общаться с утенком.
Если ты им объяснишь словами - то может ты и сам лучше поймешь или уберешь из технологии
какие-то ненужные steps которы на самом деле не нужны.

Ком-му-ни-ка-ции!

Answer 2

[Saboteur]

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

В глаза кидаются мелочи типа

В каждом сервисе подключен бутстрап конфиг, в котором подключены 4-5 конфигмапов дополнительно

А почему у вас несколько конфигмапов на одно приложение, а не один конфигмап?

При выдаче изменений версионных, в основном, требуется к примеру в 10-и конфигах сделать изменения

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

По итогу можно провтыкать изменить на каком-то окружении параметр, и всё..окружения уже не одинаково настроены.

Делать статические параметры, и в конфигмапы выносить исключительно environment-related опции.

По вашему вопросу никто не скажет решения. Это нужно сесть и переделать.
У меня свыше 100 компонентов, десяток енвайрнментов. Конфигмап один на неймспейс, секрета два на неймспейс, в принципе достаточно.

Comments

[lalatop]

А почему у вас несколько конфигмапов на одно приложение, а не один конфигмап?

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

[Saboteur]

поднимаешь задачу на переработку архитектуры под новые нужды проекта, привлекаешь архитектора, менеджера чтобы утвердили новую, и потихоньку внедряешь.

Иногда такая задача решается за 1-2 релиза. Иногда за 1-2 года..

Но однозначно нужно придумать более удобный способ для конфигурирования приложений.
Есть же куча вариантов.
Например в спрингбут есть фича, что переменные окружения могут оверрайдить значение пропертей. То есть просто конфиг в гите статичный, если надо - меняют и релизят. А если надо срочно здесь и сейчас, просто переменную окружения правильную для этого пода делаешь и значение оверрайдится. Надо только проверить версию спрингбута, чтобы это работало.

Ну и конфигмап может быть не key=value, а component_property_file=content, где маунтишь этот файл в под целиком как есть. (p.s. работаю с опенщифтом но думаю в кубере это тоже возможно).