Handbook

Gitlab

Терминология

  • Runner или Gitlab Runner - это сервер, на котором выполняются команды CI.
  • Runner executor - тип runner'а. От них зависит то, как выполняются команды.
  • Pipeline - набор стадий, через которые проходит сборка или тестирование проекта.

Типы Runner'ов

  • shell-executor (с тегом shell) - выполняет команды в контексте сервера, где установлен runner. Сейчас на них доступны базовый набор unix-утилит, bash, ansible и docker.
  • docker-executor (с тегом docker) - позволяют выполнять команды в контейнере любого образа. Смотрите документацию.

Создание нового проекта в Gitlab:

  1. Выбор группы:
    • Для инфраструктурных проектов используйте группу "infra". В остальных случаях "apliteni".
    • Обратите внимание, что проект будет доступен для всех участников выбранной группы.
  2. Выбор подгруппы:
    • Если ожидается несколько репозиториев, то имеет смысл завести подгруппу по имени проекта. Пример, "gdbc".
  3. Выбор имени проекта:
    • Разделителями в имени используйте знак минус. Пример, "auth-api-server".

Версионирование проекта

В каждом проекте заводится файл с номером версии. Это может version.php, version.go или version.ts. Номер версии выставляем согласно соглашению SemVer 2.0.

+----- Major version is synchronize with tslint's major version.
| +--- Minor version has BREAKING CHANGE and feat.
| | +- Patch version has patch.
| | |
x.x.x

Номер версии используем сразу в нескольких местах:

  • Для автоматического тегирования в git и docker образа.
  • Для blue-green деплоя в k8s.
  • Записи в лог.

Gitlab CI / CD:

CI/CD позволяет запускать набор команд (pipeline) прямо Gitlab.

Чтобы использовать CI/CD нужно создать файл .gitlab-ci.yml в репозитории проекта (документация)

Рекомендации

  1. При большом количестве кода в script: имеет смысл вынести его в bash файл (рекомендуем хранить в директории проектаci/bin/).
  2. Если нужно передать артефакты из одной стадии в другую, используйте 'artifacts' и 'dependencies' (Документация).
  3. Для включения отладочной информации при запуске job, добавьте:
job_name:
  variables:
    CI_DEBUG_TRACE: "true"
  1. Желательно тестировать не только код, но и артефакты, и даже проверять успешность деплоя.

Запуск docker-контейнеров

Чтобы использовать runner с docker'ом, нужно указать тег docker:

build:
  tags:
    - docker                 # <- добавьте тег
  image: node:9.11.1         # <- указание image'а из docker hub
  script:
      - npm install          # <- эта передается в command при запуске контейнера

Можно запускать и на runner'ах с тегом shell, только это будет более громоздко:

build:
  tags:
    - shell
  script:
    - docker run -v "${PWD}:/data" -w "/data" node:9.11.1   npm install

Более того, при создании артефактов внутри такого контейнера, нужно обновлять владельца файлов.

Например, обновление владельца vendor/ после compose install:

docker run \
    -t \
    -v "${PWD}:/data" \
    -w "/data" \
    --entrypoint=/bin/bash \
    php:7.2-cli \
    -c "chown -R ${USER} node_modules"

Gitlab Registry

По умолчанию runner'ы не имеют доступа к Gitlab Regitry. Чтобы можно было выполнять pull/push образов, потребуется авторизоваться:

before_script:
  - docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY};

CI_JOB_TOKEN и CI_REGISTRY - переменные окружения инжектит сам gitlab (документация)

Сборка образа и push (doc):

docker build -t GITLAB_REGISTRY/group/subgroup/project .
docker push GITLAB_REGISTRY/group/subgroup/project

Получение публичных ключей

Публичный ключ любого пользователя запрашивается по адресам формата:

https://gitlab.apliteni.com/USERNAME.keys

← DevOps →