Comments 24
А если это всё надо развернуть на своём сервере, желательно с бесплатным и свободным софтом? У Gitlab же только ядро свободно распространяется, за CI/CD надо покупать лицензию. Если я не хочу зависеть от серверов гитлаба?
У нас пока всё ещё на самописных шеловских скриптах. Есть ночные сборки, сборки по событиям пока нет. Вот я и думаю, допиливать свой велосипед или брать что-то готовое?
Да собственно гитлаб, пинающий раннеры, а на раннерах - что угодно по своему вкусу.
Это всё есть в "бесплатном" варианте. Ну и плюс что-нибудь типа sonatype nexus как хранилище артефактов/дистрибутивов (тоже приемлемые условия для бесплатного варианта)
А совсем уж закладываться на прям всё готовое - не факт что окажется лучшим вариантом.
А что же у них тогда в платном варианте?
Эта информация есть на сайте разработчика
https://about.gitlab.com/pricing/feature-comparison/
Я понял источник моей ошибки, в гитлабе СI/CD поддерживается, но чтобы он полноценно работал нужны другие приложения. Я думал что как раз они-то и платные. А оказывается всё это есть бесплатно тоже.
Для CI/CD с Gitlab можно использовать и внешние инструменты, например, Jenkins
Без внешних инструментов, я так понял, нельзя.
Смотря что вы подразумеваете под внешними. Jenkins - инструмент от других разработчиков, а gitlab-runner создан разработчиками Gitlab для работы с ним для выполнения задач CI/CD.
Если от разработчиков гитлаб и тоже под свободной лицензией, то это уже не совсем внешний. Но разве одного раннера достаточно? Он будет запускать какие-нибудь контейнеры чтобы в них билдить?
гитлаб, пинающий раннеры
А можно подробней. Что нужно поставить и настроить ещё кроме самого гитлаба, чтобы собирать софт под разные дистрибутивы?
Вот тут есть про раннеры. Принцип простой: в пайплайне пинается раннер, который выкачивает репу и выполняет прописанные инструкции. Раннер может быть на любой ОС, в докере или даже внутри кубернетеса. Пайплайн можно настроить так же как душе угодно - по ветке, тегу или хоть чему хочешь. Все это работает в СЕ-версии.
Да собственно раннеры + сами средства сборки (gradle, maven если речь о java). Дальше, без какой-либо магии, например по коммиту гитлаб передаст раннеру то что написано в секции gitlab-ci.yaml и оно выполнится на нем (отдавая результаты гитлабу)
Строго говоря это именно раннеры пинают гитлаб, а не наоборот.
Мы все это делаем на селфхостет comminity edition gitlab'e. Вроде хватает.
А пробовали ли вы использовать Docker plugin для Gradle? С ним легче или сложнее этим всем заниматься?
SSH можно заменить отдельный раннером с shell вместо dind и запускать деплой на нём
всё-таки, правильно не собирать руками ничего, даже в первый раз. Иначе, допустим, сервер "упал" - что дальше? Надо срочно вызывать админа, который в отпуске/на свадьбе/похоронах/навещает детей ит.п.? Есть и более веские причины зачем CI/CD нужен и почему любые ручные шаги перечеркивают весь принцип.
Даже если у вас Runner развернут на сервере по соседству с приложением, у вас нет возможности (мы не нашли способа) обратиться наружу.
Есть возможность, мы же для того и пробрасываем docker.sock хост машины внутрь runner: "/var/run/docker.sock:/var/run/docker.sock" .
Тоже недавно на проекте настраивали CI через гитлаб и выбрали способ разрветки, когда runner находится на сервере по соседству.
Важно при регистрации раннера default image docker:dind, либо же указывать это в самом CI на deploy stage.
Вот так выглядит ci скрипт.
variables:
MAVEN_OPTS: >-
-Dmaven.repo.local=$CI_PROJECT_DIR/svc/.m2/repository
MAVEN_CLI_OPTS: >-
-DskipTests
stages:
- backend
- docker-compose
cache:
paths:
- svc/target/backend-0.0.1-SNAPSHOT.jar
- svc/.m2/
build-JAR:
stage: backend
image: eclipse-temurin:17
script:
- echo "Start building image for branch [$CI_COMMIT_REF_NAME]"
- cd svc
- ./mvnw clean package $MAVEN_CLI_OPTS
rules:
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
- if: '$CI_COMMIT_MESSAGE =~ /.*deploy.*/'
when: on_success
- when: manual
deploy:
stage: docker-compose
image: docker:dind
script:
- cd svc
- docker compose up --build -d
- docker rmi $(docker images -f "dangling=true" -q)
rules:
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
- when: on_success
needs:
- build-JAR
В deploy stage, раннер через докер клиент обращается к хостовому докер демону и на нём запускает наше приложение.
Настройка CI/CD глазами разработчика