Что нужно встроить в AMI AWS и что выделить с помощью cloud-init?

Я использую AWS Cloudformation для настройки многочисленных элементов сетевой инфраструктуры (VPC, SecurityGroups, Subnets, Autoscaling groups и т. Д.) Для моего веб-приложения. Я хочу, чтобы весь процесс был автоматизирован. Я хочу нажать кнопку и иметь возможность запустить все это.

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

Для этого я создаю AMI с помощью Packer.io. Но некоторые люди вместо этого уговаривали меня использовать Cloud-Init. Какую эвристику мне следует использовать, чтобы решить, что вставлять в AMI и / или что настраивать через Cloud-Init?

Например, я хочу предварительно настроить экземпляр EC2, чтобы позволить мне (saqib) входить в систему без пароля с моего собственного ноутбука. Таким образом, у EC2 должен быть пользователь. У этого пользователя должен быть домашний каталог. И в этом домашнем каталоге должен находиться файл .ssh/known_hosts, содержащий зашифрованные коды. Должен ли я запекать эти каталоги в AMI? Или мне следует использовать cloud-init для их настройки? И как мне принять решение в этом и других подобных случаях?


person Saqib Ali    schedule 03.03.2015    source источник
comment
вам понадобится марионетка или повар для выполнения задачи автоматизации с user data, определенной в CloudFormation.   -  person BMW    schedule 03.03.2015
comment
Спасибо. Не могли бы вы объяснить, что мне нужно вставить в AMI ?? Как мне решить, должно ли что-то быть в AMI или настраиваться через user data?   -  person Saqib Ali    schedule 03.03.2015
comment
У AWS есть подробная страница, на которой обсуждаются варианты aws.amazon.com/answers / configuration-management / aws-ami-design   -  person Jason    schedule 22.05.2017


Ответы (2)


Мне нравится отделить подготовку машин от подготовки среды.

В общем, я использую в качестве руководства следующее:

Этап сборки

  • Создайте базовый образ машины с помощью чего-то вроде Packer, включая все программное обеспечение, необходимое для запуска вашего приложения. Создайте из этого AMI.
  • Установите приложение (я) на базовый образ машины, создав образ приложения. Отметьте и укажите версию этого артефакта. Не вставляйте сюда специфические для среды вещи, такие как соединения с базой данных и т. Д., Поскольку это не позволяет вам легко повторно использовать этот AMI в разных средах выполнения.
  • Убедитесь, что все службы остановлены

Этап выпуска

  • Создайте среду, состоящую из изображений и необходимой инфраструктуры, используя что-то вроде CFN.
  • Используйте Cloud-Init user-data, чтобы настроить среду приложения (соединения с базой данных, серверы пересылки журналов и т. Д.), А затем запустить приложения / службы.

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

person Matthew Fellows    schedule 29.03.2015
comment
Старый ответ, но у меня была недавняя проблема, когда я строил полностью с нуля. К сожалению, в AWS возникла проблема с dbus, и она больше не работала. К сожалению, в этом базовом образе была эта ошибка. Теперь я делаю именно это, чтобы убедиться, что мой сервер соответствует ожиданиям, и это также ускоряет развертывание. - person Paul; 07.02.2019

Одним из важных факторов, определяющих, как вы должны собирать серверы, AMI и планирование инфраструктуры, является ответ на вопрос: в производственной среде, как быстро мне понадобится запуск нового экземпляра?

Ответ на этот вопрос определит, сколько вы вложите в AMI по сравнению с тем, сколько вы создадите после загрузки.

ПРИМЕЧАНИЕ. Я имею опыт работы с Chef Server, поэтому я буду использовать терминологию Chef, но концепции такие же для любого другого стека управления конфигурацией.

Общее практическое правило - относиться к своей «инфраструктуре как к коду». Это означает, что подумайте о процессе запуска экземпляров, создании пользователей на этой машине и о процессе управления файлами known_hosts и ключами SSH так же, как и о коде вашего приложения. Возможность отслеживать изменения инфраструктуры в исходном коде значительно упрощает управление, повторное развертывание и даже CI.

Это введение от шеф-повара охватывает терминологию поваренных книг, рецептов, ресурсов и т. д. . Он показывает вам, как создать простой стек LAMP, и как вы можете так же легко перезапустить его с помощью одной команды.

Итак, учитывая пример в вашем вопросе, на высоком уровне я бы сделал следующее:

  • Запустите базовый Ubuntu Linux AMI (в настоящее время 14.04) с помощью сценария Cloudformation.
  • В разделе UserData конфигурации экземпляра загрузите процесс установки Chef Client.
  • Запустите рецепт, чтобы создать пользователя.
  • Запустите рецепт для создания файла known_hosts для пользователя.

Такие инструменты, как Chef, используются потому, что вы можете разбить инфраструктуру на небольшие блоки кода, выполняющие определенные функции. Уже существует множество созданных и доступных кулинарных книг, в которых реализованы базовые строительные блоки для создания служб, установки пакетов программного обеспечения и т. Д.

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

Представим, что ваше приложение обрабатывает изображения и требует использования ImageMagick. Предположим, вам нужно будет собрать ImageMagick из исходников. Если бы вы сделали это с помощью Chef Recipes, это могло бы добавить еще 7 минут простой компиляции ImageMagick к обычному времени загрузки экземпляра. Если ожидание 10–12 минут - это слишком долго, чтобы новый экземпляр подключился к сети, вы можете подумать о том, чтобы создать собственный AMI, в котором ImageMagick уже скомпилирован и установлен.

Это приемлемое решение, но вы должны иметь в виду, что управление собственным парком предварительно запеченных AMI увеличивает нагрузку на инфраструктуру. Вам нужно будет обновлять свои пользовательские AMI по мере выпуска новых AMI, расширения до разных типов инстансов и до разных регионов AWS.

person Mikelax    schedule 21.03.2015