Скажем, у меня есть приложение, состоящее из веб-сервера и базы данных. Если я развертываю ec2-клиент с ролью БД, как я могу автоматически вставить IP-адрес этой новой машины ec2 в конфигурацию моего веб-сервера?
В общем, как я могу получить метаданные EC2 во время запуска для использования в атрибутах других кулинарных книг?
Я знаю, что обходным способом сделать это может быть обновление DNS-сервера с помощью сценариев оболочки, но мне интересно здесь решение, использующее только шеф-повара.
Вы можете использовать правильно отформатированный search в рецептах Chef, которые вы запускаете на веб сервер которые возвращают объект узла для вашего сервера БД. Затем вы можете получить вышеупомянутые IP-адреса через узел ["ipaddress"] или, если вам нужен общедоступный IP-адрес / имя хоста при работе на EC2, узел ["облако"] ["public_hostname"] / node ["облако"] ["public_ipv4 "]. Например, после развертывания сервера БД используйте что-то вроде:
db_servers = search(:node, 'roles:db-server').map{|n| n.attribute?('cloud') ? n['cloud']['public_ipv4'] : n['ipaddress'] }
template "web/config" do
[...]
variables({ :dbs_ervers => db_servers })
end
Обновление веб-сервера будет происходить либо асинхронно при каждом запуске клиента Chef, либо вы можете принудительно запустить его вручную с помощью ручного управления. ssh или knife ssh
Chef - это лишь небольшая часть вашей облачной оркестровки и облачного мониторинга / конфигурации. Вы можете использовать chef для настройки и ничего больше. Это не для координации многих серверов.
В вашем случае вам нужен мастер-процесс, чтобы инициировать запуск нового экземпляра, экземпляр будет настроен, и мастер-процесс обновит веб-сервер после того, как экземпляр db станет работоспособным.
Многие люди, использующие Chef, совершают эту ошибку. Выше у вас есть правильное решение. Просто используйте это с умом. Также используйте серверы аутентификации.
Вы можете изучить шаблоны AWS CloudFormation в сочетании с Chef. Загрузите экземпляры EC2 и раскрутите другие ресурсы AWS с помощью CloudFormation, то есть управляйте AWS с помощью CloudFormation. Затем используйте Chef для управления стороной конфигурации сервера. Я считаю, что частично это функциональность, которую Эндрю Смит называет «главным процессом», единственной точкой, которую вы используете для управления всем жизненным циклом. Он определенно заменяет сценарии API AWS в подходе Эндрю.
Развертывание кода, вероятно, также является частью этого. Для этого можно использовать Chef, но я не считаю, что это лучший способ (если вы не делаете что-то настолько маленькое). Используйте систему сборки кода, такую как Jenkins и систему развертывания. В настоящее время мы используем внутреннюю систему, но планируем перейти на http://octopusdeploy.com/ (поскольку мы в первую очередь дом .Net). Предположим, что код в какой-либо системе контроля версий, например Git.
Полезный документ:
https://s3.amazonaws.com/cloudformation-examples/IntegratingAWSCloudFormationWithOpscodeChef.pdf
Отказ от ответственности: я не эксперт. Только недавно начали работать над нашим дизайном развертывания. Но в настоящее время архитектура выглядит так, как указано выше.