Недавно у меня появилась большая разница при запуске приложения на AWS ECS по сравнению с docker или docker-compose; У приложения нет прав на запись! Ожидается, что такое же поведение будет развиваться в других местах; Если приложение в контейнере может сохранять файлы, создавать каталоги и т. Д., Я ничего не ожидал, когда контейнер будет опубликован в AWS.
Моя установка довольно обычная, у меня есть gitlab-ci, который я предоставляю yaml-файл с задачами / заданиями / этапами для развертывания. Я использую облачную информацию и aws cli. Приложение развернуто; Выглядит нормально, пока я не попытаюсь запустить одну из его функций, в данном случае для Wordpress, установить плагин; Это работает абсолютно нормально при запуске через docker-compose в моей среде разработки, docker-compose запускает те же контейнеры Dockerfile, что и AWS ECS.
Возникает вопрос, почему такая разница?
Вот Dockerfile, nginx, который обслуживает Wordpress (есть также связанный контейнер, который запускает php-fpm, но не уверен, подходит ли он):
FROM nginx:1.17.4-alpine
WORKDIR /var/www/html
RUN apk --no-cache add --update curl iputils
COPY ./moola-wordpress-cms /var/www/html
COPY ./.env /var/www/.env
COPY ./.docker/nginx/wordpress/default.conf /etc/nginx/conf.d/default.conf
COPY ./.docker/nginx/wordpress/php-fpm.conf /etc/nginx/php-fpm.conf
# permissions
RUN set -x
RUN addgroup -g 82 -S www-data || echo "Group already exists!"
RUN adduser -u 82 -D -S -G www-data www-data && exit 0 || echo "User already exists!"
RUN chown -R www-data:www-data /var/www || echo "Failed to change ownership of www"
RUN find /var/www/html/ -type d -exec chmod 755 {} +
RUN find /var/www/html/ -type f -exec chmod 644 {} +
EXPOSE 80
На стороне приложения есть файл wp-config.php, в котором я помещаю возможность принудительной установки плагинов напрямую:
define('FS_METHOD', 'direct')
Причина в том, что как только я вхожу в административную панель wordpress wp-admin и, скажем, попробуйте установить плагин, меня просят предоставить данные ftp (похоже, это происходит потому, что приложение обнаруживает, что у него недостаточно разрешений, или запускает ложное срабатывание, предотвращающее запись напрямую в файловую систему по какой-то причине), поэтому необязательный 'FS_METHOD' -> 'direct' пропускает эту проверку и заставляет wordpress попытаться написать. Когда я пытаюсь установить, все выглядит нормально, пока я не попробую активировать и не получу:
Sorry, you are not allowed to access this page.
Понимая, что у меня куча 403 статус в консоли, что означает «запрещено», подтверждая выдачу разрешений.
Проблема здесь в том, чтобы выяснить, как заставить AWS ECS вести себя в соответствии с тем, что предоставляет docker или docker-compose, когда я его использую, то есть полностью работающее приложение во время выполнения, которое имеет полный контроль над приложением.
Я предполагаю, что, хотя Docker запускает контейнер с учетными данными root, AWS ECS этого не делает и, вероятно, должен будет назначить пользователя в файле докеров для решения этой проблемы, что не воспроизводится в моей среде разработки и может тестировать только напрямую. в AWS ECS, чтобы увидеть.
Мне не удалось найти никакой документации, раскрывающей, как AWS ECS запускает контейнеры, какой пользователь назначен контейнеру и есть ли у нас вообще какой-либо контроль.
Я проведу небольшое тестирование и, надеюсь, отправлю ответ, если найду его.
Спасибо!
НОТЫ:
Протестированный привилегированный режим, безуспешно https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html