Телеграмм чат группы terraform

сответственно создание сети и создание k8s - это два разных модуля

23:37пожаловаться #1

LS

Вопрос был немного в другом, как в зависимости от размера списка, генерировать разные по структуре ответы

23:38пожаловаться #2

VT

ок,
терраформ сперва идет в module.yc-network.
Делает prediction compute ресурсов и далее он идет в yc-kubernetes, там он споткнется о то что количество наших compute ресурсов он не может в графе предугадать.
(хотя почему бы не делать прогон несколько с частичными планами? правда?)
посмотрим что сделает terrafom 0.13 - там был подвижки в эту сторону

23:40пожаловаться #3

AR

Alexey Remizov in terraform_ru

Вопрос был немного в другом, как в зависимости от размера списка, генерировать разные по структуре ответы

locals {
  regions = length(var.master_zones) > 1 ? [{
    region    = var.master_region
    locations = var.master_zones
  }] : []

  zones = length(var.master_zones) > 1 ? [] : var.master_zones
}

.  .  .

  master {
    version   = var.master_version
    public_ip = var.master_public_ip

    dynamic "zonal" {
      for_each = local.zones

      content {
        zone      = zonal.value["zone"]
        subnet_id = zonal.value["id"]
      }
    }

    dynamic "regional" {
      for_each = local.regions

      content {
        region = regional.value["region"]

        dynamic "location" {
          for_each = regional.value["locations"]

          content {
            zone      = location.value["zone"]
            subnet_id = location.value["id"]
          }
        }
      }
    }
  }

23:41пожаловаться #4

VT

Как решают - создают две папки (очень грубо)
network/
eks/
в каждом делаешь terraform apply,
в eks ссылаешься на output из network через data remote_state ресурс.

23:41пожаловаться #5

VT

Alexey Remizov

locals {
  regions = length(var.master_zones) > 1 ? [{
    region    = var.master_region
    locations = var.master_zones
  }] : []

  zones = length(var.master_zones) > 1 ? [] : var.master_zones
}

.  .  .

  master {
    version   = var.master_version
    public_ip = var.master_public_ip

    dynamic "zonal" {
      for_each = local.zones

      content {
        zone      = zonal.value["zone"]
        subnet_id = zonal.value["id"]
      }
    }

    dynamic "regional" {
      for_each = local.regions

      content {
        region = regional.value["region"]

        dynamic "location" {
          for_each = regional.value["locations"]

          content {
            zone      = location.value["zone"]
            subnet_id = location.value["id"]
          }
        }
      }
    }
  }

вот! все переменные статичны👍

23:41пожаловаться #6

LS

Victor Tur

ок,
терраформ сперва идет в module.yc-network.
Делает prediction compute ресурсов и далее он идет в yc-kubernetes, там он споткнется о то что количество наших compute ресурсов он не может в графе предугадать.
(хотя почему бы не делать прогон несколько с частичными планами? правда?)
посмотрим что сделает terrafom 0.13 - там был подвижки в эту сторону

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

23:42пожаловаться #7

LS

Alexey Remizov

locals {
  regions = length(var.master_zones) > 1 ? [{
    region    = var.master_region
    locations = var.master_zones
  }] : []

  zones = length(var.master_zones) > 1 ? [] : var.master_zones
}

.  .  .

  master {
    version   = var.master_version
    public_ip = var.master_public_ip

    dynamic "zonal" {
      for_each = local.zones

      content {
        zone      = zonal.value["zone"]
        subnet_id = zonal.value["id"]
      }
    }

    dynamic "regional" {
      for_each = local.regions

      content {
        region = regional.value["region"]

        dynamic "location" {
          for_each = regional.value["locations"]

          content {
            zone      = location.value["zone"]
            subnet_id = location.value["id"]
          }
        }
      }
    }
  }

Спсибо, пошел пробовать )

23:42пожаловаться #8

AR

Alexey Remizov in terraform_ru

Идея в том, что в декларации кластера ты объявляешь и блок zonal и блок regional, но по построению гарантируешь, что один из блоков обязательно будет пустой.

23:43пожаловаться #9

VT

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

Создай попробуй с нуля
Когда ты сперва создал сеть в одном стейте, а потом со второго прогона создал дополнительные ресурсы - проблем нет. Всё уже известно в графе зависимостей.
Если у тебя пустой стейт и ты делаешь первый прогон - он будет жаловаться на это.

23:43пожаловаться #10

LS

Victor Tur

Создай попробуй с нуля
Когда ты сперва создал сеть в одном стейте, а потом со второго прогона создал дополнительные ресурсы - проблем нет. Всё уже известно в графе зависимостей.
Если у тебя пустой стейт и ты делаешь первый прогон - он будет жаловаться на это.

а depends_on разве как раз не для этого? чтобы вначале создать один ресурс перед тем как его использовать в другом

23:45пожаловаться #11

VT

не очень красиво решение - -target при первом прогоне на сеть.
красиво - через terragrunt dependency output и/или data terraform remote state

23:45пожаловаться #12

VT

а depends_on разве как раз не для этого? чтобы вначале создать один ресурс перед тем как его использовать в другом

Нет.

23:46пожаловаться #13

LS

Ок, понял. Пойду продолжу изучать.
Спасибо вам за помощь 🙂

23:46пожаловаться #14

VT

Partial/Progressive Configuration Changes · Issue #4149 · hashicorp/terraform

Это надо в шапку закреплять:
https://github.com/hashicorp/terraform/issues/4149

GitHub

For a while now I've been wringing my hands over the issue of using computed resource properties in parts of the Terraform config that are needed during the refresh and apply phases, where ...

23:46пожаловаться #15

VT

Partial/Progressive Configuration Changes · Issue #4149 · hashicorp/terraform

Ок, понял. Пойду продолжу изучать.
Спасибо вам за помощь 🙂

Вот решение в двух словах:
https://github.com/hashicorp/terraform/issues/4149#issuecomment-612178399

GitHub

For a while now I've been wringing my hands over the issue of using computed resource properties in parts of the Terraform config that are needed during the refresh and apply phases, where ...

23:47пожаловаться #16

VT

Just went ahead and restructured all my projects. Split them into a bunch of seperated things. Wherever there is a provider that depends on the output of a previous step, I split it.

Have done both makefiles to run them all in order and individual ci projects for each of them chained together in a pipeline depending. It's not that bad, but it does go against the flow of how you assume things should be structured.
@ pbecotte

23:48пожаловаться #17

VT

Alexey Remizov

locals {
  regions = length(var.master_zones) > 1 ? [{
    region    = var.master_region
    locations = var.master_zones
  }] : []

  zones = length(var.master_zones) > 1 ? [] : var.master_zones
}

.  .  .

  master {
    version   = var.master_version
    public_ip = var.master_public_ip

    dynamic "zonal" {
      for_each = local.zones

      content {
        zone      = zonal.value["zone"]
        subnet_id = zonal.value["id"]
      }
    }

    dynamic "regional" {
      for_each = local.regions

      content {
        region = regional.value["region"]

        dynamic "location" {
          for_each = regional.value["locations"]

          content {
            zone      = location.value["zone"]
            subnet_id = location.value["id"]
          }
        }
      }
    }
  }

и еще раз UP - ответ на вторую половину вопроса 👌

23:49пожаловаться #18

LS

А можно тогда еще вопрос, стоит ли использовать terragrunt для небольшой инфрастуктуры или ванильного terraforma хватит?

23:50пожаловаться #19

VT

А можно тогда еще вопрос, стоит ли использовать terragrunt для небольшой инфрастуктуры или ванильного terraforma хватит?

для небольшой наверное пойдет terraform с каким-нибудь Makefile'ом или враппером простеньким