Ой сколько пафоса, а по факту обычно просто делают красивый ui, где любой может накликать все что угодно, а под капотом все те же jenkins, terraform, ansible, grafana... Как говорится на арене все те же. Но зато все вокруг уже platform инженеры. Но это все сугубо моё имхо. На звание истины не претендую.
Рабочая схема. Использую нечто подобное в проде уже два года - проблем не было от слова совсем. Собрано на нодах proxmoxa, стораджи подкинуты и в сам proxmox и в кубернетес кластера - полет нормальный. Так что рекомендую.)
А почему вы просто не захотели поднять jenkins в k8s кластере + jcsac? Мы такой вариант уже много лет используем - полет нормальный. Но у нас нагрузки конечно не такие космические как у вас. Но тут тоже вопрос - а не проще ли иметь несколько разных jenkinsов? Ведь когда в одной системе 100500 пользователей и ярды джоб это ну такое себе.
а есть альтернативы? Если вы про ранать каждый экзепляр в отдельном контейнере, то его мониторить как-то нужно и хотелось бы собирать немного более чем только утилизация цпу и мемори. Если есть интересные предложения поделитесь.
А зачем весь этот огород. Попросите девопса сделать прокси репозиториев для ваших пакетов на nexus. Свои среды поверните на nexus. Все один раз заранали yarn install и репа наполнилась.
Все кто советуют pnpm - одумайтесь. С ним вечно проблемы с зависимостями когда меняются версии пакетов. Я себя сделал вывод, что от него больше проблем чем пользы.
Не могу уловить зачем этот велосипед: если у Вас вмки, то вы же все равно провижините конфигурацию веб сервера конфигурейшен менеджмент тулой типо ансибл, так пусть он и займётся секретами в связки с ансибл-вольт. Мы и деплоим все через ансибл к слову, очень даже удобно.
Если у вас микросервисы, то там вообще проблем нет: секреты кубернетиса, hashicorp vault и много-много всего.
Не маловажно отметить, что решить проблему секретов можно и средствами самого ci/cd.
Если подитожить: не изобретайте велосипед, обратитесь "DevOps инженеру" это его работа в конце-то концов.)
Полностью Вас поддерживаю. Мне вообще не понятен нынешний тренд в мире DevOps. Все упорно игнорируют Jenkins, а он настоящий швейцарский нож, который может все в сравнении с тем же gitlab ci. Огромное комьюнити, все в открытом доступе - бери и пользуйся. Гибкий, удобный, бесплатный, расширяемый, что ещё нужно.
Ой сколько пафоса, а по факту обычно просто делают красивый ui, где любой может накликать все что угодно, а под капотом все те же jenkins, terraform, ansible, grafana... Как говорится на арене все те же. Но зато все вокруг уже platform инженеры. Но это все сугубо моё имхо. На звание истины не претендую.
Рабочая схема. Использую нечто подобное в проде уже два года - проблем не было от слова совсем. Собрано на нодах proxmoxa, стораджи подкинуты и в сам proxmox и в кубернетес кластера - полет нормальный. Так что рекомендую.)
Но схд в fiberchannel всё-таки надёжнее)
А почему вы просто не захотели поднять jenkins в k8s кластере + jcsac? Мы такой вариант уже много лет используем - полет нормальный. Но у нас нагрузки конечно не такие космические как у вас. Но тут тоже вопрос - а не проще ли иметь несколько разных jenkinsов? Ведь когда в одной системе 100500 пользователей и ярды джоб это ну такое себе.
Тут же дано описание совсем базовых настроек, для них можно использовать pgtune, с этими параметрами он работает корректно.
Статья крутая, но я по прежнему буду топить за Jenkins - вот там возможностей действительно море!
Советую попробовать grafana loki, глядишь не придется ничего изобретать)
Мне лично wal-g больше симпатизирует. И дока лучше и сам инструмент проще. Плюс из ci удобно ранать прям из контейнера.
а есть альтернативы? Если вы про ранать каждый экзепляр в отдельном контейнере, то его мониторить как-то нужно и хотелось бы собирать немного более чем только утилизация цпу и мемори.
Если есть интересные предложения поделитесь.
Так может имеет смысл сразу учиться делать правильно? Чтобы потом не перерабатывать весь флоу.
Простите, но это прям следующее издание книги "Вредные советы".
Пообщайтесь с девопсами, они научат вас как нужно делать.
Может для собственного пет проекта на коленке такой подход и норм. Но для продакшен решений - нет.
А зачем весь этот огород. Попросите девопса сделать прокси репозиториев для ваших пакетов на nexus. Свои среды поверните на nexus. Все один раз заранали yarn install и репа наполнилась.
Все кто советуют pnpm - одумайтесь. С ним вечно проблемы с зависимостями когда меняются версии пакетов. Я себя сделал вывод, что от него больше проблем чем пользы.
Согласен. Тоже не понимаю как это может работать с единой базой.
Бесплатность например) У нас в конторе нельзя использовать docker desktop учитывая особенности лицензии, а покупать не хотят.
Так новый yarn умеет тоже самое и даже лучше.
Неплохо было бы еще услышать почему именно traefik, a не haproxy или nginx.
А поделитесь пожалуйста опытом, а то у меня эта связка не завелась.
Не могу уловить зачем этот велосипед: если у Вас вмки, то вы же все равно провижините конфигурацию веб сервера конфигурейшен менеджмент тулой типо ансибл, так пусть он и займётся секретами в связки с ансибл-вольт. Мы и деплоим все через ансибл к слову, очень даже удобно.
Если у вас микросервисы, то там вообще проблем нет: секреты кубернетиса, hashicorp vault и много-много всего.
Не маловажно отметить, что решить проблему секретов можно и средствами самого ci/cd.
Если подитожить: не изобретайте велосипед, обратитесь "DevOps инженеру" это его работа в конце-то концов.)
Полностью Вас поддерживаю. Мне вообще не понятен нынешний тренд в мире DevOps. Все упорно игнорируют Jenkins, а он настоящий швейцарский нож, который может все в сравнении с тем же gitlab ci. Огромное комьюнити, все в открытом доступе - бери и пользуйся. Гибкий, удобный, бесплатный, расширяемый, что ещё нужно.
Простите, но чем вам не угодил постгрес в кластере. У нас два года уже в проде,в качестве sci ceph - полет нормальный.
Для себя уже давно сделал вывод, что для небольших инсталяций и кластеров более чем достаточно proxmox, для всего остального openstack.