Настройка CI/CD глазами разработчика

[sena]

А если это всё надо развернуть на своём сервере, желательно с бесплатным и свободным софтом? У Gitlab же только ядро свободно распространяется, за CI/CD надо покупать лицензию. Если я не хочу зависеть от серверов гитлаба?

У нас пока всё ещё на самописных шеловских скриптах. Есть ночные сборки, сборки по событиям пока нет. Вот я и думаю, допиливать свой велосипед или брать что-то готовое?

[d-stream]

Да собственно гитлаб, пинающий раннеры, а на раннерах - что угодно по своему вкусу.

Это всё есть в "бесплатном" варианте. Ну и плюс что-нибудь типа sonatype nexus как хранилище артефактов/дистрибутивов (тоже приемлемые условия для бесплатного варианта)

А совсем уж закладываться на прям всё готовое - не факт что окажется лучшим вариантом.

[sena]

А что же у них тогда в платном варианте?

[Acidter]

Эта информация есть на сайте разработчика

https://about.gitlab.com/pricing/feature-comparison/

[sena]

Я понял источник моей ошибки, в гитлабе СI/CD поддерживается, но чтобы он полноценно работал нужны другие приложения. Я думал что как раз они-то и платные. А оказывается всё это есть бесплатно тоже.

[Acidter]

Для CI/CD с Gitlab можно использовать и внешние инструменты, например, Jenkins

[sena]

Без внешних инструментов, я так понял, нельзя.

[Acidter]

Смотря что вы подразумеваете под внешними. Jenkins - инструмент от других разработчиков, а gitlab-runner создан разработчиками Gitlab для работы с ним для выполнения задач CI/CD.

[sena]

Если от разработчиков гитлаб и тоже под свободной лицензией, то это уже не совсем внешний. Но разве одного раннера достаточно? Он будет запускать какие-нибудь контейнеры чтобы в них билдить?

[ColdPhoenix]

Да, естественно докер должен быть на хосте.

Как я выше говорил, мы используем бесплатный gitlab.

[sena]

я верно понимаю, что досаточно гитлаб, докер, раннер и всё это бесплатно и заработает?

[Olegofriend]

Да, друг ) У меня же работает

[sena]

гитлаб, пинающий раннеры

А можно подробней. Что нужно поставить и настроить ещё кроме самого гитлаба, чтобы собирать софт под разные дистрибутивы?

[Zhbert]

Вот тут есть про раннеры. Принцип простой: в пайплайне пинается раннер, который выкачивает репу и выполняет прописанные инструкции. Раннер может быть на любой ОС, в докере или даже внутри кубернетеса. Пайплайн можно настроить так же как душе угодно - по ветке, тегу или хоть чему хочешь. Все это работает в СЕ-версии.

[d-stream]

Да собственно раннеры + сами средства сборки (gradle, maven если речь о java). Дальше, без какой-либо магии, например по коммиту гитлаб передаст раннеру то что написано в секции gitlab-ci.yaml и оно выполнится на нем (отдавая результаты гитлабу)

[Tatikoma]

Строго говоря это именно раннеры пинают гитлаб, а не наоборот.

[d-stream]

Смотря что понимать под словом "пинать". Если "управляющее воздействие" - то всё-таки гитлаб управляет раннерами [которые проявили инициативу и подключились к нему, доложив что готовы исполнять команды]

[ColdPhoenix]

Мы все это делаем на селфхостет comminity edition gitlab'e. Вроде хватает.

[Kz1nch]

А пробовали ли вы использовать Docker plugin для Gradle? С ним легче или сложнее этим всем заниматься?

[Olegofriend]

Нет в этом необходимости. Проще написать Dockerfile в 4 строчки:

FROM gradle:8.6-jdk17-alpine
WORKDIR /planner
COPY build/libs/*.jar ./planner.jar
CMD ["java", "-jar", "planner.jar"]

[andreysam]

SSH можно заменить отдельный раннером с shell вместо dind и запускать деплой на нём

[Dmitri-D]

всё-таки, правильно не собирать руками ничего, даже в первый раз. Иначе, допустим, сервер "упал" - что дальше? Надо срочно вызывать админа, который в отпуске/на свадьбе/похоронах/навещает детей ит.п.? Есть и более веские причины зачем CI/CD нужен и почему любые ручные шаги перечеркивают весь принцип.

[meiendorf]

Даже если у вас 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, раннер через докер клиент обращается к хостовому докер демону и на нём запускает наше приложение.