Комментарии 19
Спасибо за пост. Добавьте пожалуйста причины перехода на VictoriaMetrics в основной пост.
Всё вроде стандартно, но отлично написано, спасибо.
Consul для динамических нод K8s конечно не нужен, но если у вас там помимо K8s прямо зоопарк, то, наверное, оправдано.
например docker-compose для запуска Grafana
Это я бы конечно в k3s или k3d добавил, чтобы никаких docker-compose. Заодно разработчики будут локально работать в среде ближе к реальному K8s.
Да, у нас кроме k8s, огромный зоопарк. Если бы был только k8s, то согласен, ничего дополнительно придумывать не надо, там и так уже всё придумано.
Насчет docker-compose тоже согласен, пока это решение предложено чисто как прототип. В дальнейшем придумаем какое-нибудь решение, интегрированное с Gitlab (как вариант, динамически поднимаемые окружения для Merge Request).
А подскажите, пожалуйста, разве docker-compose плох на начальных этапах разработки и для дев\стейдж окружений? Это же всё также в CI настроить можно.
Если ваш проект планирует оказаться в K8s, то желательно на docker-compose и не останавливаться, а потратить немного времени и сразу начинать в K8s. Сейчас его базовый функционал гораздо более user friendly, чем когда-то. А то у вас тесты и т.д. в compose, а prod в K8s и окружения не одинаковые получаются, хоть и похожие. А потом вам надо будет потратить время на переписывания всех этих тестов и т.п., что мало кто делает.
Есть такой замечательный продукт: k3d, который можно использовать на Gitlab runner'е, посмотрите на него (кубер в докере, можно создавать одновременно несколько кластеров на одной машине). На машинах у разработчиков можно также использовать его или его брата k3s (кубер не в докере, управляется systemd). K3s CNCF certified.
Так я вам и подсказываю решение для динамического создания окружений для MR в кубере: k3d (помимо создания нового namespace под каждый MR, конечно, что иногда не удобно). K3d - это по сути кубер в докере. Использую его на проектах, отлично себя показывает как раз в том числе для прогона тестов для MR/PR. Им в том числе можно создавать много изолированных кластеров на одном Gitlab runner'е.
Отличная статья, здорово и последовательно структурировано, ссылки не битые, большое спасибо за пищу для размышлений!
Подскажите, пожалуйста, был ли опыт работы с другими стеками для мониторинга (Zabbix, Netdata, Nagios и т.д.)?
P.S. очепятки:
Создали новую машину, но забыли добавить в мониторинг. Когда понадобились метрики, вспомнили про эту машины.
С помощью этой метки мы может обрабатывать событие вывода хостов на обслуживание и не создавать лишние алерты.
Для удаления машин с мониторинга, можно использовать любые механизмы (наприме, можно использовать Destroy-Time Provisioners для Terraform, который будет выполнять дерегистрацию сервиса в Consul)
Спасибо за замечание, исправил опечатки.
По поводу опыта работы с другими системами: да, на прошлой работе у меня был опыт внедрения системы Zabbix (в те времена актуальными были версии 4.0-4.4). Эта была для меня первая система мониторинга, с которой я познакомился.
Про Zabbix я даже готовил доклад для студентов ВУЗа, в котором сам учился: https://youtu.be/UZIjoipj3p8
GitOps начинается с IaC, но у вас этого что-то не видно...
Думаю, Вы немного смешали два понятия.
GitOps - это способ организации какого-либо процесса (например, разработки или эксплуатации) посредством создания единого источника правды в виде Git-репозитория, с которым работает команда, а также обвязки над репозиторием в виде CI/CD для ускорения процесса разработки и доставки изменений.
IaC - подход, при котором процесс управления инфраструктурой аналогичен процессу разработки ПО (используются аналогичные принципы и подходы).
Подход GitOps может быть применен к любому процессу, который технически можно организовать через Git-репозиторий (в том числе и организовать IaC у себя в проекте).
Более того, IaC может существовать и без GitOps. Например, у Вас на ПК есть каталог с набором плейбуков Ansible, которых Вам хватает для управления Вашей инфраструктурой. Это GitOps? - Нет. Это IaC? - В какой-то степени, да.
Все правильно, но у вас в примере, хоть и вынесено в гит, но по факту, вы накидали неидемпотентные башульки в ci/cd, которые никак не могут быть классифицированы, как однотипно-настроенное состояние системы.
И да, IaC может существовать вне gitops, но не уверен, что возможно обратное, по крайне мере, ни одна статья и ни один пример/опыт компании про это не говорит.
А что именно неидемпотентно и Вам не нравится в предложенном варианте CI/CD? Давайте лучше с примерами и аргументами, почему это неправильно с Вашей точки зрения.
В статье мне хотелось поделиться идеями и полученным опытом при проработке решения. Лично мне очень не хватало статей на аналогичные темы при поиске решения, поэтому я решил написать свою.
Я прекрасно понимаю, что моё решение не претендует на идеальность. В данный момент это решение еще находится в стадии доработки. И возможно Ваши комментарии помогут нам...
@alex_spq@alex_spq хорошая статья, технически грамотная и легко читать.
1) Может быть в CI не хватает создание артефакта и доставки его до провижионера Grafana... Как при классическом использовании CI. Артефакт обеспечивал бы целостную и разовую доставку всех конфигураций и самое главное откат на предыдущий, в случая какого-то обнаруженного дефекта. Опережая, сразу соглашусь что откат можно организовать на уровне git. И скорее всего здесь именно это и уместно.
2) Как быть уверенным что вся конфигурация доставилась на хост мониторинга? Может для доставки использовать git clone, где уже предусмотрено целостность? Или ещё как вариант, ansible с модулем copy и валидацией конфигов (dryRun) ?
1) Я же правильно понял, что речь в данном вопросе идет только о конфигах Grafana? В текущем CI, который я описал, действительно не хватает шагов по откату конфигов в предыдущее состояние. Если честно, пока не знаю, как это реализовать. Если поделитесь идеями, буду очень признателен. Кстати, создание артефакта уже есть на шаге build. В данный момент артефактом является каталог с дашбордами.
2) Что имеется в виду под фразой "вся конфигурация"? Каким образом поможет git clone? Чем он лучше rsync? Ansible - да, можно встроить в CI, но это еще одна дополнительная прослойка, которая усложняет CI и которую дополнительно нужно поддерживать. К слову, валидация конфигов (dryRun) выполняется внутри CI, это ничем не отличается от валидации конфигов на конечном хосте. С Графаной, конечно, посложнее.
1) Да, о конфига Grafana. В случаи использования git, можно бы сделать git restore.
2) ansible бы позволил проверить валидацию именно на хосте запуска, если конечно эта совокупная проверка со всей остальной конфигурации VM. Если нет, то может и не стоит так делать. Тем более вы указали что не отличается. Также ansible можно подсветить изменения и организовать релойд. Может это имел ввиду автор предыдущего комментария про идемпотентность...
@AlworПока думал над ответом на Ваши вопросы, нашел такую тулзу для провиженинга Grafana: https://github.com/grafana/grizzly
Пока не вдавался в детали, но выглядит интересно.
Monitoring as Code на базе VictoriaMetrics и Grafana