WordPress на AWS с ECS, EFS и ELB возвращается 502

Question

У меня есть сайт на основе WordPress 4.9.6, который развернут с использованием AWS ECS, а EFS используется для хранения файлов WordPress. В качестве базы данных я использую экземпляр AWS Aurora MySQL 5.7. Я также настроил балансировщик нагрузки приложения для доступа к контейнерам экземпляров WordPress. (Подробнее о настройке ниже.)

Обзор проблемы

Эта настройка, кажется, работает в большинстве случаев. Т.е. я умею делать GET запросы на сайте. Я могу войти в систему, увидеть панель инструментов и часто успешно обновлять. Проблема, с которой я сталкиваюсь, заключается в том, что мои попытки обновления также часто приводят к получению ответа 502 Bad Gateway, когда я фиксирую свое обновление, т.е. POST /wp-admin/post.php,

конкретика

Настроить

Во-первых, моя программа записи экземпляров БД заполняется дампом моей локальной базы данных разработчиков. URL-адреса базы данных, указывающие на сам сайт, например siteurl а также home в таблице опций есть значения с https,

EFS была создана с режимом производительности общего назначения. Я изначально пробовал с режимом Max I / O, но ресурсы предлагали скорее использовать прежний режим. Однако переключение режима производительности не меняет частоту ошибок 502.

Мои экземпляры кластера Amazon Linux ECS подготовлены для монтирования тома EFS с использованием NFSv4.1, как предложено AWS (mount опции nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2).

У меня есть изображение Docker, полученное из официального изображения WordPress, в котором я обновляю исходное изображение /usr/src/wordpress с моим пользовательским контентом. Пользовательский контент включает в себя обновленный wp_config.php в котором я поставил $_SERVER['HTTPS']='on';

Собирая части воедино, мое определение задачи ECS использует мой собственный образ Docker и монтирует каталог на моем диске EFS как том Docker в контейнере Docker. Суть в том, что когда я создаю службу ECS с определением задачи, контейнер раскручивается и пишет в /var/www/html который я впоследствии могу видеть в моем диске EFS. Все это выглядит хорошо и модно.

Мои контейнеризованные экземпляры WordPress затем успешно регистрируются в целевой группе, которую я ранее настроил для балансировщика нагрузки приложения.

Затем я могу получить доступ к своему сайту по протоколу https. Если я пытаюсь использовать http, я перенаправляюсь на https, как и планировалось. Я могу открыть целевую страницу. Когда я вхожу в систему, я пытаюсь редактировать целевую страницу.

проблема

Вот где я сталкиваюсь с настоящей проблемой. Часто, но не всегда, когда я делаю обновление на целевой странице и нажимаю кнопку Обновить, я получаю ответ 502 Bad Gateway на POST /wp-admin/post.php запрос. Также часто, когда я начинаю редактировать и GET /wp-admin/post.php?post=2&action=edit запрашивается я получаю те же 502.

Я не вижу большого паттерна, когда получаю и не получаю 502. Я попытался обновить как текстовое содержимое, так и добавить изображения на целевую страницу. 502 иногда бывает, но не всегда в обоих случаях.

Также я попытался устранить проблему, так как подозревал, что это связано с использованием EFS и последующими проблемами синхронизации между двумя экземплярами ECS, которые я настроил для теста. Были предприняты следующие попытки, не видя значительного улучшения.

• Добавить опцию монтирования sync в соответствии с руководством пользователя EFS, чтобы избежать кэширования в экземпляре ECS
• Увеличьте время простоя балансировщика нагрузки

Наконец, я сократил количество задач обслуживания ECS с 2 до 1, но проблема все еще сохраняется.

Как сообщение об ошибке в консоли браузера при встрече с 502 я часто, возможно, всегда вижу следующее: The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol.

Итак, кто-нибудь знает, что делать дальше и где искать указания на причину проблемы?

Answer 1

Похоже, после этого

https://wordpress.org/support/article/editing-wp-config-php/

Помогло решить мою проблему, обычный период времени, в который время ожидания истекло. TL; DR; В процессе сборки Dockerfile я добавил следующие строки

# Copy php.ini Over to Container
COPY php.ini /usr/local/etc/php/
COPY phpinfo.php /var/www/html/wp-admin/
COPY .htaccess /var/www/html

Php.ini

upload_max_filesize = 500M
post_max_size = 256M
memory_limit = 256M
max_execution_time = 1800
max_input_time = 180
max_input_vars = 5000

.htaccess

php_value upload_max_file 500M
php_value post_max_size 256M
php_value memory_limit 256M
    

phpinfo.php Доступ к нему можно получить, перейдя по адресу /wp-admin/phpinfo.php. Он предоставит вам сводную информацию о текущей конфигурации WP, чтобы узнать, были ли внесены изменения или нет, также отлично подходит для устранения неполадок.

<?php
phpinfo();
?>

Вы можете обновить определения задач с помощью нового контейнера, встроенного в ECR (не уверены, что вы это автоматизировали?)

Или просто получите доступ к EC2 через хост Bastion, а затем docker exec -it и отредактируйте файлы вручную. Кажется, что у вас есть EFS, он будет статическим.

Это помогло мне решить проблему с тайм-аутом. Дай мне знать, как дела!