Комментарии 9
А смысл здесь от ансиболи? Шаблонизировать можно хелмом, тем более что конфиг в кубе можно и нужно передавать извне, а не запекать в докере.
Более того, external dns не нужен, для такого масштаба проекта проще сделать запись со * с dns.
Пока выглядит как переусложненное решение тестового задания на девопса, которое можно было сделать гораздо проще и правильнее.
Плюс базу можно иметь ресурсом куба, наверняка есть операторы которые и создадут и удалят.
И сидинг лучше не через бэкап делать а через нормальный сидинг данных из кода. Он же пригодится и разработчикам при локальной разработке.
В целом задача хорошо решается через argocd, там есть генераторы которые следят за репо и видят новые каталоги. Просто скопировали каталог с манифестами или чартами - и у вас новое приложение в другом неймспейсе.
Плюс базу можно иметь ресурсом куба, наверняка есть операторы которые и создадут и удалят.
Это верно подмечено, разве что стоит также подметить что база частенько деплоится не на кубере, а отдельно на виртуалки или используется менеджед сервис и в этом случае это решение не подойдет
И сидинг лучше не через бэкап делать а через нормальный сидинг данных из кода. Он же пригодится и разработчикам при локальной разработке.
Безусловно. Но часто разработчики "очень заняты" и вариант с копированием их устраивает больше поскольку не требует их вовлечения
В целом задача хорошо решается через argocd, там есть генераторы которые следят за репо и видят новые каталоги. Просто скопировали каталог с манифестами или чартами - и у вас новое приложение в другом неймспейсе.
А можно тут поподробнее если не сложно? Как через него организовать создание окружения из ветки (даже если опустить момент с копированием базы)?
Но в целом, мы не используем арго для приложений, только для инфраструктурных сервисов. Потому что:
Не видно процесса и статуса деплоя в Gitlab, это не удобно
Нет возможности делать --atomic релизы
Иногда требуется добавить доп логику завязанную на процесс деплоя (например, сброс кеша на Cloudflare, отправка оповещалок в Telegram). Если деплой организован через арго, то это становится проблематичной задачей (все решаемо конечно, но уже сложнее)
Шаблонизировать можно хелмом
Тут согласен, банально так привык пользоваться Ansible что и не заметил что можно упростить =)
тем более что конфиг в кубе можно и нужно передавать извне, а не запекать в докере
Кубконфиг кладется в /root/.kube/config и контекст докер билда не захватывает эту папку. Или вы чтото другое имели в виду?
Более того, external dns не нужен, для такого масштаба проекта проще сделать запись со * с dns.
В случае с * придется делать отдельный поддомен. А из за этого как минимум Cloudflare не будет генерировать сертификат. Но в целом тоже рабочий вариант конечно, как-то давно использовал такое
Пока выглядит как переусложненное решение тестового задания на девопса, которое можно было сделать гораздо проще и правильнее.
В статье ведь был был не сложный проект как пример, схема в целом рабочая и для большего числа приложений
> Кубконфиг кладется в /root/.kube/config и контекст докер билда не захватывает эту папку. Или вы чтото другое имели в виду?
Другое, да. Я про конфиг который web.config, его лучше монтировать как файл из configmap куба. Ну а в идеале перейти на конфигурацию из env-переменных, но это выходит за рамки этого проекта и обсуждения)
> В случае с * придется делать отдельный поддомен. А из за этого как минимум Cloudflare не будет генерировать сертификат. Но в целом тоже рабочий вариант конечно, как-то давно использовал такое
Ну тут такое, серты можно генерить другими способами. Но да, тут аргумент принимается. Просто впервые вижу использование edns для такого масштаба, удивился.
> В статье ведь был был не сложный проект как пример, схема в целом рабочая и для большего числа приложений
"В целом рабочая" - это достаточно большой класс схем с костылями и усложнениями разного масштаба. KISS - наше всё. А то посмотришь, как предыдущие девопсы в компании напилили после таких гайдов - и рыдать хочется. Мой фаворит - это докер, внутри которого puppet, который запускает ansible, который дёргает helm, который после себя вызывает kustomize, после чего ямлы идут в кластер и там изменяются с помощью мутатора в кластере. Тоже схема-то "в целом рабочая")
Ссылка из конца статьи спрашивает логин и пароль. Что туда ввести? :)
Для kubectl delete можно использовать --ignore-not-found, вместо || true
Продвинутый CI/CD или как реализовать динамические Feature стенды