В последнее время, многие общепризнанные в мире сервисы оказались недоступны для разработчиков из России и им приходится искать аналоги. Одной из таких альтернатив для GitHub является сервис GitFlic. Это такой же хостинг исходных кодов, который, кроме того, предоставляет возможность использовать в работе реестры артефактов и пакетов для различных технологий. В нашем случае это можно засчитать за УТП (Уникальное торговое предложение), ведь не многие разработчики знают о сторонних registry-сервисах продолжая пользоваться DockerHub, который работает “по умолчанию”. Кроме того, развертывание собственного такого сервиса, соответствующего всем требованиям корпоративной безопасности, может потребовать немалых ресурсов.  

Чтобы исходный код стал артефактом, т. е. ресурсом, готовым к развертыванию в тестовых или продуктивных средах без лишней ручной работы желательно иметь некоторый пайплайн, т. е. сборочный конвейер, который выполнит все преобразования. GitFlic не предоставляет агентов пригодных для сборки контейнерных образов, но позволяет подключать собственные. В данной статье мы настроим сборочный пайплайн для Java разработки на фреймворке Jmix с использованием агента, работающего в кластере Kubernetes.  

Создаем аккаунт, компанию и репозиторий

Чтобы получить все инфраструктурные возможности в GitFlic необходимо сначала зарегистрировать персональный аккаунт и уже в нем создать компанию. Это все можно сделать бесплатно. Премиальный тариф тоже имеется и расширяет возможности командной работы с приватными репозиториями.  

Для отработки сборочных сценариев мы будем использовать специальную редакцию кластера minikube предназначенную для разработки на локальном компьютере. Разворачивать ее на отдельном сервере тоже можно, но тут повышается риск получить набор суровых пазлеров раньше времени. Начинать лучше ближе к телу и железу.

Устанавливаем minikube

На момент написания статьи GitFlic уверенно работал с версиями minikube до 1.30, самый простой способ ее установить — это скачать готовый бинарник из релизов и положить в локальный Path, например /usr/local/bin. 

На unix-like ОС это можно сделать при помощи следующих команд: 

curl -LO https://storage.googleapis.com/minikube/releases/v1.30.0/minikube-linux-amd64  
sudo cp minikube-linux-amd64 /usr/local/bin/minikube 
sudo chmod a+x /usr/local/bin/minikube  

Настраиваем kubectl

Работая с minikube использовать утилиту управления kubectl можно при помощи алияса, т.е. аналога ссылки для командного интерпретатора. Чтобы не настраивать его каждый раз можно в файл ~/.bashrc добавить следующую команду: 

alias kubectl="minikube kubectl --" 

Она будет исполняться при каждом новом терминальном логине инструктируя Bash набранное kubectl преобразовывать в minikube kubectl передавая в него все аргументы. Применить конфигурацию, не выходя из текущей сессии можно при помощи команды source. 

Запускаем minikube

Для запуска надо выполнить команду start из-под обычного пользователя

minikube start

Чтобы увидеть веб-интерфейс панели управления кластером, надо запустить еще dashboard 

minikube dashboard

Адрес панели управления будет выведен в консоли после запуска, у меня это было.

http://127.0.0.1:38257/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/#/pod 

Его надо открыть в браузере.

Если вы запускаете minikube на отдельном сервере придется поднять еще kube-proxy и открывать по внешнему ip-адресу и переназначенному порту с таким же ссылочным путем.

Устанавливаем helm

Клиентскую утилиту для пакетного менеджера Kubernetes можно установить, например, вот такой командой:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash 

Создаем группу gitflic-runner

Для работы агента создадим группу, для этого можно добавить следующую конфигурацию в манифест static.yaml: 

apiVersion: v1 
kind: Namespace 
metadata: 
  name: gitflic-runner 
  labels: 
    name: gitflic-runner 
--- 
apiVersion: rbac.authorization.k8s.io/v1 
kind: Role 
metadata: 
  namespace: gitflic-runner 
  name: manager-role 
rules: 
  - apiGroups: ["*"] 
    resources: ["*"] 
    verbs: ["*"] 
--- 
apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRole 
metadata: 
    name: gitflic-runner-read-only 
rules: 
  - apiGroups: [""] 
    resources: ["namespaces"] 
    verbs: ["get", "list"] 

И применить при помощи команды apply:

kubectl apply -f static.yaml 

Все процессы мы теперь сможем видеть в веб-панели dashboard заходя в разделы

Создаем сборочного агента

Получить параметры для регистрации сборочного агента можно на сайте gitflic.ru в настройках компании

Заполним values.yaml данными для активации агента из интерфейса выше:

registerUrl: https://coordinator.gitflic.ru/-/runner/registration 
registerToken: e168e497-0ec8-4a26-8151-41d1782ee123 
registerName: local-kuber 
registerTags: "" 

Также не помещает добавить конфигурационные параметры:

config: 
    additional: | 
      kubernetes.volumes.pollTimeout=3600 
      kubernetes.namespace=gitflic-runner 

Перечень всех поддерживаемых параметров можно узнать в официальной документации по интеграции GitFlic и Kubernetes по следующему адресу:

https://docs.gitflic.ru/setup/runner/kuber_run/

Устанавливаем агента в кластер

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

helm install gitflic-runner oci://registry.gitflic.ru/helm/company/gitflic/gitflic-runner-chart -f values.yaml

gitflic-runner - это имя, под которым будет отображаться развертывание 

адрес начинающийся с oci://... - указывает откуда брать шаблоны развертывания 

-f values.yaml - указывает на файл значений переменных шаблонов.  

После успешного выполнения команды, в списке агентов должна появиться запись со статусом “Активный”. Если что-то пошло не так, смотрите логи.  

Удалить неудачно развернутый пакет, чтобы попробовать заново можно командой uninstall. 

Если вам требуется переопределять эти конфигурации, например для изменения лимитов выделяемых ресурсов, то можно скачать пакет найдя его в поиске сайта gitflic.ru

https://gitflic.ru/search/package?q=gitflic-runner-chart 

распаковать, отредактировать и ставить из локального каталога используя точку вместо адреса. 

Дорабатываем проект для поддержки пайплайна

Создать Jmix-проект можно в любой среде разработки на основе IntelliJ IDEA с плагином Jmix Studio. В России хорошим выбором будет OpenIDE (https://openide.ru/), не только потому, что она бесплатная и доступна для скачивания без ограничений, но также и от того, что является продуктом консорциума тех же компаний, которые разрабатывают GitFlic и Jmix, а именно Группа Астра и Haulmont, а значит, их разработки содержат удобные интеграции со всеми сервисами и технологиями для эффективной Java разработки. 

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

Профили Spring 

Для более удобной работы с проектом лучше реализовать в нем поддержку профилей конфигурации Spring. 

Для этого кроме application.properties в проекте надо создать еще конфигурационные файлы с именами application-dev.properties и application-prod.properties соответствующими профилям разработки и продуктива.  

Перенести существующий датасорс в application-dev, а в prod добавить конфигурацию с какой-нибудь серверной СУБД, например PostgreSQL не забыв также указать драйвер PostgreSQL в зависимостях проекта. Манипуляции с датасорсом можно проделать несколько удобнее в панели Jmix Studio открыв конфигурацию в Data Stores из дерева категорий. 

А в build.gradle добавить выбор профиля в зависимости от режима запуска.

bootRun { 
    args = ["--spring.profiles.active=dev"] 
} 
 
tasks.named("bootBuildImage") { 
    environment["BPE_APPEND_JAVA_TOOL_OPTIONS"] = " -Dspring.profiles.active=prod" 
} 

Настраиваем сборку образа с Jib 

Для сборки контейнеров в среде Docker требуется поддержка Docker-in-Docker или его аналога для Kubernetes. Но есть альтернативное решение — это плагин под названием Jib, который позволяет собирать образы без использования Docker-рантайма. Его мы и подключим в проект добавив в build.gradle такие строчки:

plugins { 
  id 'com.google.cloud.tools.jib' version '3.4.5' 
} 

jib { 
  container { 
    format = 'Docker' 
  } 
}  

Конфигурация пайплайна

Чтобы GitFlic знал как собирать наш проект, в проектные исходники добавим файл gitflic-ci.yaml: 

image:  
  name: ahmedgalalfathy/dind-jdk-21:latest 
build: 
  before_script: 
    - docker login -u="${REG_LOGIN}" -p="${REG_PASSWORD}" ${REG_URL} 
  script: 
    - apk add --update nodejs npm 
    - ./gradlew --no-daemon -Pvaadin.productionMode=true build 
    - ./gradlew jib -Djib.to.image=registry.gitflic.ru/project/{ownerAlias}/{projectAlias}/testjmixgitflic:0.0.1-SNAPSHOT -Djib.from.image=eclipse-temurin:21-jre

Вместо {ownerAlias} и {projectAlias} надо подставить значения от вашего проекта. 

Это максимально упрощенная версия, в ней не разделены задачи, и она будет исполняться при каждом пуше в репозиторий. 

Кроме сборки исходников и образа в этой конфигурации выполняется логин в реестр образов нашей компании для последующей публикации образа в него и установка пакетов NodeJS, которые необходимы для транспиляции фронтенд-файлов. 

Добавляем переменные окружения пайплайна 

В конфигурации пайплайна мы определили переменные для аутентификации в реестре артефактов: REG_URL, REG_LOGIN и REG_PASSWORD и надо задать их значения в “Настройках CI/CD” из раздела Настроек компании. 

Коммит и пуш в репозитории с исходниками запустит процесс сборки приложения, который можно отслеживать в проектной вкладке CI/CD. 

Результат 

Когда задача успешно отработала мы можем увидеть артефакт контейнерного образа в реестре. 

Теперь мы можем использовать этот образ для автоматизированного развертывания приложения.