Как передать переменную среды токена в модуль провайдера? - PullRequest
0 голосов
/ 29 декабря 2018

Я создал скрипт Terraform, который может успешно раскрутить 2 капли DigitalOcean как узлы и установить мастер Kubernetes на одном и рабочий на другом.

Для этого он использует переменную среды оболочки bash, котораяопределяется как:

export DO_ACCESS_TOKEN="..."
export TF_VAR_DO_ACCESS_TOKEN=$DO_ACCESS_TOKEN

Затем его можно использовать в сценарии:

provider "digitalocean" {
  version = "~> 1.0"
  token   = "${var.DO_ACCESS_TOKEN}"
}

Теперь, когда все эти файлы находятся в одном каталоге, становится немного грязно.Поэтому я пытаюсь реализовать это в виде модулей.

Таким образом, у меня есть модуль provider, предлагающий доступ к моей учетной записи DigitalOcean, модуль droplet, раскручивающий каплю с заданным именем, *Модуль 1013 * и модуль Kubernetes worker.

Я могу запустить команду terraform init.

Но при запуске команды terraform plan он запрашивает у меня токен провайдера (который онпо праву не делал до того, как я реализовал модули):

$ terraform plan
provider.digitalocean.token
  The token key for API operations.

  Enter a value: 

Кажется, что он не может найти токен, определенный в среде оболочки bash.

У меня есть следующие модули:

.
├── digitalocean
│   ├── droplet
│   │   ├── create-ssh-key-certificate.sh
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── vars.tf
│   └── provider
│       ├── main.tf
│       └── vars.tf
└── kubernetes
    ├── master
    │   ├── configure-cluster.sh
    │   ├── configure-user.sh
    │   ├── create-namespace.sh
    │   ├── create-role-binding-deployment-manager.yml
    │   ├── create-role-deployment-manager.yml
    │   ├── kubernetes-bootstrap.sh
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── vars.tf
    └── worker
        ├── kubernetes-bootstrap.sh
        ├── main.tf
        ├── outputs.tf
        └── vars.tf

В моем каталоге проектов у меня есть файл vars.tf:

$ cat vars.tf 
variable "DO_ACCESS_TOKEN" {}
variable "SSH_PUBLIC_KEY" {}
variable "SSH_PRIVATE_KEY" {}
variable "SSH_FINGERPRINT" {}

, и у меня есть файл provider.tf:

$ cat provider.tf 
module "digitalocean" {
  source          = "/home/stephane/dev/terraform/modules/digitalocean/provider"
  DO_ACCESS_TOKEN = "${var.DO_ACCESS_TOKEN}"
}

И он вызывает *Модуль 1037 * определен как:

$ cat digitalocean/provider/vars.tf 
variable "DO_ACCESS_TOKEN" {}

$ cat digitalocean/provider/main.tf 
provider "digitalocean" {
  version = "~> 1.0"
  token   = "${var.DO_ACCESS_TOKEN}"
}

ОБНОВЛЕНИЕ: предоставленное решение привело меня к организации моего проекта следующим образом:

.
├── env
│   ├── dev
│   │   ├── backend.tf -> /home/stephane/dev/terraform/utils/backend.tf
│   │   ├── digital-ocean.tf -> /home/stephane/dev/terraform/providers/digital-ocean.tf
│   │   ├── kubernetes-master.tf -> /home/stephane/dev/terraform/stacks/kubernetes-master.tf
│   │   ├── kubernetes-worker-1.tf -> /home/stephane/dev/terraform/stacks/kubernetes-worker-1.tf
│   │   ├── outputs.tf -> /home/stephane/dev/terraform/stacks/outputs.tf
│   │   ├── terraform.tfplan
│   │   ├── terraform.tfstate
│   │   ├── terraform.tfstate.backup
│   │   ├── terraform.tfvars
│   │   └── vars.tf -> /home/stephane/dev/terraform/utils/vars.tf
│   ├── production
│   └── staging
└── README.md

С настраиваемой библиотекой провайдеров, стеков и модулей, наслоенных как:

.
├── modules
│   ├── digitalocean
│   │   └── droplet
│   │       ├── main.tf
│   │       ├── outputs.tf
│   │       ├── scripts
│   │       │   └── create-ssh-key-and-csr.sh
│   │       └── vars.tf
│   └── kubernetes
│       ├── master
│       │   ├── main.tf
│       │   ├── outputs.tf
│       │   ├── scripts
│       │   │   ├── configure-cluster.sh
│       │   │   ├── configure-user.sh
│       │   │   ├── create-namespace.sh
│       │   │   ├── create-role-binding-deployment-manager.yml
│       │   │   ├── create-role-deployment-manager.yml
│       │   │   ├── kubernetes-bootstrap.sh
│       │   │   └── sign-ssh-csr.sh
│       │   └── vars.tf
│       └── worker
│           ├── main.tf
│           ├── outputs.tf
│           ├── scripts
│           │   └── kubernetes-bootstrap.sh -> /home/stephane/dev/terraform/modules/kubernetes/master/scripts/kubernetes-bootstrap.sh
│           └── vars.tf
├── providers
│   └── digital-ocean.tf
├── stacks
│   ├── kubernetes-master.tf
│   ├── kubernetes-worker-1.tf
│   └── outputs.tf
└── utils
    ├── backend.tf
    └── vars.tf

1 Ответ

0 голосов
/ 31 декабря 2018

Самый простой вариант, который у вас есть - просто не определять провайдера, а просто использовать переменную окружения DIGITALOCEAN_TOKEN, как указано в документах провайдера Digital Ocean.

Это будетвсегда используйте самую последнюю версию провайдера Digital Ocean, но в противном случае она будет функционально такой же, как в настоящее время.

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

Например, у вас может быть структура каталогов, которая выглядит примерно так:

.
├── modules
│   └── kubernetes
│       ├── master
│       │   ├── main.tf
│       │   ├── output.tf
│       │   └── variables.tf
│       └── worker
│           ├── main.tf
│           ├── output.tf
│           └── variables.tf
├── production
│   ├── digital-ocean.tf -> ../providers/digital-ocean.tf
│   ├── kubernetes-master.tf -> ../stacks/kubernetes-master.tf
│   ├── kubernetes-worker.tf -> ../stacks/kubernetes-worker.tf
│   └── terraform.tfvars
├── providers
│   └── digital-ocean.tf
├── stacks
│   ├── kubernetes-master.tf
│   └── kubernetes-worker.tf
└── staging
    ├── digital-ocean.tf -> ../providers/digital-ocean.tf
    ├── kubernetes-master.tf -> ../stacks/kubernetes-master.tf
    ├── kubernetes-worker.tf -> ../stacks/kubernetes-worker.tf
    └── terraform.tfvars

У этого макета есть 2 "местоположения", в которых вы будете выполнятьДействия Terraform (например, plan / apply): постановка и производство (приведено в качестве примера поддержания максимально схожих вещей с небольшими различиями между средами).Эти каталоги содержат только файлы с символьными ссылками, кроме файла terraform.tfvars, который позволяет изменять только несколько ограниченных элементов, сохраняя при этом промежуточные и производственные среды.

Файл поставщика, содержащий символьные ссылки, будет содержать любого конкретного поставщикаконфигурация (в случае AWS это обычно включает регион, в котором должны быть созданы вещи, в Digital Ocean это, вероятно, просто ограничивает версию поставщика, которую следует использовать), но может также содержать частичную конфигурацию состояния Terraform, чтобы минимизировать то, чтоКонфигурацию, которую вам необходимо пройти, когда вы запускаете terraform init или даже просто устанавливаете требуемую версию Terraform.Пример может выглядеть примерно так:

provider "digitalocean" {
  version = "~> 1.0"
}

terraform {
  required_version = "=0.11.10"

  backend "s3" {
    region         = "eu-west-1"
    encrypt        = true
    kms_key_id     = "alias/terraform-state"
    dynamodb_table = "terraform-locks"
  }
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...