Astra linux gitlab runner

Install GitLab Runner

You can install GitLab Runner on your infrastructure.

GitLab Runner is open-source and written in Go. It can run as a single binary and has no language-specific requirements.

GitLab Runner can also run inside a Docker container or be deployed to a Kubernetes cluster.

• In a container.
• By downloading a binary manually.
• By using a repository for rpm/deb packages.

For security and performance reasons, you should install GitLab Runner on a machine that is separate to the machine that hosts your GitLab instance.

You can find information on the different installation methods below. You can also view installation instructions in GitLab by going to your project’s Settings > CI / CD, expanding the Runners section, and clicking Show runner installation instructions.

After you install GitLab Runner, you must register individual runners with your GitLab instance. This instance can be self-managed, or you can use GitLab.com.

GitLab Runner runs the CI/CD jobs that are defined in GitLab.

System Requirements

• The anticipated:
  • CPU load of CI jobs.
  • Memory usage of CI jobs.
  • Concurrent CI jobs.
  • Projects in active development.
  • Developers expected to work in parallel.

  FIPS compliant GitLab Runner

  As of GitLab Runner 14.7, we provide a FIPS 140-12 compliant GitLab Runner binary. This binary, built with the Red Hat Go compiler, bypasses the standard library cryptographic routines and instead calls into a FIPS 140-2 validated cryptographic library.

  As of GitLab Runner 15.10, we use UBI-8 minimal as the base for creating the GitLab Runner FIPS image.

  Docker images and RPM packages for the same architectures are also provided.

  FIPS compliant GitLab Runner in RHEL

  When you use the FIPS version of GitLab Runner in RHEL, you should enable FIPS mode.

  FIPS compliant GitLab Runner in other systems and architectures

  Refer to this issue to follow progress on adding other architectures and distributions.

  Repositories

  Binaries

  Containers

  Autoscale

  Источник

  Настройка CI/CD в GitLab для синхронизации проекта с веб-серверами

  

  Обновлено: 19.10.2022 Опубликовано: 02.01.2021

  Используемые термины: GitLab, CI/CD, веб-сервер, Linux. Runner в GitLab позволяют автоматизировать рутинные задачи при обновлении проектов в репозитории. В нашем примере мы рассмотрим ситуацию, когда у нас используется сервер GitLab для хранения проекта и 5 веб-серверов, куда должны попадать изменения после выполнения git push. Мы настроим наш CI/CD на синхронизацию файлов с помощью rsyncd. Предполагается, что у нас уже установлен GitLab на Linux, в противном случае, воспользуйтесь инструкцией для Ubuntu или CentOS. Нам потребуется выполнить:

  Установка и регистрация Runner

  Runner — это отдельное приложение, которое запускается для выполнения заданий CI/CD. Его можно установить на любой компьютер под управлением любой популярной операционной системы (Linux, Windows, BSD, Mac OS и так далее). Также доступны различные варианты установки — из репозитория, скачивание бинарника или запуск как приложения в Docker или кластере Kubernetes. Мы выполним установку из репозитория Linux на тот же сервер, где работает наш GitLab.

  Установка

  По умолчанию, Runner не устанавливается вместе с GitLab. Для его установки необходимо сначала настроить репозиторий — наши действия зависят от используемой системы.

  Настройка репозитория

  curl -L «https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh» | sudo bash

  curl -L «https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh» | sudo bash

  в) для систем, которые не поддерживаются GitLab, но которые основаны на базе поддерживаемых систем. Сначала загружаем скрипт:

  Установка

  После настройки репозитория, выполняем установку. Команда также зависит от типа операционной системы. а) для Debian / Ubuntu (системы на основе deb-пакетов):

  Регистрация

  Для корректной работы Runner его нужно связать с нашим проектом в GitLab. Для этого сначала заходим на портал последнего — переходим на страницу проекта — в меню слева выбираем Settings — CI / CD: Находим раздел Runners: Справа от названия кликаем по Expand: Находим параметры для регистрации нового раннера: . и оставляем страницу открытой — она понадобиться на следующем шаге. В командной строке нашего сервера GitLab вводим:

  * установить и запустить Runner можно не только на локальном сервере GitLab, но мы рассмотрим только данный способ. Система в интерактивном режиме запросит данные для регистрации — вводим их:

  Enter the GitLab instance URL (for example, https://gitlab.com/):
  https://gitlab.dmosk.ru/
  Enter the registration token:
  zX_Kvkxk7ywrgwYHsod5
  Enter a description for the runner:
  [git-server.dmoks.ru]: DMOSK Metrics API
  Enter tags for the runner (comma-separated):
  dmosk, metrics, api
  Registering runner. succeeded runner=zX_Kvkxk
  Enter an executor: parallels, virtualbox, docker+machine, docker-ssh+machine, kubernetes, custom, docker, docker-ssh, shell, ssh:
  shell

  • https://gitlab.dmosk.ru/ — адрес нашего сервера GitLab. Его можно увидеть на странице с параметрами, которую мы оставили открытой на предыдущем шаге. В моем случае, на данной странице ссылка была типа http, однако, при регистрации Runner мы ее должны поменять на https (если наш сервер использует его).
  • zX_Kvkxk7ywrgwYHsod5 — токен для регистрации раннера. Его смотрим на странице с параметрами, которые мы открывали выше.
  • DMOSK Metrics API — произвольное описание для нашего раннера.
  • dmosk, metrics, api — теги. Рекомендуется максимально точно описывать раннер тегами. С их помощью можно указывать, на каких раннерах должны выполняться те или иные задачи.
  • shell — выбираем исполнителя из предложенных вариантов. В нашем случае это просто командный интерпретатор.

  В конце мы должны увидеть:

  Runner registered successfully. Feel free to start it, but if it’s running already the config should be automatically reloaded!

  * если мы получим ошибку «status couldn execute post against certificate signed by unknown authority», переходим к решению ниже.

  Обновим страницу с параметрами для регистрации раннера — ниже мы должны увидеть, что у нас появился один новый элемент. Кликаем по изображению редактирования справа от токена:

  

  Выставляем следующие галочки для настройки Runner:

  

  • Paused Runners don’t accept new jobs — если наш обработчик заданий приостановлен, он не принимает новые задания.
  • This runner will only run on pipelines triggered on protected branches — Runner должен запускаться только на защищенных ветках.
  • Indicates whether this runner can pick jobs without tags — раннер может запускать задания без тегов. В данном примере для первого знакомства с CI/CD мы поставим галочку, но лучше этого не делать, а управлять заданиями с помощью тегов.
  • When a runner is locked, it cannot be assigned to other projects — если обработчик заблокирован, его нельзя назначать для других проектов.

  В нашем примере мы рассмотрели регистрацию персонального раннера для проекта. В GitLab также предусмотрена созможность регистрации общего runner, к которому можно привязывать проекты. Сама регистрация выполняется по такому же принципу и не должна вызвать проблем. В GitLab для этого переходим в Menu — Admin — Runners.

  И так, обработчик зарегистрирован и настроен. Переходим к созданию CI/CD.

  Создание CI/CD для проекта

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

  Переходим в GitLab на страницу проекта и кликаем по Set up CI/CD:

  

  * данной кнопки может и не быть.

  . или можно просто в корне проекта создать файл:

  Задаем содержимое нашего сценария:

  test:
  stage: test
  script: echo $CI_PROJECT_DIR/

  * Формат текста должен быть yml, а значит, отступы имеют значение.
  ** В данном примере мы создаем pipeline с одним единственным этапом, которое называется test. По данному заданию будет запускаться скрипт вывода значения переменной $CI_PROJECT_DIR — путь, по которому клонируется проект и где выполняется задание (если установлен $builds_dir, эта переменная устанавливается относительно данного значения). Также обратите внимание на директиву default с указанием на использование тегов (tags) — для всех заданий мы определили тег по умолчанию, который может контролировать, на каких раннерах должно быть запущено задание.
  *** Список возможных переменных можно посмотреть на официальном сайте в разделе документации GitLab CI/CD environment variables.
  **** Боллее подробная шпаргалка по работе с Gitlab CI/CD представлена в инструкции Шпаргалка по написанию Gitlab Pipelines.

  После сохранения файла ждем несколько секунд и перезапускаем страницу — мы должны увидеть успешный результат выполнения сценария CI/CD:

  

  Кликнем по значку зеленой галочки и в открывшейся странице кликаем по нашей единственной стадии:

  

  Мы должны увидеть ход процесса выполнения задания и результат его работы:

  

  На этой же странице справа можно вручную запустить задание еще раз:

  

  CI/CD создан. Теперь необходимо подготовить систему к синхронизации данных.

  Настройка Rsyncd

  Наша синхронизация будет выполняться с помощью Rsyncd. Это удобный инструмент, с помощью которого можно поддерживать актуальное состояние двух и более каталогов. Также у нас не возникнет проблем с правами — rsync после копирования будет задавать файлам нужного владельца и нам не нужно будет выдавать права root для runner с помощью файла sudoerst. Подробнее об установке и настройке Rsyncd.

  Настройки нужно выполнить как на веб-серверах, так и сервере с GitLab.

  Настройка на веб-серверах

  Данные действия нужно выполнить на каждом веб-сервере. Мы должны установить и настроить в качестве сервиса rsyncd. Сначала установим его. В зависимости от типа Linux, наши действия будут различаться.

  а) Ubuntu / Debian:

  Источник

  Читайте также:  Acboot аккорд astra linux