Благодарю, очень дотошный обзор, одна из лучших статей с доходчивым описанием работы памяти (после https://www.linuxatemyram.com/). Про коварность WSS до этого не знал.
Это почти правда, за исключением того, что я ранее не покупал.
Вот ответ на этот вопрос от поддержки:
"4 апреля 2023 мы бесплатно пополнили вашу коллекцию 10 мультфильмами Хаяо Миядзаки. Просто так, чтобы порадовать вас. Не переживайте, мультфильмы будут доступны для просмотра и после 31 мая ?"
Прежде, чем писать подобный "вброс", стоит качественно изучить вопрос. Ничего в мире просто так не появляется. Есть причины и последствия. DevOps появился как естественное продолжение ускорения процессов разработки, когда один или несколько релизов в день стало нормой. Когда поддерживать и чинить что-то руками стало дурным тоном. Если рассуждать про этот вопрос всерьез, тогда уж надо брать шире и исследовать тему "почему же весь мир так сильно разгоняет разработку, доставку новых фич, моментальное исправление любых багов, неприятие простоя сервиса в 5 минут", и прочее, и прочее. Смотрите шире. То, что вы описали в статье, это просто плохие практики, с которыми вам не повезло столкнуться.
1) CI пайплайн просто пушит версию приложения сначала в dev, потом в stage, потом в prod - три разных kustomization.yaml файла. Версия генерится в момент сборки.
2) Для деплоя своих приложений хелм не используем. Для кластерной обвязки (мониторинг, логгинг, безопасность и тп), используем.
3) Вообще редки ситуации, когда нужно прямо в далекое прошлое откатываться, чаще всего это в виде "задеплоили, что-то пошло не так, откатили", и тут не надо много ума определить куда откатиться. У нас монорепа для флакса, там хранится состояние всех сред со списком версий всех текущих приложений.
4) Конечно используем. Любой упавший пайплайн о себе сообщает.
5) Хватает. Если честно, тут сложно ответить абстрактно, проще было бы на конкретном примере. Обычно есть какая-то проблема, она исследуется, дальше понимаем когда она возникла - в этой точке по времени будет какой-то коммит, который нужно откатить.
А что помешало сделать это через перезапуск стейджей пайплайнов? У вас монолитные пайплайны?
Перезапуск стейджей - это все равно ручное действие. Retries не сильно распространенная фича, насколько мне известно. На самом деле, я этот пункт немного не додумал, здесь не переход CI Ops на GitOps помог, а с helm на kustomize скорее, ибо с helm действительно часто приходилось сражаться.
Для меня вообще грань эта едва уловима, эти понятия схожи. Разве что IaC просто говорит нам хранить все в виде кода, а GitOps добавляет поверх этого еще автоматический процесс синхронизации с целевой средой.
Сразу скажу, буду субъективен, и части задач, которые вы решаете, у меня на данный момент просто нет.
1) CI часть упростилась, стадия с деплойментом свелась к `git push`
2) Нет дрифта конфигурации, любые изменения откатываются сами - это пожалуй один из самых больших жирных плюсов для меня
3) Удобнее использовать `git revert` как откат версии, это просто работает, не заходя в кластер
4) Мониторинг и отладка падений тоже нравится, объект HelmRelease всегда содержит логи и ошибки от вызова хелма, по логам контроллеров можно вообще всю историю событий установить для всех объектов
5) Не забываем про историю изменений через git history
Большинство из перечисленных вами пунктов - это единоразовая работа на старте. После этого об этом не беспокоишься. Такие вещи меня совсем не смущают, пока не надо что-либо повторять регулярно.
С CI Ops мне много приходилось делать руками в кластере, чтобы чинить состояние. С GitOps этого делать практически не приходится и всегда можно вернуться в заведомо работоспособную точку.
При всем уважении, этот ответ - это "подгон под ответ".
Ну то есть, при том, что я считаю, что GitOps проще, а вы - что CI Ops проще, мы тут можем сколь угодно долго спорить, но останемся при своем мнении.
Я находился на стороне CI Ops продолжительное время, была очень продуманная шаблонизация с инклюдами, были выверенные временем деплойменты через helm, прошел через все возможные грабли.
Но когда перешел на GitOps + FluxCD, я просто почувствовал насколько это проще.
Но опять же, откат нужно спроектировать в любой системе. Поэтому это не минус/плюс GitOps подхода. GitOps подход просто дает возможность делать это через `git revert`, и это приятно.
они еще добавляют один пункт, который я не упомянул
For that, your environment only needs access to your repository and image registry. That’s it. You don’t have to give your developers direct access to the environment.
но тут на самом деле разного рода разработчики бывают, не всем будет приятно совсем не видеть напрямую, что происходит с контейнерами
GitOps специфика для меня = никаких ручных действий с инфраструктурой, любое изменение - это git commit. И если инфраструктуру стереть в пепел, ее можно полностью восстановить исходя из состояния, которое зафиксировано на репозитории.
Почему в CI систему нельзя класть пользователя с доступом в кластер?
Не утверждаю, что нельзя. Я имею в виду, что в случае GitOps мы этого не делаем, и следственно не добавляем точку хранения доступа в инфраструктуру. А в случае CI Ops делаем. И это обычно и является тем пунктом, которые ставится GitOps подходу в плюсы.
Да, конечно, это идея фундаментальна. Но кажется мы ее слегка по-разному понимаем. Я понимаю так, что Git хранит описание желаемого состояния. GitOps инструменты помогают приводить целевую инфраструктуру к этому желаемому состоянию и следить за тем, чтобы не происходило отклонения от этого состояния.
Я бы сказал в общем, что с точки зрения GitOps не будет хорошей практикой держать разные среды в разных ветках и делать мержи между ними. Для GitOps среды принципиально различаются. Это не код приложения, который через ветки стабилизируется. Если проводить аналогию, тогда ветки с точки зрения GitOps могут означать разные кластера, то есть в одном кластере мы тестируем какие-то изменения, потом мержим в основную ветку и все раскатывается в продакшн кластер. И то это очень и очень с натяжкой, и даже так делать - это разложить себе грабли на будущее. Правильнее конфигурацию разных кластеров держать в разделенных директориях или репозиториях.
Благодарю, очень дотошный обзор, одна из лучших статей с доходчивым описанием работы памяти (после https://www.linuxatemyram.com/). Про коварность WSS до этого не знал.
Это почти правда, за исключением того, что я ранее не покупал.
Вот ответ на этот вопрос от поддержки:
"4 апреля 2023 мы бесплатно пополнили вашу коллекцию 10 мультфильмами Хаяо Миядзаки. Просто так, чтобы порадовать вас. Не переживайте, мультфильмы будут доступны для просмотра и после 31 мая ?"
Возможно я что-то не улавливаю, но где кнопка "Купить"? Или уже прикрыли этот аттракцион?
Хорошая статья, спасибо!
После этой фразы было бы здорово видеть "и вот, кстати, github issue, который мы завели на эту проблему". Или даже PR с решением.
Прежде, чем писать подобный "вброс", стоит качественно изучить вопрос. Ничего в мире просто так не появляется. Есть причины и последствия. DevOps появился как естественное продолжение ускорения процессов разработки, когда один или несколько релизов в день стало нормой. Когда поддерживать и чинить что-то руками стало дурным тоном. Если рассуждать про этот вопрос всерьез, тогда уж надо брать шире и исследовать тему "почему же весь мир так сильно разгоняет разработку, доставку новых фич, моментальное исправление любых багов, неприятие простоя сервиса в 5 минут", и прочее, и прочее. Смотрите шире. То, что вы описали в статье, это просто плохие практики, с которыми вам не повезло столкнуться.
1) CI пайплайн просто пушит версию приложения сначала в dev, потом в stage, потом в prod - три разных kustomization.yaml файла. Версия генерится в момент сборки.
2) Для деплоя своих приложений хелм не используем. Для кластерной обвязки (мониторинг, логгинг, безопасность и тп), используем.
3) Вообще редки ситуации, когда нужно прямо в далекое прошлое откатываться, чаще всего это в виде "задеплоили, что-то пошло не так, откатили", и тут не надо много ума определить куда откатиться. У нас монорепа для флакса, там хранится состояние всех сред со списком версий всех текущих приложений.
4) Конечно используем. Любой упавший пайплайн о себе сообщает.
5) Хватает. Если честно, тут сложно ответить абстрактно, проще было бы на конкретном примере. Обычно есть какая-то проблема, она исследуется, дальше понимаем когда она возникла - в этой точке по времени будет какой-то коммит, который нужно откатить.
Перезапуск стейджей - это все равно ручное действие. Retries не сильно распространенная фича, насколько мне известно. На самом деле, я этот пункт немного не додумал, здесь не переход CI Ops на GitOps помог, а с helm на kustomize скорее, ибо с helm действительно часто приходилось сражаться.
IaC безусловно входит в GitOps.
Для меня вообще грань эта едва уловима, эти понятия схожи. Разве что IaC просто говорит нам хранить все в виде кода, а GitOps добавляет поверх этого еще автоматический процесс синхронизации с целевой средой.
Ну я тоже потерялся. Тред начинался с секретов.
Сразу скажу, буду субъективен, и части задач, которые вы решаете, у меня на данный момент просто нет.
1) CI часть упростилась, стадия с деплойментом свелась к `git push`
2) Нет дрифта конфигурации, любые изменения откатываются сами - это пожалуй один из самых больших жирных плюсов для меня
3) Удобнее использовать `git revert` как откат версии, это просто работает, не заходя в кластер
4) Мониторинг и отладка падений тоже нравится, объект HelmRelease всегда содержит логи и ошибки от вызова хелма, по логам контроллеров можно вообще всю историю событий установить для всех объектов
5) Не забываем про историю изменений через git history
Большинство из перечисленных вами пунктов - это единоразовая работа на старте. После этого об этом не беспокоишься. Такие вещи меня совсем не смущают, пока не надо что-либо повторять регулярно.
С CI Ops мне много приходилось делать руками в кластере, чтобы чинить состояние. С GitOps этого делать практически не приходится и всегда можно вернуться в заведомо работоспособную точку.
При всем уважении, этот ответ - это "подгон под ответ".
Ну то есть, при том, что я считаю, что GitOps проще, а вы - что CI Ops проще, мы тут можем сколь угодно долго спорить, но останемся при своем мнении.
Я находился на стороне CI Ops продолжительное время, была очень продуманная шаблонизация с инклюдами, были выверенные временем деплойменты через helm, прошел через все возможные грабли.
Но когда перешел на GitOps + FluxCD, я просто почувствовал насколько это проще.
Пожалуй, это моя главная мысль в этой ветке.
Хорошая мысль, поддерживаю на 100%.
Но опять же, откат нужно спроектировать в любой системе. Поэтому это не минус/плюс GitOps подхода. GitOps подход просто дает возможность делать это через `git revert`, и это приятно.
не сильно, согласен, но немного поднимает
они еще добавляют один пункт, который я не упомянул
но тут на самом деле разного рода разработчики бывают, не всем будет приятно совсем не видеть напрямую, что происходит с контейнерами
А как не делать это в CIOps? Что имеется в виду?
GitOps специфика для меня = никаких ручных действий с инфраструктурой, любое изменение - это git commit. И если инфраструктуру стереть в пепел, ее можно полностью восстановить исходя из состояния, которое зафиксировано на репозитории.
Не утверждаю, что нельзя. Я имею в виду, что в случае GitOps мы этого не делаем, и следственно не добавляем точку хранения доступа в инфраструктуру. А в случае CI Ops делаем. И это обычно и является тем пунктом, которые ставится GitOps подходу в плюсы.
спасибо, приятно, что помнишь!
Да, конечно, это идея фундаментальна. Но кажется мы ее слегка по-разному понимаем. Я понимаю так, что Git хранит описание желаемого состояния. GitOps инструменты помогают приводить целевую инфраструктуру к этому желаемому состоянию и следить за тем, чтобы не происходило отклонения от этого состояния.
я не выстраивал такую структуру с мержем изменений
если ее действительно можно выстроить работоспособной, то значение внутри кластера в виде секретов - это действительно выход
моя мысль была про то, что не стоит бояться четырех разных репозиториев, если их существование имеет смысл, и принципы работы задокументированы
Приходите на мой доклад на devopsconf подискутировать вживую?
https://devopsconf.io/moscow/2023/abstracts/9937
Я бы сказал в общем, что с точки зрения GitOps не будет хорошей практикой держать разные среды в разных ветках и делать мержи между ними. Для GitOps среды принципиально различаются. Это не код приложения, который через ветки стабилизируется. Если проводить аналогию, тогда ветки с точки зрения GitOps могут означать разные кластера, то есть в одном кластере мы тестируем какие-то изменения, потом мержим в основную ветку и все раскатывается в продакшн кластер. И то это очень и очень с натяжкой, и даже так делать - это разложить себе грабли на будущее. Правильнее конфигурацию разных кластеров держать в разделенных директориях или репозиториях.