Идеи Terraform
Terraform и PagerDuty - перед тем, как попробовать
Стоит знать факты, прежде чем начинать писать код инфраструктуры PagerDuty
Terraform хорошо известен своим огромным выбором провайдеров. Среди них мы можем найти интеграцию с PagerDuty. Если у вас много сервисов, пользователей и команд внутри PagerDuty, вам следует подумать об управлении такой инфраструктурой, как IaC.
По мере того, как вы тратите все больше и больше времени на написание кода HCL, вы обнаружите несколько вещей, которые вы можете терпеть или которые могут быть совершенно неприемлемыми. Я не хочу сказать, что провайдер terraform PagerDuty плохой. Собственно, пользуюсь и рекомендую. Но давайте посмотрим, что я обнаружил в своих первых попытках.
Нет поддержки EventRules внутри Сервисов
У вас нет возможности развертывать правила событий внутри служб с помощью terraform. Эта функция фактически вообще не поддерживается в API. Почему это может быть важно для вас? В моем случае я хотел управлять наборами правил, правилами внутри наборов правил и правилами событий внутри служб в терраформе.
- Набор правил с правилами должен иметь только маршрутизацию на основе служб, а не предупреждений (только метаданные, из которых поступают предупреждения приложения / компонента). Следует задать только один вопрос: Где произошло предупреждение?
- EventRules внутри служб должны устанавливать поведение / статус события на основе описания и имени предупреждения: Какое предупреждение произошло?
Эта настройка важна, если вы запускаете много компонентов в своем кластере и у каждого из них есть собственная служба, поэтому вы можете заглянуть в PagerDuty и сразу сказать, что не так с вашим кластером. И поскольку вы разделяете правила, вам не нужно иметь дело с одним огромным набором правил, заполненным сотнями правил.
Случайность порядка следования правил
Правила в PagerDuty выполняются одно за другим, пока не будут соответствовать ожидаемым условиям. Затем они добавляют дополнительные метаданные и направляют событие в назначенную службу. В правилах терраформирования положение в настоящее время достигается с помощью поля position (не ожидал этого, не так ли?).
Пример определения ресурса правила До того, как правила позиции были применены по порядку с использованием мета-аргумента depends_on (назад, когда ресурс был назван EventRule).
Допустим, через неделю вы решили изменить порядок. Затем вам придется обновлять каждый раз depends_on - что хлопотно и неэффективно. Конечно, вы можете найти обходной путь и использовать свои блестящие навыки написания сценариев, но это все же обходной путь.
Так что поле position похоже на благословение. Но даже в ресурсах вы должны обновлять номера каждый раз при изменении заказа. Вы можете упростить такой процесс, используя переменные и индексную функцию:
Теперь, чтобы изменить порядок правил, мне нужно только переключить порядок строк в списке в variables.tf.
В этот момент все должно пойти с места. После применения терраформирования:
Apply complete! Resources: 0 added, 2 changed, 0 destroyed.
Выглядит многообещающе. А затем давайте запустим план терраформирования, чтобы убедиться:
Plan: 0 to add, 2 to change, 0 to destroy.
Он просто солгал мне? Правила, в которых была изменена позиция, остаются в прежних положениях. Так что же мне делать? Снова запустите приложение. А после второго захода правила поменялись местами. Но несколько дней назад у меня была ситуация, когда после 7-го прогона изменения применялись правильно.
Проблема с такой ошибкой - воспроизводимость. Я много раз пробовал, так и не добившись ожидаемого поведения. Затем, через несколько дней на семинаре с командой, внезапно произошла ошибка. Более того, при попытке развернуть все правила сразу в пустой набор правил terraform не смог установить их в правильном порядке.
Для меня довольно больно устанавливать правила в терраформе. Я также всегда думаю о худшем сценарии, когда кто-то применит изменения и забудет проверить правильность порядка. Вы можете спроектировать некоторый конвейер для применения изменений до тех пор, пока порядок не будет правильным, но это может не сработать - однажды мне пришлось вручную перемещать правила в графическом интерфейсе PagerDuty после 10-го запуска терраформирования.
Меньше ручной работы - но писать модуль может быть сложно
Как и многие решения IaC, это также снижает количество кликов. Одна команда - и вся инфраструктура готова. В моем PagerDuty я решил сохранить такую структуру репозитория terraform:
Первый вопрос, который вы должны задать, - почему я не написал модуль для обеспечения избыточности файлов. Ответ прост - писать модуль в PagerDuty в моем случае не стоит. Есть несколько различий в мониторинге между нашими кластерами, которые мы хотим сохранить.
Допустим, нам нужен модуль, который будет развертывать все упомянутые ресурсы. В большинстве случаев вам все равно придется передавать подробную информацию о правилах, а с модулем это может быть сложно. Я также отразил нежелание моей команды использовать трудночитаемые модули (их тоже нужно поддерживать). Они предпочитают простоту. Стоит упомянуть main.tf, где мы храним информацию о поставщиках и терраформируем источники данных - ссылки на команды, пользователей, расписания, приоритеты и политики эскалации.
Вы можете попробовать сейчас
Есть два небольших неудобства в настройке PagerDuty с помощью terraform. Особенно развертывание всего PagerDuty. Также из-за невозможности использовать ресурс EventRule не хватает опыта терраформирования. Я не знаю, собираются ли они что-то делать с порядком правил, потому что это не такая распространенная проблема. Пока можно надеяться получить EventRules API.
Если вы планируете использовать terraform для своего PagerDuty, я могу порекомендовать вам это решение, но помните об этих нескольких вещах. Ваши требования могут быть выше моих, и знание упомянутых ограничений может когда-нибудь избавить вас от ненужных разочарований.