Рабочая схема. Использую нечто подобное в проде уже два года - проблем не было от слова совсем. Собрано на нодах proxmoxa, стораджи подкинуты и в сам proxmox и в кубернетес кластера - полет нормальный. Так что рекомендую.)
А почему вы просто не захотели поднять jenkins в k8s кластере + jcsac? Мы такой вариант уже много лет используем - полет нормальный. Но у нас нагрузки конечно не такие космические как у вас. Но тут тоже вопрос - а не проще ли иметь несколько разных jenkinsов? Ведь когда в одной системе 100500 пользователей и ярды джоб это ну такое себе.
а есть альтернативы? Если вы про ранать каждый экзепляр в отдельном контейнере, то его мониторить как-то нужно и хотелось бы собирать немного более чем только утилизация цпу и мемори. Если есть интересные предложения поделитесь.
А зачем весь этот огород. Попросите девопса сделать прокси репозиториев для ваших пакетов на nexus. Свои среды поверните на nexus. Все один раз заранали yarn install и репа наполнилась.
Все кто советуют pnpm - одумайтесь. С ним вечно проблемы с зависимостями когда меняются версии пакетов. Я себя сделал вывод, что от него больше проблем чем пользы.
Не могу уловить зачем этот велосипед: если у Вас вмки, то вы же все равно провижините конфигурацию веб сервера конфигурейшен менеджмент тулой типо ансибл, так пусть он и займётся секретами в связки с ансибл-вольт. Мы и деплоим все через ансибл к слову, очень даже удобно.
Если у вас микросервисы, то там вообще проблем нет: секреты кубернетиса, hashicorp vault и много-много всего.
Не маловажно отметить, что решить проблему секретов можно и средствами самого ci/cd.
Если подитожить: не изобретайте велосипед, обратитесь "DevOps инженеру" это его работа в конце-то концов.)
Полностью Вас поддерживаю. Мне вообще не понятен нынешний тренд в мире DevOps. Все упорно игнорируют Jenkins, а он настоящий швейцарский нож, который может все в сравнении с тем же gitlab ci. Огромное комьюнити, все в открытом доступе - бери и пользуйся. Гибкий, удобный, бесплатный, расширяемый, что ещё нужно.
Используем минио в проде уже почти два года. Multi-node, multi-drive. Все в кубере. В качестве csi - host path ноды.
Были и вылеты нод и вылеты дисков. Проблем не было от слова совсем. Если все сделано по документации minio, то даже вмешательство инженера не понадобится. Ну или нам очень везёт)
Рабочая схема. Использую нечто подобное в проде уже два года - проблем не было от слова совсем. Собрано на нодах 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.
Используем минио в проде уже почти два года. Multi-node, multi-drive. Все в кубере. В качестве csi - host path ноды.
Были и вылеты нод и вылеты дисков. Проблем не было от слова совсем. Если все сделано по документации minio, то даже вмешательство инженера не понадобится. Ну или нам очень везёт)