Непрерывное развертывание и автоматическое масштабирование AWS с помощью Ansible (+Docker)

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

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

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

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

теперь мы хотим для реализации автомасштабирования в EC2, и это требует некоторых изменений в сторону "относитесь к серверам как к скоту, а не к домашним животным" философия.

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

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

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

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

18
amazon-ec2 ansible autoscaling continuous-deployment docker

3 ответов

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

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

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

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

9

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

1

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

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

  1. выполните сборку в Jenkins
  2. загрузить в ведро S3
  3. развертывание на всех EC2s по одному, которые являются частью назначенной группы автоматического масштабирования AWS.

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

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

0