Проблема с подключением точки доступа EFS к тому ECS

Я столкнулся с проблемой при подключении тома ECS к EFS через точку доступа EFS.

Роль задачи настраивается с помощью ClientWrite, ClientRead и ClientRootAccess для этой файловой системы.

Точка доступа настроена с использованием идентификатора пользователя posix 1001 и идентификатора группы 1001 с разрешением 755.

Кластер и файловая система находятся в правильном VPC.

Но ECS не удалось развернуть задачу с такой ошибкой:

Ответ от демона об ошибке: не удалось скопировать информацию о файле для / var / lib / ecs / volume / {{имя-задачи}}: не удалось выполнить chown / var / lib / ecs / volume / {{имя-задачи}}

Мне удалось развернуть задачу, если я установил идентификатор пользователя POSIX точки доступа и идентификатор группы равным 0, как в корне. Но я чувствую, что это не лучший выбор по соображениям безопасности в общей FS.

После некоторых общих поисков я сформировал гипотезу, что после монтирования тома пользователь контейнера или его хоста был изменен с root, что мешает любым дальнейшим манипуляциям с файлом / каталогом из Dockerfile. В документах по точкам доступа AWS указано, что:

Когда принудительное использование пользователей включено, Amazon EFS заменяет идентификаторы пользователя и группы клиента NFS на идентификатор, настроенный на точке доступа для всех операций файловой системы.

И потому, что я думаю, что /var/lib/ecs/volumes/... на самом деле является либо контейнером, либо каталогом хоста.

Как я мог обойти эту проблему?

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


person Zack Phan    schedule 25.09.2020    source источник
comment
Привет. Я столкнулся с той же проблемой. Я решил это, удалив существующую папку в моем Dockerfile. Кажется, что когда папка существует в образе, докер (или ECS?) Хочет chown / chmod / copy в место назначения ...   -  person toph    schedule 12.02.2021


Ответы (1)


Возможно ли, что у вас есть несоответствие между определенным uid / gid в образе Docker, который вы пытаетесь запустить, и 1001/1001 uid / gid, который вы пытаетесь использовать?

Мы столкнулись с той же ошибкой, когда взяли базовый образ, в котором были определены тома, и попытались изменить uid основного пользователя в образе. Поскольку вы не можете изменить право собственности на файл или разрешения для тома, после его создания демон докера попытается применить исходное владение uid к смонтированному тому EFS, в результате чего точка доступа EFS заблокирует изменение владения / разрешений.

Вы можете проверить это, запустив оболочку в контейнер докера локально или запустив docker exec в ls -la /path/to/container/folder и проверив, установлено ли право собственности на эту папку для вашего пользователя с uid 1001.

person john-shaskin    schedule 07.01.2021