Развертывание на инстансах EC2 за балансировщиком нагрузки; PHPStorm + GitHub

Я знаю, что на этот вопрос был частично дан ответ во многих местах, но ответы такие... по всей карте, датированы и плохо объяснены. Я ищу рекомендации по состоянию на февраль 2016 г.

Настройка:

Служба приложения RESTful на основе PHP, которая находится в экземпляре EC2. Экземпляр EC2 использует S3 для загруженных пользовательских данных (файлов изображений) и RDS MySql для своей БД (эти два момента не особенно важны).

Мы разрабатываем в PHPStorm, а наша система контроля версий — GitHub. При развертывании мы просто используем встроенное в PHPStorm развертывание SFTP для загрузки файлов непосредственно в экземпляр EC2 (у нас есть один экземпляр для нашей промежуточной среды, а другой — для нашей производственной среды). Я развертываю Staging очень часто. Может быть 20 раз в день. Я просто нажимаю на файл в PHPStorm и говорю «развернуть в Staging», что делает передачу SFTP. Или я могу просто щелкнуть весь проект и нажать «развернуть в Staging» — определенные папки и файлы исключаются из загрузки, что является частью конфигурации развертывания PHPStorm.

Недавно я разместил наш инстанс EC2 за балансировщиком нагрузки. Я сделал это, чтобы воспользоваться бесплатным SSL-предложением Amazon через диспетчер сертификатов, который не поддерживает отдельные экземпляры EC2.

Итак, прямо сейчас есть балансировщик нагрузки, за которым стоит только один экземпляр EC2. Я поддерживаю эластичный IP-адрес, указывающий на экземпляр EC2, чтобы иметь к нему прямой доступ (см. мой текущий метод развертывания выше).

Вопрос:

У меня еще не хватило смелости создать дополнительные (клонированные) экземпляры EC2 за моим балансировщиком нагрузки, потому что я не уверен, как мне следует развертывать их. На ум пришло несколько идей, но все они довольно хакерские.

Учитывая приведенный выше сценарий, какой в ​​настоящее время является самым простым и лучшим способом A) быстро развернуть кодовую базу в наборе экземпляров EC2 за балансировщиком нагрузки и B) на самом деле ' клонировать мой текущий экземпляр EC2, чтобы создать дополнительные экземпляры.

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

Спасибо!


github amazon-web-services amazon-ec2 amazon-elb load-balancing
person Matthew Housser    schedule 19.02.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вы должны относиться к своему инстансу EC2 как к 100% необязательному. Это означает, что он может быть прекращен в любое время, и вас это не должно волновать. Замещающий экземпляр EC2 запустится и возьмет на себя работу.

Есть 3 способа сделать это:

Способ 1. При каждом развертывании создается новый образ AMI.

Когда вы развертываете свое приложение, вы развертываете его на рабочем экземпляре EC2, единственной целью которого является «настройка» вашего приложения. После развертывания новой версии вы создаете новый образ AMI из экземпляра EC2 и обновляете конфигурацию запуска Auto Scaling с помощью нового образа AMI. Старые экземпляры EC2 закрываются и заменяются новым кодом.

На новых инстансах EC2 уже есть последний код, поэтому они готовы к добавлению в балансировщик нагрузки.

Способ 2. Каждое развертывание выполняется в хранилище вне экземпляра (например, Amazon S3).

Инстансы EC2 загрузят последний код из Amazon S3 и установят его при загрузке.

Таким образом, чтобы ввести новый код в действие, вы завершаете старые экземпляры и запускаете новые, чтобы заменить их, которые начинают использовать новый код.

Это может быть выполнено в виде последовательного обновления или в виде синего / зеленого развертывания.

Способ 3: Аналогичен способу 2, но на этот раз экземпляры обладают некоторыми интеллектуальными возможностями и могут получить сигнал для загрузки и установки кода.

Таким образом, вам не нужно завершать работу экземпляров: существующим экземплярам предлагается обновиться с S3, и они делают это самостоятельно.

Некоторые инструменты, которые могут помочь, включают:

  • шеф-повар
  • Ансибль
  • CloudFormation

Обновление:

Методы 2 и 3 начинаются с «базового» AMI, настроенного на извлечение ресурсов веб-страницы из S3. Этот AMI не меняется от версии к версии вашего веб-сайта.

Например, в AMI могут быть уже установлены Apache и PHP, и при загрузке он извлекает ресурсы веб-сайта .php из S3 и помещает их в /var/www/html.

CloudFormation хорошо подходит для этого. Кроме того, для метода 3 вы можете использовать cfn-hup для ожидания сигналов обновления. При получении сигнала он будет извлекать обновленные ресурсы из S3.

Другая возможность — использовать Elastic Beanstalk, который может управлять всем этим за вас.

Обновление:

Чтобы получить образ AMI из Git, попробуйте следующее:

  1. Настройте экземпляр EC2 со всем установленным, что вам нужно установить для вашего веб-приложения.
  2. Установите Git и настройте локальное репо, готовое к Git pull.
  3. Выключите и создайте AMI вашего экземпляра.

При развертывании вы делаете следующее:

  1. Git push на GitHub
  2. Запустите новый экземпляр EC2 на основе вашего образа AMI.

В составе пользовательских данных (указанных при запуске инстанса EC2) укажите что-то вроде следующего:

#!/bin/sh
cd /git/app
git pull
; copy files from repo to web folder
composer install

Когда это делается таким образом, эти пользовательские данные действуют как сценарий, который запускается при первой загрузке.

person Matt Houser    schedule 19.02.2016
comment
Хорошо... подождите... во-первых, я должен спросить: действительно ли мне отвечает кто-то по имени Мэтт Хаузер? - person Matthew Housser; 19.02.2016
comment
Ну, это Мэтью Хауссер, так что это забавно. =P Хорошо, продолжим... Думаю, я начну с того, что задам несколько вопросов, и начну с этого: с Методом 3, будет ли это хорошо работать с автоматическим масштабированием? Я предполагаю, что Auto Scaling — это действительно умная вещь, которую я должен в конечном итоге сделать. Метод 3, по-видимому, не обновляет AMI, так как же он будет работать (возможно, не будет)? - person Matthew Housser; 20.02.2016
comment
Да, все это работает с Auto Scaling. Автоматическое масштабирование — это то, что нужно, даже с одним экземпляром (если этот экземпляр одноразовый). Я внес обновления в свой ответ, чтобы ответить на вопрос AMI для методов 2 и 3. - person Matt Houser; 20.02.2016
comment
Поскольку мы используем GitHub для нашего серверного кода и на самом деле не хотим начинать использовать S3 для размещения нашего серверного кода, будет ли справедливо сказать, что мы можем заменить все ваши предложения по извлечению из S3 выше на получение из GitHub? - person Matthew Housser; 20.02.2016
comment
Да, вы могли бы сделать это тоже. На самом деле не имеет значения, откуда он поступает, если вы не загружаете его вручную. - person Matt Houser; 20.02.2016
comment
В порядке. По сути, похоже, что я должен выбирать между а) обновлением AMI каждый раз, когда я хочу развернуть, и б) выполнением чего-то, что включает в себя простой запуск «обновления из GitHub», который может или не может завершить все экземпляры EC2 (в зависимости от того, какой метод ). Я не уверен, как выбрать. Можно ли выполнить оба этих действия полностью автоматизированным способом, который я мог бы, скажем, запустить, набрав «развернуть» в моей локальной среде разработки? Кроме того, есть ли большая разница в «чистоте» при обновлении AMI по сравнению с обновлением без AMI? - person Matthew Housser; 20.02.2016
comment
Мне больше всего нравится метод 3, но для простоты вы можете начать с метода 2 и сделать так, чтобы ваш базовый AMI выполнял простую операцию git pull при первой загрузке. Затем запустите новый экземпляр, дайте ему загрузиться, подключите его к балансировщику нагрузки, а затем завершите работу старого. - person Matt Houser; 20.02.2016
comment
Однако получение данных с GitHub может оказаться ненадежным долгосрочным решением. Я рекомендую решение GitHub › CI Build › S3 › Testing › Trigger Update. Преимущество заключается в управлении версиями, простом откате, избежании несоответствия кода в ваших экземплярах и т. д. - person Matt Houser; 20.02.2016
comment
Итак, я немного слаб в настройке/скриптах Linux/EC2. Не могли бы вы добавить к своему ответу (который я скоро приму, обещаю!) небольшое руководство относительно того, как заставить ваш базовый AMI выполнять простой git pull при первой загрузке? Я никогда не учил свои экземпляры EC2, как что-либо делать при загрузке. Это просто тупые серверы Apache/PHP. Кроме того, я использую инфраструктуру Laravel, основанную на Composer, для управления зависимостями, поэтому после развертывания мне также может понадобиться запустить composer install, что я сейчас делаю вручную через SSH-терминал. - person Matthew Housser; 20.02.2016
comment
Кроме того, делает ли AWS CodeDeploy этот метод проще? Я просто изучаю это сейчас. Похоже, он может обрабатывать метод «обновить текущие запущенные экземпляры» (хотя и не метод «завершить текущие экземпляры, поскольку новые экземпляры будут извлекаться из github при запуске»). - person Matthew Housser; 20.02.2016
comment
CodeDeploy также может помочь. Вы можете получить его из github и отправить на свои экземпляры EC2. Я не использовал его, хотя. - person Matt Houser; 20.02.2016
comment
Спасибо. Дал вам ответ. Кроме того, в вашей фамилии отсутствует буква «с». Я думаю, что теперь у меня достаточно информации, чтобы начать играть с вещами. Вероятно, у меня будет куча дополнительных вопросов, но я чувствую, что задал вам достаточно вопросов, и эта ветка длится уже достаточно долго! - person Matthew Housser; 20.02.2016