Size: a a a

2020 March 16

GG

George Gaál in DevOps
я никуда не тороплюсь когда напьюсь тогда напьюсь
У тебя проблема или с долгом, или с архитектурой. Кто-то за кем-то не успевает. Или одменам или разрабам не хватает человеко-часов.
Я сомневаюсь в твоей верной оценке происходящего
источник

ЕО

Евгений Омельченко in DevOps
Dmitry Sergeev
ну вот реальный кейс. Давай еще раз
Есть одно и тоже приложение для разных платформ:
google, ios - юзеры во сновном из европы.
wechat, tiktok - китай
yahoojp - япония

Базы общие не нужны, бэкенды тоже. Самый просто способ - деплоить их отдельно. Нет никакой причины держать для них общий бэк и базу. Иначе проблем с тем что  у тебя бэкенды и база геораспределены по всему земному шару просто уйма. + у тебя нет всяких там AS и bgp anycast и тому подобного.

Просто не понимаю, почему когда ты идешь в сторону упрощения архитектуры, чтобы не страдать от сложных проблем это легаси?
Ну это же другой вопрос совершенно. Почему ты не спросил сразу — как деплоить в 5 кластеров одновременно?
источник

LB

Let Eat Bee in DevOps
для ясности  моя позиция: гитопс инфра репа это то откуда синкается состояние кластера. эта такая штука скажем одна на весь куб кластер или хотя б на одну команду и все её неймспейсы. там хранятся  отрендеренне манифесты, просто голые ямлы без никаких темплейтов или кастомайзов. туда комиты попадают из сиай разных реп, не важно что там они делают, но на выходе выдают пачку ямлов и комитят ее в инфра репу, затем у себя записывают комит инфра репы, что потом позволяет отследить деплои
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Евгений Омельченко
Слушайте, если вам нужно в 10 конфигурациях деплоить одно и то же приложение для прода, то это легаси. Бессмысленно обсуждать как применять практики, рассчитанные на микросервисную архитектуру, к такой конфигурации, тут несомненно нужны костыли
Да. С точки зрения бизнеса дешевле чтобы девопс допиливали как можно больше версий инфры под версии кода (последние-точно), если это не тупо миграции схемы в обе стороны
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Евгений Омельченко
Ну просто не будут работать смузи-практики для вас, нужно что-то своё придумывать, чтобы по максимуму сохранить декларативность, принцип single source of truth и single responsibility. Но скорее всего придётся чем-то пожертвовать
+
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Евгений Омельченко
Ну просто не будут работать смузи-практики для вас, нужно что-то своё придумывать, чтобы по максимуму сохранить декларативность, принцип single source of truth и single responsibility. Но скорее всего придётся чем-то пожертвовать
Убить десяток разрабов и сказать, что так и было. Или больше
источник

ЕО

Евгений Омельченко in DevOps
Let Eat Bee
для ясности  моя позиция: гитопс инфра репа это то откуда синкается состояние кластера. эта такая штука скажем одна на весь куб кластер или хотя б на одну команду и все её неймспейсы. там хранятся  отрендеренне манифесты, просто голые ямлы без никаких темплейтов или кастомайзов. туда комиты попадают из сиай разных реп, не важно что там они делают, но на выходе выдают пачку ямлов и комитят ее в инфра репу, затем у себя записывают комит инфра репы, что потом позволяет отследить деплои
А как этот комшар контролировать? Там будет человеконечитаемая каша
источник

ЕО

Евгений Омельченко in DevOps
Я навидался описаний инфры, которые не читаются человеком. Не хочу туда обратно
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Dmitry Sergeev
Ну такое вот требование не у легаси проекта. Хотелки бизнеса. Сказать бизнесу что у них неправильные хотелки ?)
Бизнесу нужно всё менять очень быстро, в т.ч. и "как было до". Ты - слабое звено и должен делать инфру, на которой будет работать и старый и новый код.
источник

LB

Let Eat Bee in DevOps
Евгений Омельченко
А как этот комшар контролировать? Там будет человеконечитаемая каша
что значит контролировать? каких действий хочется?
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Евгений Омельченко
Если бизнес хочет определённую архитектуру приложения, то это неправильные хотелки, да
+
источник

VS

Vladimir Smirnov in DevOps
Dmitry Sergeev
Ну такое вот требование не у легаси проекта. Хотелки бизнеса. Сказать бизнесу что у них неправильные хотелки ?)
Если хотелка определенно приведет к великой боли и в общем вредна для бизнеса. А что бизнес ее не понимает - твоя задача как инженера объяснить
источник

VS

Vladimir Smirnov in DevOps
бизнес вообще по хорошему не должен в это лезть, так-то
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Let Eat Bee
> нет.
> Если например ты откатываешь с v1.0.3 до v1.0.1 разреверт тебя откатит на v1.0.2


а куда 1.0.2 делось? решили что успешное, а потом предумали? тогда "откат" это реверт двух комитов. но в любом случае так как в инфра репе все намешано то откат только ревертами
Какое-то готовое решение должно быть для этого. Типа чётных (стабильных) и нечётных минорных версий. Мне лень гуглить.
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Евгений Омельченко
Ревертить через версию это безумие :)
Это явно не то место, где надо чинить. Возможно, ему так проще или не оставляют другого выхода
источник

DS

Dmitry Sergeev in DevOps
Евгений Омельченко
Ну это же другой вопрос совершенно. Почему ты не спросил сразу — как деплоить в 5 кластеров одновременно?
ну так суть же не изменилась. Как было куча разных весрий для разных платформ, так и осталась. + это простым образом решает проблему, когда нужно иметь разные версии для разных платформ
источник

VS

Vladimir Smirnov in DevOps
я никуда не тороплюсь когда напьюсь тогда напьюсь
Какое-то готовое решение должно быть для этого. Типа чётных (стабильных) и нечётных минорных версий. Мне лень гуглить.
а что делать когда ты выкатили релиз 1.0, в нем нашли баг, выкатили фикс, потом еще фикс, потом еще фикс (1.03), а потом выяснили что в текущем релизме что-то сломано и в прошлом сломано и простой способ все поднять это откатить на 1.01?
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Dmitry Sergeev
ну то есть с описанным подходом. У нас всегда одна версия. Откат максимум на одну назад. А если хотим откатить функционал, до старой версии, то прогеры пусть откатывают в коде и делают из него как бы новую версию но со старым фунционалом. У нас к сожелнию меня нахер пошлют с таким предложением, но мне оно нравится =)
Backporting. Но по-твоему не сделают (если ты не начальник/не CTO/не командует ими), их человеко-часы дороже стоят.
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Vladimir Smirnov
а что делать когда ты выкатили релиз 1.0, в нем нашли баг, выкатили фикс, потом еще фикс, потом еще фикс (1.03), а потом выяснили что в текущем релизме что-то сломано и в прошлом сломано и простой способ все поднять это откатить на 1.01?
Не знаю. Я же джун. Ты мне вопросы задаёшь как будто я …
источник

ЕО

Евгений Омельченко in DevOps
Я исхожу из трёх принципов:
1. Принцип единой ответственности, т.е. за одну вещь в один момент времени должен отвечать один агент. Если ответственность передаётся, то механизмы её передачи должны быть читаемыми и прозрачными для всех участников процесса
2. Принцип повторяемости инфраструктуры, при наличии бекапов приложения инфраструктура уметь быть легко развернута повторно на новых мощностях
3. Принцип читаемости кода инфраструктуры, человек должен легко уметь прочитать код из 2 и сделать выводы о том как устроена инфраструктура приложения
источник