Преимущества непрерывной интеграции очевидны. Бесспорная необходимость в том, чтобы циклы развертывания, которые раньше занимали от шести месяцев до года, резко сокращалась, что позволяло компаниям развертывать код много раз в день. Однако с таким огромным количеством ежедневных развертываний возникла растущая необходимость вывести автоматизацию всего этого процесса на новый уровень, при этом обеспечивая его расширяемость, масштабируемость и мониторинг.
Процессы непрерывной интеграции стали более сложными с различными вариантами использования и сценариями, которые необходимо поддерживать — от создания надежного конвейера CI до непрерывной доставки, до необходимости A / B-тестирования развертываний, прежде чем приступить к производству, среди прочего.
Cloudify — перенос CI на CD с простым планом. Дай вихрь.
Идти
Именно здесь начинается Cloudify. В этой статье я расскажу о более сложном сценарии использования, который позволит вам организовать весь процесс CI с помощью Jenkins, одновременно проводя A / B-тестирование и мониторинг всего процесса, и, наконец, Не в последнюю очередь, выбирая код, который вы хотите развернуть в производстве.
A / B-тестирование с Jenkins & Cloudify
Архитектура, которую мы выбрали для этой демонстрации, состоит в том, чтобы создать три среды, две для тестирования и одну для производственной среды — назовем их A / B test 1, A / B test 2 и Production.
Вот изображение окружающей среды:
Для начала нам нужно было создать единого главного или основного менеджера Cloudify в качестве единой точки управления для этих трех сред, которая также будет управляться дополнительным менеджером Cloudify для каждой среды вместе с сервером Jenkins.
(Примечание: RND Cloudify фактически использует Travis и Circle CI для таких процедур, но этот же сценарий можно запустить с любым инструментом CI, таким как QuickBuild, TeamCity и т. Д.)
Это был фактически первый раз, когда мы пытались развернуть Cloudify Manager с Cloudify Manager, но, о чудо, успех. Пить наш собственный мерло работал с некоторыми изменениями. Таким образом, каждый Cloudify Manager внутри «основного» менеджера может управлять различными развертываниями независимо от других менеджеров. Кроме того, для целей данного варианта использования нам пришлось немного изменить план Cloudify Manager, чтобы отключить многоадресную рассылку Elasticsearch (которая является частью стека менеджера Cloudify), чтобы предотвратить связь / синхронизацию между Менеджеры Cloudify, которые все находятся в одной сети или подсети — так как несоответствие этих сред было действительно важно в этом случае.
Вот измененный фрагмент проекта менеджера, который отключает многоадресную рассылку:
node_templates:
manager:
type: cloudify.nodes.CloudifyManager
multicast_disabler:
type: cloudify.nodes.ApplicationModule
interfaces:
cloudify.interfaces.lifecycle:
configure:
implementation: fabric.fabric_plugin.tasks.run_commands
inputs:
commands:
- printf "discovery.zen.ping.multicast.enabled\x$(printf %x 58) false\n" >> `find / -name "elasticsearch.yml" | grep config | head -1`
- service elasticsearch restart
fabric_env:
user: { get_input: agents_user }
key_filename: { get_input: ssh_key_filename }
host_string: { get_attribute: [manager_host, public_ip] }
relationships:
- type: cloudify.relationships.contained_in
target: manager
Это развертывание было запущено на Softlayer (облачном провайдере IBM), поэтому мы взяли базовый проект Softlayer и загрузили (запустили) главного менеджера, а затем развернули три разные среды Cloudify, развернув три менеджера в главном менеджере Cloudify: один для A / B тест 1, один для A / B, тест 2 и третий для производства. Затем мы создали проект Jenkins и настроили его для запуска с тремя заданиями Jenkins:
Два запланированных задания Jenkins, настроенных для выборки репозитория GitHub для сред тестирования, и одно простое (готовое к вызову) задание Jenkins для производственной среды.
Вот изображение, которое показывает роль Дженкинса в этом сценарии:
Как это работает
Этот сценарий работает путем выборки репозитория Github каждые 15 минут для обнаружения и развертывания любых внесенных изменений, а затем эти изменения передаются в различные среды (A / B 1st test и A / B 2nd test соответственно).
При обнаружении изменения в хранилище задание № 1 развернет его в Cloudify Manager # 1, а задание № 2 развернет в Cloudify Manager № 2. Фактически, при каждом отправке кода в GitHub Jenkins будет одновременно выполнять два задания, каждое из которых будет вызывать собственное независимое развертывание в соответствующем диспетчере Cloudify.
Третья среда ведет себя несколько иначе преднамеренно и на самом деле не запускает никаких команд, чтобы поддерживать полуавтоматическое выполнение производственного задания. Это связано с тем, что, по сути, это сценарий A / B-тестирования, ручное вмешательство позволяет сравнить две разные среды тестирования и выбрать версию, которую вы хотите развернуть в рабочей среде. Как только администратор выбирает предпочтительную версию, он нажимает кнопку, чтобы вызвать рабочий процесс Cloudify, который обращается к Jenkins через главный менеджер Cloudify, чтобы переместить выбранную версию (из первого теста A / B или из второго теста A / B) в рабочую.
Таким образом, несмотря на то, что на данный момент у нас есть две среды тестирования с небольшими отличиями и полуавтоматическим производственным развертыванием, в конечном счете, можно полностью создать сценарий, по сути, замкнув цикл от непрерывной интеграции к непрерывной доставке.
В проекте Jenkins мы также создали собственный рабочий процесс, который позволяет пользователям запускать любые команды CLI Jenkins из CLI Cloudify, поэтому вам даже не нужно (хотя вы можете) получить доступ к CLI Jenkins для запуска команд. Это отличный пример того, как механизм рабочих процессов Cloudify можно использовать для создания настраиваемой автоматизации рабочих процессов для удаленного доступа к вашим средам без необходимости использования SSH или использования каких-либо других агентов (однако вы можете сделать это, если хотите).
В этом случае мы выбрали наше приложение Drupal, которое является одной из самых популярных платформ CMS, поэтому каждое развертывание на каждом из менеджеров Cloudify состоит из трех уровней: Apache, MySQL и Memdached.
Вот изображение, которое показывает, как Jenkins разворачивает приложение Drupal:
В этом примере также демонстрируется, как вы можете использовать все дополнительные возможности Cloudify, которые входят в комплект поставки, для расширения функциональности Jenkins и обеспечения надежного CI через CD, включая все, что необходимо для после развертывания, что является критически важным элементом в процессах непрерывной доставки . Таким образом, вы можете по существу контролировать Jenkins — и не только само приложение, но и весь жизненный цикл процессов сборки и развертывания (например, успех / сбой), а также определять собственные метрики на основе вашего развертывания с помощью механизма политики Cloudify.
Это позволяет проводить интеллектуальный анализ системы независимо от ее построения, а также принимать решения на основе собранных файлов журналов и других KPI, получать оповещения и автоматически восстанавливать систему и масштабировать ее на основе этих политик. Более того, независимость от инфраструктуры позволяет запускать этот пример на любой виртуальной машине, сервере без поддержки или даже в контейнерах Docker.
Другим важным элементом в непрерывной интеграции является очистка — и не оставлять грязные машины позади вас. Это также может быть включено в ваш план, что позволит вам затем отменить развертывание каждого задания Jenkins и результатов заданий или фактических развертываний, а также соответствующего менеджера Cloudify. Некоторые другие интересные изменения и модификации, которые были сделаны, позволяют создавать версии с помощью процесса ручной очистки, позволяя настроить версии развертываний, а затем выбрать любую версию (для перехода к производству) в любое время.
С Cloudify и Jenkins можно многое сделать — я только начал взламывать некоторые изящные возможности. Вы можете посмотреть видео в действии, приведенном ниже, и не стесняйтесь комментировать и делиться любыми другими идеями, которые могут у вас возникнуть для получения максимальной отдачи от вашего КИ.
Вся эта реализация, включая проект Дженкинса, также доступна в Github .
Посмотрите видео этого в действии ниже:
