Идеи 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, я могу порекомендовать вам это решение, но помните об этих нескольких вещах. Ваши требования могут быть выше моих, и знание упомянутых ограничений может когда-нибудь избавить вас от ненужных разочарований.