Почему пользовательский образ 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 был рекомендован этим постом на мета.

Источник

1 ответ

Нет никакой разницы. Пользовательские контейнеры 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 и что вы добавили его, но в вашем пользовательском образе также, вероятно, отсутствует докер, и я не видел, чтобы вы подтвердили, что он установлен. В качестве примера того, как будет выглядеть ошибка, указанная вами строка выдает что-то похожее на приведенное ниже, если docker не установлен в Ubuntu:

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

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

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

Источник
Другие вопросы по тегам