Назад | Перейти на главную страницу

Почему для настраиваемого образа CodeBuild требуется настройка aws, а не управляемая?

У меня есть AWS CodePipeline с этапом сборки с использованием CodeBuild. Раньше я использовал управляемый образ для этого задания сборки, и я мог без проблем использовать следующую команду:

aws ecr get-login --no-include-email --region us-east-1

Теперь я переключился на собственный образ, чтобы сократить время сборки. Команда не удалась, и после устранения неполадок я понял, что в настраиваемом образе не установлен AWS CLI. Теперь, когда AWS CLI установлен, указанная выше строка входа завершается с кодом ошибки 127. Я считаю, что это потому, что я выполнил все шаги в это руководство по настройке aws, кроме aws configure.

Я могу настроить, но это неудобно, потому что мне нужно предпринять дополнительные шаги, чтобы скрыть секрет и так далее.

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

Также хочу отметить, что CodeBuild и CodePipeline в настоящее время не используются тегами в ServerFault, поэтому дайте мне знать, если я предпочитаю другой StackExchange. ServerFault был рекомендован этот пост в мета.

Нет никакой разницы. Пользовательские контейнеры CodeBuild не нужно использовать aws configure если все остальные факторы сборки настроены соответствующим образом.

Проблема, которую вы описываете, объясняется конфигурацией ECR, а не вариацией CodeBuild.

Выполните следующее на управляемом образе:

  - echo $AWS_ACCESS_KEY_ID
  - echo $AWS_SECRET_ACCESS_KEY
  - echo $AWS_SESSION_TOKEN

  - cd /
  - ls
  - cd ~
  - ls
  - cd ~/.aws
  - ls

Обратите внимание, что CodeBuild заблокирован. Он не будет отображать необходимые переменные среды и не позволит вам увидеть физические файлы. Возможно, это указывает на разницу в механизме: вы пытаетесь использовать переменные среды, но управляемый образ снабжен физическими файлами, поэтому управляемый образ не нужно запускать. aws configure.

Похоже, это указывает на то, что вы также должны подготовить настраиваемый контейнер с предварительно настроенными aws, но это означает, что вы будете фиксировать ECR или где-либо еще с простым текстом KEY_ID и ACCESS_KEY, исключая очень сложные обходные пути. Кроме того, вы не можете предварительно настроить AWS_SESSION_TOKEN, так как через некоторое время он истечет. Опять же, вы можете настроить некоторые системы, чтобы дать фиксированному сеансу бесконечный тайм-аут, но это антипаттерн, потому что тайм-аут токена сеанса является функцией безопасности.

Вместо того, чтобы делать все это, проверьте разрешения ECR и установку докера:

1 - Перейдите к разрешениям ECR и добавьте новый оператор разрешения. Раньше вы, вероятно, подписались официальный учебник который предоставляет разрешения ECR для codebuild.amazonaws.com. В дополнение к этому, поскольку ваша сборка находится в конвейере, добавьте codepipeline.amazonaws.com и любые другие вовлеченные объекты IAM должны быть добавлены в раздел разрешений объектов IAM.

2 - Для докера просто убедитесь, что он установлен. Вы упоминаете, что в настраиваемом образе отсутствовал aws cli и что вы добавили его, но в вашем настраиваемом образе также, вероятно, отсутствовал докер, и я не видел, чтобы вы подтвердили, что он был установлен. В качестве примера того, как будет выглядеть ошибка, упомянутая вами строка выдаст что-то вроде следующего, если докер не установлен в Ubuntu:

/codebuild/output/tmp/script.sh: 4: /codebuild/output/tmp/script.sh: docker: not found

Если докер установлен, также убедитесь, что он работает.

Последняя проблема, если вы работаете в организации, может заключаться в том, что существует неочевидная политика безопасности AWS, которая блокирует вас. Например, включение разрешений с подстановочными знаками считается небезопасным, поэтому одна компания, в которой я работал, автоматически откатывала пользователей и политики IAM, которые обеспечивали доступ с подстановочными знаками к любому сервису AWS. По иронии судьбы, указание конкретных разрешений ECR для пользователя IAM работало, а включение всех разрешений в этом случае не удалось.