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

На данный момент у меня есть удаленный бэкэнд terraform в s3 и Dynamodb, назовем его моей основной учетной записью. Затем у меня есть среды разработки / тестирования и т. Д. В отдельных учетных записях. Развертывание terraform в настоящее время выполняется на моем локальном компьютере (Mac) и использует учетную запись aws 'master' и ее учетные данные, которые, в свою очередь, принимают роль в целевой учетной записи развертывания для создания ресурсов в соответствии с:

provider "aws" { // tell terraform which SDK it needs to load
  alias  = "target"
  region = var.region
  assume_role {

  role_arn = "arn:aws:iam::${var.deployment_account}:role/${var.provider_env_deployment_role_name}"
  }
}

Я создаю ряд сервисов ecs с развертыванием Fargate. Образы контейнеров создаются в отдельных репозиториях с помощью GitHub Actions и сохраняются как пакеты GitHub. Эти имена и версии пакетов развертываются после создания ecr и службы (возможно, это не идеально), и именно здесь возникают проблемы.

Процесс состоит в том, чтобы извлечь изображение из пакетов GitHub, пометить его тегами и загрузить в ecr, используя несколько выполнений local-exec null_resource. Прекрасно работает автономно, но имеет проблемы в процессе терраформирования. Я думаю, причина в том, что другие ресурсы используют вышеуказанного провайдера для получения разрешений, но поскольку null_resource не принимает провайдера, он не может получить разрешения таким образом. Итак, я передавал значения aws creds в оболочку. Не уверен, что это действительно безопасно, но в настоящее время это спорный вопрос, так как он тоже не работает. Я получаю такую ​​ошибку:

Error saving credentials: error storing credentials - err: exit status 1, out: `error storing credentials - err: exit status 1, out: `The specified item already exists in the keychain.``

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

В качестве альтернативы, может быть, просто исчезнет брелок, и мой процесс будет работать нормально? Безопасный ??

Это нормально для этого сценария, но на самом деле это не общий подход для всех моих вариантов использования.

Вскоре я собираюсь начать развертывание нескольких лямбда-функций aws с контейнерами докеров. Не делал этого раньше, но похоже, что процесс будет следующим: создать ecr, развернуть контейнер, развернуть лямбда-функцию. Это действительно означает, что развертывание контейнера должно быть неотъемлемой частью развертывания terraform, которое возвращается к моей проблеме с local-exec ??

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

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

0
Chanonry 28 Мар 2021 в 21:15

2 ответа

Лучший ответ

Как предложил Кевин Бакс, ответ ...

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

Действие загрузило переменные среды из секретов GitHub для учетных данных моей «основной» учетной записи aws.

AWS_ACCESS_KEY_ID: ${{ secrets.NK_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.NK_AWS_SECRET_ACCESS_KEY }}

Я также загрузил учетные данные целевых учетных записей в переменные среды таким же образом, НО с префиксом TF_VAR.

TF_VAR_DEVELOP_AWS_ACCESS_KEY_ID: ${{ secrets.DEVELOP_AWS_ACCESS_KEY_ID }}
TF_VAR_DEVELOP_AWS_SECRET_ACCESS_KEY: ${{ secrets.DEVELOP_AWS_SECRET_ACCESS_KEY }}

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

variable "DEVELOP_AWS_ACCESS_KEY_ID" {
  description = "access key for the dev account"
  type = string
}
variable "DEVELOP_AWS_SECRET_ACCESS_KEY" {
  description = "secret access key for the dev account"
  type = string
}

И когда я запускаю сценарий оболочки с локальным exec:

resource "null_resource" "image-upload-to-importcsv-ecr" {

   provisioner "local-exec" {
      command = "./ecr-push.sh ${var.DEVELOP_AWS_ACCESS_KEY_ID} ${var.DEVELOP_AWS_SECRET_ACCESS_KEY} "
   }
}

Затем в сценарии я могу использовать эти аргументы для установки учетных данных, например

AWS_ACCESS=$1
AWS_SECRET=$1
.....
export AWS_ACCESS_KEY_ID=${AWS_ACCESS}
export AWS_SECRET_ACCESS_KEY=${AWS_SECRET}

И у сценария теперь есть учетные данные, чтобы делать что угодно.

0
Chanonry 30 Мар 2021 в 20:34

Я знаю, что это неполный ответ, но вы должны получать свои кредиты AWS из переменных среды. Я действительно не понимаю, нужны ли вам учетные данные для разных учетных записей, но если вы это сделаете, поменяйте их местами во время выполнения вашего действия. См. https://docs.aws.amazon.com /cli/latest/userguide/cli-configure-envvars.html. Terraform должен их подобрать и автоматически использовать для доступа к AWS.

1
Kevin Buchs 30 Мар 2021 в 02:54