[Эта статья была написана Коби Нахмани.]
Если вы знакомы с управлением конфигурациями (aka CM) и автоматизацией, вы, вероятно, знаете кое-что о Puppet, а также об удивительной и богатой коллекции модулей, которые она предлагает. Puppet Forge содержит множество сторонних модулей, которые позволяют нам делать довольно приятные вещи практически без усилий. Puppet помогает справиться с грязными частями CM, такими как установка двоичных файлов и запуск сценариев установки, которые утомительно делать вручную.
Такие инструменты, как Puppet, изначально создавались для ИТ-специалистов, которые в основном ориентированы на инфраструктуру и лучше всего подходят для настройки и обслуживания хостов в физическом центре обработки данных. Работа с приложениями и, безусловно, управление приложениями в гибкой виртуализированной или даже облачной среде, создает ряд новых проблем, несмотря на гибкость и другие преимущества, которые она обеспечивает.
А теперь представьте, что мы можем объединить эту доброту с интеллектуальной структурой оркестровки для всего развертывания?
В этом посте я хотел бы продемонстрировать, как оркестратор облачных приложений может дополнять уже существующие процессы автоматизации, основанные на инструментах управления конфигурацией , в этом случае мы продемонстрируем это с Puppet.
В качестве примеров я буду использовать приложение nodecellar и популярную платформу управления контентом WordPress.
Надеемся, что это станет хорошим введением в проекты Cloudify.
обзор
Итак, мы увидели, как Cloudify 3 позволяет нам легко организовать приложение «nodecellar»
Читайте об этом Cloudify чертежи здесь.
На примере «nodecellar» Cloudify развертывает сложное приложение, используя рабочие процессы, которые отображают события жизненного цикла развертывания на сценарии bash, используя подключаемый модуль Cloud Runner.
Интеграция Puppet в Cloudify теперь делает это довольно просто.
Cloudify 3.0 — перевод куколки на новый уровень оркестровки.
Проверьте это.
Идти
Синергия между Cloudify и Puppet не только позволяет вам пользоваться преимуществами вашей среды Puppet, но также повышает ее удобство использования, предоставляя уникальные преимущества, которые помогут решить следующие распространенные проблемы, связанные с инструментами управления конфигурацией:
-
Установка агента. Предоставьте виртуальные машины для обслуживания, установите агент Puppet (если хотите) и подключите его к Puppet Master. Или, если вы решите запустить автономно, вы также можете установить агент с соответствующими манифестами, необходимыми для этой службы.
-
Порядок зависимостей. Определите зависимости между стеками приложений, службами и ресурсами инфраструктуры. Который затем будет запущен на основе этого заказа.
-
Удаленное выполнение и обновления. Помимо базовой установки / удаления, Cloudify включает настраиваемые рабочие процессы приложений, которые позволяют запускать такие инструменты, как сценарии удаленной оболочки, для группы экземпляров, принадлежащих определенной службе или определенному экземпляру в группе. Эта функция полезна для выполнения операций обслуживания, таких как моментальные снимки в случае базы данных или добавления кода в модель непрерывного развертывания. Кроме того, вы можете запустить,
puppet apply
когда вы чувствуете, что это подходит для вашего обслуживания. -
После развертывания: как только ваше приложение будет запущено, Cloudify сможет склеить ваш инструмент мониторинга по вашему выбору, или вы можете использовать встроенный. Надежный механизм политик обеспечивает автоматическое восстановление и даже автоматическое масштабирование в соответствии с требуемым SLA вашего сервиса.
Теперь я собираюсь глубоко погрузиться в мой опыт с примером WordPress, который, по моему мнению, является очень хорошим представлением о том, как Puppet и Cloudify работают синхронно.
Допустим, мы хотим развернуть популярный стек приложений WordPress на двух виртуальных машинах.
Что-то следующее:
Поток довольно прост:
-сервер 3.5.1 с установленными основными модулями:
| — hunner-wordpress (v0.6.0)
| — puppetlabs-apache (v1.0.1) — с включенными модами php
| — puppetlabs-mysql (v2.1.0)
Ваш файл site.pp должен выглядеть примерно так:
node /^apache_web.*/ { include apache class { 'wordpress': create_db => false, create_db_user => false, } } node /^mysql.*/ { class { '::mysql::server': root_password => 'password', override_options => { 'mysqld' => { 'bind_address' => '0.0.0.0' } } } include mysql::client include wordpress }
Как мы видим, у нас есть приложение Apache PHP, которое, вероятно, потребует строку подключения к базе данных (IP, порт, пользователь и пароль).
Именно здесь Cloudify облегчает «склейку» всех частей вместе, позволяя нам вводить динамические / статические пользовательские факты в зависимый узел (сервер Apache).
Cloudify поддерживает как автономные агенты, так и PuppetMaster.
Шаг 2: Настройка оригинального модуля WordPress.
Некоторые незначительные изменения в классе WordPress init модуля WordPress позволят нам внедрить эти факты во время вызова агента Puppet.
Ниже приведен фрагмент кода (с усеченными значениями по умолчанию):
class wordpress ( $db_host_ip = $cloudify_related_host_ip, $db_user, = $cloudify_properties_db_user, $db_password = $cloudify_properties_db_pw, . . )
И некоторые настройки для templates / wp-config.php.erb:
/** MySQL hostname */ define('DB_HOST', '<%= @db_host_ip %>');
Давайте добавим несколько тегов для более точного контроля выполнения манифеста:
Узлу MySQL не требуется, чтобы часть приложения выполнялась на нем, поэтому я исключил его, используя «тег» Puppet (подробнее о тегах Puppet ).
Cloudify, конечно, поддерживает это и будет предоставлять соответствующие теги во время вызова агента.
-> class { 'wordpress::app': tag => ['postconfigure'], install_dir => $install_dir, install_url => $install_url, version => $version, db_name => $db_name, . .}
Шаг 3: Создание плана
По аналогии с планом «nodecellar», сначала давайте создадим папку с именем «wp_puppet» и создадим в ней файл blueprint.yaml. Этот файл будет служить файлом проекта.
Теперь давайте объявим название этого проекта.
blueprint: name: wp_puppet nodes:
Теперь мы можем начать создавать топологию.
Шаг 4: Создание узлов VM
Поскольку в этом случае я использую провайдера OpenStack для создания узлов, давайте импортируем плагин «Типы OpenStack».
imports: - http://www.getcloudify.org/spec/openstack-plugin/1.0/plugin.yaml
Поскольку виртуальные машины одинаковы, я объявил универсальный шаблон для хоста виртуальных машин:
vm_host: derived_from: cloudify.openstack.server properties: - install_agent: true - worker_config: user: ubuntu port: 22 # example for ssh key file (see `key_name` below) # this file matches the agent key configured during the bootstrap key: ~/.ssh/agent.key # Uncomment and update `management_network_name` when working a n neutron enabled openstack - management_network_name: cfy-mng-network - server: image: 8c096c29-a666-4b82-99c4-c77dc70cfb40 flavor: 102 key_name: cfy-agnt-kp security_groups: ['cfy-agent-default', 'wp_security_group'] # This is how we inject the puppet server's ip userdata: | #!/bin/bash -ex grep -q puppet /etc/hosts || echo "x.x.x.x puppet" | sudo -A tee -a /etc/hosts
Создайте виртуальные машины MySQL и Apache:
- name: mysql_db_vm type: vm_host instances: deploy: 1 - name: apache_web_vm type: vm_host instances: deploy: 1
Шаг 5: Объявление серверов Apache и MySQL
Поскольку мы используем плагин Puppet для создания этих серверов, сначала нам нужно его импортировать:
plugins: puppet_plugin: derived_from: cloudify.plugins.agent_plugin properties: url: https://github.com/cloudify-cosmo/cloudify-puppet-plugin/archive/nightly.zip
Плагин определяет типы серверов следующим образом:
middleware_server, app_server, db_server, web_server, message_bus_server, app_module.
Они практически одинаковы, но служат лучшей читаемости для пользователя и визуализации графического интерфейса.
Тип сервера Puppet является типом output_from: cloudify.types.server, но включает некоторые свойства, характерные для кукол, и события жизненного цикла.
Для документации см .: Типы кукол
Итак, теперь мы пойдем дальше и объявим типы серверов:
cloudify.types.puppet.web_server: derived_from: cloudify.types.web_server properties: # All Puppet related configuration goes inside # the "puppet_config" property. - puppet_config interfaces: cloudify.interfaces.lifecycle: # Specifically "start" operation. Otherwise tags must be # provided. - start: puppet_plugin.operations.operation cloudify.types.puppet.app_module: derived_from: cloudify.types.app_module properties: - puppet_config interfaces: cloudify.interfaces.lifecycle: - configure: puppet_plugin.operations.operation cloudify.types.puppet.db_server: derived_from: cloudify.types.db_server properties: - puppet_config interfaces: cloudify.interfaces.lifecycle: - start: puppet_plugin.operations.operation
Шаг 6: Создание узлов Apache и MySQL:
Здесь мы предоставляем конфигурацию и теги Puppet и определяем отношения между узлами. Агент Cloudify будет использовать эти отношения для определения соответствующих фактов для внедрения.
- name: apache_web_server type: cloudify.types.puppet.web_server properties: port: 8080 puppet_config: server: puppet environment: wordpress_env relationships: - type: cloudify.relationships.contained_in target: apache_web_vm - name: wordpress_app type: cloudify.types.puppet.app_module properties: db_user: wordpress db_pass: passwd puppet_config: server: puppet tags: ['postconfigure'] environment: wordpress_env relationships: - type: cloudify.relationships.contained_in target: apache_web_server - type: wp_connected_to_mysql target: mysql_db_server - name: mysql_db_server type: cloudify.types.puppet.db_server properties: db_user: wordpress db_pass: passwd puppet_config: server: puppet environment: wordpress_env relationships: - type: cloudify.relationships.contained_in target: mysql_db_vm
Шаг 7. Загрузите Blueprint и создайте развертывание (через CLI или GUI)
Затем выполните развертывание (через CLI или GUI).
ubuntu@koby-n-cfy3-cli:~/cosmo_cli$ cfy blueprints upload -b wp9 wordpress/blueprint.yaml ubuntu@koby-n-cfy3-cli:~/cosmo_cli$ cfy deployments create -b wp9 -d WordPress_Deployment_1