AWS автоматически масштабирует общий веб-сервер Wordpress - AMI против пользовательских скриптов
У меня есть общий хостинг-сервер Wordpress с примерно 50 сайтами на нем, который полностью настраивается через Ansible.
I Я пытаюсь найти хорошую границу между
а) обновлением AMI каждый раз при добавлении сайта или изменении конфигурации, например, это повлияет на виртуальные хосты и файлы пула PHP
б) выполнение некоторых из этих изменений конфигурации с помощью специального сценария запуска и просто предоставление экземпляру большего времени при запуске, прежде чем он получит трафик от балансировщика нагрузки
В настоящее время существует является единичным экземпляром, и автоматическое масштабирование, вероятно, какое-то время не потребуется, чтобы справиться с огромными изменениями объемов трафика. Скорее, существует потребность в использовании автоматического масштабирования для автоматической замены экземпляра, если он выйдет из строя в нерабочее время.
Исходя из моих текущих масштабов для хорошего управления расходами, мне лучше всего запустить c5.large ночью и запланировать автоматическое масштабирование для 2 c5.large в дневное время, что дало бы мне дополнительное преимущество в виде надежности в нескольких зонах доступности по той же цене, что и один c5.xlarge
I ' Я планирую использовать EFS для совместного использования всех файлов Wordpress и, вероятно, Redis для общего управления сеансами, однако это не является темой данного вопроса.
Меня беспокоит решение а), что каждый раз, когда добавляется новый сайт, промежуточный сайт Создано или требуется любое другое изменение конфигурации, мне нужно создать новый экземпляр, внести изменения, создать AMI и повернуть AMI в мою группу автомасштабирования. Даже если бы он был полностью автоматизирован, я бы ожидал, что это займет слишком много времени, чтобы обеспечить приемлемую скорость обработки.
Вместо этого я мог бы внести эти изменения в небольшом количестве экземпляров и обновить AMI программно. Тогда он только стал бы использоваться Мне нужно создать новый экземпляр, внести изменения, создать AMI и повернуть AMI в мою группу автомасштабирования. Даже если бы он был полностью автоматизирован, я бы ожидал, что это займет слишком много времени, чтобы обеспечить приемлемую скорость обработки.
Вместо этого я мог бы внести эти изменения на небольшом количестве экземпляров и обновить AMI программно. Тогда он только стал бы использоваться Мне нужно создать новый экземпляр, внести изменения, создать AMI и повернуть AMI в мою группу автомасштабирования. Даже если бы он был полностью автоматизирован, я бы ожидал, что это займет слишком много времени, чтобы обеспечить приемлемую скорость обработки.
Вместо этого я мог бы внести эти изменения в небольшом количестве экземпляров и обновить AMI программно. Тогда он только стал бы использоваться - в случае отказа или - когда выполняется тест восстановления или - когда разработка тестируется на тестовом стеке
Это хороший подход к управлению средой общего хостинга?
Я планирую использовать EFS для совместного использования всех файлов Wordpress и, вероятно, Redis для общего управления сеансами, однако это не тема данного вопроса.
Хм, жаль. Я как раз собирался предложить вам выгрузить всю конфигурацию и пользовательские данные из экземпляров в надежное общее хранилище и использовать экземпляры исключительно как веб-серверы без сохранения состояния - легко масштабируемые, легко заменяемые. Преобразование из локального хранилища в EFS легко (на самом деле это не реорганизация системы, а только перемещение некоторых каталогов в EFS) и может быть выполнено с очень небольшим временем простоя.
Все файлы конфигурации Apache / Nginx / PHP и Wordpress, а также загруженные пользовательские мультимедийные файлы будут затем сохранены в общей файловой системе, и экземпляры будут самостоятельно настраиваться оттуда.
В любом случае, если вы сразу отклоните лучшее и очевидное решение нам остается предложить несколько худших вариантов. У меня есть шаблон CloudFormation, который делает что-то близкое к тому, что вы хотите:
- Экземпляр EC2 находится в группе AutoScaling min = 1 / max = 1. Т.е. если он умирает, он автоматически перезапускается.
- Каждую ночь Lambda создает моментальный снимок экземпляра в качестве нового AMI и обновляет Конфигурацию запуска ASG новым идентификатором AMI. Т.е. если экземпляр умирает на следующий день, он будет развернут из моментального снимка прошлой ночи.
Это хорошо работает для экземпляров, которые не меняются очень часто. Например. наша CMS имеет все данные в базе данных и все файлы конфигурации приложения и пользователя в EFS, и только некоторые пакеты и файлы конфигурации системы обновляются на экземпляре время от времени, но не очень часто.
Может что-то подобное сработает для вас? Однако усилия по реализации этого, скорее всего, выше, чем переход на EFS в первую очередь, и результат тоже не такой хороший и устойчивый.
Надеюсь, что это поможет :)