Как развернуть сервер GitLab с помощью Docker — CloudSavvy IT

GitLab — ведущая платформа для размещения репозиториев Git, конвейеров непрерывной интеграции и рабочих процессов DevOps. Он доступен как предложение SaaS на GitLab.com или как самоуправляемый дистрибутив для частного использования на вашем собственном оборудовании.

GitLab — это сложная система, состоящая из сети отдельных компонентов и зависимостей. Установка пакетов GitLab непосредственно в вашу операционную систему добавит на вашу машину новые весомые сервисы, включая PostgreSQL, Redis, Gitaly и основное веб-приложение GitLab на основе Rails.

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

В этом руководстве мы будем использовать Docker для развертывания готового экземпляра GitLab, который вы можете использовать для размещения исходного кода и совместной работы над проектами. Прежде чем продолжить, следует учесть, что Docker не устраняет основные требования GitLab к оборудованию: вам потребуется не менее 4 ГБ свободной оперативной памяти и около 10 ГБ неиспользуемого хранилища.

Официальный образ Docker

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

Образ является монолитным по своей природе, объединяя все компоненты GitLab, поэтому они работают в одном контейнере. Это упрощает настройку, но затрудняет масштабирование установки в будущем. Это идет вразрез с передовыми методами контейнеризации, поскольку в контейнере запускается несколько отдельных компонентов.

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

Развертывание GitLab с помощью Docker

Прежде чем продолжить, установите Docker и настройте запись DNS A для своего доменного имени GitLab. Вы должны указать DNS-запись на IP-адрес вашего хоста Docker. Мы будем использовать gitlab.example.com в качестве домена в оставшейся части этого руководства.

Вы можете запустить GitLab, выполнив следующую команду:

docker run -d -p 22:22 -p 80:80 -p 443:443 \ –name gitlab \ –hostname gitlab.example.com \ –restart if-stopped \ –shm-size 256m \ -v gitlab_config:/etc/gitlab \ -v gitlab_logs:/var/log/gitlab \ -v gitlab_data:/var/opt/gitlab \ gitlab/gitlab-ce:14.7.0-ce.0

Docker загрузит образ GitLab Community Edition (CE) и запустит новый контейнер, используя его. Лучше всего закрепить конкретную версию GitLab, выбрав соответствующий тег изображения, в данном случае 14.7.0-ce.0. Вот объяснение флагов, используемых в команде:

• -d — отсоединить терминал от контейнера, чтобы он работал в фоновом режиме.
• -p — привязать порты 22, 80 и 443 в контейнере к соответствующим портам на вашем хосте; это позволяет GitLab получать Git и веб-трафик через SSH и HTTP/S, когда он направлен на ваш хост.
• –name — присвойте контейнеру понятное имя, чтобы вы могли удобно ссылаться на него при выполнении команд Docker CLI в будущем.
• –hostname — Установить имя хоста контейнера; это должно соответствовать домену, который вы используете для доступа к GitLab.
• –restart — назначьте контейнеру политику перезапуска, чтобы он автоматически перезапускался при завершении работы из-за сбоя или перезагрузки хоста.
• –shm-size — это объясняется в следующем разделе.
• -v — настроить тома Docker для постоянного хранения файлов конфигурации GitLab, журналов и сгенерированных пользовательских данных вне контейнера. Это жизненно важно, чтобы вы не потеряли свои данные, когда контейнер остановится!

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

docker exec -it grep ‘Пароль:’ /etc/gitlab/initial_root_password

Замените именем, которое вы присвоили при создании контейнера. Это был gitlab в приведенном выше примере.

Исследование проблем развертывания

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

журналы докеров gitlab –follow

Лучший способ действий, если веб-интерфейс GitLab недоступен, — просто подождать немного дольше и позволить процедуре настройки завершиться. Если что-то пошло не так, вы видите 500 ошибок в своем браузере, а журналы контейнера не показывают новую активность, иногда может помочь перезапуск контейнера с помощью docker restart gitlab.

Одно распространенное сообщение об ошибке, которое вы можете увидеть в журналах, выглядит примерно так:

запись значения в /dev/shm/gitlab/… не удалась с несопоставленным файлом

Это происходит из-за того, что службы, связанные с GitLab, записывают значительные объемы данных во временную файловую систему /dev/shm. Docker по умолчанию выделяет контейнерам пространство /dev/shm размером 64 МБ. Этого редко бывает достаточно для поддержания сбора метрик GitLab через Prometheus, который отвечает за большую часть операций записи в файловую систему.

Емкость /dev/shm можно увеличить с помощью флага –shm-size при создании контейнера с помощью docker run. Это показано в приведенном выше примере развертывания, где выделено 256 МБ — минимум, рекомендованный GitLab. Для очень активных установок может потребоваться использование большего размера.

Еще одна проблема связана с лог-файлами GitLab: они быстро расширяются, что может привести к обнаружению ошибок переполнения буфера при запуске Docker. Этого можно избежать, периодически удаляя старые файлы в каталоге /var/log/gitlab из вашего контейнера GitLab:

docker exec -it gitlab rm /var/log/gitlab/*

Файлы журналов, которые Docker собирает из выходных потоков контейнера и сохраняет на вашем хосте, также быстро увеличиваются до больших размеров. Драйвер хранилища журналов Docker по умолчанию в формате json не подходит для использования с производственным экземпляром GitLab. Файлы JSON, которые он создает, тяжелые, многословные, никогда не сжимаются и не вращаются. Переключитесь на другой драйвер хранилища, такой как локальный или journald, чтобы обеспечить регулярную ротацию журналов.

Настройка GitLab

Вы можете предоставить фрагменты файла конфигурации GitLab при создании контейнера, установив переменную среды GITLAB_OMNIBUS_CONFIG. Это должна быть допустимая строка Ruby, которая будет добавлена ​​к файлу /etc/gitlab/gitlab.rb внутри контейнера:

docker run -e GITLAB_OMNIBUS_CONFIG=”gitlab_rails[‘allowed_hosts’] знак равно [‘gitlab.example.com]; нгинкс[‘redirect_http_to_https’] = правда;”

Вы также можете отредактировать файл /etc/gitlab/gitlab.rb внутри контейнера после его запуска. Когда вы закончите вносить изменения, вы должны перезапустить контейнер, чтобы применить их:

докер перезапустить gitlab

Образ GitLab Docker автоматически запускает скрипт перенастройки Omnibus при каждом запуске. Это берет текущую конфигурацию из вашего gitlab.rb и применяет ее к вашей установке. GitLab может быть недоступен в течение нескольких секунд после перезапуска контейнера, пока этот процесс завершается.

Применение обновлений GitLab

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

Извлеките новый образ, соответствующий выбранному вами выпуску GitLab:

докер вытащить gitlab/gitlab-ce:14.7.1-ce.0

Удалите существующий контейнер:

докер рм gitlab

Наконец, запустите новый контейнер, повторив исходные флаги, но изменив ссылку на изображение:

docker run -d -p 22:22 -p 80:80 -p 443:443 \ –name gitlab \ … gitlab/gitlab-ce:14.7.1-ce.0

Ваши данные останутся нетронутыми, так как тома из старого контейнера будут присоединены к новому.

Вы можете избежать повторения флагов запуска Docker, инкапсулировав свою конфигурацию в файл docker-compose.yml:

версия: “3” сервисы: gitlab: образ: gitlab/gitlab-ce:14.7.0-ce-0 имя хоста: gitlab.example.com порты: – 22:22 – 80:80 – 443:443 тома: gitlab_config:/ etc/gitlab gitlab_logs:/var/log/gitlab gitlab_data:/var/opt/gitlab перезапуск: если не остановлены тома: gitlab_config: gitlab_logs: gitlab_data:

Когда вы используете Docker Compose, вы можете запустить свой экземпляр GitLab, запустив docker-compose up -d. Чтобы выполнить обновление до новой версии, соответствующим образом измените поле изображения и повторите команду. Docker Compose автоматизирует процесс замены контейнера.

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

Резервное копирование вашей установки

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

GitLab имеет встроенную утилиту резервного копирования, которую можно использовать для создания полного архива вашей установки. Это доступно в образе Docker с помощью команды gitlab-backup:

docker exec -t gitlab gitlab-backup создать

Резервные копии по умолчанию сохраняются в каталоге /var/opt/gitlab/backups. Это означает, что они будут храниться вне контейнера, в одном из подключенных томов Docker. Для большей безопасности вы должны настроить GitLab для загрузки резервных копий в провайдер удаленного хранилища объектов, добавив эти строки в ваш файл конфигурации:

gitlab_rails[‘backup_upload_connection’] = { “provider” => “AWS”, “region” => “eu-west-1”, “aws_access_key_id” => “access_key”, “aws_secret_access_key” => “secret_key”, # “endpoint” => “https //…” }

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

0 * * * * docker exec -t gitlab gitlab-backup создать

Резюме

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

Развертывание Dockerized GitLab — хороший способ быстро опробовать платформу. Это также эффективная стратегия для запуска и обслуживания небольшого сервера GitLab для долгосрочного использования. Другие варианты, такие как GitLab Omnibus на выделенном сервере или облачная установка Kubernetes, как правило, лучше подходят для более высоких требований и устойчивого внедрения на предприятии.