Мультисайт на AWS EC2

Я работаю над многосайтовым приложением, предназначенным для полноценного запуска Amazon Web Services. Из-за своего характера, он будет иметь значительные всплески трафика, за которыми последуют длительные периоды низкого трафика, поэтому необходимость масштабирования экземпляров EC2 является обязательной.

Итак, структура, которую я имею в виду:

                                _____________________
                                Elastic Load Balancer
                                _____________________
                                          |
                                          V
                                _____________________
                          []   []   []   []   []   []   []
                                   Autoscaling EC2
                                With Dynamic Virtual
                                        Hosts
                                Global Business Logic
                                _____________________
                                /         |          \
                               /          |           \
                       Amazon RDS         S3        Site Views?
                      One Per Site       for      
                                     static files

Теперь у меня есть два вопроса:

  1. Где я должен хранить специфичные для сайта файлы "views" или "theme"? Достаточно ли быстр S3, чтобы справиться с этим? Или мне действительно нужно создавать новые AMI каждый раз, когда мне нужно настроить тему определенного сайта?
  2. Файлы конфигурации. Поскольку каждый сайт подключается к отдельной базе данных, каждому из них нужны свои собственные файлы конфигурации. Снова, я должен сохранить их на S3, и все экземпляры EC2 время от времени проверяют S3 на обновленные конфигурации?

Я чувствую, что есть какое-то недостающее звено, о котором я не знаю. В основном я видел людей, которые советуют вам создать новый AMI, закрыть текущие экземпляры и заменить их новыми. Это кажется тяжелым бременем, особенно в многосайтовой структуре, где эти изменения могут относиться только к одному сайту. Есть ли предпочтительный метод обработки таких изменений кода?

Источник

1 ответ

  1. Техника, которую я собираюсь использовать, заключается в создании пользовательских AMI, которые при запуске будут загружать необходимые данные для начальной загрузки. В вашем случае вы можете сохранить свои сайты на S3 и загрузить файлы при загрузке. Если вы используете CloudInit для Ubuntu или что-то подобное для других дистрибутивов, то вы можете легко установить скрипт вашего сайта. Я полагаю, что он запускается только при первой загрузке, поэтому в результате прерывания узлов должна быть запущена актуальная версия сайта. В этом случае вам не придется постоянно обновлять AMI.

  2. Если у вас нет настройки системы управления конфигурацией, то достаточно просто сохранить файл на S3 с необходимой вам конфигурацией. По мере взросления шеф-повар или марионетка могут стать лучше, но им нужно некоторое время, чтобы научиться. Этот файл может быть загружен таким же образом или запущен с помощью таких инструментов, как Fabric или Capistrano.

Ткань и Capistrano могут помочь вам запустить небольшие обновления. Если вы повторно используете скрипт CloudInit, вам не придется кодировать его дважды. Как Fabric, так и Capistrano могут довольно легко интегрироваться с API AWS, что позволяет динамически запрашивать работающие узлы, поэтому вам не придется поддерживать постоянно меняющиеся списки серверов.

Инструмент для создания недавно запущенных AMI под названием Packer также может быть полезен для вас. В моей первой попытке я смог создать новый AMI, созданный за 30 минут после запуска урока. Это также может помочь в создании AMI для нескольких регионов.

Источник
Другие вопросы по тегам