организация кода terrraform для распространения контента

Question

Я изучаю терраформ. У меня есть мой код terraform, в настоящее время организованный как -

  main.tf
   ->modules
    ->route53
    ->network
    ->ec2

. Это хорошо работает в большинстве случаев, но теперь я хочу распространить весь рецепт запуска сервера (ec2 с некоторыми программами, которые я настроил), включая route53доменное имя как переменная и подсети / группы безопасности, которые являются ресурсом в моей сети. У меня много ресурсов в модулях для route53 / network / ec2 и т. Д. И т. Д.
Есть ли хорошая практика или шаблон или команда одним щелчком мыши (например, если бы я хотел запустить только все ресурсы в сети модулей, я мог быделать)

target apply -f network

так что я могу сделать что-то вроде

terraform apply -target module.network.(resource) -target module.ec2.(resource) -target module.route53 

и т. д. и т. д.

Answer 1

Лучшей практикой для создания кода Terraform является

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

From: Руководство по составлению модулей TF

В основном это означает:

1. Держите модули в другом git или в той же папке уровня, что и ваши немодульные tf-файлы (provisioners), делайте модули небольшими и придерживайтесь SRP (Single Responsibility).
2. Составьте сложный поток с помощью компоновки модулей, имея в виду DIP - Инверсия зависимостей
3. Модули являются абстракциями с одной ответственностью, в то время как provisioners являются фактическими настройками, которые составляют вызовы модулей- на плоском уровне, в то время как более поздние вызовы модулей могут использовать выходы предшествующих им вызовов модулей в потоке

Это означает:

- /modules
   - /vpc
     - vpc.tf
   - /subnets_private
     - subnets.tf
     - routing_tables.tf
   - /ecs_cluster
     - iam_ecs.tf
     - asg_ecs.tf
   - /network
- /provisioners
   - /staging
     - /workload_cluster_core_domain
         - main.tf
     - /control_plane_network
         - main.tf

Где main.tf имеют плоскую структуру:

    module1--
             |    
  --module2<-  
  |   
  ->module3  

Где каждый module может использовать выходные данные из:

• предшествующих (в дереве зависимостей) module вызовов
• data вызовов.

Конечно, вы можете разделить свои потоки на уровне состояния, но вам нужно будет поддерживать его, или использовать OOS framework, как Terragrunt, или написать свою собственную оболочку (довольно распространенный подход, кстати) - но это,очевидно, потребуется обернуть использование TF cli в bash / go / python / node / etc.