Монтирование корзины GCS в гибкой среде AppEngine

Я пытаюсь смонтировать ведро GCS в приложении AppEngine Flexible Environment с помощью gcsfuse.

Мои файлы Dockerfiles включают следующее:

# gscfuse setup
RUN echo "deb http://packages.cloud.google.com/apt cloud-sdk-jessie main" | tee /etc/apt/sources.list.d/google-cloud.sdk.list
RUN echo "deb http://packages.cloud.google.com/apt gcsfuse-jessie main" | tee /etc/apt/sources.list.d/gcsfuse.list
RUN wget -qO- https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
RUN apt-get update && apt-get install -y --no-install-recommends google-cloud-sdk gcsfuse strace
RUN gcsfuse --implicit-dirs my_bucket my_dir

Я взял большую часть этого здесь. Это просто стандартный способ установки gcsfuse плюс --no-install-recommends.

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

Вот что сбивает с толку. Если я запускаю gcloud app instances ssh "<instance>", затем container_exec gaeapp /bin/bash, тогда gcsfuse my_bucket my_dir работает нормально.

Однако, если я запустил gcloud app instances ssh "<instance>" --container gaeapp, тогда gcsfuse my_bucket my_dir выйдет из строя с этой ошибкой:

fusermount: failed to open /dev/fuse: Operation not permitted

Это та же ошибка, которую я получаю, если запускаю gcsfuse как подпроцесс в моем main.py.

Основываясь на этой неразрешенной теме, я запустил strace -f и увидел ту же проблему, что и этот пользователь. сделал, проблема EPERM.

[pid    59] open("/dev/fuse", O_RDWR)   = -1 EPERM (Operation not permitted)

Каким бы способом я ни зашел в контейнер (или если я запустил подпроцесс из main.py), я являюсь пользователем root. Если я запускаю export, я вижу разные вары, поэтому есть некоторая разница в том, что запускается, но все остальное для меня выглядит одинаково.

Другие предложения, которые я видел, включают использование флагов gcsfuse -o allow_other и -o allow_root. Это не сработало.

Это может быть подсказка в том факте, что если я попытаюсь запустить umount при входе в систему, который не может запустить gcsfuse, будет написано "must be superuser to unmount", даже если я являюсь пользователем root.

Похоже, есть какие-то настройки безопасности, которые я не понимаю. Однако, поскольку теоретически я мог бы заставить main.py запустить внешнюю программу для входа в систему и запуска gcsfuse для меня, похоже, должен быть способ заставить ее работать без необходимости этого делать.


person hgbrian    schedule 07.10.2017    source источник


Ответы (1)


Команды RUN предназначены для создания нового слоя для вашего файла докеров, поэтому вы фактически запускаете эту команду во время создания образа, что не нравится системе сборки Flex.

Я не уверен, почему оболочка в приложении не сработала, вы можете попробовать 'sudo' в подпроцессе python или, возможно, вытолкнуть его из кода приложения, добавив 'gcsfuse setup &&' к ENTRYPOINT в dockerfile.

person Jon Donovan    schedule 11.10.2017
comment
Спасибо, Джон. Я пробовал эти идеи. Точка входа у меня не работала (я выполняю команду gcsfuse && gunicorn). Попытка вызвать sudo из подпроцесса python не сработала, потому что sudo не был найден (в любом случае пользователь является пользователем root). Для меня главной загадкой является разница между sshing для экземпляра, затем запуском container_exec (gcsfuse работает) и sshing с --container gaeapp (gcsfuse не работает). - person hgbrian; 12.10.2017