Назад | Перейти на главную страницу

Лучший способ автоматического масштабирования пользовательского образа Debian 9 при изменении кодовой базы в AWS

Я активировал группу автоматического масштабирования (из конфигурации запуска) с настроенным образом Debian9 в AWS, где я предварительно установил программные пакеты, такие как Apache, Memcache, Chrony, вместе с базой кода PHP и другими необходимыми пакетами. Это отлично работает, пока я не изменю кодовую базу PHP. Каждый день, по крайней мере, один раз кодовая база PHP изменяется вручную на сервере.

Каждый раз, когда запускается автоматическое масштабирование на основе заранее определенных показателей (таких как загрузка памяти, процессор и т. Д.), Я хотел бы развернуть еще один сервер. Этот вновь созданный сервер должен иметь обновленную базу кода, чтобы оба сервера были синхронизированы.

Вопрос: Как этого добиться без простого копирования файлов с одного сервера на другой, когда второй сервер запускается и работает?

Одним из способов может быть копирование файлов из / var / www / * с помощью rsync со старого сервера на вновь созданный сервер. Я считаю, что это не лучшее решение. Делать моментальные снимки каждый час нельзя, поскольку это увеличивает эксплуатационные расходы.

Как лучше всего обновить пользовательское изображение при изменении кодовой базы php? Может ли кто-нибудь предложить / порекомендовать мне лучший способ сделать? Я считаю, что в этом сообществе есть эксперты, которые проделывали подобные вещи в AWS.

Разместите свой PHP-код на Amazon S3. Прекратите обновлять экземпляр EC2 вручную.

После запуска вашего экземпляра EC2 загрузите код PHP с S3. Таким образом, все недавно запущенные экземпляры EC2 будут иметь обновленный код.

Когда вы обновляете свой PHP-код:

  1. Обновите свой PHP-код в S3,
  2. Запустите новый экземпляр EC2 (он получит новый код),
  3. Удалите старый экземпляр EC2.

Другой вариант - использовать Elastic Beanstalk для вашего PHP-приложения вместо самостоятельного управления экземплярами EC2.

Есть несколько способов сделать это:

  • Поместите весь свой код в EFS и смонтируйте его на своих серверах (проще всего, но производительность может снизиться, если вы используете большое / сложное приложение, которое включает в себя множество модулей - вы можете использовать php opcache для смягчения этого).
  • Запекайте свой код в новом AMI при каждом выпуске
  • Сделайте git pull при загрузке
  • Настройте сборку кода для сборки кода и загрузки в S3, а затем используйте CodePipeline для развертывания его в экземплярах EC2. Вы можете автоматизировать это, чтобы он запускался автоматически при каждом нажатии на github (вот статья, которую я написал об использовании Codebuild с PHP )
  • Используйте докер и ECS, а не EC2 (особенно новый ECS Fargate, который позволит вам полностью отказаться от инстансов EC2)

Если ваше приложение использует сеансы, вам необходимо поделиться ими между своими экземплярами - лучший способ, по нашему опыту, - использовать DynamoDB

Если у вас есть код в репо, то имеет смысл получить код прямо из репо. Этот подход имеет преимущество по сравнению с наличием кода на S3: вы будете извлекать только изменения с момента создания AMI, а не весь каталог проекта. Быстрее и дешевле.