Gitlab runner настройка debian

Обновлено: 03.07.2024

GitLab - представляет собой веб-инструмент жизненного цикла с открытым исходным кодом, который в последние несколько лет по праву завоевал популярность, заняв прочную нишу среди таких аналогов как GitHub, Bitbucket, GitBucket, Mercurial etc. Одними из главных задач GitLab является: предоставление репозитория для кода, система отслеживания ошибок, CI/CD и другие функции в решении задач DevOps.

Для понимания общей картины, рассмотрим основные возможности GitLab:

GitLab является частным репозиторием. Все данные размещены на изолированном виртуальном или физическом сервере, доступ к которому извне ограничен вашими настройками безопасности.
Система отслеживания ошибок позволяет детально производить анализ и отладку различных ошибок, анализ кода, ставить метки, классификации.
Встроенная система непрерывной интеграции (CI\CD) позволяет создавать pipeline и держать под контролем жизненный цикл деплоя приложения, от загрузки кода в репозиторий, до его выгрузки в среду production.
Широкий выбор DevOps инструментов. К примеру, Вы можете интегрировать GitLab с вашей средой Kubernetes, Terraform, Jenkins и другими популярными платформами.
GitLab является полноценным хранилищем кода Git, он позволяет возвращать коммиты, выполнять слияние коммитов, выполнять правки в исходной ветке проекта и копировать её в другую ветвь.
GitLab бесплатный, но существуют так же корпоративные решения, с которыми можно ознакомиться на официальном сайте.

В этом руководстве мы рассмотрим установку GitLab, его первоначальную настройку и краткий пример работы.

2. Технические требования

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

1 ядро поддерживает до 100 пользователей, но приложение может работать немного медленнее из-за того, что все рабочие и фоновые задания выполняются на одном и том же ядре.

2 ядра - рекомендуемое минимальное количество ядер и поддержка до 100 пользователей.

4 ядра поддерживают до 500 пользователей

4 ГБ ОЗУ + 4 ГБ файл подкачки, поддерживает до 100 пользователей, однако в промышленных масштабах это будет довольно медленно.

8 ГБ ОЗУ является рекомендуемым минимальным объемом памяти для всех установок и поддерживает до 100 пользователей.

16 ГБ ОЗУ поддерживает до 500 пользователей.

Если Вы только начинаете изучать GitLab и планируете заказать у нас обрачный VPS, минимальный рекомендуемый тариф - Cloud2, технических характеристик данного виртуального сервера должно хватить для изучения платформы. Для работы с кодом, и поддержки проекта небольшой команды разработчиков, следует обратить внимание на Cloud3. Для полноценной работы GitLab мы рекомендуем тариф Cloud4 или аренду физического сервера.

3. Установка GitLab

Установку будем выполнять на сервер с предустановленной операционной системой Debian 10. Первым делом обновим индексы пакетов и установим с официального репозитория программное обеспечение, необходимое для работы GitLab:

Во время установки postfix мы увидим окно выбора конфигурации. Вы можете выбрать Internet Site, указав при этом ip адрес сервера или домен, с которого система будет отправлять уведомления. Вы так же можете отказаться от настройки и выполнить правку конфигурационных файлов postfix позднее.

На следующем этапе, перейдите в каталог /tmp, загрузите установочный скрипт и запустите его:

Возможно Вы обратили внимание, что в названии файла сценария не указана версия GitLab. Так и должно быть, при его запуске, скрипт определяет тип вашей операционной системы, ее версию и автоматически подготавливает необходимые компоненты, исходя из полученной информации. После того как сценарий будет сконфигурирован, запустите установку:

4. Настройка GitLab

Настроим брандмауэр. Если Вы используете UFW, команды будут следующие:

Настройку брандмауэра UFW мы ранее рассматривали в статье «Как обеспечить безопасность Linux сервера?»

Чтобы приступить к работе в GitLab, отредактируем главный конфигурационный файл:

Он содержит огромное число параметров, правка которых зависит от поставленных перед Вами задач. Мы рассмотрим основные параметры, которые необходимы для работы веб-окружения. Найдите строку external_url

Если планируете использовать сертификат от Let'sEncrypt, раскоментируйте следующие строки подставив:

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

Сохраните файл и выполните переконфигурацию. Все изменения главного конфигурационного файла вступают в силу после команды:

Время реконфигурации во многом зависит от технических характеристик сервера и может занять до 10 минут. После перезагрузки, введя ip адрес сервера в адресной строке браузера, Вы увидите окно приветствия с возможностью установить новый пароль для учетной записи root. Обратите внимание, это пользователь root веб-интерфейса, а не системного пользователя root. Это две разные аутентификации.

5. Пример использования GitLab

В этом разделе мы загрузим проект с локального ПК в репозиторий GitLab с помощью Git. Вы можете использовать обычную аутентификацию по логину и паролю, или настроить доступ по ssh ключам.

Более подробно, о защите ssh и использовании ключей мы рассматривали ранее в одной из наших предыдущих статей: «Как обеспечить безопасность Linux сервера?»

Если Вы планируете делать доступ по ssh ключам, его необходимо будет добавить в настройках пользователя GitLab. Подтвердите нажатием кнопки «Add key»:

Далее, на локальном ПК установим git:

Выполните настройку пользователя. Эти данные будут добавлены к Вашим коммитам:

Затем проверьте правильность указанной информации:

Допустим, у нас есть проект приложения Django, который необходимо с локального ПК загрузить в репозиторий. Для этого перейдите в директорию с проектом и выполните следующие команды:

В веб-оружении проекта мы увидим следующую картину. Проект успешно загружен в репозиторий:

6. Краткий обзор CI\CD

Допустим, у нас есть проект Django, для которого мы написали собственный helm chart для деплоя в Kubernetes. У нас есть заранее настроенный кластер Kubernetes, настроена интеграция Kubernetes и GitLab. Рассмотрим, что происходит с нашим проектом при пуше в репозиторий.

В файле .gitlab-ci.yml у нас описаны несколько stage (build, test, staging, production), которые представляют собой pipelines GitLab. После того как данные были загружены в репозиторий, мы можем перейти в раздел CI\CD и посмотреть результаты. В одном из конфигурационных файлов мы заранее сделали ошибку. И вот что получилось:

Мы получили ошибку на деплое приложения в окружение staging кластера Kubernetes, посмотрим из-за чего она произошла. Для этого перейдем в нужный нам stage и проанализируем ее:

Возвращаемся обратно на локальный ПК, правим код. Повторяем процедуру push в репозиторий и следим за результатом. Ошибка исправлена:

7. Резервное копирование и восстановление GitLab

Для резервного копирования у GitLab предусмотрен штатный функционал, запустить его можно командой:

По умолчанию, все резервные копии формируются в следующей директории: /var/opt/gitlab/backups в формате *.tar. Однако, во время резервного копирования могут появляться ошибки, если с GitLab в это время идет активная работа и данные изменяются. На этот случай существует такая возможность как «стратегия». Выполнив следующую команду, файлы сначала будут скопированы во временную директорию и уже после этого она будет упакована архиватором tar:

Все настройки резервного копирования выполняются в главном конфигурационном файле, о котором мы говорили ранее. Рассмотрим некоторые полезные надстройки.

Изменить место хранения резервных копий:

Время хранения резервной копии:

Обратите внимание. При резервном копировании Вам кроме каталогов непосредственно с GitLab, так же нужно отдельно копировать файлы расположенные в /etc/gitlab. В частности — главный конфигурационный файл /etc/gitlab/gitlab.rb

Восстановление данных происходит следующим образом. Необходимо установить GitLab версии которая аналогична той, что у нас в архиве *.tar. Восстанавливаете вручную файл /etc/gitlab/gitlab-secrets.json. Архив с резервной копией размещаете по стандартному пути: /var/opt/gitlab/backups. И выполняете восстановление:

Теперь копируем наш главный конфиг /etc/gitlab/gitlab.rb, резервную копию которого мы сделали ранее и перезапустим систему:

Более детально о нюансах резервного копирования рекомендуем почитать в официальной документации.

8. Ограничение регистрации в GitLab

В четвертой главе Вы могли заметить, что регистрация нового пользователя доступна любому пользователю, который перешел по адресу вашего сервера, эту возможность рекомендуется отключить. Для этого Вам нужно зайти в веб-окружение с правами администратора, и в верхней панели инструментов нажать на иконку с изображением «гаечный ключ». Попав в зону администрирования (Admin Area), в левом меню перейдите на вкладку Settings, расположенную внизу списка и нажмите на вкладку General. Нас интересует блок Sign-up restrictions. Теперь уберите «птичку» с функции «Sign-up enabled» и сохраните изменения нажатием «Save changes»

Это может быть не всегда удобно, если у Вас большое количество пользователей. В этом случае можно оставить возможность регистрации, но ограничить возможность регистрации по доменному имени:

Заключение

В рамках одной статьи невозможно детально рассмотреть все особенности работы с GitLab и внедрение CI\CD. Однако не было лишним выполнить краткий визуальный обзор возможностей и как это работает. Рассмотренный нами сервис является неплохой альтернативой GitHub и он завоевывает все большую популярность, его функционал постоянно развивается. GitLab уже взяли на вооружение и используют такие компании как IBM, корпорация Alibaba (AliExpress), Sony, NASA и другие. По мнению многих специалистов, за этой платформой большое будущее. И если Вы с ней незнакомы, рекомендуем не откладывать это приятное знакомство в долгий ящик. GitLab имеет широкое комьюнити по всему миру и достаточно хорошо документирован.

У нас Вы можете заказать выделенный VPS сервер с предустановленной системой GitLab или заказать физический сервер, на который не составит труда его установить и приступить к работе. Наша техническая поддержка работает круглосуточно и в случае возникших вопросов готова на на них ответить.

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. Для его установки необходимо сначала настроить репозиторий — наши действия зависят от используемой системы.

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

а) система на базе deb-пакетов (Debian / Ubuntu):

б) система на базе RPM-пакетов (Red Hat / CentOS):

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

Сначала загружаем скрипт:

* в данном примере, загружен скрипт для систем на базе пакетов RPM.

Открываем его на редактирование:

И меняем их на что-то подобное:

* в данном примере мы указали, что установка будет выполняться как для CentOS 8.

Установка

После настройки репозитория, выполняем установку. Команда также зависит от типа операционной системы.

а) для Debian / Ubuntu (системы на основе deb-пакетов):

apt-get install gitlab-runner

б) для Red Hat / CentOS (системы на основе RPM):

yum install gitlab-runner

После установки gitlab-runner разрешаем автозапуск сервиса и стартуем его:

systemctl enable gitlab-runner --now

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

Находим раздел Runners:

Справа от названия кликаем по Expand:

Находим параметры для регистрации нового раннера:

. и оставляем страницу открытой — она понадобиться на следующем шаге.

В командной строке нашего сервера GitLab вводим:

* установить и запустить Runner можно не только на локальном сервере GitLab, но мы рассмотрим только данный способ.

Система в интерактивном режиме запросит данные для регистрации — вводим их:

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

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

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

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

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

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

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

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

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

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

test:
stage: test
script: echo $CI_PROJECT_DIR/

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

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

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

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

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

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

Настройка Rsyncd

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

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

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

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

Сейчас я расскажу как можно настроить gitlab-runner на разные Unix/Linux ОС. Но для начала, запустим сервисы.

Установка GitLab-Runner-а в Mac OS X

Конечно же, выставить права нужно:

После того как выставили права, необходимо зарегестрировать гитлаб-ранер, например, это можно сделать следующим образом:

Для помощи есть команда:

Установим Runner как сервис и запустим его:

Для обновления сервиса, нужно выполнить все теже действия что я описывал ранее, но перед этим, стоит остановить службу.

Вот и все использование.

Установка GitLab-Runner-а в GNU/Linux

Скачиваем бинарник в зависимости от разрядности и архитектуры ОС.

Если у вас, Linux x86-64:

Если у вас, Linux x86:

Если у вас, Linux arm:

Конечно же, выставить права нужно:

При желании, если вы хотите использовать Docker, установите Docker с:

Создайте пользователя GitLab CI:

После того как выставили права, необходимо установить Runner как сервис и запустить его:

Потом, зарегестрировать гитлаб-ранер, например, это можно сделать следующим образом:

PS: Конечно если кто-то привык устанавливать программы через пакеты, то можно установить гитлаб-раннер через паркет. Приведу пару примеров:

Для Debian или Ubuntu:

А чтобы установить, можно выполнить:

Для RedHat или CentOS:

Вот и все использование.

Установка GitLab-Runner-а в FreeBSD

Не было необходимости!

Установка GitLab-Runner-а через docker контейнер в Unix/Linux

Можно запустить контейнер, например следующим образом:

Но после создания контейнера, стоит на него зайти:

И запустить регистрацию, я ее описывал ранее несколько раз.

Установка GitLab-Runner-а через Kubernetes

Не было обходимости пока еще.

This entry was posted in Arch Linux, CircleCI, Debian's, FreeBSD, Gentoo, Gitlab, Gitlab, Gitlab, Kali Linux, MacOS, RHEL's, Slackware, Непрерывная интеграция (CI), Непрерывная интеграция (CI), Непрерывная интеграция (CI), Непрерывная интеграция (CI). Bookmark the permalink.

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Если вы используете Git и GitLab для хранения кода, то можете упростить и автоматизировать разворачивание вашего кода на сервере сразу же, при появлении новых изменений в GitLab репозитории. Этот процесс называется CI/CD (Continuous Integration, Continuous Delivery или Непрерывная интеграция и доставка). С помощью этой технологии вы можете выполнять тесты, собирать проект, а затем помещать результат сборки или исходники в нужное место.

В этой небольшой статье будет рассмотрена настройка GitLab CI CD для небольшого проекта на PHP без сборки и тестов, а только с копированием исходников в директорию веб-сервера на сервере проекта.

Настройка GitLab CI/CD

1. Установка GitLab Runner

Для того чтобы у GitLab был доступ к серверу, на этот сервер необходимо установить службу gitlab-runner. Именно эта программа будет забирать новые исходники с GitLab, выполнять с ними нужные действия и разворачивать на сервере. Установить её в Ubuntu можно из официальных репозиториев. Сначала добавьте репозиторий в систему:

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

Обратите внимание, что поддерживаются Ubuntu 16.04, 18.04 и 20.04, если у вас другая версия, после установки репозитория вам надо будет изменить его на версию для ближайшего поддерживаемого дистрибутива. После этого можно установить пакет:

sudo apt install gitlab-runner

Так выполняется установка GitLab runner Ubuntu. В CentOS и других Red Hat дистрибутивах процедура установки похожая. Сначала добавьте репозиторий:

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

Затем установите пакет:

sudo yum install gitlab-runner

Возможно, в будущем процедура или ссылки на пакеты изменятся. Смотрите официальную документацию.

После установки запустите сервис с помощью systemd и добавьте его в автозагрузку:

sudo systemctl enable --now gitlab-runner

Откройте репозиторий на GitLab, для которого вы хотите настроить CI/CD, затем кликните по шестеренке (пункт Settings) в меню, а потом выберите CI/CD:

Возле пункта Runners нажмите кнопку Expand:

Общие раннеры от GitLab можно отключить для того чтобы они вам не мешали и не забирали задачи у вашего раннера. Для этого под надписью Enable shared runners for this project установите значение выключателя в положение выключено:

Необходимая вам информация находится в левой части окна, в разделе Specific runners. Тут вам надо узнать URL сервиса и токен авторизации, с которым вы будете регистрировать раннер:

Теперь возвращайтесь на сервер, на котором был установлен runner и выполните такую команду:

sudo gitlab-runner register

Программа спросит URL и токен, которые вы узнали на GitLab.

Затем надо ввести описание и теги для раннера. Теги будут использоваться в будущем для того чтобы отправлять этому раннеру задания. Далее останется только выбрать способ выполнения команд. Для того чтобы просто запускать командную оболочку можно выбрать shell.

Обратите внимание, что команду надо выполнять именно с sudo. Поскольку демон выполняется от имени пользователя root, то и авторизацию нужно выполнять от имени этого пользователя, иначе работать не будет, но и ошибок не выдаст.

Для того чтобы убедится, что всё настроено и работает нормально выполните такую команду:

sudo gitlab-runner verify

3. Настройка GitLab Runner

Кликните по значку карандаша (Edit) возле раннера и выставьте такие настройки:

Active - должно быть включено, иначе раннер не сможет выполнять задания;
Protected - должно быть включено, для того чтобы раннер брал задания из всех веток, а не только защищённых;
Run untagged jobs - должно быть включено, позволяет раннеру брать задачи без тегов;
Lock to current projects - если включено, этот раннер доступен только для этого проекта.

Все остальные опции можно не трогать.

После завершения настройки на забудьте нажать кнопку Save Changes. Дальше можно переходить к созданию файла .gitlab-ci.yml.

4. Создание gitlab-ci.yml

Именно в этом файле описываются все задачи, а также команды, которые gitlab-runner будет выполнять на сервере. Вы можете создать его вручную или же, если такого файла ещё нет, то на главной странице проекта нажмите кнопку Setup CI/CD:

После этого кликните по кнопке Create New CI/CD Pipeline:

Дальше перед вами откроется редактор файла .gitlab-ci.yml.

Как и следует из расширения - это файл в формате YAML, поэтому отступы перед значениями очень важны. Сразу же можете удалить отсюда все комментарии. Структура файла примерно такая:

Раздел stages описывает этапы разворачивания приложения и очередность их выполнения. Затем описываются задачи, которые будут выполняться в рамках каждого этапа. У задачи должен быть указан этап: stage и script со списком команд, которые будут выполняться на сервере. Во время разворачивания gitlab-runner автоматически создает на сервере (по умолчанию в домашней папке) директорию build, клонирует туда свежие исходники проекта и переходит в папку с исходниками. А дальше с помощью команд в секции script вы можете делать всё, что нужно с этими исходниками.

Для этого примера можно оставить только секцию deploy. Самый простой конфигурационный файл будет выглядеть вот так:

stages:
- deploy
deploy-job:
stage: deploy
script:
- echo "Deploying application. "
- echo "Application successfully deployed."

Сохраните этот файл. Для этого пролистайте вниз страницы и нажмите кнопку Commit Changes.

5. Проверка работы Pipeline

Если всё было сделано правильно, то ваш раннер получит эту задачу, склонирует исходники и выведет две строчки в терминал. Для того чтобы убедится что это всё произошло, в боковом меню выберите значок ракеты (CI/CD) а затем Pipelines:

Здесь отображаются все задачи CI/CD. В данном случае у вас должна быть одна задача.

Если всё прошло успешно перед ней будет зеленая кнопка Passed. Для того чтобы посмотреть лог выполнения задачи, кликните по этой кнопке, а затем выберите непосредственно задачу из списка:

В результате откроется лог выполнения раннера для этой задачи:

Поскольку внизу зелёным написано Job succeeded, значит задача выполнилась успешно. В самом верху лога вы можете видеть какой раннер использовался для выполнения, убедитесь, что это именно ваш раннер, а не один из стандартных.

6. Разворачивание исходников

Программа уже скачивает исходники на сервер, но дальше вы можете сделать с ними всё что хотите. Настраивать раннер загружать исходники прямо в папку веб-сервера не стоит, программа для этого не предназначена. Для копирования исходников лучше использовать rsync. Эта утилита позволяет копировать только изменившиеся файлы. Например, для копирования файлов из репозитория в /var/www/project необходимо добавить такую команду в секцию script:

rsync -av --no-perms --no-owner --no-group --exclude ".git*" $CI_PROJECT_DIR/ /var/www/project

Для редактирования файла .gitlab-ci.yml можете воспользоваться пунктом меню CI/CD -> Editor или найти и отредактировать этот файл в списке файлов. Папка, в которую вы собираетесь разврачивать проект должна существовать на сервере и у пользователя gitlab-runner должны быть права на запись в неё:

sudo mkdir -p /var/www/project

sudo chown gitlab-runner:gitlab-runner /var/www/project

Если всё было сделано верно на этот раз, то файлы появятся в папке:

Аналогичным образом вы можете добавлять другие команды, которые необходимо выполнить с исходниками на сервере. Можно даже загружать их на другие сервера с помощью того же rsync. Вообще говоря, локально можно было бы и обойтись без этой утилиты и воспользоваться cp. Но rsync позволяет именно синхронизировать изменения, что очень удобно.

Выводы

Теперь вы знаете как выполняется настройка GitLab CI CD, а также GitLab-runner. Как видите, это довольно полезные инструменты. Теперь на сервере будут оказываться все новые коммиты и у вас больше не будет необходимости выгружать их туда вручную.

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Читайте также: