• База знаний
  • /
  • Блог
  • /
  • Wiki
  • /
+380 (44) 364 05 71
  1. Введение
  2. Технические требования
  3. Установка GitLab
  4. Настройка GitLab
  5. Работа с репозиторием
  6. Краткий обзор CI\CD
  7. Резервное копирование и восстановление GitLab
  8. Ограничение регистрации в GitLab

1. Введение

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

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

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

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

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

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

CPU:

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

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

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

Memory:

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

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

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

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

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

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

root@host:~$ sudo apt update
root@host:~$ sudo apt upgrade
root@host:~$ sudo apt install ca-certificates curl openssh-server postfix

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

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

root@host:~$ cd /tmp
root@host:~$ curl -LO
https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
root@host:~$ sudo bash /tmp/script.deb.sh

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

root@host:~$ sudo apt install gitlab-ce

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

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

root@host:~$ sudo ufw allow http
root@host:~$ sudo ufw allow https
root@host:~$ sudo ufw allow OpenSSH

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

Для iptables:

root@host:~$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
root@host:~$ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
root@host:~$ iptables -A INPUT -p tcp --dport 22 -j ACCEPT

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

root@host:~$ sudo mcedit /etc/gitlab/gitlab.rb

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

Находим external_url

Если планируется использовать сервер в тестовых целях, можно оставить как есть и работать по протоколу HTTP. Для этого вместо https://gitlab.example.com укажите IP адрес сервера.

Для работы в production рекомендуется настроить работу по протоколу HTTPS. В этом случае, вместо https://gitlab.example.com укажите свой домен: https://yourdomain.example.com

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

letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['yourmane@yourdomain.example.com']

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

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

root@host:~$ sudo gitlab-ctl reconfigure

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

Создание нового пользователя.

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

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

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

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

Учтановка доступа по SSH

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

root@host: apt install git -y

 

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

root@host: git config --global user.name "First name Last Name"
root@host: git config --global user.email "yourmane@yourdomain.example.com"

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

root@host: git config --list

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

root@host: git init
root@host: git remote add origin https://your_ip/root/django-helloworld.git
root@host: git add
root@host: git remote set-url origin https://your_ip/root/django-helloworld.git
root@host: git commit -m "new docker registry"
root@host: git push -u origin master

 

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

Загрузка проекта в репозиторий

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 предусмотрен штатный функционал, запустить его можно командой:

root@host:~$ gitlab-rake gitlab:backup:create

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

root@host:~$ gitlab-rake gitlab:backup:create STRATEGY=copy

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

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

gitlab_rails['backup_upload_connection'] = {
:provider => 'Local',
:local_root => '/mnt/gitlab-backups'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'

 

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

## Limit backup lifetime to 7 days - 604800 seconds
gitlab_rails['backup_keep_time'] = 604800

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

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

root@host: gitlab-ctl stop unicorn
root@host: gitlab-ctl stop sidekiq
root@host: gitlab-ctl status
root@host: gitlab-rake gitlab:backup:restore BACKUP=6345346124_2020_01_18_12.6.1-ce

 

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

 

root@host: gitlab-ctl restart
root@host: gitlab-rake gitlab:check SANITIZE=true

 

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

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

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

Раздел Settings в веб-окружении

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

Ограничение возможности регистрации по доменному имени

Заключение

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

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

 

Дата: 23.01.2020
Автор: Евгений
Голосование

Авторам статьи важно Ваше мнение. Будем рады его обсудить с Вами:

comments powered by Disqus
Спасибо, что выбираете FREEhost.UA