🐹 CentOS 7: Установка и настройка GitLab.

Содержание:

1. Введение.

1.1. Что такое GitLab?
1.2. GitLab и GitHub.
1.3. Возможности.
1.4. Компонентный состав сервиса.
1.5. Системные требования.
1.6. Как пользоваться?

2. Предварительная подготовка сервера.

2.1. Как временно или навсегда отключить SELinux.
2.2. Обновление системы.
2.3. Настройка часового пояса и синхронизации времени.
2.4. Настройка брандмауэра.

3. Установка GitLab.
4. Nginx proxy_pass и SSL.

4.1. Одиночный сервер.
4.2. Настройка proxy_pass стороннего Nginx server’а.

5. Отключение регистрации новых пользователей.
5. Настройка ssh доступа по ключам.

6.1. Пользователь GitLab и ключ от него же.

6.1.1. Создание пользователя GilLab.
6.1.2. Настройка sudo.
6.1.3. Публичный ключ GitLab.

6.2. Другой пользователь и ключ от GitLab пользователя.
6.3. Ключ на основе почтового адреса.
6.4. Копирование ключа пользователя.

7. Как создать или удалить проект.
8. Как создать нового пользователя в сервисе.
9. Добавление пользователя к проекту.
10. Как загрузить или скачать проект.
11. Устранение возможных ошибок.

11.1. Ошибка 500 или 502 в GitLab.
11.2. Ошибка «Warning: Remote host identification has changed!»

12. Оригиналы источников информации.


На чем было опробовано:

  1. CentOS Linux release 7.9.2009.
  2. GitLab 13.5.3

1. Введение.

1.1. Что такое GitLab?

GitLab Community Edition — это сервис для работы с системой контроля версий Git и совместной разработки проектов с открытым исходным кодом. Данный сервис является одним из лучших альтернатив GitHub для размещения ваших проектов с открытым исходным кодом, которую вы только сможете найти.

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

Использовать GitLab можно непосредственно на сайте gitlab.com как SAAS сервис, зарегистрировав там аккаунт. Так же вы можете установить GitLab Community Edition на свой сервер и использовать по своему усмотрению.

Внимание! Статья подразумевает, что вы устанавливаете GitLab Community Edition на «чистый» сервер. Установка на сервер с уже настроенными сервисами категорически не рекомендуется! Будут затронуты зависимости, которые могут привести к неработоспособности работающих приложений.

1.2. GitLab и GitHub.

Как известно, главный конкурент GitLab — это сервис GitHub. Появился он на три года раньше, в 2008 году, поэтому более популярен. GitHub сегодня — это сайт номер один по размещению Open source-проектов. Они почти все на нём и размещаются. И у многих людей Git напрямую ассоциируется с сервисом GitHub.

Да, плюсов у GitHub много, но мы не будем сейчас сравнивать оба сервиса. Скажем только, что несмотря на повышенную популярность и огромнейшее комьюнити GitHub, наблюдается тенденция перехода крупных команд разработчиков на GitLab. Это происходит благодаря расширенным возможностям GitLab.

1.3. Возможности.

GitLab — это отличный инструмент для разработчиков, который предоставляет следующие возможности:

  • управление публичными и приватными git-репозиториями;
  • управление пользователями и группами, правами доступа к git-репозиториям;
  • отслеживание ошибок, деплой, анализ кода;
  • интеграция с разными CI-системами CI;
  • организация самостоятельного процесса CI посредством встроенных средств.

Есть и другие возможности: функционал api, wiki-страниц, доски задач и идей, отслеживание изменений, комментарии к проектам и прочие.

Подробнее можно узнать из официальной документации.

1.4. Компонентный состав сервиса.

GitLab Community Edition представляет из себя web-приложение, состоящее из нескольких компонентов:

  • Ruby.
  • Go.
  • Nodejs.
  • PostgreSQL или MySQL.
  • Redis.
  • Nginx.

1.5. Системные требования.

Системные требования:

  • CPU. Рекомендуется 2-4 ядра. На одном тоже будет работать, но разработчики предупреждают, что может тормозить при работе каких-нибудь воркеров или задач в фоне. Для старта и знакомства достаточно будет 1 ядра, но это не точно и не факт, что заработает.
  • Memory. Установить GitLab на сервер можно только если у него 2-4 и более Гб оперативной памяти. Если меньше, установщик сообщит об ошибке и прекратит работу. Работа с 2-4 Гб памяти возможна только в тестовом или ознакомительном режиме. Все будет сильно тормозить. Для полноценной работы надо от 4 Гб памяти, лучше 8 Гб.
  • Storage. Здесь никаких рекомендаций и ограничений нет. Все будет зависеть от сценария использования.
  • Database. GitLab поддерживает работу с двумя типами баз данных: PostgreSQL и MySQL. При этом настоятельно рекомендуется использовать PostgreSQL. Она же ставится в комплекте по умолчанию.

1.6. Как пользоваться?

У GitLab есть неплохая официальная документация.

Ссылка на официальный сайт с документацией: docs.gitlab.com.

2. Предварительная подготовка сервера.

2.1. Как временно или навсегда отключить SELinux.

Когда вы устанавливаете CentOS 7, функция SELinux включена по умолчанию, из-за этого некоторые приложения в вашей системе могут фактически не поддерживать этот механизм безопасности. Чтобы такие приложения функционировали нормально, вам необходимо отключить SELinux.

Ссылка: «CentOS 7: Как временно или навсегда отключить SELinux».

2.2. Обновление системы.

Обновим операционную систему:

# yum -y update && yum -y upgrade

2.3. Настройка часового пояса и синхронизации времени.

Очень важно иметь правильно настроенную систему учета времени на сервере, потому что сервер — существо электромеханическое и все процессы в нём ориентируются на точно время. Например, резервное копирование, мониторинг и синхронизация с другими системами в сети.

Чтобы время на сервере CentOS 7 соответствовало вашему часовому поясу, его можно изменить вручную.

Ссылка: «CentOS 7: Настройка часового пояса. Утилита tzdata».

Ссылка: «CentOS 7: Настройка синхронизация времени по Network Time Protocol. Утилита chrony».

Для корректной работы сервера требуется правильно настроить его синхронизацию времени по Network Time Protocol.

Внимание! В CentOS 7 данная утилита уже идет в комплекте даже при минимальной комплектации установщика. Устанавливать отдельно в CentOS 7 утилиту chrony не надо. В CentOS 8 данная утилита не идет в комплекте и потребуется её установка и настройка.

Ссылка: «CentOS 7: Настройка синхронизация времени по Network Time Protocol. Утилита ntp».

2.4. Настройка брандмауэра.

Для работы web-сервера требуется пробросить 80 порт или 443 порт через брандмауэр. В зависимости от того как вы будете пользоваться системой.

Ссылка: «CentOS 7: Первичная настройка брандмауэра web-сервера. Проброс 80 порта и 443 порта. Настройка firewalld или iptables».

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

Устанавливаем зависимости, необходимые для работы GitLab:

# yum -y install curl policycoreutils-python postfix mc

Подключим репозиторий GitLab.

Для этого используется скрипт, который определяет версию системы и в зависимости от нее подключает нужный репозиторий и автоматически начинает установку GitLab Community Edition на локальный сервер:

# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash

Запускаем непосредственно установку, указав адрес будущего сайта или IP-адрес сервера:

# EXTERNAL_URL="http://192.168.0.17" yum -y install gitlab-ee

Ответ:

Терпеливо ждем… Будет выкачано из репозитория почти 1 Gb информации.

После закачки, распаковки и установки в консоли появится лисичка:

После завершения установки, идем по указанному ранее IP-адресу:

# http://192.168.0.17

Внимание! Если у вас ничего не открылось, то вы забыли настроить межсетевой экран по 80 порту и 443 порту!

Первым делом нужно установить пароль для учетной записи root.

После того, как это сделаете, можете зарегистрироваться или зайти в систему под root.

Логин: root
Пароль: тот, который только что придумали.

Внимание! Есть некоторая вероятность, что вам не получится зайти с первого раза в систему, потому что могут выскочить ошибка 500 или ошибка 502. Просто обновите страницу или зайдите заново через минут 10-15. Чаще всего ошибка сама проходит так же внезапно, как и появилась.

Если сможете зайти, то вас поприветствует первоначальная страница:

4. Nginx proxy_pass и SSL.

Установка по умолчанию закончена. Теперь надо решить как продолжить использовать GitLab дальше.

После установки Gitlab работает по протоколу HTTP. Если вы его только тестируете, то можете так и оставить. Если же планируете пользоваться в дальнейшем, то лучше настроить HTTPS.

Mожет быть 2 варианта работы Gitlab web-интерфейса:

  1. Одиночный сервер или виртуальная машина с белым IP-адресом. На этом IP-адресе кроме GitLab больше ничего нет.
  2. Нет отдельного IP-адреса для GitLab, он работает в локальной сети с серыми IP-адресом за шлюзом, который проксирует соединения в зависимости от домена на разные сервера.

4.1. Одиночный сервер.

Если у вас первый случай с одиночным сервером, то выполните пару простых действий для настройки HTTPS в GitLab.

В файле конфигурации /etc/gitlab/gitlab.rb измените следующие параметры:

# cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.original

# mcedit /etc/gitlab/gitlab.rb

letsencrypt['enable'] = true
external_url "https://example.com"
letsencrypt['contact_emails'] = ['hamster@example.com']

И перезапустите GitLab:

# gitlab-ctl reconfigure

После этого сразу же заработает HTTPS с автоматическим редиректом с HTTP. Больше ничего делать не надо.

4.2. Настройка proxy_pass стороннего Nginx server’а.

Во втором случае настраивать HTTPS на самом сервере с GitLab не обязательно. Сделаем это на сервере с Nginx, который работает в режиме proxy_pass.

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

Ссылка: «Nginx: Проксирование запросов с помощью proxy_pass».

Создадим новый файл конфигурации на Nginx server /etc/nginx/conf.d/:

# mcedit /etc/nginx/conf.d/gitlab.conf

И наполним его вот таким содержимым:

server {
   listen 80;
   server_name example.com;
   return 301 https://$server_name$request_uri;
}

server {
   listen 443 ssl http2;
   server_name example.com;

   access_log /var/log/nginx/gitlab-access.log;
   error_log  /var/log/nginx/gitlab-error.log;

   ssl_certificate         /etc/letsencrypt/live/example.com/fullchain.pem;
   ssl_certificate_key     /etc/letsencrypt/live/example.com/privkey.pem;
   ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

   ssl_session_timeout 5m;
   ssl_protocols TLSv1.1 TLSv1.2;
   ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
   ssl_prefer_server_ciphers on;
   ssl_session_cache shared:SSL:10m;

location /.well-known {
   root /tmp;
   }

location / {
#  auth_basic "GitLab Server";
#  auth_basic_user_file /etc/nginx/htpasswd/gitlab_server;
   proxy_pass http://192.168.0.17;
   proxy_read_timeout 300;
   proxy_connect_timeout 300;
   proxy_redirect off;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header Host $http_host;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Frame-Options SAMEORIGIN;
   }
}

где — auth_basic и auth_basic_user_file — это переменные для базовой аутентификации.

Ссылка: «Nginx: Базовая аутентификация. Как поставить пароль на раздел, директорию или каталог сайта? Утилита htpasswd.»

Наша следующая задача — получить бесплатные сертификаты шифрования.

Ссылка: «CentOS 7: Настройка бесплатного ssl-сертификата Let’s Encrypt».

Создайте каталог для перевыпуска сертификатов:

# mkdir -p /tmp/.well-known && chown nginx. /tmp/.well-known

Не забудьте добавить задание в cron на перевыпуск сертификата.

Проверим корректность составления файла конфигурации:

# nginx -t

Если ошибок не обнаружено, то пересчитаем файл конфигурации, чтобы другие сессии не слетели на работающем Nginx server:

# nginx -s reload

В качестве бонуса, можете еще настроить ротацию log-файлов web-сервера Nginx Server. Если этого не сделать, то через какое-то, обычно продолжительное, время возникает проблема в связи с огромным размером лог-файлов на жестких дисках.

Ссылка: «CentOS 7: Ротация логов web-сервера Nginx».

Теперь проверьте, по example.com у вас будет открываться web-интерфейс GitLab:

# https://example.com

Ответ:

Затем настроим имя вашего пользователя и заполним первичную информацию про вас в профиле анкеты пользователя.

По умолчанию используется имя пользователя Administrator. Это имя профиля, а не учетной записи. Ваш псевдоним для других пользователей системы.

Откройте меню Settings и найдите там пункт Full Name и укажите там желаемое имя, например, ваше имя и фамилию:

Далее прокрутите страницу до самого низа и нажмите сохранение настроек клавишей Update profile settings:

5. Отключение регистрации новых пользователей.

Если у вас закрытый проект, то нужно будет сделать отключение возможности регистрации посторонних пользователей на вашем ресурсе.

Для отключения этой возможности, нажмите на кнопку в автоматическом поле оповещения об этой опции.

Далее вы попадёте в раздел условий регистрации новых пользователей. На начальном этапе настройки GitLab мы отключим самостоятельную возможность регистрации новых пользователей в системе.

Нас будет интересовать деактивация вот этих двух параметров:

  • Sign-up enabled — Регистрация включена. При включении любой пользователь, посещающий http://192.168.0.17/users/sign_in сможете создать учетную запись.
  • Require admin approval for new sign-ups — Требуется одобрение администратора для новых регистраций. При включении любой пользователь, посещающий http://192.168.0.17/users/sign_in и создание учетной записи должно быть явно одобрено администратором, прежде чем они смогут войти в систему. Этот параметр действует только в том случае, если включена регистрация.

Опустошаем квадратики от галочек:

Прокручиваем страничку вниз до самой надписи Save changes и жмём на ее, чтобы сохранить настройки с этой страницы:

Принимаем информационное оповещение клавишей Approve users, о том что новые пользователи не смогут регистрироваться после изменения текущих настроек:

Надпись-предупреждение с главной страницы пропадает и система GitLab становится замкнутой. Свободная регистрация отключена.

6. Настройка ssh доступа по ключам.

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

Рассмотрим 2 варианта работы в GilLab:

  1. У вас пользователь GilLab и ключ от него же.
  2. У вас другой пользователь и ключ от GilLab пользователя.

Подключаемся к серверу или рабочей машине, с которой мы будем работать с удаленными репозиториями GilLab. Нам нужно сгенерировать новые ключи для ssh. Если у вас уже есть пара приватного и публичного ключей, которые вы хотите использовать, то можете пропустить этот пункт. Я рассмотрю момент создания отдельного ключа именно для работы с GitLab.

6.1. Пользователь GitLab и ключ от него же.

В примере я буду использовать специально созданного локального пользователя по имени gitlab.

Как быстро сделать пользователя и дать ему права sudo описано в этой инструкции.

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

Создадим gitlab учетную запись:

# adduser gitlab

Сделаем ему пароль от учетной записи:

# passwd gitlab

6.1.2. Настройка sudo.

Если вам нужны права sudo на данного пользователя, то можно их тоже сделать, это не сложно. Если не надо ему таких прав, то не делайте.

Сделаем копию системного файла.

# cp /etc/sudoers /etc/sudoers.original

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

# mcedit /etc/sudoers

Ищем раздел «Same thing without a password» и добавляем в него в него строку:

gitlab ALL=(ALL) NOPASSWD: ALL

Проверим:

# su gitlab

Ответ: Зашел в учетную запись пользователя gitlab ввода без пароля.

# sudo su

Ответ: Зашел в учетную запись root ввода без пароля.

Выходим из цепочки учетных записей.

# exit

И еще раз:

# exit

Настройка sudo и root‘ирование без пароля настроено.

6.1.3. Публичный ключ GitLab.

Для этого сначала создайте соответствующий ключ для gitlab командой.

# ssh-keygen

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

Ответ:

Теперь копируем содержимое файла ~/.ssh/id_rsa.pub:

# cat ~/.ssh/id_rsa.pub

6.2. Другой пользователь и ключ от GitLab пользователя.

Если в вашей системе уже есть другие ssh-ключи, то вы можете изменить имя создаваемого ключа.

Генерируем пару ключей для gitlab пользователя:

# ssh-keygen -t rsa -f ~/.ssh/gitlab

Ответ:

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

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

Для этого создаем файл ~/.ssh/config:

# mcedit ~/.ssh/config

Примерно следующего содержания:

Host example.com
IdentityFile /root/.ssh/gitlab
port 22

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

Теперь копируем содержимое файла ~/.ssh/gitlab.pub:

# cat ~/.ssh/gitlab.pub

6.3. Ключ на основе почтового адреса.

На сервере требуется сделать:

# ssh-keygen -t rsa -b 4096 -C "твоя@почта-из-гита"

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

# cat /home/yodo/.ssh/id_rsa.pub

Потом на GitLab, зайди в Settings, раздел SSH ключи, как на скрине и добавь туда содержимое своего публичного ключа из прошлой команды.

6.4. Копирование ключа пользователя.

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

Идем в web-интерфейс GitLab, открываем раздел Preferences —> SSH Keys и вставляем в поле key — наш ключ.

С авторизацией по SSH закончили. Можно будет ее использовать в дальнейшем.

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

Внимание! Надо заметить, что с пользователем root на локальной машине такая операция не пройдёт, также ничего не будет работать, если вы попытаетесь использовать того же пользователя, от имени которого вы авторизованы в системе.

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

Напимер вид в старом интерфейсе:

После этого можно смело зайти на свой GitLab и скопировать оттуда ssh-ссылку на fork-репозитория, если он у вас есть готовый, как на скрине.

Если всё было сделано успешно, то заработает скачивание репозитория на сервер, с которого мы копирвали ssh-ключ:

# git clone ссылка/на/гит

Ответ:

7. Как создать или удалить проект.

Давайте создадим наш первый проект в GitLab. Для этого достаточно на главной странице нажать на Create a Project, либо в любом месте сайта в верхнем меню нажать на +.

Система спросит, какой тип проекта нас интересует:

Я для примера создадим Create blank project — проект wordpress, куда позже зальем исходники сайта, с которым будем работать.

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

  1. Private — доступ только у вас.
  2. Internal — доступ только у пользователей вашего сайта.
  3. Public — публичный доступ для всех без аутентификации.

Галочку Initialize repository with a README пока не нажимайте, так как дальше мы инициализируем репозиторий в другом месте и зальем в этот проект.

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

Для удаления проекта в GitLab, вам нужно зайти в сам проект. В левом меню выбрать раздел Settings (Гаечный ключ) —> General, в самом низу, в блоке Advanced нажать на Expand:

И там уже в самом глубоком низу выбрать Delete project:

Проходим небольшую защиту от случайного удаления:

Проект удалён, а мы двигаемся дальше в изучении работы в GitLab:

8. Как создать нового пользователя в сервисе.

Для создания нового пользователя перейдем в соответствующий по тематике раздел Settings (Гаечный ключ) —> Users —> New user:

Заполняйте анкету по смыслу и нажимайте клавишу Create user.

Указанный вами пользователь будет успешно зарегистрирован в системе.

9. Добавление пользователя к проекту.

Посмотрим, как добавить пользователя в проект в GitLab.

Для этого открываем проект. В левом меню выбираем раздел Settings —> Members. Здесь вы можете проверить доступ других пользователей к проекту. При необходимости, добавить нового. Сделаем это. В поле Select members to invite выберите пользователя, укажите права доступа к проекту и срок, на который вы выдаете эти права и жмите Add to Project.

Все, пользователю добавлен доступ на просмотр к вашему проекту с ограничением доступа по времени.

10. Как загрузить или скачать проект.

Переходим к самому интересному!

Протестируем работу приёма и передачи информации с локального компьютера на сервер GitLab.

Делайте всё тоже самое, что делали выше по инструкции, когда создавали тестовый проект wordpress.

Кликните по кнопке со значком Плюс, затем выберите New Project:

Система спросит, какой тип проекта нас интересует:

Я для примера создадим Create blank project. В открывшемся окне введите имя проекта, например testproject, и нажмите кнопку Create Project.

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

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

Глобальная настройка Git.

# git config --global user.name "Sasha Hamster"
# git config --global user.email "admin@example.com"

Создайте новый репозиторий.

# git clone git@192.168.0.17:root/egisso.git
# cd egisso
# touch README.md
# git add README.md
# git commit -m "add README"
# git push -u origin master

Загрузите текущий «существующий» каталог.

# cd existing_folder
# git init
# git remote add origin git@192.168.0.17:root/egisso.git
# git add .
# git commit -m "Initial commit"
# git push -u origin master

Загрузите текущий «существующий» Git репозиторий.

# cd existing_repo
# git remote rename origin old-origin
# git remote add origin git@192.168.0.17:root/egisso.git
# git push -u origin --all
# git push -u origin --tags

Затем откройте терминал.

На вашем локальном компьютере установлена уже система управления git, для того, чтобы она начала успешно работать с сервисом GitLab потребуется прописать учетную запись, в которую мы будем ломиться в GitLab’е и в которую мы прописывали ssh-ключ от учетной записи из под которой будем отправлять или получать информацию с GitLab.

# git config --global user.name "Sasha Hamster"
# git config --global user.email "admin@example.com"

Перейдите в каталог, в который вы хотели бы клонировать проект из GilLab:

# cd ~

Просим систему git зайти на сервер сервиса GitLab и забрать с него репозиторий проекта testproject, после чего сохранить его локально на компьютере:

# git clone git@192.168.0.17:root/testproject.git

Если это первый заход, то локальный компьютер спросит хотим ли мы добавить сервер GitLab в знакомые хосты и начать с ним обмениваться информацией используя публичный ключ локальной учетной записи, с которой мы ломимся на GitLab? Выбираем yes, связь устанавливается и мы получаем копию каталога с репозиторием testproject.

# ls

Ответ:

Он у нас пустой, так как на сервере сервиса GitLab, ничего, кроме каркаса проекта, мы не создавали.

Перейдем в каталог репозитория тестового проекта:

# cd testproject

Для тестирования обмена информацией, создадим на локальном компьютере файл README.md в структуре каталогов репозитория проекта testproject:

# touch README.md

# mcedit README.md

И заполним его произвольной информацией с текстовым описанием того, о чем проект:

The text that describes the project.

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

# cd testproject

# git add README.md
# git commit -m "add README"
# git push -u origin master

или

# git add --all
# git commit -m "add ALL"
# git push -u origin master

Ответ:

Теперь в интерфейсе программы вы увидите только что созданный commit и новый файл:

Теперь создадим тестовый файл в тестовом каталоге прямо в web-интерфейсе системы GitLab, чтобы отправить его на локальный компьютер.

Возвращаемся в консоль локального компьютера, проходим в каталог локальной копии репозитория testproject:

# cd ~/testproject/

Находясь внутри каталога, запрашиваем прислать изменения с сервера сервиса GitLab:

# git pull

Ответ:

В ответ нам прислали на локальный компьютер файлы, которые появились или изменились на сервере сервиса GitLab.

Этой пары команд, для перекидывания информации с локального компьютера на сервер сервиса GitLab и обратно, вполне хватит на первоначальном этапе работы с сервисом GitLab. Остальные команды семейства git, и их описание, можно найти в интернете.

Чтобы полноценно пользоваться данной системой изучайте команды семейства git.

Возможности GitLab очень большие.

11. Устранение возможных ошибок.

11.1. Ошибка 500 или 502 в GitLab.

Внимание! Данная ошибка, обычно сама проходит, если немного подождать минут 10-15 и попробовать зайти снова.

Часто пользователи GitLab сталкиваются с ошибкой 500 или ошибкой 502 (Whoops, GitLab is taking too much time to respond.). Вам ее показывает Nginx. В общем случае это означает, что web-сервер не смог получить ответ от бэкенда. В случае с GitLab бэкендом выступает unix сокет/var/opt/gitlab/gitlab-workhorse/socket. Почему не отвечает бэкаенд и вылезает ошибка 502 наверняка сказать нельзя.

Вот самые простые и очевидные причины:

  1. У вас мало оперативной памяти на сервере. Если ее только 2-4 Гб, то ошибку 502 вы можете видеть время от времени, даже если работаете с GitLab один. Для работы Nginx, Redis, Postgresql и прочих элементов GitLab надо много памяти. Так что если у вас ее 2 гигабайта, просто увеличьте до 4-х и проверьте результат. Как вариант, можете увеличить или включить Swap, если у вас его совсем не было.
  2. У вас упала служба GitLab-workhorse, которая открывает сокет, который слушает Nginx. Почему она упала — отдельный вопрос. Или почему она работает, а сокета нет. Попробуйте просто перезагрузить сервер. Если повторяться ошибка не будет, можете считать, что решили проблему. Одной из причин падений сервиса может быть занятый порт какой-то службы, которая относится к GitLab. Это может случиться, если на сервере, помимо GitLab работают другие службы. Возможно ошибки в конфиге или проблемы после обновления.
  3. По какой-то причине могли измениться права доступа к сокету /var/opt/gitlab/gitlab-workhorse/socket, и Nginx не может получить к нему доступ. Исправьте это. Посмотрите от какого пользователя работает Nginx и убедитесь в том, что у него хватает прав для доступа к сокету.

11.2. Ошибка «Warning: Remote host identification has changed!»

Бывает желаешь ты такой начать пользоваться GitLab, а он тебе «фигвам’ы» рисует:

# git clone git@192.168.0.17:root/egisso.git

Ответ:

Давайте разберемся с известнейшей проблемой, часто возникающей при подключении по протоколу ssh.

По умолчанию, для большей безопасности, в настройках ssh значение параметра StrictHostKeyChecking установлено в ‘yes’.

Именно поэтому при первом подключении к удаленному хосту можно увидеть следующее:

# ssh 192.168.0.12

Ответ:

Введя в консоли ‘yes’, мы подтверждаем, что действительно хотим подключиться к этому хосту и отпечаток его ssh-ключа добавляется в файл ~/.ssh/known_hosts.

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

# ssh 192.168.0.17

Ответ:

Для устранения данной проблемы необходимо удалить строку с указанным ssh-ключом из файла /root/.ssh/known_hosts.

Сделать это можно несколькими способами.

Первый способ, указан в самом сообщении с ошибкой):

# ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.0.17

Ответ:

Второй способ удаления ключа:

# sed -i '75d' /root/.ssh/known_hosts

Ответ: ничего.

Примечание: Номер строки с ssh-ключем, который нужно удалить, указывается с помощью ‘75d’.

Третий способ удаления ключа с использованием perl:

# perl -pi -e 's/\Q$_// if ($. == 75);' /root/.ssh/known_hosts

После проделанных действий пробуем подключиться по ssh к удаленному хосту — проблема должна исчезнуть.

Пробуем снова подключиться к репозиторию GitLab:

# git clone git@192.168.0.17:root/egisso.git

Ответ:

Всё получилось исправно!

12. Оригиналы источников информации.

  1. serveradmin.ru «Установка и настройка Gitlab на Centos и Ubuntu» от 2019.09.20.
  2. blog.sedicomm.com «Как установить и настроить GitLab на CentOS 8/7?»
  3. netpoint-dc.com «Установка и базовая настройка GitLab в CentOS, Debian и Ubuntu Linux».
  4. losst.ru «Установка GitLab в Ubuntu 18.04».
  5. otus.ru «Что такое GitLab? Настройка и использование GitLab».
  6. ealebed.github.io «Как убрать WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED».

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