1) Я же правильно понял, что речь в данном вопросе идет только о конфигах Grafana? В текущем CI, который я описал, действительно не хватает шагов по откату конфигов в предыдущее состояние. Если честно, пока не знаю, как это реализовать. Если поделитесь идеями, буду очень признателен. Кстати, создание артефакта уже есть на шаге build. В данный момент артефактом является каталог с дашбордами.
2) Что имеется в виду под фразой "вся конфигурация"? Каким образом поможет git clone? Чем он лучше rsync? Ansible - да, можно встроить в CI, но это еще одна дополнительная прослойка, которая усложняет CI и которую дополнительно нужно поддерживать. К слову, валидация конфигов (dryRun) выполняется внутри CI, это ничем не отличается от валидации конфигов на конечном хосте. С Графаной, конечно, посложнее.
По поводу опыта работы с другими системами: да, на прошлой работе у меня был опыт внедрения системы Zabbix (в те времена актуальными были версии 4.0-4.4). Эта была для меня первая система мониторинга, с которой я познакомился.
А что именно неидемпотентно и Вам не нравится в предложенном варианте CI/CD? Давайте лучше с примерами и аргументами, почему это неправильно с Вашей точки зрения.
В статье мне хотелось поделиться идеями и полученным опытом при проработке решения. Лично мне очень не хватало статей на аналогичные темы при поиске решения, поэтому я решил написать свою.
Я прекрасно понимаю, что моё решение не претендует на идеальность. В данный момент это решение еще находится в стадии доработки. И возможно Ваши комментарии помогут нам...
GitOps - это способ организации какого-либо процесса (например, разработки или эксплуатации) посредством создания единого источника правды в виде Git-репозитория, с которым работает команда, а также обвязки над репозиторием в виде CI/CD для ускорения процесса разработки и доставки изменений.
IaC - подход, при котором процесс управления инфраструктурой аналогичен процессу разработки ПО (используются аналогичные принципы и подходы).
Подход GitOps может быть применен к любому процессу, который технически можно организовать через Git-репозиторий (в том числе и организовать IaC у себя в проекте).
Более того, IaC может существовать и без GitOps. Например, у Вас на ПК есть каталог с набором плейбуков Ansible, которых Вам хватает для управления Вашей инфраструктурой. Это GitOps? - Нет. Это IaC? - В какой-то степени, да.
Да, у нас кроме k8s, огромный зоопарк. Если бы был только k8s, то согласен, ничего дополнительно придумывать не надо, там и так уже всё придумано.
Насчет docker-compose тоже согласен, пока это решение предложено чисто как прототип. В дальнейшем придумаем какое-нибудь решение, интегрированное с Gitlab (как вариант, динамически поднимаемые окружения для Merge Request).
Так всё-таки модуль или провайдер? Если речь идет о провайдере, то для его написания нужно знать Golang. К этому я пока не готов. И не думаю, что это будет проще, чем использовать вышеописанный туллинг.
Если речь идет о модуле, то с помощью модуля эту задачу не решишь, поскольку провайдера нужного всё равно нету.
@AlworПока думал над ответом на Ваши вопросы, нашел такую тулзу для провиженинга Grafana: https://github.com/grafana/grizzly
Пока не вдавался в детали, но выглядит интересно.
1) Я же правильно понял, что речь в данном вопросе идет только о конфигах Grafana? В текущем CI, который я описал, действительно не хватает шагов по откату конфигов в предыдущее состояние. Если честно, пока не знаю, как это реализовать. Если поделитесь идеями, буду очень признателен. Кстати, создание артефакта уже есть на шаге build. В данный момент артефактом является каталог с дашбордами.
2) Что имеется в виду под фразой "вся конфигурация"? Каким образом поможет git clone? Чем он лучше rsync? Ansible - да, можно встроить в CI, но это еще одна дополнительная прослойка, которая усложняет CI и которую дополнительно нужно поддерживать. К слову, валидация конфигов (dryRun) выполняется внутри CI, это ничем не отличается от валидации конфигов на конечном хосте. С Графаной, конечно, посложнее.
Спасибо, почитаю про эти штуки.
Спасибо за замечание, исправил опечатки.
По поводу опыта работы с другими системами: да, на прошлой работе у меня был опыт внедрения системы Zabbix (в те времена актуальными были версии 4.0-4.4). Эта была для меня первая система мониторинга, с которой я познакомился.
Про Zabbix я даже готовил доклад для студентов ВУЗа, в котором сам учился: https://youtu.be/UZIjoipj3p8
А что именно неидемпотентно и Вам не нравится в предложенном варианте CI/CD? Давайте лучше с примерами и аргументами, почему это неправильно с Вашей точки зрения.
В статье мне хотелось поделиться идеями и полученным опытом при проработке решения. Лично мне очень не хватало статей на аналогичные темы при поиске решения, поэтому я решил написать свою.
Я прекрасно понимаю, что моё решение не претендует на идеальность. В данный момент это решение еще находится в стадии доработки. И возможно Ваши комментарии помогут нам...
Думаю, Вы немного смешали два понятия.
GitOps - это способ организации какого-либо процесса (например, разработки или эксплуатации) посредством создания единого источника правды в виде Git-репозитория, с которым работает команда, а также обвязки над репозиторием в виде CI/CD для ускорения процесса разработки и доставки изменений.
IaC - подход, при котором процесс управления инфраструктурой аналогичен процессу разработки ПО (используются аналогичные принципы и подходы).
Подход GitOps может быть применен к любому процессу, который технически можно организовать через Git-репозиторий (в том числе и организовать IaC у себя в проекте).
Более того, IaC может существовать и без GitOps. Например, у Вас на ПК есть каталог с набором плейбуков Ansible, которых Вам хватает для управления Вашей инфраструктурой. Это GitOps? - Нет. Это IaC? - В какой-то степени, да.
Да, у нас кроме k8s, огромный зоопарк. Если бы был только k8s, то согласен, ничего дополнительно придумывать не надо, там и так уже всё придумано.
Насчет docker-compose тоже согласен, пока это решение предложено чисто как прототип. В дальнейшем придумаем какое-нибудь решение, интегрированное с Gitlab (как вариант, динамически поднимаемые окружения для Merge Request).
Если речь идет о модуле, то с помощью модуля эту задачу не решишь, поскольку провайдера нужного всё равно нету.