¶ Руководство пользователя GitlabProducer
Микросервис для выгрузки данных из git.miem.hse.ru в kafka
¶ Сборка
Собрать сервис можно тремя способами:
- Собрать бинарный файл из исходников
- Собрать докер образ из исходников
- Собрать докер образ в registry git.miem.hse.ru
¶ Бинарный файл
- Скопируйте репозиторий на своё устройство:
git clone https://git.miem.hse.ru/300/gitlab-producer.git - Перейдите в папку проекта и соберите бинарный файл:
make build
¶ Докер образ из исходников
- Скопируйте репозиторий на своё устройство:
git clone https://git.miem.hse.ru/300/gitlab-producer.git - Перейдите в папку проекта и соберите бинарный файл:
make package
¶ Докер образ в GitLab
- Перейдите по ссылке:
https://git.miem.hse.ru/300/gitlab-producer/-/pipelines/new
- Укажите ветку master
- Создайте переменную RELEASE_VERSION со значением например
gp-2023.1.0-test
(В поле input variable key напишите RELEASE_VERSION, в поле input variable key - ваше значение) - Запустите сборку нажатием на клавишу
Run pipeline - Образ будет собран и запушен в registry данного проекта
¶ Запуск и конфигурация
Приложение ищет yaml файл с конфигурацией в configs/conf.yaml,
также конфиг дообогащается переменными среды
| Переменная | Обязательность | Описание | Пример значения |
|---|---|---|---|
| SCHEDULING_POLL_INTERVAL | - | Интервал в секундах, который проходит между выгрузкой данных из Gitlab | 30 |
| GITLAB_BASE_URL | + | URL api Gitlab | https://git.miem.hse.ru/api/v4 |
| GITLAB_PRIVATE_TOKEN | + | Токен для api Gitlab | top-secret |
| GITLAB_PER_PAGE_PAGINATION | - | Кол-во элементов при пагинированных запросах в Gitlab | 10 |
| KAFKA_BOOTSTRAP_SERVERS | + | Брокеры Kafka через запятую | kafka-host1:9092,kafka-host2:9092 |
| KAFKA_TOPIC | + | Топик Kafka в который будут отправляться сообщения | data-bus.gitlab.events |
| KAFKA_LOGIN | - | Логин Kafka | user |
| KAFKA_PASSWORD | - | Пароль Kafka | pass |
| CACHE_TTL | - | Время хранения кэша (в минутах) | 1440 |
| OPERATIONS_PER_SECOND | - | Количество запросов в секунду в gitlab | 1 |
| METRICS_PORT | - | Порт для метрик | 9000 |
| METRICS_URL | - | Ручка для метрик | metrics |
| REDIS_ADDRESS | - | Адрес Redis | redis:6379 |
| REDIS_PASSWORD | - | Пароль к Redis | password |
| LOG_PORT | - | Порт для смены уровня логирования | 8002 |
| LOG_LEVEL | - | Стандартный уровень логирования | info |
| SCHEDULING_POLL_INTERVAL | - | Время ожидания в секундах между sink раундами | 30 |
¶ Запуск
¶ Запуск контейнера, собранного в Gitlab
- Для запуска образа на своей машине нужно выполнить команду:
sudo docker login https://git.miem.hse.ru/300/gitlab-producer/container_registry - После авторизации в интерактивном режиме, можно запускать контейнер, расположенный в gitlab. Конечный путь будет зависеть от значения переменной RELEASE_VERSION, в нашем примере:
https://registry.miem.hse.ru/300/gitlab-producer:gp-2023.1.0-test
¶ Запуск контейнера, собранного локально
После локальной сборки контейнер с именем gitlab-producer:latest будет готов к запуску
Для корректной работы приложения через docker контейнер, необходимо указать ему переменные среды штатными средствами docker (аргумент --env/--env-file, либо создание файла docker-compose, в котором необходимо указать путь до контейнера и необходимые переменные среды)
¶ Запуск бинарного файла, собранного из исходников
После сборки проекта исходный бинарный файл будет готов к запуску. Для конфигурирования параметров необходимо открыть конфигурационный файл configs/conf.yaml, в котором установлены значения по умолчанию, и установить свои параметры
Команда запуска сервиса: ./gitlab-producer
¶ Особенности
У сервиса предусмотрена возможность изменения уровня логирования во время работы. Для этого нужно отправить запрос: curl -X PUT адрес_вашего_сервиса:порт_логирования/log_level -d level=info
¶ Принцип работы
¶ Синк раунды
Основой сервиса являются синк-раунды. В синк-раунд входят 4 ассинхронных процесса - загрузка новых проектов, синхронизация загруженных проектов, загрузка новых пользователей и синхронизация загруженных пользователей.
Загрузка новых проектов запрашивает проекты с изменениями не позднее текущего дня и выгружает их в канал.
При наличии проекта в канале функция синхронизации запрашивает из гитлаба события для этого проекта и проверяет на наличии в кэше. Если событие отсутствует в кэше - событие будет кэшировано и отправлено в кафку
Пример гитлаб-события:
{
"id": 1,
"title":null,
"project_id":1,
"action_name":"opened",
"target_id":160,
"target_type":"Issue",
"author_id":25,
"target_title":"Qui natus eos odio tempore et quaerat consequuntur ducimus cupiditate quis.",
"created_at":"2017-02-09T10:43:19.667Z",
"author":{
"name":"User 3",
"username":"user3",
"id":25,
"state":"active",
"avatar_url":"http://www.gravatar.com/avatar/97d6d9441ff85fdc730e02a6068d267b?s=80\u0026d=identicon",
"web_url":"https://gitlab.example.com/user3"
},
"author_username":"user3"
}
Процессы для пользователей работают по такому же принципу, только изначально вместо проектов выгружаются пользователи
После выгрузки всех актуальных событий по проектам и пользователям синк-раунд заканчивается и сервис уходит в ожидание на SCHEDULING_POLL_INTERVAL секунд
¶ Ограничение нагрузки
Для регуляции нагрузки в сервисе используется ограничение на количество запросов в гитлаб. Установка ограничения происходит посредством задания значения переменной OPERATIONS_PER_SECOND.
¶ Кэш
Для хранения кэша событий используется Redis. События хранятся в виде
ID события - true