Часто ли ресурс Terraform взаимодействует с несколькими группами API или он должен быть сопоставлен 1:1?

Контекст: я разрабатываю TF Provider и просматриваю руководство HashiCorp.

Я пытаюсь придумать определение ресурса и не могу понять, какое из них выбрать.

  • Опция 1:
Schema: map[string]*schema.Schema{
    "name": {
        Type:         schema.TypeString,
        Required:     true,
    },
    "endpoint": {
        Type:        schema.TypeString,
        Required:    true,
    },
},

resource "foo" "bar" {
  name = "alex"
  endpoint = "https://api.stripe.com" # unique for every bar
}
  • Вариант №2:
Schema: map[string]*schema.Schema{
    "name": {
        Type:         schema.TypeString,
        Required:     true,
    },
    "district_id": {
        Type:        schema.TypeString,
        Required:    true,
    },
},


resource "foo" "bar" {
  name = "alex"
  district_id = "NE53DE" # unique for every bar
}

Преимущество № 1 заключается в том, что он следует API, и для выполнения операций CRUD TF Provider может взаимодействовать только с одной группой API (существует сопоставление 1: 1 между группой API и ресурсом).

Преимущество № 2 заключается в том, что он более удобочитаем, но для вызова группы API № 1 нам все равно нужно выяснить конечную точку, поэтому TF Provider должен вызвать группу API № 2 для получения этой конечной точки.

Какой из этих вариантов чаще используется при разработке TF Providers?

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
0
19
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

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

Большим преимуществом тщательного следования дизайну удаленного API является то, что меньше вероятность того, что будущее расширение дизайна API сделает недействительным дизайн вашего провайдера. Это может быть особенно важно, если провайдер разрабатывается кем-то, кто не работает напрямую с командой, разрабатывающей API, поскольку разработчик провайдера обычно не может предсказать, как API может измениться в будущем и какие принципы проектирования будут использоваться. Команда разработчиков API обычно следует им при рассмотрении новых вариантов использования.

Однако, как вы заметили, реальные API-интерфейсы часто не предназначены для удобного прямого использования, а вместо этого предназначены для предоставления необработанных строительных блоков в предположении, что другие создадут подходящие абстракции конкретный вариант использования поверх них. Разработчик поставщика Terraform оказывается здесь в несколько затруднительном положении, потому что он обычно также пытается предоставить общее решение (нет ориентирован на конкретный вариант использования), но также хочет разработать что-то, что относительно удобно для использования в языке Terraform.

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

Наряду с управляемыми типами ресурсов, которые представляют Terraform, непосредственно управляющим каким-либо объектом в удаленной системе, Terraform также поддерживает типы ресурсов данные (для краткости «источники данных»), которые появляются на языке Terraform как data блоки. По сути, они моделируют внешние зависимости конкретного модуля, под которым я подразумеваю объекты, которые, как ожидается, модуль уже создал кем-то другим и которые модуль должен объявить объектами, которыми он будет управлять сам (его ресурсы удалось).

Если ваше сопоставление «идентификатора района» с «конечной точкой» можно в каком-то смысле представить как внешний объект, то источник данных может помочь заполнить этот пробел. Не беспокойтесь слишком сильно о том, действительно ли является является первоклассным объектом в удаленной системе; здесь важно то, разумно ли автору модуля Terraform думать о нем как об одном, чтобы он мог представить ваше требование «выяснить конечную точку» как ресурс данных:

data "foo_district_endpoint" "example" {
  district_id = "NE53DE"
}

resource "foo" "bar" {
  name     = "alex"
  endpoint = data.foo_district_endpoint.example.endpoint
}

Затем это делает явной описанную вами потребность сделать запрос API для определения конечной точки по идентификатору района, а не скрывать его как деталь реализации foo. Важным преимуществом явного описания является то, что модуль, который его ищет, не всегда может быть тем модулем, который его использует; для конфигураций, использующих шаблоны Состав модуля, возможно, что эти две потребности будут разделены на два меньших модуля, и, таким образом, значение endpoint будет перетекать от одного к другому с использованием выходных значений и входных переменных.

Две возможности, которые вы описали, и эта третья возможность, которую я добавил, являются допустимыми и оправданными конструкциями для различных ситуаций. Хотя я не могу сказать вам, какой из них лучше всего подходит для вашей конкретной ситуации, я надеюсь, что этот комментарий, по крайней мере, поможет вам кое-что рассмотреть, чтобы помочь вам принять решение для себя.

Другие вопросы по теме

Похожие вопросы

Как я могу использовать выходные данные модулей Terraform в качестве входных данных для другого модуля Terraform?
Как обрезать имя пользователя из идентификатора электронной почты в terraform
Невозможно одновременно создать множество наборов правил брандмауэра Azure в Terraform
Вывести вывод terraform из списка списка в список строк
Какая последняя версия доступна для политики доступа AWS cloudsearch?
Не удается изменить разрешения учетной записи службы передачи хранилища из terraform
Ошибка:: Неподдерживаемый атрибут. Этот объект не имеет атрибута с именем «nsg_name»
Ошибка Terraform: ошибка: создание подсети: исходная ошибка: код = «NetcfgInvalidSubnet» сообщение = «внутренняя подсеть» недействительна в виртуальной сети
Terraform: преобразование списка переменных в один список карт
Terraform - убедитесь, что значение установлено в зависимости от того, установлено ли другое значение