Блог

В документации AWS CLI v2 представлены опции и руководство по установке / настройке cli с помощью docker. Руководство достаточно простое, чтобы следовать, и контейнер отлично работает с ключевыми элементами, являющимися

• монтирование локального .aws каталога для предоставления учетных данных контейнеру
• требуется монтаж $pwd для любых операций ввода-вывода

Я использую его для s3 и понял, что любые файлы, которые я копирую на свой локальный диск с s3, отображаются как принадлежащие root .

 >docker run --rm -v "$HOME/.aws:/root/.aws:rw" -v "$PWD:/aws:rw" amazon/aws-cli s3 cp s3://xxx/hello .
download: s3://xxx/hello to ./hello
>ls -l
total 0
-rw-r--r-- 1 root root 0 Oct  2 09:43 hello
  

Это имеет смысл, поскольку процесс выполняется как root в контейнере, но не идеально. В контейнере нет другого пользователя, поэтому я не могу просто запустить «как» kirk .

 >docker run --rm -u kirk -v "$HOME/.aws:/root/.aws:rw" -v "$PWD:/aws:rw" amazon/aws-cli s3 cp s3://xxx/hello .
docker: Error response from daemon: unable to find user kirk: no matching entries in passwd file.
  

Есть ли способ смонтировать том «как» пользователя или путем делегирования пользовательского доступа к контейнеру? Мне все равно (и я не уверен, что могу контролировать) пользователя внутри контейнера, но я бы хотел, чтобы процесс выполнялся в контексте пользователя в хост-системе. Какой здесь правильный подход?

Вы можете запустить контейнер от имени пользователя, которого нет внутри изображения, используя числовые значения для -u ${UID}:${GID} . Например:

 docker run --rm 
    -u 1000:1000 
    -e AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} 
    -e AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} 
    -v ${PWD}:/aws:rw 
    amazon/aws-cli s3 cp s3://devops-example/lolz.gif .
  

… скопирует файл как UID 1000 GID 1000.

Примечание: использование AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY переменных среды и для передачи учетных данных вместо монтирования файла учетных данных. Полный список переменных среды доступен здесь .