07.04.2021 Время чтения: 5 минут

Как мы автоматизировали развёртывание тестовых стендов с помощью Gitlab и VMmanager

Как в ISPsystem экономят 15 человеко-часов в неделю, рассказал специалист QA Антон Рязанцев.

Зачем автоматизировать создание тестовых стендов

В продуктовых командах мы стремимся автоматизировать рутинные задачи, которые отнимают много времени. Иногда для этого используем собственные продукты. Например, VMmanager помогает нам в развёртывании тестовых стендов. В процессе разработки и тестирования поднимать стенды требуется довольно часто, и хочется сделать этот процесс максимально простым. Код наших продуктов хранится в Gitlab, процессы CI/CD также организованы в нём. Поэтому удобно интегрировать Gitlab и VMmanager для создания стендов.

Как запуск создания тестового стенда реализован в Gitlab

Разработчик подготавливает ветку в репозитории в Gitlab. Пайплайна (pipeline) этого репозитория включает ручные задачи (job). Каждая из них устанавливает продукт из ветки на некоторый тестовый стенд. В качестве тестового стенда выступает виртуальная машина на VMmanager . Такая виртуальная машина и ручная задача для неё есть у каждого разработчика и тестировщика.

Пайплайна ветки в Gitlab, включающая ручные задачи для развёртывания стендов из этой ветки

Когда это необходимо, пользователь (разработчик или тестировщик) запускает задачу.

Для задачи задан ID виртуальной машины, на которую она разворачивает стенд, а также ID скрипта в VMmanager и параметры для него.

Задача по API VMmanager выполняет необходимые действия над виртуальной машиной:

Переустанавливает операционную систему, чтобы очистить виртуальную машину от результатов предыдущего использования.
Выполняет скрипт VMmanager с параметрами, чтобы развернуть стенд с продуктом, с которым хочет работать пользователь.

Пользователю остаётся дождаться завершения задачи, чтобы получить готовый стенд.

Пример задачи:


variables:
  RECIPE_ID: 1
.stand_setup:
  stage: VM6_stand
  image: python:3.9-alpine
  script:
    - echo “Run env install on vm $VM_ID”
    - python3 reinstall_vm.py --domain “$VM6_HOST” --login “$VM6_LOGIN” --password “$VM6_PASSWORD” --vm_id “$VM_ID” --platform “$PRODUCT” --vm_recipe “$RECIPE_ID” --intrepo_password “$CI_JOB_TOKEN” --token “$TOKEN” --branch “$CI_COMMIT_REF_NAME”
  when: manual

QA1_stand:
  extends: .stand_setup
  variables:
    VM_ID: 1
    PRODUCT: “dci”
    TOKEN: “$QA1_TOKEN”

За взаимодействие с VMmanager 6 по API отвечает Python-скрипт reinstall_vm.py. Реализовать такой скрипт на Python или Bash не сложно. Для этого нам понадобится API VMmanager.

Скрипт принимает в качестве аргументов:

Данные доступа к VMmanager (VM6_HOST, VM6_LOGIN, VM6_PASSWORD).
ID виртуальной машины, на которой будет развёрнут стенд (VM_ID).
Платформу, которую будем устанавливать на стенд (PRODUCT).
ID скрипта на VMmanager, который установит необходимый продукт на виртуальную машину (RECIPE_ID).
Пароль для доступа к внутреннему репозиторию (CI_JOB_TOKEN).
Лицензионный токен, который нужен, чтобы установить необходимый продукт (TOKEN).
Ветку в репозитории, из который будет установлен необходимый продукт (CI_COMMIT_REF_NAME).

Часть из этих данных мы храним в Gitlab CI/CD Variables в защищённом виде.

Список переменных в Gitlab CI/CD variables для репозитория, в котором есть задачи для развёртывания стендов

Как создание тестового стенда реализовано с помощью VMmanager

Скрипт в VMmanager 6 содержит последовательность команд, которая устанавливает и настраивает стенд на виртуальную машину.

Форма редактирования скрипта для установки и настройки окружения на стенде в VMmanager

Тело скрипта:


# Устанавливаем необходимые пакеты на стенд

yum -y install epel-release
yum -y install vim the_silver_searcher jq

# Настраиваем стенд

curl -o /root/.bashrc https://raw.githubusercontent.com/airreality/.dotfiles/master/.bashrc
curl -o /root/.aliases https://raw.githubusercontent.com/airreality/.dotfiles/master/.aliases_test_servers
curl -o /root/.aliases_docker https://raw.githubusercontent.com/airreality/.dotfiles/master/.aliases_docker

# Записываем в конфигурационный файл docker данные для доступа к внутреннему репозиторию

mkdir -p ~/.docker
echo '{"auths": {"internal.example.com": {"auth": "'$(echo -n "($LOGIN):($PASSWORD)" | base64)'"}}}' > ~/.docker/config.json

# Устанавливаем платформу, которую будем тестировать

curl -O http://internal.example.com/($PRODUCT)/($BRANCH)
chmod +x ($PRODUCT)
./($PRODUCT) install -l ($TOKEN)

Скрипт содержит параметры:

PASSWORD
PRODUCT
BRANCH
TOKEN

Удобно и безопасно, что эти данные нигде не фигурируют. Нам не приходится их записывать в тело скрипта, перед тем как его запустить. Вместо этого мы один раз передаём их при запуске скрипта по API.

Также используется глобальная переменная LOGIN — логин для доступа к внутреннему репозиторию. Логин всегда одинаковый, поэтому мы храним его в глобальных переменных.

Отфильтрованный список глобальных переменных для скриптов в интерфейсе VMmanager

Такая автоматизация позволяет нам сэкономить на каждом поднятии тестового стенда около 15-20 минут разработчика или тестировщика. В среднем новый стенд приходится поднимать примерно раз в рабочий день. Так за неделю мы экономим около полутора часов на каждого человека. В средней команде из 10 разработчиков и тестировщиков это даёт около 15 часов, которые можно потратить на другие задачи.