Pull to refresh

Comments 15

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

Утопично? Внешнее хранилище на то и внешнее, что для при изменении кредов там вам не придется перезапускать все контейнеры. Например, в каком-нибудь AWS Secret Manager вы просто меняете креды и вуаля — все контейнеры, которые используют эти креды получают новые.
Креды, да. Но конфиги — это не только креды
Я думаю, что в статье речь идет именно об архитектуре основанной на контейнерах. То есть каждый новый деплой — это абсолютно новый контейнер с новыми конфигами. То есть с контейнерами отпадает необходимость менять что-либо «на лету».
С контейнерами понятно, для этого в k8s есть ConfigMaps (про AWS ECS не знаю), но статья не только про контейнеры, но и про VMы. И хранить все конфиги в AWS Secret Manager не рационально. Это же скажется на производительности.
Смешно. Оно так уже работает. И лазить нужно именно по чиху — не подошёл закешированый пароль — лезим за новым и т.п.
У кого оно так работает?
А если это не пароль, а опция? Как ее кешировать?
Конфиги можно хранить в предназначенных для этого местах. Конфигмапы, секреты, внешние хранилища типа Consul и др.
В контейнерах и особенно в кубере или опенщифте локальные конфиги уже практически исчезают, и практически одновременно с такой миграцией уходят локальные логи.
Спасибо.

Было бы здорово, если бы вы предлагали какое проверенное на собственном опыте чтиво, по рекомендуемому стеку, по каждой из тем.

Оффициальная дока на 80% для всех этих тулз. не промахнетесь…
Главное кусочками делайте и прикладную задачу решайте!
Я лично не люблю эту ерунду с изучением каких-то вещей "прозапас" — это просто для галочки/бумажки и не работает.

Прикольно я вообще социализировался в яве, последнее время скорее архитект, но этот стек полностью тоже мой ;) Так я и DevOps ещё ;)
Сарказм немного ибо DevOps это не об стеке технологий

Sign up to leave a comment.