Я только начинаю с балансировщика нагрузки EC2 и пытаюсь реализовать авто-вызовы и отказоустойчивость. База данных размещена в RDS, сеансы являются общими, файлы общими с использованием S3.
Кажется, я не могу найти лучшего решения для развертывания кода. Я не хочу использовать фабрику для повторного запуска команд развертывания во всех экземплярах.
Обновление кода в одном экземпляре, создание из него AMI и последующий перезапуск экземпляров с этим AMI кажутся мне серьезным излишеством, поскольку мы развертываем несколько раз в день, а весь процесс немного громоздок.
В идеале я хотел бы хранить код приложения на общем томе (NFS?) Во всех экземплярах и обновлять код на этом томе во время развертывания. Все экземпляры могут отслеживать изменения в конкретном файле и перезапускать рабочие приложения при касании файла.
Есть ли способ использовать NFS и автоматически монтировать общую EBS на всех экземплярах?
или есть лучший способ сделать это?
Резюме желаемого:
Я обновляю 1 экземпляр EC2 / том NFS и остаюсь забираю его без всего процесса создания нового AMI, уничтожения экземпляров и создания новых. Я не хочу, чтобы некоторые экземпляры оставались в подвешенном состоянии, когда код приложения и схемы базы данных не синхронизированы. Я знаю, что лучше всего писать код, поддерживающий 2 последовательных изменения схемы БД, но на данный момент мы не можем себе этого позволить.
Я бы посоветовал избегать общих ресурсов NFS, поскольку они создают единую точку отказа для вашей системы, и клиенты NFS могут иногда иметь проблемы с восстановлением после простоя сервера NFS. На самом деле NFS - это не «облачный способ». Способ AWS для обмена данными между виртуальными машинами включает использование различных децентрализованных сервисов AWS.
Для этой конкретной цели я бы предложил использовать сервис AWS S3. Создайте корзину S3 для своих выпусков программного обеспечения, загрузите туда свои выпуски и дайте виртуальным машинам доступ, чтобы они могли загружать выпуски, опросив корзину. Я также предлагаю использовать роли IAM, чтобы предоставить производственным виртуальным серверам доступ только для чтения к корзине S3 без каких-либо жестко закодированных учетных данных API. Эта схема защищает ваши выпуски и корзину на случай, если злоумышленнику удастся получить доступ к вашим серверам. Поскольку нет жестко закодированных учетных данных API, они не могут быть реконструированы или использованы где-либо еще.
Среды сборки и разработки можно настроить аналогичным образом - сервер сборки или CI-сервер может иметь роль для доступа для чтения и записи к корзине, если она находится в инфраструктуре AWS. Если ваш сервер сборки / CI находится в другом месте, вы можете настроить группу IAM с соответствующими правами доступа к S3 и создать пользователя IAM с учетными данными API для использования на внешнем сайте.
Вам по-прежнему необходимо подготовить AMI, чтобы он загружал и настраивал выпуск по вашему желанию и запускал приложение, но, по крайней мере, вам не нужно повторять этот процесс каждый раз, когда вы создаете новый выпуск. Использование какого-либо инструмента управления конфигурацией, такого как Chef, Puppet или Ansible, вероятно, может сделать все, что вы хотите, но вам нужно выделить время, чтобы ознакомиться с инструментами и смоделировать свою среду с их помощью.
Инфраструктуру (балансировщики нагрузки, asgs, группы безопасности, роли и т. Д.) Можно смоделировать, создать и поддерживать с помощью AWS CloudFormation. Если ваша среда становится более сложной, чем один ELB и один ASG, я бы рекомендовал взглянуть на это. Моделируя свою инфраструктуру с помощью CloudFormation, вы можете довольно легко создавать и поддерживать точные копии всей вашей среды - например, одну для тестирования / qa и одну для производства. Описание инфраструктуры - это json-документ, который можно хранить в вашем репозитории VCS.
Надеюсь, это поможет.
В идеале ваша система автоинициализации должна подключаться к вашей среде развертывания, чтобы получить исходный код для новых узлов. Группы автомасштабирования отлично подходят для запуска экземпляров, но проблема обновления кода остается для пользователя в качестве упражнения. Запекание кода в AMI работает хорошо, если вы не обновляете код несколько раз в день; в этом случае лучше всего создать отдельный механизм развертывания кода.
Это действительно зависит от вашего кода. У вас есть несколько способов сделать это.
Развертывание методом вытягивания
Это метод, который вы описали: каждый узел что-то отслеживает, и как только происходит событие изменения, он знает, что нужно вытащить новый код. Есть несколько способов добиться этого.
Преимущество здесь в том, что вы можете довольно хорошо масштабировать инфраструктуру развертывания кода. Методы вытягивания означают, что интервал, когда на вашем уровне кода работают две версии, больше, что снижает, насколько мощной должна быть ваша инфраструктура развертывания.
Однако вы сказали, что не можете терпеть несколько версий кода. Это будет проблемой. Вытягивание, вероятно, не тот метод, который вам нужен прямо сейчас (хотя в конечном итоге будет).
Push-развертывания
Этот метод имеет код, помещенный в узлы. Как и в случае с вытягиванием, это можно сделать несколькими способами:
Преимущество push заключается в том, что легче поддерживать жесткую синхронизацию в вашей кодовой базе. Если вам действительно нужен строгий уровень, состоящий только из одной версии, это сделать проще. В зависимости от того, как вы настроили интервалы масштабирования, вы можете отключить часть своих экземпляров, обновить код на подмножестве и включить их. Ключ схемы в вашей базе данных указывает коду не обрабатывать какую-либо работу и направлять запросы тем, у кого есть правильный ключ. Обновите ключ в базе данных, и в течение нескольких миллисекунд узлы нового кода начинают выполнять всю работу, а узлы старого кода начинают пересылку. Затем обновите код на другом уровне.
Если масштабируемые группы не могут терпеть сбой кода ... вам, вероятно, придется перейти к системе A / B для групп масштабируемости. Обновите код в группе B, переверните бит в базе данных, измените ELB так, чтобы он указывал на группу B. Обратитесь для следующего обновления.
Какие методы вы используете, полностью зависит от того, насколько терпимо ваше приложение в целом к нескольким версиям кода, выполняющимся одновременно. Подобная распределенная система - сложная система, и состояние одной части системы будет немного отличаться от состояния другой части, как бы вы ни старались. Чем менее вы терпимы, тем больше будет простоев при каждом обновлении кода. Отключение может длиться меньше секунды, но это все равно отключение.