а есть альтернативы? Если вы про ранать каждый экзепляр в отдельном контейнере, то его мониторить как-то нужно и хотелось бы собирать немного более чем только утилизация цпу и мемори. Если есть интересные предложения поделитесь.
А зачем весь этот огород. Попросите девопса сделать прокси репозиториев для ваших пакетов на nexus. Свои среды поверните на nexus. Все один раз заранали yarn install и репа наполнилась.
Все кто советуют pnpm - одумайтесь. С ним вечно проблемы с зависимостями когда меняются версии пакетов. Я себя сделал вывод, что от него больше проблем чем пользы.
Не могу уловить зачем этот велосипед: если у Вас вмки, то вы же все равно провижините конфигурацию веб сервера конфигурейшен менеджмент тулой типо ансибл, так пусть он и займётся секретами в связки с ансибл-вольт. Мы и деплоим все через ансибл к слову, очень даже удобно.
Если у вас микросервисы, то там вообще проблем нет: секреты кубернетиса, 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 года.
Советую попробовать 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, то даже вмешательство инженера не понадобится. Ну или нам очень везёт)
В целом все чётко и по делу. Как же жаль, что не все это понимают.
Спасибо. Было приятно читать.
Варианты? Да их масса, сперва не плохо бы использовать готовые решения типа wal-g например, а не городить свои скрипты. И складывать бэкапы в s3. Вызывать wal-g из ci в контейнере например. Креды или в vault, или можно через ansible vault если не хочется возится с контейнерами. В целом вариантов масса.
Я лишь хотел сказать, что предложенное решение совсем не продпкшен реди для 2023 года.
Ещё бы пару слов о том, как все это добро использовать с SSR на nuxt например, было бы вообще здорово. А так огромное спасибо - было полезно.
Ох, да((( Сейчас бы в 23 году создавать бэкапы дампом, да ещё и запускать из крона и хранить все креды в открытом виде. Бегите из этой компании.!