модули сами по себе это чиcтый IaC - то есть тот же код просто в отдельной папке, строго говоря в терраформе даже центральная конфигурация являеться модулем(root module) - поэтому это точно не IaD.
helm charts - абсолютно не про инфраструктуру, не понял тут вашу мысль
Я не совсем понимаю что вы пытаетесь доказать: Что нет такого подхода? Что террагрант лучше?
Я просто рассказал как этот подход понимаю я, потому что в других местах это описывалось очень мудрено. Мой короткий рассказ был о том как добиться управляемости и расширяемости через стандартные инструменты Терраформ без посторонних тулов. Используя такой подход я создаю отлично читаемую конфигурацию, без террагранта и модулей; Не всегда и везде это сработает, и модули используються там где без них грустно.
Это рассказ о подходе, модули тут не играют особой роли- именно потому что они в нашем случае это код, а подход предпологает отделение данных и управление именно через данные. Пример неправильного на мой взгляд использования конфигураций когда пытаються управлять конфигурацией прямо в коде, нечто вроде:
Не ищите здесь прорыва, это просто рассказ о том как эфектино управлять кодом, варианты всегда есть, никто не навязвает единственный подход, у нас в довольно больших масштабах это подход работает отлично.
Выгода достигаеться от наличия в гите множества плоских конфигов в которых только флаги или переменнные. Если вы используете GitOps - это здорово помогает автоматизировать все.
Просто представьте что терраформ для вас черная коробка- и все что вам надо знать - для создания нового кластера кубернетеса в новом регионе вам надо скопировать один yaml файл и отредактировать его, сохранить- и все остальное выполниться без вас. Еще раз этот файл не содержит код, а только кастомизацию в виде переменных и флагов.
Вы просто смотрите с колокольни разработчика, и как для молотка все в мире гвозди, то и для девелопера все задачи это про немедленное и жесточайшее написание кода. Отступление законченно.
Я рискну предположить что проблемы со скрамом и канбаном проистекают из проблем с планированием. Если у вас канбан, то все задачи должны быть одинакового размера, иначе ритмичности работы вы не добьетесь. И вот тут и прячеться дьявол, ибо это довольно сложная сама по себе задача, грамотно разбить сложный таск на допустим 6 «стандартных» которые можно сделать за день и протестировать за день.
В скраме задачи могут быть любого размера, но и там проблема с эстимейтвми.
Грамотное среднесрочное планирование и многократное разбиение тасков на более мелкие отнимает много времени и сил, и потому очень непопулярно у команд - ну все и так же ясно, погнали!
То что вы описываете проблемы менеджмента, а не инфраструктуры. У нас сертификаты обновляет cert-manager. Мы вообще его на let's encrypt настроили и ничего не платим за сертификаты- все хорошо уже 2 года. Это решение спокойно маштабируется на все кластера централизованно или в виде шаблона.
Но повторюсь - 200 автономных команд на базе платформы которой все равно управляет инфраструктурная команда - вполне способны работать. Никто не говорит, что оно само заработает. Да много чего надо допиливать.
Но я опровергал ваше заявление о том что ваш солюшен дешевле облачных решений. По практическому опыту- самопилные вещи всегда дороже. Да иногда это оправданно, но не дешевле чем взять готовое и допилить.
@makc9I да я пишу в 2014 год )) Вы в курсе что во всем мире перерабатывается только около 3% батареек- их переработку трудно автоматизировать, и это делает ее невыгодной.
так а почему знакомые и гугл должны помогать? Это какой-то ложный посыл- раз гугл и знакомые не помогли, то виноват не я. Вы не справились, никто не виноват кроме вас.
[1] постоянно этим занимаемся, это вполне нормальные сроки, если приложений много, не вижу вообще ничего плохого в том, чтобы не ломая ничего переехать постепенно. Просто новые проекты не разрешают создавать по старому и все за 2 года максимум переезжает.
[2] Контроль это вообще административное понятие, у вас же руководители способны контролировать инженеров? Надеюсь что да. Вот до руководителей доноситься это правило, они доносят до инжинеров. Со второй стороны это как раз вашей структурой и должно контролироваться- в виде ассесмента/валидации КАЖДОГО нового сервиса. У нас это поставлено на поток, если ты поставил сервис в прод без валидации и добавления его в backstage- это равносильно запуску биткойн генератора по последствиям.
[3] ИБ не религия, с ними всегда можно договориться исходя из реалий бизнеса. Нужно вам получить определенный сертификат в этой области- смотрите что не попадает - идете к ИБ и к клауд провайдеру и разговариваете. Все эти стороны заинтересованы договориться. Да клауд провайдер может пилить сервис в нужную вам сторону дольше чем вы- например год. Но вы не единственные клиенты которые сталкиваются с такой проблемой, а провайдер держит нос по ветру и критичные вещи он должен быстро исправлять, ведь он то сам как то это сертификат получил ))
[4] Смотря что понимать под доступностью. В общем случае - использовать не один регион а 2-3, реплики БД, запасной провайдер. 3 региона у Яндекса уже надежнее ваших двух датацентров. Их тупо 3, а может быть 10 за совсем небольшие деньги.
Ну и люди всегда будут ругать любой солюшен, какой бы он не был. Просто когда он сделан по канонам, гораздо больше людей понимает почему так, и не нужно тратить время на обьяснения
Так это не обязательно должно быть через клауд, графана и ELK которую вы крутите как сервис - вполне справятся. Большая часть тут должна быть не на вас а на командах которые отвечают за сервис, вы только предоставляете платформу.
Прелесть не теряется- вы допиливаете только небольшие части. У нас сами команды допиливают мелкие opensource сервисы никто никаких заявок в инфра подразделение не пишет. Зачем кудато писать если большинство сервисов это docker image? Поменял код - запустил и дальше работаешь.
Я ответил выше в треде, но про провайдер специфик штучки скажу так - очень сильно стоит подумать, а так ли нужны они? Вспомните MongoDB- в период популярности на его базе че только не пилили, а сейчас я даже встречал lock на использование монго на уровне дизайна.
Например вот без секьюрити фич вам не обойтись, у каждого провайдера нетворк и секьюрити свой. Но опять же, снаружи можно сделать все по дефолту, а внутри кластера Кубернетес использовать его инструменты, и это обычно везде работает. Если вы не решите использовать AWS EKS Pod security group конечно.
Маленький бэкенд
главное не размер, а как ты пользуешься этим бекендом
модули сами по себе это чи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
так а почему знакомые и гугл должны помогать? Это какой-то ложный посыл- раз гугл и знакомые не помогли, то виноват не я. Вы не справились, никто не виноват кроме вас.
может стоит освоить Ansible?
[1] постоянно этим занимаемся, это вполне нормальные сроки, если приложений много, не вижу вообще ничего плохого в том, чтобы не ломая ничего переехать постепенно. Просто новые проекты не разрешают создавать по старому и все за 2 года максимум переезжает.
[2] Контроль это вообще административное понятие, у вас же руководители способны контролировать инженеров? Надеюсь что да. Вот до руководителей доноситься это правило, они доносят до инжинеров.
Со второй стороны это как раз вашей структурой и должно контролироваться- в виде ассесмента/валидации КАЖДОГО нового сервиса. У нас это поставлено на поток, если ты поставил сервис в прод без валидации и добавления его в backstage- это равносильно запуску биткойн генератора по последствиям.
[3] ИБ не религия, с ними всегда можно договориться исходя из реалий бизнеса. Нужно вам получить определенный сертификат в этой области- смотрите что не попадает - идете к ИБ и к клауд провайдеру и разговариваете. Все эти стороны заинтересованы договориться. Да клауд провайдер может пилить сервис в нужную вам сторону дольше чем вы- например год. Но вы не единственные клиенты которые сталкиваются с такой проблемой, а провайдер держит нос по ветру и критичные вещи он должен быстро исправлять, ведь он то сам как то это сертификат получил ))
[4] Смотря что понимать под доступностью. В общем случае - использовать не один регион а 2-3, реплики БД, запасной провайдер. 3 региона у Яндекса уже надежнее ваших двух датацентров. Их тупо 3, а может быть 10 за совсем небольшие деньги.
[5]
https://cloud.yandex.ru/services/managed-redis
https://cloud.vk.com/databases/redis/
Ну и люди всегда будут ругать любой солюшен, какой бы он не был. Просто когда он сделан по канонам, гораздо больше людей понимает почему так, и не нужно тратить время на обьяснения
Так это не обязательно должно быть через клауд, графана и ELK которую вы крутите как сервис - вполне справятся.
Большая часть тут должна быть не на вас а на командах которые отвечают за сервис, вы только предоставляете платформу.
Прелесть не теряется- вы допиливаете только небольшие части.
У нас сами команды допиливают мелкие opensource сервисы никто никаких заявок в инфра подразделение не пишет.
Зачем кудато писать если большинство сервисов это docker image?
Поменял код - запустил и дальше работаешь.
Я ответил выше в треде, но про провайдер специфик штучки скажу так - очень сильно стоит подумать, а так ли нужны они?
Вспомните MongoDB- в период популярности на его базе че только не пилили, а сейчас я даже встречал lock на использование монго на уровне дизайна.
Например вот без секьюрити фич вам не обойтись, у каждого провайдера нетворк и секьюрити свой. Но опять же, снаружи можно сделать все по дефолту, а внутри кластера Кубернетес использовать его инструменты, и это обычно везде работает. Если вы не решите использовать AWS EKS Pod security group конечно.
Каждый сам себе злобный буратино.