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