Понимание пользовательских проверок условий

В этой статье я представляю точку зрения на пользовательские проверки условий как подход проектирования по контрактам для написания модулей Terraform.

В 2020 году команда Terraform ввела пользовательские правила проверки входных переменных в качестве экспериментальной функции, а затем выпустила ее как стабильную функцию в версии 0.13. В этом году они расширили пользовательские проверки, представив предусловия и постусловия в выпуске v1.2.0, которые предназначены для использования в ресурсах, источниках данных и выходных блоках.

Оба приведенных выше способа позволяют авторам Terraform определять точный контракт для модулей, определяющий обязательства и гарантии для вызывающей стороны модуля.

В дизайне программного обеспечения это называется «Проектирование по контракту» — термин, введенный Бертраном Мейером¹. Его центральная идея — метафора того, как элементы программной системы взаимодействуют друг с другом на основе взаимных обязательств и выгод².

Программный компонент предоставляет контракт на услуги, которые он будет предоставлять, и что, используя компонент, клиент соглашается с условиями этого контракта³.

Контракт представляет собой перечень спецификаций. Спецификации могут включать:

  • Предварительные условия: клиент обязан выполнить необходимые предварительные условия функции перед вызовом функции. Если предварительные условия не соблюдены, функция может работать некорректно.
  • Постусловия: функция гарантирует выполнение определенных условий после завершения работы. Если постусловие не выполнено, то функция не завершила свою работу корректно
  • Приемлемые и недопустимые входные значения

Механизмами выражения обязательств и гарантий являются утверждения. Наличие утверждений как части кода делает контракты полезным инструментом для проверки правильности. Рассмотрим следующую функцию для вычисления квадратного корня:

square_root(x):
  assert x > 0   # precondition
  ...
  /*a computation to get the square root of x as y*/
  ...
  assert y*y == x # postcondition
  return y

Контракты в Terraform

С точки зрения Terraform утверждения представлены аргументом condition внутри блока validation/ precondition/ postcondition. condition принимает выражение, которое должно оцениваться как true/ false . Если утверждение нарушается, Terraform вернет error_message и остановит выполнение.

condition = self.private_dns != ""
error_message = "The instance must be in a VPC that has private DNS hostnames enabled."

Где пользовательские проверки условий появляются в различных типах блоков

Пользовательские проверки условий Захват допущений и гарантий

Обратите внимание, что выше используется слово «предположение» вместо «обязательство». Это может немного сбивать с толку, поэтому, чтобы прояснить ситуацию, рассмотрите следующие точки зрения:

Ресурс:

Ресурс должен обеспечить выполнение постусловия: дает гарантию для вызывающей стороны. Ресурс может сделать предположение о том, как его использует вызывающая сторона: определяет предварительные условия, которые должны быть выполнены вызывающей стороной.

Звонивший:

Вызывающий объект должен обеспечить выполнение предварительного условия, определенного ресурсом, и может принять на себя некоторые гарантии, предоставляемые ресурсом (постусловие).

Сравнение того, как можно использовать пользовательские проверки условий Terraform

Рекомендации

[1] Bertrand Meyer, in Applying “Design by Contract” (October 1992). IEEE Computer.
[2] Wikipedia Contributors, Design by contract (June 2022). Wikipedia.
[3] Martin Reddy, in API Design for C++ (2011). 9.1.2 Documenting the Interface’s Contract.

Хотите подключить

If you think this was helpful and would like to show your support here's my :
PayPal page
Buy me a coffee page
Ko-fi page