CUSTIS Labs. Развертываем инфраструктуру за минуты

Старт любого нашего проекта начинается с подготовки инфраструктуры. Времени на это порой уходит довольно много. Как минимум необходимо нарезать виртуалки или донастроить Kubernetes, настроить CI, базы данных, логирование, мониторинг и прочие компоненты. В лучшем случае в этих заботах проходит несколько дней, а ни строчки кода еще не написано. Знакомая ситуация?

Лучшим решением для нас стал собственный набор сервисов, инструментов и подходов — CUSTIS Labs. Он помог нам сократить время подготовки инфраструктуры с нескольких дней до минут. Также убрал лишние коммуникации, которые возникают между разными специалистами при создании инфраструктуры вручную. Теперь разработчику не надо узнавать у девопса, где лежат логи, где находятся метрики сервиса и как подключиться к базе — все настраивается и сообщается разработчику автоматически.

Настройка быстрого старта не единственная задача, которую решает CUSTIS Labs. Подробнее о других его функциях расскажем в следующих статьях.

Почему все не в Kubernetes

Популярный на рынке способ быстрого старта — все всегда стартовать в Kubernetes — мы отмели сразу.

Во-первых, сам Kubernetes не всегда подходит под конкретные задачи. Для определенных работ сейчас есть более удобные и эффективные инструменты. Например, с базами данных пока лучше работать вне Kubernetes.

Во-вторых, стенд разработки и тестирования на нашей стороне должен быть максимально похож на стенд клиента. А на всех проектах заказчик разный, со своими особенностями и стандартами.

Как мы стартуем проекты

В отделе разработки у нас есть группа MVP (minimum viable product), она же группа прототипирования. Это небольшая команда, состоящая из одного-двух фулстек-разработчиков и тимлида. Основные задачи этой команды — тестирование гипотез, разработка коммерческих предложений и запуск новых проектов. Для решения этих задач как раз очень хорошо подходит Kubernetes.

В отделе прототипирования все происходит стремительно. От задумки до прототипа должны проходить максимум дни. Идея, сбор команды, прототип, демо — и так постоянно.  Ребята как можно быстрее должны приступить к написанию бизнес-логики, не отвлекаясь на выделение инфраструктуры под проект, создание баз данных и прочее.

Мы используем популярные на рынке технологии. Техстек и инфраструктура проектов в отделе MVP выглядит так:

• Kubernetes как среда исполнения контейнеров;

• PostgreSQL как СУБД;

• В GitLab мы храним код;

• GitLab CI — наша сборка и деплой;

• OpenSearch, Grafana, Prometheus — сбор и визуализация метрик и логов;

• Выбор языка программирования зависит от клиента, но, как правило, это Java/.NET;

• Кэш — Redis;

• Очереди — RabbitMQ.

Как видите, все довольно стандартно.

Итак, для старта проекта команде MVP необходимо:

• Подготовить инфраструктуру;

• Создать проект в GitLab;

• Создать для проекта базу данных;

• Настроить CI;

• Настроить логирование и сбор метрик;

• Настроить внешний URL проекта для заказчика;

• Выписать для этого URL необходимые сертификаты.

Для того, чтобы все это автоматизировать, нужен был какой-то подход. Мы посмотрели вокруг и поняли, что модель ChatOps наиболее подходящая в нашем случае. 

Создали бота в Телеграме и подключили его к нашему CI. Бот принимает определенные команды, в недрах инфраструктуры происходит запуск pipelines и по результатам внутренней магии бот рапортует пользователю о проделанной работе.

Пример:

Командуем боту /newproject, отвечаем на вопросы по названию проекта, типу бэкенда, наличию фронтендa, необходимости в базе данных. Через некоторое время получаем в ответ URL созданного проекта или группы проектов в GitLab с кодом и уже настроенным CI, описанной инфраструктурой в Terraform, а также URL для доступа к логам, метрикам и URL для клиента.

Как происходит запуск под капотом

Всё, что нам надо для работы, готово. Предлагаем посмотреть, как это устроено.

Общая схема работы:

Бот получает данные от пользователя и:

1. Дергает API GitLab для запуска pipeline проекта INFRA

2. Runner подхватывает pipeline и:

• создает репозиторий из заранее подготовленного шаблона;

• создает БД для проекта, если необходимо;

• в последнем шаге pipeline и сообщает в чат о проделанной работе.

Основная логика работы находится в проекте INFRA.

Выглядит он как стандартный репозиторий с Ansible:

• …

• files

• inventory

• roles

• templates

• deploy-new-db.yml

• deploy-new-gitlabproject.yml

• .gitlab-ci.yml

• ….

Для проекта INFRA мы создали pipeline trigger и добавили вызов этого триггера в логику работы бота, тут всё по документации:

curl -X POST \
     -F token=TOKEN \
     -F "ref=REF_NAME" \
     -F "variables[SOMEVAR]=true" \
     https://git.custis.ru/api/v4/projects/1524/trigger/pipeline

Бот вызывает этот POST с нужными нам параметрами.

Далее Runner подхватывает pipeline и выполняет по очереди шаги из секции scripts:

Создает новый проект из templates в GitLab.

script:
    - …
    - export BACKTYPE=…
    - …
    - ansible-playbook -c local deploy-new-gitlabproject.yml -vv

Создает новую БД для проекта, если необходимо.

script:
    - …
    - export DBNAME=…
    - export DBUSER=…
    - export DBPASS=…
    - ansible-playbook -i dbcluster deploy-new-db.yml -vv

В самом конце рапортует пользователю о проделанной работе:

.x-chat-notification: &chat_notification
  - |
    notification_send(){ curl --silent --insecure --max-time 10 --data chat_id="${TG_CHAT_ID}" --data "disable_notification=true" --data "disable_web_page_preview=true" --data "parse_mode=html" --data "text=$(echo $@)" "https://chat-url/chatbot${RC_BOT_TOKEN}/sendMessage"; }
    notification_message(){
      echo "<b>Project details</b>
  Project external URL: &lt;a href='$NEWPROJECTURL'&gt;$NEWPROJECTURL&lt;/a&gt;
  Project Gitlab URL: &lt;a href='$NEWPROJECTGITURL'&gt;$NEWPROJECTGITURL&lt;/a&gt;
  Logs: $ELKURL
  Metrics: $GRAFANAURL
  "|xxd -p|tr -d \\n|sed 's/../%&amp;/g';
}
notification_send $(notification_message)

script:
- …
- *chat_notification

Структура созданного проекта кроме кода каркаса сервиса на указанном языке программирования содержит типичный набор компонент для деплоя.

На примере бэкенд-сервиса:

1. Код каркаса сервиса на C# или Java;

2. Dockerfile;

3. .helm файлы;

4. .gitlab-ci.yml с шагами сборки, проверки на безопасность и деплоя.

Пользователю после получения сообщения от бота осталось только сделать git clone и написать бизнес-логику :-) 

Commit, Push и деплой на dev-стенд стартует автоматически. После тестов, сборки и деплоя наш проект доступен по адресу  https://dev-<projectname>.labs.domain.ru

Расскажите в комментариях, а как вы решаете задачу быстрого старта?

Мы рассмотрели только один случай применения CUSTIS Labs. Однако у нас его активно использует не только группа MVP. В других отделах разработки, где продукты уже внедрены, важна стандартизация компонентов проекта — единые шаблоны, форматы и вводные. Когда первые шаги стандартны, гораздо легче работать: база сама создается, логи в одном месте, — бери и пиши код. Кроме того, упрощается вход новых сотрудников в проект, которые должны как можно скорее начать ориентироваться в нем и приступать к решению бизнес-задач. Тоже самое справедливо и при переходе с одного проекта на другой. Со всем этим нам также помогает CUSTIS Labs.

В следующий раз подробно расскажем про то, как мы стандартизируем и управляем компонентами на проектах на примере СУБД PostgreSQL.