Интересно. А для чего вы его используете? Как на нем DevOps пайпланы писать?
У меня есть пайплайн в GitLab, в котором два уровня триггеров, потому что набралось 108 кластеров, а и есть лимит триггеров, потому их пришлось организовать так. Сначала идут триггеры среды, они создают триррегы кластеров, а они в свою очередь создают пайплан для отдельного кластера. И все это чистый YAML, и знаний программирования не надо.
Такое в Jenkins даже думать страшно. Насколько я помню TeamCity не далеко от Jenkins, там тоже DSL, и что-то сложное на нем подчас просто не напишешь. Могу ошибаться.
Я ничего не писал на С или Rust, поэтому даже особо сказать нечего. Тут каждый выбирает то, что ему больше нравится.
Мне Rust приглянулся тем, что у него самый высокий рейтинг "радости" разработчиков и что компилятор помогает находить и решать ошибки до исполнения. А как с этим дело в С?
Читал что уже в ядре Linux есть маленькая часть кода на Rust, так что думаю у него есть будущее. Не думаю, что матёрые разработчики ядра Linux абы кого к себе пустили.
С еще долго будет с нами, потому очень стабильный выбор.
Есть ещё путь поддержки редкого легаси кода и всяких Fortran. Ниша, но слышал там хорошо платят, а специалистов мало.
Согласен, когда перебор с переменами, не успеваешь продумать одно, как наваливается другое, а потом через неделю недоделанное первое дело даёт о себе знать и так попадаешь в порочный круг. Ещё достает, когда начинаешь рабочий день с четкого плана, а потом сразу всё идёт куда попало. Раньше меня это сильно беспокоило, но потом я понял, что рабочий день у меня нормированный, и я могу все это время либо решать чужие проблемы, либо свои задачи, но не все вместе. И как-то отпустило. Сроки можно и подвинуть, а вопрос о том, на что мое время будет лучше потрачено оставлю менеджерам.
Вот вы говорите что ООП и ФП противоестественны. А что в них такого? Не из пробирки же они вылезли. Как и все, они были рождены для решения проблем. И если эти проблемы Вам не знакомы, то и решение будет казаться чем-то странным.
Приведу пример. Работал в компании. Там было всего две среды - тест и прод. Чтобы развернуть два кластера БД, можно было написать скрипт для тест среды, потом его скопировать и поменять части под прод и будет два скрипта. Потом приходит требование сделать ещё один БД кластер в каждой среде. И тут начинаешь думать. По накатанной копировать скрипты и менять в них перенные или подумать, а чем же они отличаются и что в них одно и то же и вынести все разное отдельно, а все одинаковое вместе. Вот и получается абстракция. А скрипт становиться функцией от переменных, который в идеале должен приводить к кластеру БД.
Или а том же GitLab есть могучая функция extends, с помощью которой можно много чего упростить и сделать скрипт более компактным и понятным, а по сути это банальное наследование и композиция.
Вообще OOП зародился в Smalltalk в плоскости GUI и подразумевал обмен сообщениями между объектами, что ничего общего не имеет с тем же ООП в Java.
Думаю что True OOP - это сейчас Erlang. Гениальный язык и среда выполнения.
ФП - это уже из математики. Пока только помог чтобы осознать map/reduce ;) Монады вообще от лукавого.
Мне C нравиться тем, что на нём можно написать самую быструю прогорамму, но вот недавно я понят что можно ещё быстрее! ПЛИС - программируешь себе процессор, которые будет выполнять задачи быстрее любого кода, даже на ассемблере.
Вот думаю когда DevOps наскучит, разобраться в ПЛИС. Жаль там денег мало платят, но как хобби сойдёт.
Прочитав внимательно вашу статью. Полагаю что высокая ЗП и привела к выгоранию, поскольку приходилось её оправдывать сверхурочными часами, ну и к тому же перфекционизм, который тоже не дает покоя на работе. Еще вижу, что вам приходилось внедряться во много разных компаний и проектов где все было по разному, и вам сильно захотелось прийти к общему знаменателю и выбрать хоть какой-то плот стабильности в этом хаотичном мире ИТ.
Отчасти с вами соглашусь, каждый год выходят новые технологии, и уследить за ними уже не хватает времени и сил, но, вместе с тем, огромное количество технологий становятся не нужными, и только единицы становятся популярными и полезными.
Вот жил себе спокойной Terraform, и тут появился Pulumi. Мне начальство говорит, мол вон смотри, тут новый пацан на районе, как он тебе? А я говорю, что это тоже самое что и Terraform, только вам нужно учить какой-нибудь язык программирования, людей с опытом в ней нет, нужно организовывать модули и тд и тп, и начальство немного остывает. Но я его как-нибудь попробую, чтобы понять что это за зверь.
В деплоях на виртуалки ничего лучше Ansible еще не придумали, хотя активно пытаются.
БД потихоньку обрастают операторами для кубернетеса. Я был всегда против, но теперь я уже думаю, что это неизбежно и операторы уже дошли до стадии, когда ими можно реально пользоваться без хайпа.
CI/CD тут уже много шишек набито, и думаю что лучше GitLab ничего нет.
А чем вам не угодили контейнеры? По-моему это крутая технология, которая много чего упрощает.
В начале карьеры DevOps я был ближе к разработчикам и помогал им конфигурировать и деплоить приложения. Потом стал поддерживать и администрировать БД, и стал ближе к инфраструктуре. Потом случился Kubernetes и понадобилась помощь и там и там. Было интересно, да и до сих пор интересно, потому что простые пробеламы сменяются сложными и все глубже погружаешься в недры куба.
Потом настал AWS и GCP, стал учить Terraform и облака. Тоже интересно, там валом всего, чтобы мысленно поупражняться.
Я думаю, что у вас выгорание чистой воды от переработок и смен работы, и скорее всего коротких сроков, что у вас не осталось удовольствия от работы и технологий. Логичным был уход в тихую гавань вечного и могучего С. Я вот тоже подумаю, только про Rust ;)
Но пока к меня поле не пахано с PostgreSQL в Kubernetes, и Data Science стеком на Амазоне при помощи Pulumi ну и своим Kubernetes кластером в on prem.
На последок хочу поблагодарить вас за то, что поедлились своей опытом и болью. Надеюсь вы найдете себя в С, а DevOps останется страшным сном ;)
З.Ы. Считаю что дело не в DevOps, а в условиях труда, коротких сроках и стрессе.
Без hugepages раз в 10 в некоторых случаях медленнее запросы. Есть даже случай почти 100кратного ускорения для таблицы. Но это почти на уровне эзотерики, потому что я до сих пор не понимаю откуда такой прирост.
Хотелось бы посмотреть на отчеты, очень интересно.
К etcd конечно только через k8s API обращаться, это понятно.
По поводу менеджмента пользователей. Для сотрудников у нас Active Directory, и для него у меня в CI есть ежечасная задача, которая синхронизирует пользователей с БД посредством ldap2pg. Вот её можно повесить как cronJob прямо в кластере.
Я понимаю, что кубер операторы это не панацея и что они выполняют те же задачи, только в другой среде, и что одни проблемы заменяются на другие. Хай с ним, я достаточно работал с k8s чтобы уверенно поддерживать кластер.
Вы как-то обошли стороной GitOps, а я считаю, что это очень важный момент при поддержке сложных систем.
Меня больше беспокоит производительность PostgreSQL в контейнере, насколько она разная при прочих равных?
Чтобы сделать автоматическое переключение primary на standby - нужен Patroni, а для него нужен etcd. В том же etcd нужен менеджмент пользователей, мониторинг, бэкапы, обновления.
В том же кубере etcd - уже часть архитекторы k8s.
Ладно, отбросим Patroni. Чтобы сделать хотя бы простенький PostgreSQL кластер, без Terraform / Ansible уже никуда.
Ну для того же кубера без этого не обойтись, но намного проще установка, взять тот же RKE2 от Rancher.
Возьмём вопрос конфигурации. Вот она есть в репозитории, а что сейчас находиться на кластере? То ли это, или кто уже что-то задеплоил, и нужно копать в логах кто там что делал, или лезть на сервер и сравнивать. А тут запилил GitOps репозиторий, и если все зелёное, то значит конфиг в кластере соответсвует коду.
Та же оркестрация обновлений. Оператор все сделает в нужном порядке, а тебе останется откинуться на спинку табуретки и смотреть.
Это я ещё не говорю про бэкапы, восстановление, менеджмент пользователей. Для всего нужно писать скрипты рукам, если хочешь по уму.
Если хотя бы часть этих проблем сможет решить оператор, то почему бы не попробовать?
А какой у вас опыт? Сколько кластеров? Где крутятся, в какой обвязке работают?
У меня более 70 кластеров. Управлять ими через Terraform / Ansible уже изрядно надоело. К тому же хочется чтобы все было декларативно. К тому же кубер даёт удобный интерфейс для просмотра текущего статуса и лёгкий доступ к логам.
Я многие годы был против контейнеров, когда кластеров было менее 10. Сначала перешёл на докер и контейнер. И все работало хорошо. Теперь думаю может пора в кубере опробовать.
Вот я тоже прихожу к такому выводу. Пока вижу решение так. Выделить скажем 3 нода под PostgreSQL кластер. Установить nodeSelector, чтобы выбирал только их. Пробрасываю 5432 порт через сеть хоста. Создаю DNS A запись 3 нодами (возможно посредством external-dns). ??? PROFIT
Хотел бы поинтересоваться, предоставляете ли вы доступе к БД для приложений вне кластера, если да, то каким образом? Через load balancer?
Очень интересно. Ищу как бы можно было на отдельный нод в кластере повесить базу с прямым доступом по порту без посредников. nodePort не подходит, потому что хочу один и тот же порт использовать для разных кластеров БД.
Как балансировщики нагрузок узнают IP пода куда направлять трафик?
Более интересен overcommit по памяти. Видел сценарий, когда обычная команда grep убивала все поды на ноде посредством OOM killer. При memory overcommit = 0 такого не происходит.
Уточню по ресурсы подов. Допускаете ли разные request и limits по памяти или по процессору? Видел рекомендации, что по памяти request и limit должны быть одинаковые, а по процессору нужно иметь request (желательно целочисленный),а limit опустить.
По характеристикам она намного сильнее продуктов от Steam и Nintendo. Базовая версия имеет 4-нм игровой процессорAMD Ryzen Z1, 16 Гб оперативной и 256 Гб постоянной памяти (у Nintendo — 4 и 32 Гб, у Steam Deck — 16 и 64 Гб).
Может намного сильнее Switch, но не на много Deck, а сравнивать постоянную память на минимальной комплектации Deck совсем не красиво, или нужно все же было как-то подтвердить первый тезис?
Гаджет справляется с играми уровня Cyberpunk даже в 4K (хотя разрешение экрана тут 720p).
Гаджет не справляется с играми в 4K, это просто ложь.
Если бы мощь была самым важным критерием, пихали бы в них мобильные RTX, они бы плавили руки и работали три минуты.
В портативной консоли главное - это баланс производительности и автономности.
Возможен и такой порядок действий. При подозрении на уязвимость — сообщить администрации сайта без попыток использования уязвимости. В таком случае, конечно не будет удовлетворения от того, что узнал к чему же может эта уязвимость привести и не будет интересной истории для рассказа, зато благие намерения будут бескорыстными и не будут преследоваться законом.
Тут конечно можно поспекулировать на тему «а если проигнорируют» или «не поймут», и это может тоже доставить, а потом в сердцах все же довести возможную уязвимость до реальной и написать об этом статью, а ещё лучше инструкцию, чтобы неповадно было.
Спасибо за статью!
Интересно было бы узнать об опыте использования Pulimi а сравнении с Terraform.
Интересно. А для чего вы его используете? Как на нем DevOps пайпланы писать?
У меня есть пайплайн в GitLab, в котором два уровня триггеров, потому что набралось 108 кластеров, а и есть лимит триггеров, потому их пришлось организовать так. Сначала идут триггеры среды, они создают триррегы кластеров, а они в свою очередь создают пайплан для отдельного кластера. И все это чистый YAML, и знаний программирования не надо.
Такое в Jenkins даже думать страшно. Насколько я помню TeamCity не далеко от Jenkins, там тоже DSL, и что-то сложное на нем подчас просто не напишешь. Могу ошибаться.
Я ничего не писал на С или Rust, поэтому даже особо сказать нечего. Тут каждый выбирает то, что ему больше нравится.
Мне Rust приглянулся тем, что у него самый высокий рейтинг "радости" разработчиков и что компилятор помогает находить и решать ошибки до исполнения. А как с этим дело в С?
Читал что уже в ядре Linux есть маленькая часть кода на Rust, так что думаю у него есть будущее. Не думаю, что матёрые разработчики ядра Linux абы кого к себе пустили.
С еще долго будет с нами, потому очень стабильный выбор.
Есть ещё путь поддержки редкого легаси кода и всяких Fortran. Ниша, но слышал там хорошо платят, а специалистов мало.
Согласен, когда перебор с переменами, не успеваешь продумать одно, как наваливается другое, а потом через неделю недоделанное первое дело даёт о себе знать и так попадаешь в порочный круг. Ещё достает, когда начинаешь рабочий день с четкого плана, а потом сразу всё идёт куда попало. Раньше меня это сильно беспокоило, но потом я понял, что рабочий день у меня нормированный, и я могу все это время либо решать чужие проблемы, либо свои задачи, но не все вместе. И как-то отпустило. Сроки можно и подвинуть, а вопрос о том, на что мое время будет лучше потрачено оставлю менеджерам.
Вот вы говорите что ООП и ФП противоестественны. А что в них такого? Не из пробирки же они вылезли. Как и все, они были рождены для решения проблем. И если эти проблемы Вам не знакомы, то и решение будет казаться чем-то странным.
Приведу пример. Работал в компании. Там было всего две среды - тест и прод. Чтобы развернуть два кластера БД, можно было написать скрипт для тест среды, потом его скопировать и поменять части под прод и будет два скрипта. Потом приходит требование сделать ещё один БД кластер в каждой среде. И тут начинаешь думать. По накатанной копировать скрипты и менять в них перенные или подумать, а чем же они отличаются и что в них одно и то же и вынести все разное отдельно, а все одинаковое вместе. Вот и получается абстракция. А скрипт становиться функцией от переменных, который в идеале должен приводить к кластеру БД.
Или а том же GitLab есть могучая функция extends, с помощью которой можно много чего упростить и сделать скрипт более компактным и понятным, а по сути это банальное наследование и композиция.
Вообще OOП зародился в Smalltalk в плоскости GUI и подразумевал обмен сообщениями между объектами, что ничего общего не имеет с тем же ООП в Java.
Думаю что True OOP - это сейчас Erlang. Гениальный язык и среда выполнения.
ФП - это уже из математики. Пока только помог чтобы осознать map/reduce ;) Монады вообще от лукавого.
Мне C нравиться тем, что на нём можно написать самую быструю прогорамму, но вот недавно я понят что можно ещё быстрее! ПЛИС - программируешь себе процессор, которые будет выполнять задачи быстрее любого кода, даже на ассемблере.
Вот думаю когда DevOps наскучит, разобраться в ПЛИС. Жаль там денег мало платят, но как хобби сойдёт.
Прочитав внимательно вашу статью. Полагаю что высокая ЗП и привела к выгоранию, поскольку приходилось её оправдывать сверхурочными часами, ну и к тому же перфекционизм, который тоже не дает покоя на работе. Еще вижу, что вам приходилось внедряться во много разных компаний и проектов где все было по разному, и вам сильно захотелось прийти к общему знаменателю и выбрать хоть какой-то плот стабильности в этом хаотичном мире ИТ.
Отчасти с вами соглашусь, каждый год выходят новые технологии, и уследить за ними уже не хватает времени и сил, но, вместе с тем, огромное количество технологий становятся не нужными, и только единицы становятся популярными и полезными.
Вот жил себе спокойной Terraform, и тут появился Pulumi. Мне начальство говорит, мол вон смотри, тут новый пацан на районе, как он тебе? А я говорю, что это тоже самое что и Terraform, только вам нужно учить какой-нибудь язык программирования, людей с опытом в ней нет, нужно организовывать модули и тд и тп, и начальство немного остывает. Но я его как-нибудь попробую, чтобы понять что это за зверь.
В деплоях на виртуалки ничего лучше Ansible еще не придумали, хотя активно пытаются.
БД потихоньку обрастают операторами для кубернетеса. Я был всегда против, но теперь я уже думаю, что это неизбежно и операторы уже дошли до стадии, когда ими можно реально пользоваться без хайпа.
CI/CD тут уже много шишек набито, и думаю что лучше GitLab ничего нет.
А чем вам не угодили контейнеры? По-моему это крутая технология, которая много чего упрощает.
В начале карьеры DevOps я был ближе к разработчикам и помогал им конфигурировать и деплоить приложения. Потом стал поддерживать и администрировать БД, и стал ближе к инфраструктуре. Потом случился Kubernetes и понадобилась помощь и там и там. Было интересно, да и до сих пор интересно, потому что простые пробеламы сменяются сложными и все глубже погружаешься в недры куба.
Потом настал AWS и GCP, стал учить Terraform и облака. Тоже интересно, там валом всего, чтобы мысленно поупражняться.
Я думаю, что у вас выгорание чистой воды от переработок и смен работы, и скорее всего коротких сроков, что у вас не осталось удовольствия от работы и технологий. Логичным был уход в тихую гавань вечного и могучего С. Я вот тоже подумаю, только про Rust ;)
Но пока к меня поле не пахано с PostgreSQL в Kubernetes, и Data Science стеком на Амазоне при помощи Pulumi ну и своим Kubernetes кластером в on prem.
На последок хочу поблагодарить вас за то, что поедлились своей опытом и болью. Надеюсь вы найдете себя в С, а DevOps останется страшным сном ;)
З.Ы. Считаю что дело не в DevOps, а в условиях труда, коротких сроках и стрессе.
Без hugepages раз в 10 в некоторых случаях медленнее запросы. Есть даже случай почти 100кратного ускорения для таблицы. Но это почти на уровне эзотерики, потому что я до сих пор не понимаю откуда такой прирост.
Хотелось бы посмотреть на отчеты, очень интересно.
Кстати, HugePages уже поддерживаются в Kubernetes 1.29
К etcd конечно только через k8s API обращаться, это понятно.
По поводу менеджмента пользователей. Для сотрудников у нас Active Directory, и для него у меня в CI есть ежечасная задача, которая синхронизирует пользователей с БД посредством ldap2pg. Вот её можно повесить как cronJob прямо в кластере.
Я понимаю, что кубер операторы это не панацея и что они выполняют те же задачи, только в другой среде, и что одни проблемы заменяются на другие. Хай с ним, я достаточно работал с k8s чтобы уверенно поддерживать кластер.
Вы как-то обошли стороной GitOps, а я считаю, что это очень важный момент при поддержке сложных систем.
Меня больше беспокоит производительность PostgreSQL в контейнере, насколько она разная при прочих равных?
Пользовались ли вы CloudNativePG? Как оно?
Вот подскажите чем же они легче?
Чтобы сделать автоматическое переключение primary на standby - нужен Patroni, а для него нужен etcd. В том же etcd нужен менеджмент пользователей, мониторинг, бэкапы, обновления.
В том же кубере etcd - уже часть архитекторы k8s.
Ладно, отбросим Patroni. Чтобы сделать хотя бы простенький PostgreSQL кластер, без Terraform / Ansible уже никуда.
Ну для того же кубера без этого не обойтись, но намного проще установка, взять тот же RKE2 от Rancher.
Возьмём вопрос конфигурации. Вот она есть в репозитории, а что сейчас находиться на кластере? То ли это, или кто уже что-то задеплоил, и нужно копать в логах кто там что делал, или лезть на сервер и сравнивать. А тут запилил GitOps репозиторий, и если все зелёное, то значит конфиг в кластере соответсвует коду.
Та же оркестрация обновлений. Оператор все сделает в нужном порядке, а тебе останется откинуться на спинку табуретки и смотреть.
Это я ещё не говорю про бэкапы, восстановление, менеджмент пользователей. Для всего нужно писать скрипты рукам, если хочешь по уму.
Если хотя бы часть этих проблем сможет решить оператор, то почему бы не попробовать?
А какой у вас опыт? Сколько кластеров? Где крутятся, в какой обвязке работают?
У меня более 70 кластеров. Управлять ими через Terraform / Ansible уже изрядно надоело. К тому же хочется чтобы все было декларативно. К тому же кубер даёт удобный интерфейс для просмотра текущего статуса и лёгкий доступ к логам.
Я многие годы был против контейнеров, когда кластеров было менее 10. Сначала перешёл на докер и контейнер. И все работало хорошо. Теперь думаю может пора в кубере опробовать.
Вот я тоже прихожу к такому выводу. Пока вижу решение так.
Выделить скажем 3 нода под PostgreSQL кластер.
Установить nodeSelector, чтобы выбирал только их.
Пробрасываю 5432 порт через сеть хоста.
Создаю DNS A запись 3 нодами (возможно посредством external-dns).
???
PROFIT
Интересно, какая целевая аудитория этой ОС? В чем ее преимущества по сравнению с популярными дистрибутивами или перед теми же *BSD системами?
Спасибо за статью, вдохновили.
Хотел бы поинтересоваться, предоставляете ли вы доступе к БД для приложений вне кластера, если да, то каким образом? Через load balancer?
Очень интересно. Ищу как бы можно было на отдельный нод в кластере повесить базу с прямым доступом по порту без посредников. nodePort не подходит, потому что хочу один и тот же порт использовать для разных кластеров БД.
Спасибо за ответы. Успехов в развитии платформы!
Спасибо большое за ответ!
Обязательно почитаю остальные статьи.
Если можно, еще немного вопросов.
Как балансировщики нагрузок узнают IP пода куда направлять трафик?
Более интересен overcommit по памяти. Видел сценарий, когда обычная команда grep убивала все поды на ноде посредством OOM killer. При memory overcommit = 0 такого не происходит.
Уточню по ресурсы подов. Допускаете ли разные request и limits по памяти или по процессору? Видел рекомендации, что по памяти request и limit должны быть одинаковые, а по процессору нужно иметь request (желательно целочисленный),а limit опустить.
Используете ли Rancher?
Заранее благодарен;)
Во-первых, спасибо за статью. Очень познавательно, особенно когда сам не работал с кластерами более 1000 подов.
Есть ряд вопросов, если изволите.
Сколько нодов в кластере?
Все ли ноды одинаковы по ресурсам?
Какие спеки у нод? Кол-во ядер и памяти?
Сколько нод выделено для мастеров?
Есть ли ноды с тейнтами? Как используются?
Пользуетесь ли квотами неймспесов?
Используете ли какие-нибудь приложения для аудита? Например чтобы аннотации были, или чтобы много ресурсов не указывали?
Какие рекомендации можете дать по запросу ресуров контейнерами requests / limits?
Для таких больших кластеров, используете ли nodePort или IP подов для распределения нагрузки?
Разрешаете ли overcommit на самих нодах? Используете ли swap?
Очень интересно узнать ваш опыт.
Может намного сильнее Switch, но не на много Deck, а сравнивать постоянную память на минимальной комплектации Deck совсем не красиво, или нужно все же было как-то подтвердить первый тезис?
Гаджет не справляется с играми в 4K, это просто ложь.
Если бы мощь была самым важным критерием, пихали бы в них мобильные RTX, они бы плавили руки и работали три минуты.
В портативной консоли главное - это баланс производительности и автономности.
Тут конечно можно поспекулировать на тему «а если проигнорируют» или «не поймут», и это может тоже доставить, а потом в сердцах все же довести возможную уязвимость до реальной и написать об этом статью, а ещё лучше инструкцию, чтобы неповадно было.