Небольшое введение или зачем эта затея?
Первое, с чего нужно начать любому разработчику, это выбор его главного инструмента, оптимизирующего большинство его временных затрат. Таковым является его рабочий репозиторий. Сейчас существует большое количество различных вариантов, где painless можно хранить свою работу.
Можно конечно и не считать это за проблему и хранить свои наработки и пет проекты где нипопадя, но какие-то локальные проблемы рано или поздно возникнут и не дадут вам спать спокойно.
Моя статья могла бы и рассмотреть репозитории из большой тройки (github, gitlab, bitbucket), но сейчас появилась отличная конкурентоспособная альтернатива в виде Gitea, которую можно разместить на любом сервере.
Из плюсов можно выделить то, что весь этот проект написан на go, а также возможность запуска без дополнительного сервера — и обычную и docker версию можно поднять на машине, прокинув порты.
Настройка контейнера с Gitea-сервером
Не будем вдаваться в детали и запустим наш первый gitea сервер через docker-compose. Для начала рассмотрим конфиг, от которого следует оттолкнуться в первый раз:
mkdir /srv/gitea
cd /srv/gitea
nano docker-compose.yml
version: "3"
services:
server:
image: gitea/gitea:latest
environment:
- USER_UID=2004
- USER_GID=2004
restart: always
volumes:
- ./data:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"
Формирование коротких и понятных путей в Linux системах очень полезно, если вы постоянно путешествует через терминал или Midnight Commander.
docker-compose up -d
Перед этим желательно проводим подготовку портов к новому сервису, проверяем настройки iptables, ufw и других систем имеющих влияние на конфигурирование сетевых интерфейсов. В данном конфиге был использовано переназначение порта на аналогичный внутреннему, поскольку 80 и 443 порты обычно уже заняты.
После первого запуска Gitea, вместо регистрации по адресу localhost:3000 веб-сервис предложит вам провести быструю настройку. В том числе можно отметить здесь возможность конфигурирования пути к репозиториям, которые будут хранится на вашем сервисе. Если вы планируете переназначить этот путь на другой, то стоит проверить свой docker-compose конфиг, чтобы репозитории хранились не в одном из слоев докера, а на смонтированном хранилище.
После нажатия кнопки установить, необходимо подождать некоторое время. После чего необходимо снова попасть на страницу регистрации. Теперь вы реально можете зарегистрироваться в собственном репозитории.
Развертывание Drone-сервера рядом
Создадим аналогичную папку рядом с новосозданным gitea-сервером и заставим жить в ней другую часть нашего будущего пайплайна. Конфиг опять крайне примитивный, однако здесь обязательно будет разобрать несколько мелочей.
version: "3"
services:
drone:
image: drone/drone:latest
environment:
# Включаем поддержку агентов - машин для выполнения удаленной сборки
- DRONE_AGENTS_ENABLED=true
# Указываем адрес нашего Gitea-репозитория (например: https://адрес-gitea.сервера)
- DRONE_GITEA_SERVER=
# В настройках личного аккаунта получаем OAuth2 ключи для доступа из Drone
- DRONE_GITEA_CLIENT_ID=
- DRONE_GITEA_CLIENT_SECRET=
# Генерируем RPC-клюс, который затем будет использоваться для разрешения доступа агентам
- DRONE_RPC_SECRET=
# Указываем адрес хоста (например: drone.localhost)
- DRONE_SERVER_HOST=
# Указываем проткол хоста (http/https)
- DRONE_SERVER_PROTO=
# Выключаем SSL и автосертификацию сервера
- DRONE_TLS_AUTOCERT=false
- DRONE_GIT_ALWAYS_AUTH=false
restart: always
volumes:
- ./data:/data
ports:
- 3001:80
Но перед тем как запускать контейнер с сервером, необходимо заполнить данные OAuth2, которые мы легко можем получить из настроек вашего личного профиля на Gitea.
Для этого, на вкладке Applications находим подраздел Manage OAuth2 Applications с кнопкой Create Application и нажимаем на нее.
Из вкладки забираем так необходимые нам Client ID и Secret, которые необходимо ввести в конфигурационном файле.
В поле Redirect URI стоит добавить /login, потому что gitea очень капризно относится к процессу авторизации и предоставлении доступа через OAuth2. Поэтому, пока вы не добьетесь полного сходства адресов, gitea не даст drone доступа к пользовательским данным.
Вот оно заветное окно, которое возникает при правильной настройке OAuth2 аутентификации.
А теперь создаем пробный репозиторий, заливаем в него код для теста и добавляем наш заветный .drone.yml. В моем случае я залил проект-шаблон, который создается командой dotnet.exe new blazorserver.
kind: pipeline
name: default
platform:
os: linux
arch: amd64
steps:
- name: build-test
image: mcr.microsoft.com/dotnet/core/sdk:latest
commands:
- dotnet restore
- dotnet build
Активируем репозиторий в drone.
И запускаем дополнительного агента для сборки наших билдов. Позволительно даже собираться под Windows 10 и под Windows Server.
version: "3"
services:
drone-agent:
image: drone/agent:latest
command: agent
restart: always
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
# Указываем адрес основного сервера
- DRONE_RPC_SERVER=
# Указываем секретку для осуществления доступа к сборке из данного агента
- DRONE_RPC_SECRET=
Успешность всех операций определяет следующее окно с данными.
Сам лично я провел все данные операции за два часа, попутно настраивая сервер на базе сервиса https://labs.play-with-docker.com/ и занимаясь описыванием всех моих действий внутри этой статьи. Не обошлось и без проблем, с которыми может столкнутся каждый, но опыт, который я описал здесь, поможет прямолинейно настроить свой отдельный уголок для сборки проектов.