тестам то все равно какой у имеджа регион, мы точно про Docker registry говорим? это место откуда имеджи скачивают для запуска контейнеры. Мы тесты напротив энвайромента запускаем а там может быть сколько угодно регионов, за то что бы версия правильная была совсем другая часть отвечает которая GitOps называеться А это часть отвечает только за то чтобы одинаковые имеджи были во всех регионах где сервисы надо ранать- максимально близко, чтобы скорость загрузки имеджа была не 100мс а 2мс, это влияет на скорость старта контейнера. А в деплойментах каждого региона hash контейнера даже а не тег имеджа так что самому деплойменту, да и контейнеру неважно откуда он там береться если хеш совпадает.
реплицируеться уже протестированный образ(релиз). И конечно у него везде одинаковое содержимое и контрольная сумма; Это не часть CI/CD, это нечто что происходит между CI и CD - просто технический момент. Так сказать кэширование.
Просто вы свой образ ложите возможно в одно место и вам хватает. У нас очень важно время старта подов(их тясячи), потому нам приходиться заморачиваться и копировать их в каждый регион- поближе;
PS конечно у нас не один сервис, но на примере одного проще пояснить
да у вас там просто девопсов нормальных нету, вот отсюда и все беды, прод у них отстает от дева. Расскажите разработчикам про feature flags + версионирование API но они вам не поверят конечно. Если серьезно - динамические энвайроменты выглядят неплохо на первый взгляд, но они то не решают главной проблемы- после того как вы удалите эфемерный энвайромент- вам же надо будет проверять интеграцию и снова деплоить в общие энвайроменты, где остались все те же проблемы что были и до этого!
Автор может я вас расстрою, но в моих заметках нет графа и они не связанны с друг другом, из за чего возникает задвоение, или эффект "ах ты вот оно где было, чтож когда надо не мог найти!!!" Так что ВикиЛЛМ для меня гораздо удобнее, и если хранить все в гите и через коммиты вносить изменения заставить, то спокойно видно кто и когда был источником информации. Это я к тому что это ничуть не хуже памяти а лучше. Вот конспекты писать по тем материалам которые я читаю- я не брошу, но индексиерует и ищет по ним пусть ллм
модули сами по себе это чиcтый IaC - то есть тот же код просто в отдельной папке, строго говоря в терраформе даже центральная конфигурация являеться модулем(root module) - поэтому это точно не IaD.
helm charts - абсолютно не про инфраструктуру, не понял тут вашу мысль
Я не совсем понимаю что вы пытаетесь доказать: Что нет такого подхода? Что террагрант лучше?
Я просто рассказал как этот подход понимаю я, потому что в других местах это описывалось очень мудрено. Мой короткий рассказ был о том как добиться управляемости и расширяемости через стандартные инструменты Терраформ без посторонних тулов. Используя такой подход я создаю отлично читаемую конфигурацию, без террагранта и модулей; Не всегда и везде это сработает, и модули используються там где без них грустно.
Это рассказ о подходе, модули тут не играют особой роли- именно потому что они в нашем случае это код, а подход предпологает отделение данных и управление именно через данные. Пример неправильного на мой взгляд использования конфигураций когда пытаються управлять конфигурацией прямо в коде, нечто вроде:
Не ищите здесь прорыва, это просто рассказ о том как эфектино управлять кодом, варианты всегда есть, никто не навязвает единственный подход, у нас в довольно больших масштабах это подход работает отлично.
Выгода достигаеться от наличия в гите множества плоских конфигов в которых только флаги или переменнные. Если вы используете GitOps - это здорово помогает автоматизировать все.
Просто представьте что терраформ для вас черная коробка- и все что вам надо знать - для создания нового кластера кубернетеса в новом регионе вам надо скопировать один yaml файл и отредактировать его, сохранить- и все остальное выполниться без вас. Еще раз этот файл не содержит код, а только кастомизацию в виде переменных и флагов.
Вы просто смотрите с колокольни разработчика, и как для молотка все в мире гвозди, то и для девелопера все задачи это про немедленное и жесточайшее написание кода. Отступление законченно.
Я рискну предположить что проблемы со скрамом и канбаном проистекают из проблем с планированием. Если у вас канбан, то все задачи должны быть одинакового размера, иначе ритмичности работы вы не добьетесь. И вот тут и прячеться дьявол, ибо это довольно сложная сама по себе задача, грамотно разбить сложный таск на допустим 6 «стандартных» которые можно сделать за день и протестировать за день.
В скраме задачи могут быть любого размера, но и там проблема с эстимейтвми.
Грамотное среднесрочное планирование и многократное разбиение тасков на более мелкие отнимает много времени и сил, и потому очень непопулярно у команд - ну все и так же ясно, погнали!
То что вы описываете проблемы менеджмента, а не инфраструктуры. У нас сертификаты обновляет cert-manager. Мы вообще его на let's encrypt настроили и ничего не платим за сертификаты- все хорошо уже 2 года. Это решение спокойно маштабируется на все кластера централизованно или в виде шаблона.
Но повторюсь - 200 автономных команд на базе платформы которой все равно управляет инфраструктурная команда - вполне способны работать. Никто не говорит, что оно само заработает. Да много чего надо допиливать.
Но я опровергал ваше заявление о том что ваш солюшен дешевле облачных решений. По практическому опыту- самопилные вещи всегда дороже. Да иногда это оправданно, но не дешевле чем взять готовое и допилить.
@makc9I да я пишу в 2014 год )) Вы в курсе что во всем мире перерабатывается только около 3% батареек- их переработку трудно автоматизировать, и это делает ее невыгодной.
тестам то все равно какой у имеджа регион, мы точно про Docker registry говорим? это место откуда имеджи скачивают для запуска контейнеры. Мы тесты напротив энвайромента запускаем а там может быть сколько угодно регионов, за то что бы версия правильная была совсем другая часть отвечает которая GitOps называеться
А это часть отвечает только за то чтобы одинаковые имеджи были во всех регионах где сервисы надо ранать- максимально близко, чтобы скорость загрузки имеджа была не 100мс а 2мс, это влияет на скорость старта контейнера.
А в деплойментах каждого региона hash контейнера даже а не тег имеджа так что самому деплойменту, да и контейнеру неважно откуда он там береться если хеш совпадает.
реплицируеться уже протестированный образ(релиз). И конечно у него везде одинаковое содержимое и контрольная сумма;
Это не часть CI/CD, это нечто что происходит между CI и CD - просто технический момент. Так сказать кэширование.
Просто вы свой образ ложите возможно в одно место и вам хватает. У нас очень важно время старта подов(их тясячи), потому нам приходиться заморачиваться и копировать их в каждый регион- поближе;
PS конечно у нас не один сервис, но на примере одного проще пояснить
да у вас там просто девопсов нормальных нету, вот отсюда и все беды, прод у них отстает от дева. Расскажите разработчикам про feature flags + версионирование API но они вам не поверят конечно.
Если серьезно - динамические энвайроменты выглядят неплохо на первый взгляд, но они то не решают главной проблемы- после того как вы удалите эфемерный энвайромент- вам же надо будет проверять интеграцию и снова деплоить в общие энвайроменты, где остались все те же проблемы что были и до этого!
Автор может я вас расстрою, но в моих заметках нет графа и они не связанны с друг другом, из за чего возникает задвоение, или эффект "ах ты вот оно где было, чтож когда надо не мог найти!!!" Так что ВикиЛЛМ для меня гораздо удобнее, и если хранить все в гите и через коммиты вносить изменения заставить, то спокойно видно кто и когда был источником информации. Это я к тому что это ничуть не хуже памяти а лучше.
Вот конспекты писать по тем материалам которые я читаю- я не брошу, но индексиерует и ищет по ним пусть ллм
Нельзя ли озвучить причины почему не подошли стандартные подходы?
Маленький бэкенд
главное не размер, а как ты пользуешься этим бекендом
модули сами по себе это чиcтый IaC - то есть тот же код просто в отдельной папке, строго говоря в терраформе даже центральная конфигурация являеться модулем(root module) - поэтому это точно не IaD.
helm charts - абсолютно не про инфраструктуру, не понял тут вашу мысль
Я не совсем понимаю что вы пытаетесь доказать:
Что нет такого подхода?
Что террагрант лучше?
Я просто рассказал как этот подход понимаю я, потому что в других местах это описывалось очень мудрено.
Мой короткий рассказ был о том как добиться управляемости и расширяемости через стандартные инструменты Терраформ без посторонних тулов.
Используя такой подход я создаю отлично читаемую конфигурацию, без террагранта и модулей; Не всегда и везде это сработает, и модули используються там где без них грустно.
Это рассказ о подходе, модули тут не играют особой роли- именно потому что они в нашем случае это код, а подход предпологает отделение данных и управление именно через данные. Пример неправильного на мой взгляд использования конфигураций когда пытаються управлять конфигурацией прямо в коде, нечто вроде:
Не ищите здесь прорыва, это просто рассказ о том как эфектино управлять кодом, варианты всегда есть, никто не навязвает единственный подход, у нас в довольно больших масштабах это подход работает отлично.
Выгода достигаеться от наличия в гите множества плоских конфигов в которых только флаги или переменнные. Если вы используете GitOps - это здорово помогает автоматизировать все.
Просто представьте что терраформ для вас черная коробка- и все что вам надо знать - для создания нового кластера кубернетеса в новом регионе вам надо скопировать один yaml файл и отредактировать его, сохранить- и все остальное выполниться без вас. Еще раз этот файл не содержит код, а только кастомизацию в виде переменных и флагов.
Пишу вам из 2025 года, на луну никто так и не полетел, не переводите им никаких денег, купите лучше завод по производству масок медицинских
Вы просто смотрите с колокольни разработчика, и как для молотка все в мире гвозди, то и для девелопера все задачи это про немедленное и жесточайшее написание кода. Отступление законченно.
Я рискну предположить что проблемы со скрамом и канбаном проистекают из проблем с планированием. Если у вас канбан, то все задачи должны быть одинакового размера, иначе ритмичности работы вы не добьетесь. И вот тут и прячеться дьявол, ибо это довольно сложная сама по себе задача, грамотно разбить сложный таск на допустим 6 «стандартных» которые можно сделать за день и протестировать за день.
В скраме задачи могут быть любого размера, но и там проблема с эстимейтвми.
Грамотное среднесрочное планирование и многократное разбиение тасков на более мелкие отнимает много времени и сил, и потому очень непопулярно у команд - ну все и так же ясно, погнали!
Горный Куй всяко лучше
Вобщем не хочу расстраивать, но как раз по законам физики - тормозной путь не зависит от массы авто
Чето ходят слухи что Бетельгейзе все таки поплахело
Это когда капитализация влияла на умственные способности директоров? Ну чтобы их мнения возводить в императив?
Ну резковато, но по делу
а где я говорил, что там что-то не так?
То что вы описываете проблемы менеджмента, а не инфраструктуры. У нас сертификаты обновляет cert-manager. Мы вообще его на let's encrypt настроили и ничего не платим за сертификаты- все хорошо уже 2 года. Это решение спокойно маштабируется на все кластера централизованно или в виде шаблона.
Но повторюсь - 200 автономных команд на базе платформы которой все равно управляет инфраструктурная команда - вполне способны работать. Никто не говорит, что оно само заработает. Да много чего надо допиливать.
Но я опровергал ваше заявление о том что ваш солюшен дешевле облачных решений. По практическому опыту- самопилные вещи всегда дороже.
Да иногда это оправданно, но не дешевле чем взять готовое и допилить.
@makc9I да я пишу в 2014 год )) Вы в курсе что во всем мире перерабатывается только около 3% батареек- их переработку трудно автоматизировать, и это делает ее невыгодной.
https://www.adobe.com/products/photoshop/online.html