VS
Не знаю. Я же джун. Ты мне вопросы задаёшь как будто я …
ну ты сказал про решение, которое должно быть. Значит и вопрос к тебе.
Size: a a a
2020 March 16
DS
а что делать когда ты выкатили релиз 1.0, в нем нашли баг, выкатили фикс, потом еще фикс, потом еще фикс (1.03), а потом выяснили что в текущем релизме что-то сломано и в прошлом сломано и простой способ все поднять это откатить на 1.01?
ну вот в моем подходе есть простой способ это откатить. А вот когда тебе нужно ревертить туеву кучу коммитов в инфра репе, это не прстой способ
VS
Ситуации к сожалению случаются
VS
ну вот в моем подходе есть простой способ это откатить. А вот когда тебе нужно ревертить туеву кучу коммитов в инфра репе, это не прстой способ
тут еще вопрос что считается инфрой
DS
тут еще вопрос что считается инфрой
конкретно в нашей беседе. Инфрой считаются именно манифесты куба для того чтобы задеплоить сервис
як
это условный пример, вмест cronjob допиши что нравится
Я знаю только миграции БД. Любые другие сущности - ЛИШНИЕ здесь, IMHO
ЕО
Я исхожу из трёх принципов:
1. Принцип единой ответственности, т.е. за одну вещь в один момент времени должен отвечать один агент. Если ответственность передаётся, то механизмы её передачи должны быть читаемыми и прозрачными для всех участников процесса
2. Принцип повторяемости инфраструктуры, при наличии бекапов приложения инфраструктура уметь быть легко развернута повторно на новых мощностях
3. Принцип читаемости кода инфраструктуры, человек должен легко уметь прочитать код из 2 и сделать выводы о том как устроена инфраструктура приложения
1. Принцип единой ответственности, т.е. за одну вещь в один момент времени должен отвечать один агент. Если ответственность передаётся, то механизмы её передачи должны быть читаемыми и прозрачными для всех участников процесса
2. Принцип повторяемости инфраструктуры, при наличии бекапов приложения инфраструктура уметь быть легко развернута повторно на новых мощностях
3. Принцип читаемости кода инфраструктуры, человек должен легко уметь прочитать код из 2 и сделать выводы о том как устроена инфраструктура приложения
Ваш gitdb предлагает рушить 1 и начинает залезать на поляну 3 (ведёт в конце концов к принципу, объявленному @yamlcoder'ом, т.е. git repo окончательно становится нечитабельной версионной базой данных)
DS
Я знаю только миграции БД. Любые другие сущности - ЛИШНИЕ здесь, IMHO
еще раз это был условный пример. Я его просто выдумал, там нет конкретики. Замени cronjob на любой объект куба из своей головы, если хочешь я могу поправить свои сообщения, и заменю там cronjob на service если тебя это беспокоит
як
Это не возможно
Удалите его - он не облачный пацанчик! (Понаберут со своей nVidia-ей!) 🤗
LB
Я исхожу из трёх принципов:
1. Принцип единой ответственности, т.е. за одну вещь в один момент времени должен отвечать один агент. Если ответственность передаётся, то механизмы её передачи должны быть читаемыми и прозрачными для всех участников процесса
2. Принцип повторяемости инфраструктуры, при наличии бекапов приложения инфраструктура уметь быть легко развернута повторно на новых мощностях
3. Принцип читаемости кода инфраструктуры, человек должен легко уметь прочитать код из 2 и сделать выводы о том как устроена инфраструктура приложения
1. Принцип единой ответственности, т.е. за одну вещь в один момент времени должен отвечать один агент. Если ответственность передаётся, то механизмы её передачи должны быть читаемыми и прозрачными для всех участников процесса
2. Принцип повторяемости инфраструктуры, при наличии бекапов приложения инфраструктура уметь быть легко развернута повторно на новых мощностях
3. Принцип читаемости кода инфраструктуры, человек должен легко уметь прочитать код из 2 и сделать выводы о том как устроена инфраструктура приложения
чтение хелм темплейтов не сильно лучше голых ямлов. зато голые ямлы можно визуализировать как в каком-нибудь argocd для наглядности. и ни один способ не чтения инфра репы не даст знания об архитектуре приложения всё равно, так что 3. предлагаю исключить)
як
Нет, не нужно )
Это от стоимости интеграции зависит. Если не [не]нулевая - лучше хранить. Собирать по принципу Changelog - из истории запуска пайплайнов
ЕО
чтение хелм темплейтов не сильно лучше голых ямлов. зато голые ямлы можно визуализировать как в каком-нибудь argocd для наглядности. и ни один способ не чтения инфра репы не даст знания об архитектуре приложения всё равно, так что 3. предлагаю исключить)
Даст, несомненно
LB
Даст, несомненно
что он даст? расскажет как оно ходит в RDS? или откуда oauth токены забирает и кому отдает?
DS
Не знаю как у вас. У меня деплоет проект менеджер. Он точно не будет делать реверты в инфра репе для деплоя или отката. Видимо gitops не для моего кейса. Можно конечно автоматизировать это, но тут тоже нюансы и миллион костылей, когда тебе надо не просто ревертнуть, а откатить на -10 версий назад
як
чем плох? где то же надо хранить желаемое состояние. кто-то в last-applied-configuration, кто то в configmap. в гите самое удобное - есть уникальный идентификатор каждого состояния, можно метадату об успехах деплоя через git notes добавить, дифы, реверты, атомарные комиты чтоб гонки не устраивать,
У вас менеджеры лазят в git?
як
Оно тянет необходимость бекапа етсд и привет
Выкинь свой etcd!
LB
Не знаю как у вас. У меня деплоет проект менеджер. Он точно не будет делать реверты в инфра репе для деплоя или отката. Видимо gitops не для моего кейса. Можно конечно автоматизировать это, но тут тоже нюансы и миллион костылей, когда тебе надо не просто ревертнуть, а откатить на -10 версий назад
реверт это супер рабочий инструмент. можно перед ревертом 10 комитов попробовать "задеплоить тег", который попытается создать новый комит с желаемым состоянием, но не факт что будет идентичным
як
Начнёшь хранить стейты инфры в базе и вернёшься в мир заббикса и винды
Всю ветку прочитал и стало яснее.
LB
У вас менеджеры лазят в git?
менеджеры нет, не тулзы которыми они пользуются - почему б нет? впрочем нигде не видел деплоящих менеджеров
як
@yamlcoder
Вопрос свелся к тому что, сохранять ли инфу о совместимости версий репы кодовой с инфра репой. Если сохранять, то ифра репу можно хранить как сабмодуль или в прям в кодовой репе. Если нет, то я пока не понял, как решать свои проблемы, свзяанные с этим.
Вопрос свелся к тому что, сохранять ли инфу о совместимости версий репы кодовой с инфра репой. Если сохранять, то ифра репу можно хранить как сабмодуль или в прям в кодовой репе. Если нет, то я пока не понял, как решать свои проблемы, свзяанные с этим.
Посмотри на рутрекере OTUS свежий, там много зарелизили. В одной из серий ДЖВА ЧАСА РАССКАЗЫВАЮТ ПРО State