Напълно автоматичен CI/CD пайплайн с GitLab CI: От код до контейнер

Въведение в съвременните доставчични практики

Непрекъснатата интеграция и доставка (CI/CD) са фундаментални практики в съвременното разработване на софтуер. Те позволяват автоматизация на процесите от писането на код до неговото внедряване в производствена среда. GitLab CI/CD предоставя мощен вграден инструмент за изграждане на автоматизирани пайплайни. Този инструмент трансформира всеки къмит в потенциална производствена актуализация.

Този статия ще ви преведе през изграждането на пълен автоматизиран пайплайн. Ще започнем от управлението на кода и ще стигнем до публикуване на Docker контейнер. Целта е да демонстрираме как да създадете надежден, повтаряем и ефективен процес.

Основна архитектура на GitLab CI/CD

GitLab CI/CD работи чрез конфигурационен файл, наречен .gitlab-ci.yml. Този файл се намира в корена на хранилището. Той дефинира структурата и изпълнението на пайплайна. GitLab Runner е компонентът, който изпълнява дефинираните задания. Рънърите могат да бъдат инсталирани на различни операционни системи и среди.

Пайплайнът се разделя на няколко ключови етапа. Тези етапи обикновено включват build, test и deploy. Всяко задание в рамките на етап се изпълнява в изолирана среда. Това гарантира последователност и сигурност. Промяната в кода задейства автоматично изпълнение на пайплайна.

Стъпка 1: Конфигурация на базовия пайплайн

Създаването на .gitlab-ci.yml файл е първата стъпка. Този файл използва YAML синтаксис. Той дефинира последователността от задачи, които GitLab трябва да изпълни.

Пример за основна структура:

stages:
  - build
  - test
  - package
  - deploy

variables:
  DOCKER_IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

Променливите на средата като CI_COMMIT_SHORT_SHA се предоставят автоматично от GitLab. Те осигуряват уникални идентификатори за всяка изпълнение.

Стъпка 2: Етап на компилация (Build)

В етапа на компилация, кодът се подготвя за по-нататъшна обработка. За компилирани езици това включва изграждане на изпълними файлове. За интерпретируеми езици може да включва инсталиране на зависимости.

Пример за задание за компилация на Java приложение:

build-jar:
  stage: build
  image: maven:3.8.4-openjdk-11
  script:
    - mvn clean compile
    - mvn package -DskipTests
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 hour

Ключовият елемент artifacts запазва изхода от заданието. Следващите етапи могат да използват този изход. В този случай, изграденият JAR файл се предава напред.

Стъпка 3: Етап на тестване (Test)

Автоматичното тестване е сърцето на CI процеса. То гарантира, че промените не нарушават съществуваща функционалност.

Пример за многостепенно тестване:

unit-test:
  stage: test
  image: maven:3.8.4-openjdk-11
  script:
    - mvn test

integration-test:
  stage: test
  image: maven:3.8.4-openjdk-11
  script:
    - mvn verify -DskipUnitTests
  needs: ["unit-test"]

Директивата needs позволява паралелно изпълнение. В примера, integration-test ще изчака завършването на unit-test. Това оптимизира времето за изпълнение на пайплайна.

Стъпка 4: Контейнеризация на приложението (Package)

Създаването на Docker контейнер е стандартна практика за пакетиране. Той опакова приложението с неговите зависимости в преносим образ.

Примерен Dockerfile (в хранилището):

FROM openjdk:11-jre-slim
COPY target/myapp-*.jar /app/app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

Задание в GitLab CI за изграждане на образа:

build-container:
  stage: package
  image: docker:20.10.12
  services:
    - docker:20.10.12-dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
  script:
    - docker build -t $DOCKER_IMAGE_TAG .
    - docker push $DOCKER_IMAGE_TAG
  only:
    - main
    - merge_requests

Използването на Docker-in-Docker (dind) услуга е важно. Тя позволява на заданието да изгражда Docker образи вътре в контейнерния си runner.

Стъпка 5: Внедряване (Deploy)

Последният етап е внедряването на контейнеризираното приложение. Това може да се случи в различни среди: разработка, стейджинг или производство.

Пример за деплой към Kubernetes:

deploy-to-kubernetes:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl config set-cluster my-cluster --server="$KUBE_SERVER"
    - kubectl config set-credentials gitlab-ci --token="$KUBE_TOKEN"
    - kubectl set image deployment/myapp app=$DOCKER_IMAGE_TAG -n production
  environment:
    name: production
    url: https://myapp.example.com
  only:
    - main

Защитените променливи като KUBE_TOKEN се съхраняват в настройките на GitLab. Те не се разкриват в логове или код. Директивата environment предоставя връзка към действителната среда.

Управление на зависимости и кеширане

Повторното изтегляне на зависимости при всяко изпълнение е неефективно. GitLab CI поддържа кеширане за значително ускоряване.

Пример за кеширане на Maven зависимости:

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository"

cache:
  key: "${CI_COMMIT_REF_SLUG}"
  paths:
    - .m2/repository/

Кешът се съхранява между различни пайплайни в същия клон. Промяна в клона създава нов кеш. Това предотвратява потенциални конфликти.

Условно изпълнение и правила (Rules)

Модерните пайплайни използват директивата rules за контрол на изпълнението. Тя заменя остарелите only и except в по-нови версии.

Пример за сложни правила:

deploy-staging:
  stage: deploy
  script: "./deploy.sh staging"
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"
      when: always
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
      allow_failure: true

Този пример автоматично деплойва към стейджинг среда от клона develop. За merge request пайплайните, деплоят е ръчна стъпка. Той може да се пропусне без да се провали целия пайплайн.

Интеграция с GitLab Container Registry

GitLab предоставя вграден контейнерен регистър. Той е идеален за съхраняване на Docker образи.

Автентикацията е прозрачна за заданията в пайплайна. Рънърът автоматично получава права за достъп до регистъра на проекта. Командата docker login не е необходима при използване на стандартните променливи. Образът се публикува с команда docker push $CI_REGISTRY_IMAGE.

Пример за извличане на кеширани слоеве от регистъра:

docker-build:
  script:
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - docker build
      --cache-from $CI_REGISTRY_IMAGE:latest
      --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      --tag $CI_REGISTRY_IMAGE:latest
      .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

Използването на || true предотвратява грешка, ако образът latest не съществува. Стратегията за кеширане от предишен образ драстично намалява времето за изграждане.

Сигурност и най-добри практики

Сигурността е от първостепенно значение в автоматизираните пайплайни.

Никога не кеширайте чувствителни данни. Проверете файловете в artifacts и cache пътища.
Използвайте защитени променливи за токени, пароли и ключове. GitLab ги криптира и не ги показва в логове.
Ревизирайте Dockerfile-овете си за известни уязвимости. Интегрирайте инструменти като docker scan или trivy в пайплайна.
Прилагайте принципа на най-малките привилегии за услуги и деплой акаунти.

Пример за интеграция на сканиране за уязвимости:

container-scan:
  stage: test
  image: docker:20.10.12
  services:
    - docker:20.10.12-dind
  script:
    - docker pull aquasec/trivy:latest
    - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image --exit-code 1 $DOCKER_IMAGE_TAG

Това задание ще се провали, ако бъде открита критична уязвимост. Това спира пайплайна преди деплой в производство.

Мониторинг и отстраняване на грешки

GitLab предоставя подробни визуализации за изпълнение на пайплайни. Лесно можете да видите продължителността на всяко задание. Логовете са в реално време по време на изпълнение.

При проблеми, започнете от проверка на YAML синтаксиса. GitLab има вграден валидатор в раздел „CI/CD → Editor“. След това, проверете логите на заданието за конкретни съобщения за грешка. Често проблеми идват от липсващи зависимости или неточни пътища.

Заключение и следващи стъпки

Изграждането на напълно автоматичен CI/CD пайплайн с GitLab CI превръща доставката на софтуер в предвидим и надежден процес. Той намалява ръчната намеса и ускорява времето за пазар. Пайплайнът, описан тук, преминава от код до работещ контейнер без човешка намеса.

За да продължите напред, разгледайте възможностите за канарен деплой и разклонени пайплайни. Експериментирайте с динамични среди, които се създават и унищожават автоматично. Интегрирайте известия за Slack или Microsoft Teams за незабавна обратна връзка. С GitLab CI, автоматизацията на вашия жизнен цикъл на разработка е ограничена само от въображението и нуждите на вашия екип. Започнете с прост пайплайн и постепенно го разширявайте, докато покрие целия процес на доставка на вашия софтуер.

Финални думи

Ако предпочитате този процес да бъде изпълнен изцяло от професионалисти, това е напълно разумно решение. Нашият екип вече се разшири с още един опитен специалист, което ни позволява да поемаме по-големи и по-сложни проекти. Свържете се с нас, когато искате сигурна, планирана и добре изпълнена работа.

Федя Серафиев

е DevOps технологичен ентусиаст с опит в Linux, Docker, Kubernetes и CI/CD. Той споделя практични ръководства и анализи, които помагат на специалистите да изграждат по-добри и ефективни системи. На devopsbg.net Федя предоставя актуални и полезни насоки за автоматизация, сигурност и оптимизация на инфраструктурата.