Не могу уловить зачем этот велосипед: если у Вас вмки, то вы же все равно провижините конфигурацию веб сервера конфигурейшен менеджмент тулой типо ансибл, так пусть он и займётся секретами в связки с ансибл-вольт. Мы и деплоим все через ансибл к слову, очень даже удобно.
Если у вас микросервисы, то там вообще проблем нет: секреты кубернетиса, hashicorp vault и много-много всего.
Не маловажно отметить, что решить проблему секретов можно и средствами самого ci/cd.
Если подитожить: не изобретайте велосипед, обратитесь "DevOps инженеру" это его работа в конце-то концов.)
Полностью Вас поддерживаю. Мне вообще не понятен нынешний тренд в мире DevOps. Все упорно игнорируют Jenkins, а он настоящий швейцарский нож, который может все в сравнении с тем же gitlab ci. Огромное комьюнити, все в открытом доступе - бери и пользуйся. Гибкий, удобный, бесплатный, расширяемый, что ещё нужно.
Используем минио в проде уже почти два года. Multi-node, multi-drive. Все в кубере. В качестве csi - host path ноды.
Были и вылеты нод и вылеты дисков. Проблем не было от слова совсем. Если все сделано по документации minio, то даже вмешательство инженера не понадобится. Ну или нам очень везёт)
Варианты? Да их масса, сперва не плохо бы использовать готовые решения типа wal-g например, а не городить свои скрипты. И складывать бэкапы в s3. Вызывать wal-g из ci в контейнере например. Креды или в vault, или можно через ansible vault если не хочется возится с контейнерами. В целом вариантов масса.
Я лишь хотел сказать, что предложенное решение совсем не продпкшен реди для 2023 года.
Работаю с терраформ достаточно давно и довольно много и могу с уверенностью сказать, что провайдер для прохмох это худшее, что мне довелось видеть. Примитивные вещи да работают, но как начинаешь углубляться сплошные косяки. Он реально может завалить инфрастуркту при попытке глубокой автоматизации. Не все вещи работают как хотелось бы. Документация часто не соответствует реальности. Эти танцы с дисками когда создаёшь новую ВМ из темплита. Вообщем у меня за год впечатление скорее негативное
Господи, сколько советчиком. Все человек правильно делает. Тот кто предлагает кубспрей, а вы пробовали поддерживать такое решение в большом кластере и распределенной команде специалистов разного уровня? Врятли есть что-то страшнее этого. Коробочные решения это тоже такое себе ведь вы теряете в гибкости и ресурсах, тот же ранчер содержит больше элементов которые не нужны зачастую. Вот хард Вэй это отличное начало чтобы разобраться. Касаемо лонгхорна - он хорош, но линстор вроде как быстрее и надёжнее. Нфска на воркере это совсем не очень. Но чтобы понять, что такое сторэджкласс достаточно.
Но все это очень просты темы. Все пишут о том как развернуть кластер, но никто не пишет о том как например обновить сертификаты кластера, особенно если изменился рут са. Я имею ввиду именно внутренние серты кластера.
Увы все это становится не столь радужно если вы используете онпремис инфраструктуру на VMw или Openstack. Готовых модулей для них почти нет. А terragrant по своей сути это просто оркестратор терраформ модулей. Придется написать уйму модулей для своей инфраструктуры. Но предварительно нужно будет еще обсудить и разработать концепт написания этих самых кастомных модулей. А потом еще и танцы с импортами и это все со скудную документацию, как уде сказал прошлый комметатор- желание переезжать на террагрант отпадает. Документация увы за годы лучше не стала.
Как вступительное слово для лекции по IaC может и сойдет, но есть вопросики:
Ansible, chef это не процедурные языки, а инструменты использующие декларативный языки разметки. Так и не понял почему это они стали процедурными если они тоже описывают желаемое состояние.
Не понял почему terraform стал immutable. Мне кажется что вообще нельзя применять здесь такие понятия как mutable/immutable. Терраформ изменяет существующие ресурсы, а вот если ресурс можно изменить только пересоздание, то он его пересоздает, но это уже зависит от провайдера, ресурса и клауда.
Chef можно использовать как в master так и в masterless варианте.
Стоило бы отметить, что терраформ использует свой HCL. Вообще колонка синтаксис не совсем понятна.
Также стоит отметить что Ansible использует под капотом python, как chef ruby что позволяет им быть достаточно гибкими и расширять функционал с помощью самописных плагинов и модулей.
И так далее по списку)))
Но за статью спасибо, уверен кому-то она будет полезной.
Неплохо было бы еще услышать почему именно traefik, a не haproxy или nginx.
А поделитесь пожалуйста опытом, а то у меня эта связка не завелась.
Не могу уловить зачем этот велосипед: если у Вас вмки, то вы же все равно провижините конфигурацию веб сервера конфигурейшен менеджмент тулой типо ансибл, так пусть он и займётся секретами в связки с ансибл-вольт. Мы и деплоим все через ансибл к слову, очень даже удобно.
Если у вас микросервисы, то там вообще проблем нет: секреты кубернетиса, hashicorp vault и много-много всего.
Не маловажно отметить, что решить проблему секретов можно и средствами самого ci/cd.
Если подитожить: не изобретайте велосипед, обратитесь "DevOps инженеру" это его работа в конце-то концов.)
Полностью Вас поддерживаю. Мне вообще не понятен нынешний тренд в мире DevOps. Все упорно игнорируют Jenkins, а он настоящий швейцарский нож, который может все в сравнении с тем же gitlab ci. Огромное комьюнити, все в открытом доступе - бери и пользуйся. Гибкий, удобный, бесплатный, расширяемый, что ещё нужно.
Простите, но чем вам не угодил постгрес в кластере. У нас два года уже в проде,в качестве sci ceph - полет нормальный.
Для себя уже давно сделал вывод, что для небольших инсталяций и кластеров более чем достаточно proxmox, для всего остального openstack.
Используем минио в проде уже почти два года. Multi-node, multi-drive. Все в кубере. В качестве csi - host path ноды.
Были и вылеты нод и вылеты дисков. Проблем не было от слова совсем. Если все сделано по документации minio, то даже вмешательство инженера не понадобится. Ну или нам очень везёт)
В целом все чётко и по делу. Как же жаль, что не все это понимают.
Спасибо. Было приятно читать.
Варианты? Да их масса, сперва не плохо бы использовать готовые решения типа wal-g например, а не городить свои скрипты. И складывать бэкапы в s3. Вызывать wal-g из ci в контейнере например. Креды или в vault, или можно через ansible vault если не хочется возится с контейнерами. В целом вариантов масса.
Я лишь хотел сказать, что предложенное решение совсем не продпкшен реди для 2023 года.
Ещё бы пару слов о том, как все это добро использовать с SSR на nuxt например, было бы вообще здорово. А так огромное спасибо - было полезно.
Ох, да((( Сейчас бы в 23 году создавать бэкапы дампом, да ещё и запускать из крона и хранить все креды в открытом виде. Бегите из этой компании.!
Ух, спасибо Вам огромное за проделанную работу. Прям оооочень полезные вещи. Держите в курсе)
Работаю с терраформ достаточно давно и довольно много и могу с уверенностью сказать, что провайдер для прохмох это худшее, что мне довелось видеть. Примитивные вещи да работают, но как начинаешь углубляться сплошные косяки. Он реально может завалить инфрастуркту при попытке глубокой автоматизации. Не все вещи работают как хотелось бы. Документация часто не соответствует реальности. Эти танцы с дисками когда создаёшь новую ВМ из темплита. Вообщем у меня за год впечатление скорее негативное
Господи, сколько советчиком. Все человек правильно делает. Тот кто предлагает кубспрей, а вы пробовали поддерживать такое решение в большом кластере и распределенной команде специалистов разного уровня? Врятли есть что-то страшнее этого. Коробочные решения это тоже такое себе ведь вы теряете в гибкости и ресурсах, тот же ранчер содержит больше элементов которые не нужны зачастую. Вот хард Вэй это отличное начало чтобы разобраться. Касаемо лонгхорна - он хорош, но линстор вроде как быстрее и надёжнее. Нфска на воркере это совсем не очень. Но чтобы понять, что такое сторэджкласс достаточно.
Но все это очень просты темы. Все пишут о том как развернуть кластер, но никто не пишет о том как например обновить сертификаты кластера, особенно если изменился рут са. Я имею ввиду именно внутренние серты кластера.
Потому что суппортать потом кластер созданный при помощи kubespray это БОЛЬ!
Увы все это становится не столь радужно если вы используете онпремис инфраструктуру на VMw или Openstack. Готовых модулей для них почти нет. А terragrant по своей сути это просто оркестратор терраформ модулей. Придется написать уйму модулей для своей инфраструктуры. Но предварительно нужно будет еще обсудить и разработать концепт написания этих самых кастомных модулей. А потом еще и танцы с импортами и это все со скудную документацию, как уде сказал прошлый комметатор- желание переезжать на террагрант отпадает. Документация увы за годы лучше не стала.
Как вступительное слово для лекции по IaC может и сойдет, но есть вопросики:
Ansible, chef это не процедурные языки, а инструменты использующие декларативный языки разметки. Так и не понял почему это они стали процедурными если они тоже описывают желаемое состояние.
Не понял почему terraform стал immutable. Мне кажется что вообще нельзя применять здесь такие понятия как mutable/immutable. Терраформ изменяет существующие ресурсы, а вот если ресурс можно изменить только пересоздание, то он его пересоздает, но это уже зависит от провайдера, ресурса и клауда.
Chef можно использовать как в master так и в masterless варианте.
Стоило бы отметить, что терраформ использует свой HCL. Вообще колонка синтаксис не совсем понятна.
Также стоит отметить что Ansible использует под капотом python, как chef ruby что позволяет им быть достаточно гибкими и расширять функционал с помощью самописных плагинов и модулей.
И так далее по списку)))
Но за статью спасибо, уверен кому-то она будет полезной.