В последнее время в компании WSO2 проделали огромную работу по доступности своих продуктов для различных платформ и сервисов. Если мы посмотрим на типичную страницу скачивания какого-либо продукта WSO2 - то мы увидим огромное количество опций:

Кнопка Download автоматически определяет вашу операционную систему и предложит вам скачать дистрибутив под вашу операционную систему (pkg для MacOS, msi для Windows). Есть и старый добрый zip, есть пакеты для различных дистрибутивов Linux (apt/yum). Есть скрипты для Puppet, Ansible и прочего. Есть возможность разворачивания в Kubernetes. Меня же очень интересовала возможность разворачивания в AWS с использованием AWS Cloud Formation. Наконец я попробовал и посмотрим что из этого получилось.

Для тех кто не в курсе - очень грубо - AWS Cloud Formation - это скрипт для запуска вычислительных ресурсов в облаке AWS.

При клике на "AWS Cloud Formation" мы попадает на страницу выбора региона. Я думаю это связано с тем, что исходные образы продуктов WSO2  доступны не во всех регионах. По факту - только в регионах, размещенных в USA (плюс один в Азии). Так же можно выбрать конфигурацию (в случае с Enterprise Integrator-ом предлагается две опции - Интегратор с Аналитикой, или Интегратор с вынесенным Брокером плюс Аналитика).

При клике - вы попадаете на визард старта стека (Stack - это набор ресурсов, созданных в результате работы Cloud Formation). На первом шаге вы выбираете шаблон (собственно говоря скрипт для исполнения). При клике с сайта WSO2 вам по умолчанию будет загружен скрипт для выбранного продукта.

Далее наступает самое интересное окно - параметров для запуска стека:

Вам надо будет указать:

• Stack Name - имя стека. Проставляется автоматически - но можно изменить.
• AWSAccessKeyId / AWSAccessKeySecret - id ключа и секрет. Чтобы их получить вам надо сделать в AWS IAM пользователя с программным доступом и необходимыми правами (проще всего администратора) и указать тут его данные.
• KeyPairName - ключевая пара. Будет потом использоваться вами для логина на созданные машины по ssh.
• WSO2 Instance Type - тип запускаемых машин - по умолчанию t2.medium
• Certificate Name - имя сертификата, который будет использован для https протокола на балансировщике нагрузки (Load Balancer-е). С ним самое интересное - об этом напишу ниже
• DBUserName/DBPassword - имя пользователя и пароль, которые будут созданы в базе данных и использованы для доступа. Тут можно указать любые значения (например admin/admin).
• WUM UserName/Password - имя пользователя и пароль для доступа в WUM (WSO2 Update Manager) - в случае если у вас есть активная подписка WSO2. Если нет - то оставляем пустыми

Использование сертификата SSL

Тут возникла определенная проблема. Дело в том, что скрипт настроен на использование серверного сертификата, загруженного через IAM. При этом, Amazon рекомендует использовать эти сертификаты только в регионах, где недоступен ACM (Amazon Certificate Manager). В итоге мне пришлось поменять скрипт на использование сертификатов ACM. Для этого на первом шаге визарда создания Stack-а я открыл шаблон в редакторе, скачал его - а дальше загружал уже свою версию. В шаблон необходимо внести изменения в настройку SSLCertificateId и Certificates у LoadBalancer-ов (я пока не понял, но почему-то используются разные типы балансировщиков для Аналитики и самого Интегратора). Искать надо по ключевому слову "server-certificate"  и заменять формирование ARN сертификата на конструкцию типа

SSLCertificateId: !Join
            - ''
            - - 'arn:aws:acm:us-east-1:'
              - !Ref 'AWS::AccountId'
              - ':certificate'
              - /
              - !Ref CertificateName

(не забываем указать другой регион, в случае если вы используете что-то отличное от us-east-1).

Запуск Stack-а

После указания всех параметров мы доходим до кнопки "Create Stack". У меня создание стека заняло порядка 5-ти минут. Если что-то пойдет не так, то вы увидите "CREATE_FAILED" (я такое получал пока боролся с сертификатом), и как итог статус стека - "ROLLBACK_COMPLETE". А если все хорошо - то статус будет "CREATE_COMPLETE". В окне стека можно посмотреть созданные ресурсы

А в качестве результата исполнения - две ссылки - для доступа к поратлу аналитики и для доступа к карбоновской панели Интегратора. И ни одна из них в моем случае не заработала :)

Пойдем разбираться что же запустил данный шаблон.

Запущенные ресурсы

В ходе работы скрипт Cloud Formation создал все необходимое окружение - VPC, Security Groups.... Создал базу данных (RDS) на MySQL с заданным администратором (помните мы указывали имя пользователя и пароль для базы знаний). Внутри VPC запущено несколько виртуалок:

• Бастион - единственная доступная на ssh снаружи - для доступа к другим виртуалкам.
• Puppet Мастер - для настройки остальных нод
• Два инстанса самого Интегратора
• Analytics Worker - для сбора аналитики
• Analytics Dashboard - портал для просмотра аналитики

Для доступа к инстансам интегратора и портала аналитики используются балансировщики нагрузки (доступные снаружи).

Если надо зайти на запущенные машины по ssh - то надо сначала зайти на бастион (используем имя пользователя ubuntu и ключевую пару, которую указали при запуске стека):

ssh -i <path/to/keypair.pem> ubuntu@<bastion.public.ip.address>

И дальше уже с него можно идти по ssh на другие машины (только предварительно закинуть ключевую пару на бастион).

Развертывание продукта происходит с использованием Puppet (и занимает некоторое время, поэтому после старта Stack-а ссылки не работали - после старта требовалось некоторое время, чтобы конфигурация прокачалась с puppet-а.

WSO2 устанавливается в /usr/lib/wso2. Все сервера кроме PuppetMaster стартуют с дефолтового AMI с Ubuntu, для Puppet Master используется заранее подготовленный образ. Обе ноды Integrator-а шарят  /deployment/server через EFS. База Данных используется для Puppet (WSO2 EI ее не использует).

В итоге, подождав некоторое время я получил рабочую ссылку на карбон (доступ по умолчанию - admin / admin)

Доступ к порталу аналитики не заработал (при том что сам портал аналитики работает). Как показало исследование - неправильно был настроен HealthCheck на балансировщике нагрузки - как результат он не видел ноду портала. После исправления - и портал аналитики тоже стал доступен.

В качестве заключения

В целом почти все заработало (не без напильника, ну куда ж без него родимого). Неплохой пример на котором можно разобрать настройку простейшего кластера. Ну или если надо быстро поднять в AWS кластер для каких-то тестовых работ. В Production я бы конечно с этим не пошел - слишком много "неизвестного" под капотом.