Подтвердить что ты не робот

Непрерывное развертывание и автомасштабирование AWS с использованием Ansible (+ Docker?)

Мой веб-сайт организации - это приложение Django, работающее на веб-серверах front end + несколько серверов обработки фоновых изображений в AWS.

В настоящее время мы используем Ansible для обоих:

  • Конфигурация системы (из голого образа ОС)
  • частое развертывание кода с ручным запуском.

Такая же Ansible playbook может предоставить либо локальную Vagrant dev VM, либо экземпляр EC2 производства с нуля.

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

Первым обязательным условием было перейти от статически управляемого Ansible инвентаря к динамическому, основанному на EC2 интерфейсу.

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

  • Выпекать новый полностью развернутый AMI для каждого развертывания, создать новую конфигурацию AS Launch и обновить группу AS с этим. Звучит очень, очень громоздко, но также очень надежно из-за подхода чистого сланца и гарантирует, что любая система изменит требуемый код. Кроме того, никаких дополнительных шагов, необходимых для загрузки экземпляра, не запускается и не выполняется быстрее.
  • Использовать базовый AMI, который не изменяется очень часто, автоматически получает последний код приложения из git при загрузке, запускает веб-сервер. Как только это произойдет, просто ручное развертывание по мере необходимости, как и раньше. Но что, если новый код зависит от изменения конфигурации системы (новый пакет, разрешения и т.д.)? Похоже, вам нужно начинать заботиться о зависимостях между версиями кода и версиями системы /AMI, тогда как подход "просто сделать полный контроль" более интегрирован и более надежным. Это больше, чем просто потенциальная головная боль на практике?
  • Использовать Docker? У меня есть сильная догадка, что это может быть полезно, но я еще не уверен, как это будет соответствовать нашей картине. Мы являемся относительно автономным интерфейсным интерфейсом Django с помощью только RabbitMQ + memcache в качестве сервисов, которые мы никогда не будем запускать на том же хосте в любом случае. Итак, какие преимущества существуют при создании образа Docker с использованием Ansible, который содержит системные пакеты + последний код, а не как Ansible, просто делать это непосредственно на экземпляре EC2?

Как вы это делаете? Любые идеи/лучшие практики? Спасибо!

4b9b3361

Ответ 1

Этот вопрос очень основан на мнениях. Но для того, чтобы дать вам мой прием, я бы просто пошел с prebaking AMI с Ansible, а затем использовал CloudFormation для развертывания ваших стеков с помощью Autoscaling, Monitoring и ваших предварительно обработанных AMI. Преимущество этого заключается в том, что если у вас есть большая часть стека приложений, предварительно испеченная в автомасштабировании AMI UP, произойдет быстрее.

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

Сказав, что некоторые люди находят Docker полезными не таким образом, чтобы оптимизировать ресурсы на одном сервере, а скорее способом, позволяющим предварительно выпекать ваши приложения в контейнерах. Поэтому, когда вы развертываете новую версию или новый код, все, что вам нужно сделать, это копировать/реплицировать эти контейнеры докеров на своих серверах, а затем останавливать старые версии контейнеров и запускать новые версии контейнеров.

Мои два цента.

Ответ 2

Гибридное решение может дать желаемый результат. Сохраните изображение докеры головы в S3, предварительно загрузите AMI с помощью простой выборки и запустите script при запуске (или передайте его в AMI запаса с пользовательскими данными). Управление версиями, перемещая изображение головы до последней стабильной версии, вы, вероятно, также можете реализовать тестовые стеки новых версий, сделав fetch script достаточно умным, чтобы определить, какую версию докера можно получить на основе тегов экземпляров, которые настраиваются при запуске экземпляра.

Ответ 3

Вы также можете использовать AWS CodeDeploy с AutoScaling и сервером сборки. Мы используем плагин CodeDeploy для Jenkins.

Эта настройка позволяет:

  • выполнить свою сборку в Jenkins
  • Загрузка в корзину S3
  • Разверните все EC2 один за другим, которые являются частью назначенной группы автомасштабирования AWS.

Все это нажатием кнопки!

Вот учебник AWS: Развертывание приложения в группе автоматического масштабирования с использованием AWS CodeDeploy