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