자체 컴파일 설치

Tier: Free, Premium, Ultimate Offering: Self-Managed

이 문서는 소스 파일을 사용하여 프로덕션 GitLab 서버를 설정하는 공식 설치 가이드입니다. Debian/Ubuntu 운영 체제에서 작성되었으며 테스트되었습니다. 하드웨어 및 운영 체제 요구 사항에 대해 알아보려면 requirements.md를 읽어보세요. RHEL/CentOS에서 설치하려는 경우 Linux 패키지를 사용해야 합니다. 기타 다양한 설치 옵션에 대해서는 주요 설치 페이지를 참조하세요.

이 가이드는 많은 케이스를 다루고 필요한 모든 명령을 포함하기 때문에 길지만, 실제로 제대로 작동하는 몇 안 되는 설치 스크립트 중 하나입니다. 다음 단계는 작동하는 것으로 알려져 있습니다. 이 가이드에서 벗어날 때는 주의가 필요합니다. GitLab이 환경에 대한 가정을 위반하지 않도록 주의하세요. 예를 들어, 많은 사람들이 디렉터리의 위치를 변경하거나 잘못된 사용자로 서비스를 실행했기 때문에 권한 문제에 직면합니다.

이 가이드에서 버그/오류를 찾으면 병합 요청을 제출하세요.

Linux 패키지 설치를 고려해 보세요

자체 컴파일 설치는 많은 작업을 필요로 하고 에러가 발생하기 쉬우므로, 빠르고 안정적인 Linux 패키지 설치 (deb/rpm)를 강력히 추천합니다.

Linux 패키지가 더욱 신뢰성이 더 높은 이유 중 하나는, GitLab 프로세스 중 하나가 크래시가 발생할 경우 runit을 사용하여 다시 시작하기 때문입니다. 사용량이 많은 GitLab 인스턴스에서는 Sidekiq 백그라운드 워커의 메모리 사용량이 시간이 흐름에 따라 증가합니다. Linux 패키지는 이를 해결하기 위해 Sidekiq가 너무 많은 메모리를 사용하면 graceful하게 종료되도록하도록 합니다. 이 종료 후 runit은 Sidekiq이 실행되지 않고 있다는 것을 감지하고 시작합니다. 자체 컴파일 설치는 프로세스 감시를 위해 runit을 사용하지 않기 때문에 Sidekiq이 종료되지 않고 메모리 사용량이 시간이 흐름에 따라 증가할 수 있습니다.

설치할 버전 선택

GitLab 설치 가이드를 보려면 GitLab 릴리즈(버전)에 따라 링크를 확인해야 합니다 (예: 16-0-stable). GitLab의 왼쪽 상단 모서리(메뉴 바 아래)의 버전 드롭다운 목록에서 해당 브랜치를 선택할 수 있습니다.

가장 높은 버전의 안정적인 브랜치가 분명하지 않은 경우, 해당 버전에 대한 설치 가이드 링크는 GitLab 블로그를 확인하세요.

소프트웨어 요구 사항

소프트웨어 최소 버전 비고
Ruby 3.2.x GitLab 17.5 이상에서는 Ruby 3.2가 필요합니다. 표준 MRI Ruby 구현을 사용해야 합니다. JRuby와 Rubinius을 사랑하지만, GitLab은 네이티브 확장을 가진 여러 Gems가 필요합니다.
RubyGems 3.5.x 특정 RubyGems 버전이 필요하지는 않지만, 알려진 몇 가지 성능 향상을 위해 업데이트해야 합니다.
Go 1.22.x GitLab 17.1 이상에서는 Go 1.22 이상이 필요합니다.
Git 2.46.x GitLab 17.4 이상에서는 Git 2.46.x 이상이 필요합니다. Gitaly가 제공하는 Git 버전을 사용해야 합니다.
Node.js 20.13.x GitLab 17.0 이상에서는 Node.js 20.13 이상이 필요합니다.
PostgreSQL 14.x GitLab 17.0 이상에서는 PostgreSQL 14 이상이 필요합니다.

GitLab 디렉터리 구조

다음 디렉터리는 설치 단계를 거치면서 생성됩니다. 

|-- home
|   |-- git
|       |-- .ssh
|       |-- gitlab
|       |-- gitlab-shell
|       |-- repositories
  • /home/git/.ssh - OpenSSH 설정을 포함합니다. 특히 GitLab Shell이 관리하는 authorized_keys 파일이 포함됩니다.
  • /home/git/gitlab - GitLab 코어 소프트웨어
  • /home/git/gitlab-shell - GitLab의 코어 추가 구성 요소. SSH 클론 및 기타 기능을 유지합니다.
  • /home/git/repositories - 모든 프로젝트에 대해 네임스페이스별로 구성된 베어 저장소를 유지합니다. 이곳은 모든 프로젝트에서 푸시/풀하는 Git 저장소가 유지되는 곳입니다. 프로젝트에 대한 중요 데이터가 포함되어 있습니다. 백업을 유지하세요.

저장소의 기본 위치는 GitLab의 config/gitlab.yml 및 GitLab Shell의 config.yml에서 구성할 수 있습니다.

이 단계에서 이러한 디렉터리를 수동으로 만들 필요는 없으며, 이렇게하면 나중에 설치 중에 오류가 발생할 수 있습니다.

더 자세한 내용은 GitLab 아키텍처 문서를 참조하세요.

개요

GitLab 설치는 다음 구성요소를 설정하는 것으로 구성됩니다:

  1. 패키지 및 종속성.
  2. Ruby.
  3. RubyGems.
  4. Go.
  5. Node.
  6. 시스템 사용자.
  7. 데이터베이스.
  8. Redis.
  9. GitLab.
  10. NGINX.

1. 패키지 및 종속성

sudo

Debian에는 기본적으로 sudo가 설치되어 있지 않습니다. 시스템이 최신 상태인지 확인하고 설치하세요. 

# root로 실행하세요!
apt-get update -y
apt-get upgrade -y
apt-get install sudo -y

빌드 종속성

루비 및 루비 젬의 네이티브 익스텐션을 컴파일하는 데 필요한 필수 패키지를 설치합니다: 

sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libre2-dev \
  libreadline-dev libncurses5-dev libffi-dev curl openssh-server libxml2-dev libxslt-dev \
  libcurl4-openssl-dev libicu-dev libkrb5-dev logrotate rsync python3-docutils pkg-config cmake \
  runit-systemd

참고: GitLab은 OpenSSL 버전 1.1이 필요합니다. Linux 배포판이 다른 버전의 OpenSSL을 포함하는 경우 버전 1.1을 수동으로 설치해야 할 수 있습니다.

Git

Gitaly에서 제공하는 Git 버전을 사용해야 합니다. 이 Git 버전은:

  • 항상 GitLab에서 필요로 하는 버전입니다.
  • 올바른 작동을 위해 필요한 사용자 정의 패치가 포함될 수 있습니다.

  1. 필요한 종속성을 설치합니다: 

    sudo apt-get install -y libcurl4-openssl-dev libexpat1-dev gettext libz-dev libssl-dev libpcre2-dev build-essential git-core

  2. Gitaly 저장소를 복제하고 Git을 컴파일합니다. 원하는 GitLab 버전에 맞는 stable 브랜치(예: GitLab 16.7을 설치하려면 16-7-stable 브랜치 이름 사용)로 대체합니다: 

    git clone https://gitlab.com/gitlab-org/gitaly.git -b <X-Y-stable> /tmp/gitaly
cd /tmp/gitaly
sudo make git GIT_PREFIX=/usr/local

  3. 선택적으로 시스템 Git 및 해당 종속성을 제거할 수 있습니다: 

    sudo apt remove -y git-core
sudo apt autoremove

나중에 config/gitlab.yml 편집 시에 Git 경로를 변경해야 합니다:

  • 다음으로: 

    git:
  bin_path: /usr/bin/git

  • 다음으로: 

    git:
  bin_path: /usr/local/bin/git

GraphicsMagick

사용자 정의 파비콘을 사용하려면 GraphicsMagick을 설치해야 합니다. 

sudo apt-get install -y graphicsmagick

메일 서버

메일 알림을 수신하려면 메일 서버를 설치해야 합니다. 기본적으로 Debian은 exim4을 포함하고 있지만, 문제점이 있으며 Ubuntu는 기본으로 제공되지 않습니다. 권장하는 메일 서버는 postfix이며 다음 명령으로 설치할 수 있습니다: 

sudo apt-get install -y postfix

그런 다음 ‘인터넷 사이트’를 선택하고 호스트명을 확인하려면 Enter을 누릅니다.

ExifTool

GitLab Workhorse는 업로드된 이미지에서 EXIF 데이터를 제거하기 위해 exiftool이 필요합니다. 

sudo apt-get install -y libimage-exiftool-perl

2. 루비

GitLab을 실행하려면 Ruby 인터프리터가 필요합니다. 최소 Ruby 요구 사항은 요구 사항 섹션을 참조하세요.

GitLab을 운영 중에 RVM(https://rvm.io/), rbenv 또는 chruby와 같은 Ruby 버전 관리자 사용은 종종 진단하기 어려운 문제를 일으킬 수 있습니다. 버전 관리자는 지원되지 않으며 시스템 Ruby를 사용하는 것을 강력히 권장합니다.

일반적으로 Linux 배포판은 오래된 버전의 Ruby를 제공하므로, 공식 소스 코드에서 Ruby를 설치하는 방법이 설계되었습니다.

Ruby 설치를 참조하세요.

3. RubyGems

때로는 RubyGems의 더 최신 버전이 번들된 버전보다 필요할 수 있습니다.

특정 버전으로 업데이트하려면: 

gem update --system 3.4.12

또는 최신 버전으로 업데이트하려면: 

gem update --system

4. Go

GitLab에는 Go로 작성된 여러 데몬이 있습니다. GitLab을 설치하려면 Go 컴파일러가 필요합니다. 아래 지침은 64비트 Linux을 사용한다고 가정합니다. 다른 플랫폼용 다운로드는 Go 다운로드 페이지에서 찾을 수 있습니다. 

# 이전 Go 설치 폴더 삭제
sudo rm -rf /usr/local/go

curl --remote-name --location --progress-bar "https://go.dev/dl/go1.22.5.linux-amd64.tar.gz"
echo '904b924d435eaea086515bc63235b192ea441bd8c9b198c507e85009e6e4c7f0  go1.22.5.linux-amd64.tar.gz' | shasum -a256 -c - && \
  sudo tar -C /usr/local -xzf go1.22.5.linux-amd64.tar.gz
sudo ln -sf /usr/local/go/bin/{go,gofmt} /usr/local/bin/
rm go1.22.5.linux-amd64.tar.gz

5. Node

GitLab은 JavaScript 자산을 컴파일하고 JavaScript 의존성을 관리하기 위해 Node를 필요로 하며 Yarn을 필요로 합니다. 이러한 데 모든 최소 요구 사항은 다음과 같습니다:

  • node 20.x 릴리스 (v20.13.0 또는 그 이상). 다른 LTS 버전의 Node.js은 자산을 빌드할 수 있지만, 우리는 Node.js 20.x만을 보장합니다.
  • yarn = v1.22.x (Yarn 2는 아직 지원되지 않음)

많은 배포판에서 공식 패키지 저장소에서 제공하는 버전이 오래되어 있으므로 다음 명령을 통해 설치해야 합니다: 

# node v20.x 설치
curl --location "https://deb.nodesource.com/setup_20.x" | sudo bash -
sudo apt-get install -y nodejs

npm install --global yarn

이러한 단계에 문제가 있는 경우 node 및 yarn 공식 웹 사이트를 방문하세요.

6. 시스템 사용자

GitLab을 위해 git 사용자를 생성합니다: 

sudo adduser --disabled-login --gecos 'GitLab' git

7. 데이터베이스

참고: PostgreSQL만 지원됩니다. GitLab 17.0 이후에는 PostgreSQL 14+가 필요합니다.

  1. 데이터베이스 패키지를 설치합니다.

    Ubuntu 22.04 이상의 경우: 

    sudo apt install -y postgresql postgresql-client libpq-dev postgresql-contrib

    Ubuntu 20.04 이전의 경우, 사용 가능한 PostgreSQL이 최소 버전 요구 사항을 충족시키지 않습니다. PostgreSQL의 리포지토리를 추가해야 합니다: 

    sudo sh -c 'echo "deb https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get -y install postgresql-14

  2. 설치된 PostgreSQL 버전이 설치하려는 GitLab 버전에서 지원되는지 확인합니다: 

    psql --version

  3. PostgreSQL 서비스를 시작하고 서비스가 실행 중인지 확인합니다: 

    sudo service postgresql start
sudo service postgresql status

  4. GitLab을 위한 데이터베이스 사용자를 생성합니다: 

    sudo -u postgres psql -d template1 -c "CREATE USER git CREATEDB;"

  5. pg_trgm 확장을 생성합니다: 

    sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"

  6. btree_gist 확장을 생성합니다: 

    sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS btree_gist;"

  7. plpgsql 확장을 생성합니다: 

    sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS plpgsql;"

  8. GitLab 프로덕션 데이터베이스를 생성하고 데이터베이스에 대한 모든 권한을 부여합니다: 

    sudo -u postgres psql -d template1 -c "CREATE DATABASE gitlabhq_production OWNER git;"

  9. 새로운 사용자로 새 데이터베이스에 연결을 시도합니다: 

    sudo -u git -H psql -d gitlabhq_production

  10. pg_trgm 확장이 활성화되었는지 확인합니다: 

    SELECT true AS enabled
FROM pg_available_extensions
WHERE name = 'pg_trgm'
AND installed_version IS NOT NULL;

    확장이 활성화된 경우 다음 결과가 생성됩니다: 

    enabled
---------
 t
(1 row)

  11. btree_gist 확장이 활성화되었는지 확인합니다: 

    SELECT true AS enabled
FROM pg_available_extensions
WHERE name = 'btree_gist'
AND installed_version IS NOT NULL;

    확장이 활성화된 경우 다음 결과가 생성됩니다: 

    enabled
---------
 t
(1 row)

  12. plpgsql 확장이 활성화되었는지 확인합니다: 

    SELECT true AS enabled
FROM pg_available_extensions
WHERE name = 'plpgsql'
AND installed_version IS NOT NULL;

    확장이 활성화된 경우 다음 결과가 생성됩니다: 

    enabled
---------
 t
(1 row)

  13. 데이터베이스 세션을 종료합니다: 

    gitlabhq_production> \q

8. Redis

최소 Redis 요구 사항은 요구 사항 페이지를 참조하세요.

다음으로 Redis를 설치하세요: 

sudo apt-get install redis-server

완료되면 Redis를 구성할 수 있습니다: 

# Redis를 소켓 사용하도록 구성
sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.orig

# 'port'를 0으로 설정하여 Redis의 TCP 수신을 중지합니다
sudo sed 's/^port .*/port 0/' /etc/redis/redis.conf.orig | sudo tee /etc/redis/redis.conf

# 기본 Debian / Ubuntu 경로에 대해 Redis 소켓을 활성화합니다
echo 'unixsocket /var/run/redis/redis.sock' | sudo tee -a /etc/redis/redis.conf

# 소켓에 대한 권한을 redis 그룹의 모든 구성원에게 부여합니다
echo 'unixsocketperm 770' | sudo tee -a /etc/redis/redis.conf

# git 사용자를 redis 그룹에 추가합니다
sudo usermod -aG redis git

systemd를 사용하여 Redis 감독

시스템이 systemd init을 사용하고 다음 명령의 출력이 notify인 경우 수정하지 마세요: 

systemctl show --value --property=Type redis-server.service

출력이 notify가 아닌 경우, 다음을 실행하세요: 

# Redis가 백그라운드 프로세스가 아닌 대신 systemd의 감독을 받도록 Redis를 구성하고 pidfile을 비활성화합니다
sudo sed -i \
         -e 's/^daemonize yes$/daemonize no/' \
         -e 's/^supervised no$/supervised systemd/' \
         -e 's/^pidfile/# pidfile/' /etc/redis/redis.conf
sudo chown redis:redis /etc/redis/redis.conf

# systemd 유닛 파일에 동일한 변경 사항을 적용합니다
sudo mkdir -p /etc/systemd/system/redis-server.service.d
sudo tee /etc/systemd/system/redis-server.service.d/10fix_type.conf <<EOF
[Service]
Type=notify
PIDFile=
EOF

# redis 서비스를 다시 로드합니다
sudo systemctl daemon-reload

# redis.conf에 대한 변경 사항을 활성화합니다
sudo systemctl restart redis-server.service

감독되지 않는 Redis 유지

시스템이 SysV init을 사용하는 경우 다음 명령을 실행하세요: 

# 소켓을 포함하는 디렉터리를 생성합니다
sudo mkdir -p /var/run/redis
sudo chown redis:redis /var/run/redis
sudo chmod 755 /var/run/redis

# 해당하는 경우 소켓을 포함하는 디렉터리를 영속화합니다
if [ -d /etc/tmpfiles.d ]; then
  echo 'd  /var/run/redis  0755  redis  redis  10d  -' | sudo tee -a /etc/tmpfiles.d/redis.conf
fi

# redis.conf에 대한 변경 사항을 활성화합니다
sudo service redis-server restart

9. GitLab 

# GitLab을 사용자 "git"의 홈 디렉터리에 설치합니다
cd /home/git

소스 복제

커뮤니티 에디션 복제: 

# GitLab 저장소 복제
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-foss.git -b <X-Y-stable> gitlab

엔터프라이즈 에디션 복제: 

# GitLab 저장소 복제
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab.git -b <X-Y-stable-ee> gitlab

설치하려는 버전과 일치하는 stable 브랜치로 <X-Y-stable>을 교체하세요. 예를 들어, 11.8을 설치하려면 브랜치 이름을 11-8-stable로 사용해야 합니다.

경고: master 버전을 사용하려면 <X-Y-stable>을 master로 변경할 수 있지만, 제발 프로덕션 서버에는 master를 설치하지 마세요!

구성 

# GitLab 설치 폴더로 이동
cd /home/git/gitlab

# 예시 GitLab 구성 복사
sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml

# GitLab 구성 파일 업데이트. 파일 상단의 지시에 따르세요.
sudo -u git -H editor config/gitlab.yml

# 예시 비밀 파일 복사
sudo -u git -H cp config/secrets.yml.example config/secrets.yml
sudo -u git -H chmod 0600 config/secrets.yml

# GitLab이 log/ 및 tmp/ 디렉터리에 쓸 수 있도록 합니다
sudo chown -R git log/
sudo chown -R git tmp/
sudo chmod -R u+rwX,go-w log/
sudo chmod -R u+rwX tmp/

# GitLab이 tmp/pids/ 및 tmp/sockets/ 디렉터리에 쓸 수 있도록 합니다
sudo chmod -R u+rwX tmp/pids/
sudo chmod -R u+rwX tmp/sockets/

# public/uploads/ 디렉터리 생성
sudo -u git -H mkdir -p public/uploads/

# public/uploads/ 디렉터리에는 이제 GitLab 사용자만 액세스할 수 있도록 합니다
# 이제 public/uploads 디렉터리의 파일은 gitlab-workhorse에 의해 제공됩니다
sudo chmod 0700 public/uploads

# CI 작업 로그가 저장된 디렉터리의 권한 변경
sudo chmod -R u+rwX builds/

# CI 아티팩트가 저장된 디렉터리의 권한 변경
sudo chmod -R u+rwX shared/artifacts/

# GitLab Pages가 저장된 디렉터리의 권한 변경
sudo chmod -R ug+rwX shared/pages/

# 예시 Puma 구성 복사
sudo -u git -H cp config/puma.rb.example config/puma.rb

# 자세한 내용은 https://github.com/puma/puma#configuration을 참조하세요.
# 사용 가능한 CPU 코어 수에 따라 Puma workers 및 threads를 확장해야 합니다. 이를 위해 `nproc` 명령어를 사용하여 해당 수를 얻을 수 있습니다.
sudo -u git -H editor config/puma.rb

# Redis 연결 설정 구성
sudo -u git -H cp config/resque.yml.example config/resque.yml
sudo -u git -H cp config/cable.yml.example config/cable.yml

# 기본 Debian / Ubuntu 구성을 사용하지 않는 경우 Redis 소켓 경로 변경
sudo -u git -H editor config/resque.yml config/cable.yml

설정을 맞추기 위해 gitlab.yml 및 puma.rb를 수정해야 합니다.

HTTPS를 사용하려면 Using HTTPS를 참조하여 추가 단계를 수행해야 합니다.

GitLab DB 설정 구성

참고: GitLab 15.9부터 database.yml에 main: 섹션만 있는 것은 사용되지 않습니다. GitLab 17.0 이후로 database.yml에는 main: 및 ci: 두 섹션이 필요합니다. 

sudo -u git cp config/database.yml.postgresql config/database.yml

# config/database.yml에서 host, username 및 password 라인을 삭제합니다.
# 수정된 후 'production' 설정은 다음과 같을 것입니다:
#
#   production:
#     main:
#       adapter: postgresql
#       encoding: unicode
#       database: gitlabhq_production
#     ci:
#       adapter: postgresql
#       encoding: unicode
#       database: gitlabhq_production
#       database_tasks: false
#
sudo -u git -H editor config/database.yml

# 원격 PostgreSQL 전용:
# config/database.yml에서 username/password를 업데이트합니다.
# production 설정 (첫 번째 부분)만 조정하십시오.
# 데이터베이스 가이드를 따랐다면 다음 작업을 수행하세요:
# 'secure password'를 $password에 할당한 값으로 변경합니다
# 비밀번호 주변의 쌍따옴표는 유지할 수 있습니다
sudo -u git -H editor config/database.yml

# config/database.yml에서 `ci:` 섹션을 주석 처리 해제합니다.
# `ci:`의 `database` 값이 `main:`의 `database` 값과 일치하는지 확인합니다.

# config/database.yml을 git만 읽을 수 있게합니다
sudo -u git -H chmod o-rwx config/database.yml

database.yml에 두 개의 섹션이 있어야 합니다: main: 및 ci:. ci 연결은 동일한 데이터베이스에 있어야 합니다.

젬 설치

참고: Bundler 1.5.2부터 bundle install -jN (여기서 N은 프로세서 코어 수)을 호출하여 병렬 젬 설치를 사용할 수 있으며 완료 시간에 실질적인 차이를 느낄 수 있습니다 (~60% 빨라짐). 코어 수는 nproc 명령어로 확인할 수 있습니다. 자세한 내용은 이 글을 참조하세요.

bundle -v를 실행하여 bundle이 있는지 확인하세요:

  • >= 1.5.2, 왜냐하면 1.5.2에서 일부 문제가 수정되었기 때문입니다.
  • < 2.x.

젬을 설치합니다 (사용자 인증에 Kerberos를 사용하려면 --without 옵션에서 kerberos를 생략하세요): 

sudo -u git -H bundle config set --local deployment 'true'
sudo -u git -H bundle config set --local without 'development test kerberos'
sudo -u git -H bundle config path /home/git/gitlab/vendor/bundle
sudo -u git -H bundle install

GitLab Shell 설치

GitLab Shell은 GitLab을 위해 특별히 개발된 SSH 액세스 및 저장소 관리 소프트웨어입니다. 

# gitlab-shell의 설치 작업을 실행합니다:
sudo -u git -H bundle exec rake gitlab:shell:install RAILS_ENV=production

# 기본적으로 gitlab-shell 구성은 주요 GitLab 구성에서 생성됩니다.
# 다음과 같이 gitlab-shell 구성을 검토(및 수정)할 수 있습니다:
sudo -u git -H editor /home/git/gitlab-shell/config.yml

HTTPS를 사용하려면 추가 단계를 위해 HTTPS 사용를 참조하세요.

호스트 이름이 적절한 DNS 레코드이거나 /etc/hosts에 추가 줄(“127.0.0.1 hostname”)로 기기 자체에서 해석될 수 있는지 확인하세요. 예를 들어, GitLab을 역방향 프록시 뒤에 설정한 경우에 필요할 수 있습니다. 호스트 이름이 해석되지 않으면 최종 설치 확인이 Check GitLab API access: FAILED. code: 401로 실패하고 커밋을 푸시할 때 [remote rejected] master -> master (hook declined)로 거부됩니다.

GitLab Workhorse 설치

GitLab-Workhorse는 GNU Make를 사용합니다. 다음 명령줄은 추천 위치인 /home/git/gitlab-workhorse에 GitLab-Workhorse를 설치합니다. 

sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]" RAILS_ENV=production

추가 매개변수로 다른 Git 저장소를 지정할 수 있습니다: 

sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse,https://example.com/gitlab-workhorse.git]" RAILS_ENV=production

Premium 및 Ultimate용 GitLab-Elasticsearch-indexer 설치

Tier: Premium, Ultimate Offering: Self-managed

GitLab-Elasticsearch-Indexer는 GNU Make를 사용합니다. 다음 명령줄은 추천 위치인 /home/git/gitlab-elasticsearch-indexer에 GitLab-Elasticsearch-Indexer를 설치합니다. 

sudo -u git -H bundle exec rake "gitlab:indexer:install[/home/git/gitlab-elasticsearch-indexer]" RAILS_ENV=production

추가 매개변수로 다른 Git 저장소를 지정할 수 있습니다: 

sudo -u git -H bundle exec rake "gitlab:indexer:install[/home/git/gitlab-elasticsearch-indexer,https://example.com/gitlab-elasticsearch-indexer.git]" RAILS_ENV=production

먼저 소스 코드가 첫 번째 매개변수로 지정된 경로에 가져오고 bin 디렉토리 아래에서 바이너리가 빌드됩니다. 그런 다음 gitlab.yml의 production -> elasticsearch -> indexer_path 설정을 해당 바이너리를 가리키도록 업데이트해야 합니다.

GitLab Pages 설치

GitLab Pages는 GNU Make를 사용합니다. 이 단계는 선택 사항이며 GitLab 내에서 정적 사이트를 호스팅하려는 경우에만 필요합니다. 다음 명령은 /home/git/gitlab-pages에 GitLab Pages를 설치합니다. 추가 설정 단계는 관리 가이드를 참조하십시오. GitLab Pages 데몬은 여러 가지 다른 방법으로 실행될 수 있기 때문입니다. 

cd /home/git
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
cd gitlab-pages
sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_PAGES_VERSION)
sudo -u git -H make

Gitaly 설치 

# git 저장소 데이터 디렉토리를 생성하고 액세스를 제한합니다
sudo install -d -o git -m 0700 /home/git/repositories

# Git로 Gitaly 소스를 가져와 Go로 컴파일합니다
cd /home/git/gitlab
sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly,/home/git/repositories]" RAILS_ENV=production

추가 매개변수로 다른 Git 저장소를 지정할 수 있습니다: 

sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly,/home/git/repositories,https://example.com/gitaly.git]" RAILS_ENV=production

다음으로 Gitaly가 구성되었는지 확인하세요: 

# Gitaly 소켓 액세스를 제한합니다
sudo chmod 0700 /home/git/gitlab/tmp/sockets/private
sudo chown git /home/git/gitlab/tmp/sockets/private

# 비정상적인 설정을 사용하는 경우 config.toml을 업데이트해야 합니다
cd /home/git/gitaly
sudo -u git -H editor config.toml

Gitaly 구성에 대한 자세한 내용은 Gitaly 문서를 참조하십시오.

서비스 설치

GitLab은 항상 SysV 이닛 스크립트를 지원해왔으며, 널리 지원되며 이식성이 뛰어난 편입니다. 그러나 이제 systemd가 서비스 감독의 표준이 되었으며 모든 주요 Linux 배포판에서 사용됩니다. 가능하면 원본 systemd 서비스를 사용하여 자동 다시 시작, 더 나은 샌드박싱 및 리소스 제어의 이점을 누려야 합니다.

systemd 유닛 설치

시스템 초기화로 systemd를 사용하는 경우, SysV 이닛 스크립트 단계를 따르십시오.

서비스를 복사하고 systemd가 이를 인식하도록 systemctl daemon-reload를 실행합니다: 

cd /home/git/gitlab
sudo mkdir -p /usr/local/lib/systemd/system
sudo cp lib/support/systemd/* /usr/local/lib/systemd/system/
sudo systemctl daemon-reload

GitLab이 다른 디렉토리에 설치되었거나 기본값이 아닌 사용자로 설치한 경우 유닛 파일에서 이러한 값을 변경해야 합니다.

예를 들어, Redis와 PostgreSQL을 GitLab과 동일한 기기에서 실행 중이라면:

  • Puma 서비스 편집: 

    sudo systemctl edit gitlab-puma.service

    열리는 편집기에 다음을 추가하고 파일을 저장하세요: 

    [Unit]
Wants=redis-server.service postgresql.service
After=redis-server.service postgresql.service

  • Sidekiq 서비스 편집: 

    sudo systemctl edit gitlab-sidekiq.service

    다음을 추가하고 파일을 저장하세요: 

    [Unit]
Wants=redis-server.service postgresql.service
After=redis-server.service postgresql.service

systemctl edit은 /etc/systemd/system/<unit 이름>.d/override.conf에 드롭인 구성 파일을 설치하여 나중에 유닛 파일을 업데이트할 때 지역 구성이 덮어씌워지지 않도록 합니다. 드롭인 구성 파일을 분할하려면 .conf 파일에 위의 스니펫을 추가할 수 있습니다.

유닛 파일을 수동으로 변경하거나 systemctl edit을 사용하지 않고 드롭인 구성 파일을 추가한 경우 (모두 systemctl edit을 사용하지 않은 경우), 변경 사항이 적용되도록 다음 명령을 실행하십시오: 

sudo systemctl daemon-reload

GitLab 부팅 시 시작하도록 만듭니다: 

sudo systemctl enable gitlab.target

SysV 초기화 스크립트 설치

SysV 초기화 스크립트를 사용하는 경우 이러한 단계를 따르십시오. 만약 systemd를 사용하는 경우, systemd 유닛 단계를 따르세요.

init 스크립트를 다운로드합니다(/etc/init.d/gitlab): 

cd /home/git/gitlab
sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab

그리고 기본 폴더나 사용자가 아닌 다른 경로에 GitLab을 설치하는 경우, defaults 파일을 복사하고 편집하세요: 

sudo cp lib/support/init.d/gitlab.default.example /etc/default/gitlab

만약 기본이 아닌 다른 디렉토리에 GitLab을 설치했거나 기본 사용자 외의 사용자로 설치했다면, /etc/default/gitlab에서 이러한 설정을 변경해야 합니다. 업그레이드 시 /etc/init.d/gitlab을 편집해서는 안 됩니다.

GitLab을 부팅 시 시작하도록 만드세요: 

sudo update-rc.d gitlab defaults 21
# systemd를 사용하는 기계에서 실행 중인 경우
sudo systemctl daemon-reload
sudo systemctl enable gitlab.service

로그로테이트 설정 

sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab

Gitaly 시작

다음 섹션을 진행하려면 Gitaly가 실행 중이어야 합니다.

  • systemd를 사용하여 Gitaly 시작: 

    sudo systemctl start gitlab-gitaly.service

  • SysV에서 수동으로 Gitaly 시작: 

    gitlab_path=/home/git/gitlab
gitaly_path=/home/git/gitaly

sudo -u git -H sh -c "$gitlab_path/bin/daemon_with_pidfile $gitlab_path/tmp/pids/gitaly.pid \
  $gitaly_path/_build/bin/gitaly $gitaly_path/config.toml >> $gitlab_path/log/gitaly.log 2>&1 &"

데이터베이스 초기화 및 고급 기능 활성화 

cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production
# 'yes' 입력하여 데이터베이스 테이블을 만드세요.

# 또는 force=yes를 추가하여 질문을 건너뛸 수 있습니다.
sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production force=yes

# 완료되면 'Administrator account created:' 메시지가 표시됩니다.

아래와 같이 환경 변수인 GITLAB_ROOT_PASSWORD 및 GITLAB_ROOT_EMAIL을 입력하여 관리자/루트 비밀번호와 이메일을 설정할 수 있습니다. (기본 비밀번호로 설정하지 않은 경우) 설치가 완료되고 서버에 처음으로 로그인할 때까지 공개 인터넷에 GitLab을 노출하지 마십시오. 첫 번째 로그인 중에 기본 비밀번호를 변경하도록 강제됩니다. Enterprise Edition를 활성화하려면 GITLAB_ACTIVATION_CODE 환경 변수에 활성화 코드를 제공하여이 시간에도 활성화할 수 있습니다. 

sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production GITLAB_ROOT_PASSWORD=yourpassword GITLAB_ROOT_EMAIL=youremail GITLAB_ACTIVATION_CODE=yourcode

secrets.yml 보안

secrets.yml 파일은 세션 및 안전한 변수를 위한 암호화 키를 저장합니다. secrets.yml을 안전한 곳에 백업하되, 데이터베이스 백업과 동일한 위치에 저장하지 마십시오. 그렇지 않으면 백업 중 하나가 침해당하는 경우 비밀이 노출됩니다.

애플리케이션 상태 확인

GitLab 및 해당 환경이 올바르게 구성되었는지 확인합니다: 

sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

에셋 컴파일 

sudo -u git -H yarn install --production --pure-lockfile
sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production NODE_ENV=production

rake가 JavaScript heap out of memory 오류로 실패하는 경우 다음과 같이 NODE_OPTIONS를 설정하여 다시 실행해보세요. 

sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production NODE_ENV=production NODE_OPTIONS="--max_old_space_size=4096"

GitLab 인스턴스 시작 

# systemd를 사용하는 시스템의 경우
sudo systemctl start gitlab.target

# SysV init를 사용하는 시스템의 경우
sudo service gitlab start

10. NGINX

NGINX은 GitLab의 공식적으로 지원하는 웹 서버입니다. NGINX를 웹 서버로 사용할 수 없거나 사용하지 않으려는 경우 GitLab 레시피를 참조하세요.

설치 

sudo apt-get install -y nginx

사이트 구성

예제 사이트 구성을 복사하세요: 

sudo cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
sudo ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab

설정 파일을 해당 세팅에 맞게 편집하세요. 특히 git 사용자가 아닌 사용자를 위해 설치하는 경우 GitLab에 대한 경로를 확인하세요: 

# GitLab을 호스트로 제공하는 호스트의 완전히 지정된 도메인 이름인 YOUR_SERVER_FQDN로 변경하세요.
#
# 특히 'git' 사용자가 아닌 사용자를 위해 설치하는 경우 GitLab과 관련된 경로를 매치해야 합니다.
#
# Ubuntu 기본 nginx 설치를 사용하는 경우:
# listen 줄에서 default_server를 제거하거나 sudo rm -f /etc/nginx/sites-enabled/default을 실행하세요
sudo editor /etc/nginx/sites-available/gitlab

GitLab Pages를 사용하려는 경우 별도의 NGINX 구성 파일을 사용해야 합니다. 필요한 구성에 대한 모든 정보는 GitLab Pages 관리 가이드에서 확인하세요.

HTTPS를 사용하려는 경우 gitlab NGINX 구성 파일을 gitlab-ssl로 교체하세요. HTTPS 구성 세부 정보에 대해서는 HTTPS 사용를 참조하세요.

GitLab-Workhorse 소켓을 읽을 수 있도록 NGINX가 설정되어야 하며, 이를 위해 www-data 사용자가 GitLab 사용자가 소유한 소켓을 읽을 수 있어야 합니다. 이것은 기본적으로 0755 권한을 가지므로 소켓이 전체적으로 읽을 수 있어야 합니다.

구성 테스트

다음 명령어로 gitlab 또는 gitlab-ssl NGINX 구성 파일을 유효성 검사하세요: 

sudo nginx -t

syntax is okay와 test is successful 메시지를 수신해야 합니다. 오류 메시지가 표시되면 제공된 오류 메시지에서 오탈자를 확인하세요.

설치된 버전이 1.12.1보다 큰지 확인하세요: 

nginx -v

1.12.1보다 낮으면 아래의 오류를 받을 수 있습니다: 

nginx: [emerg] unknown "start$temp=[filtered]$rest" variable
nginx: configuration file /etc/nginx/nginx.conf test failed

다시 시작 

# systemd를 실행 중인 시스템의 경우
sudo systemctl restart nginx.service

# SysV init을 실행 중인 시스템의 경우
sudo service nginx restart

설치 후 조치

애플리케이션 상태 재확인

놓치지 않고 모든 항목을 확인하려면 다음을 실행하세요. 

sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

모든 항목이 초록색이면 GitLab의 설치가 성공적으로 완료된 것을 축하합니다!

참고: gitlab:check에 SANITIZE=true 환경 변수를 제공하여 검사 명령의 출력에서 프로젝트 이름을 생략할 수 있습니다.

초기 로그인

첫 번째 GitLab 로그인을 위해 웹 브라우저에서 YOUR_SERVER를 방문하세요.

설치 중 루트 암호를 제공하지 않았다면 설정 중에 루트 암호를 제공하지 않았다면, 초기 관리자 계정의 암호를 제공하기 위해 암호 재설정 화면으로 리디렉션됩니다. 원하는 암호를 입력하면 다시 로그인 화면으로 리디렉션됩니다.

기본 계정의 사용자 이름은 root입니다. 이전에 생성한 암호를 제공하고 로그인하세요. 로그인 후 원하는 경우 사용자 이름을 변경할 수 있습니다.

즐기세요!

다음과 같은 방법으로 GitLab을 시작하고 중지할 수 있습니다.

  • systemd units: sudo systemctl start gitlab.target 또는 sudo systemctl stop gitlab.target.
  • SysV init 스크립트: sudo service gitlab start 또는 sudo service gitlab stop.

권장하는 다음 단계

설치를 완료한 후 권장하는 다음 단계를 고려해보세요. 이 단계에는 인증 옵션 및 가입 제한 사항이 포함됩니다.

고급 설정 팁

상대 URL 지원

상대 URL을 사용하여 GitLab을 구성하는 방법에 대한 자세한 내용은 상대 URL 문서를 참조하세요.

HTTPS 사용

HTTPS로 GitLab을 사용하려면 다음을 수행하세요.

  1. gitlab.yml에서:
    1. 섹션 1에서 port 옵션을 443으로 설정합니다.
    2. 섹션 1에서 https 옵션을 true로 설정합니다.
  2. GitLab Shell의 config.yml에서:
    1. gitlab_url 옵션을 GitLab의 HTTPS 엔드포인트로 설정합니다(예: https://git.example.com).
    2. ca_file 또는 ca_path 옵션을 사용하여 인증서를 설정합니다.
  3. gitlab-ssl NGINX 예제 구성을 gitlab 구성 대신 사용합니다.
    1. YOUR_SERVER_FQDN을 업데이트합니다.
    2. ssl_certificate 및 ssl_certificate_key를 업데이트합니다.
    3. 구성 파일을 검토하고 다른 보안 및 성능 향상 기능을 적용할 수 있습니다.

자체 서명된 인증서를 사용하는 것은 권장되지 않습니다. 필요한 경우 표준 방법에 따라 자체 서명 SSL 인증서를 생성하십시오. 

mkdir -p /etc/nginx/ssl/
cd /etc/nginx/ssl/
sudo openssl req -newkey rsa:2048 -x509 -nodes -days 3560 -out gitlab.crt -keyout gitlab.key
sudo chmod o-r gitlab.key

이메일로 회신 활성화

이를 설정하는 방법에 대한 자세한 내용은 “이메일 회신” 문서를 참조하세요.

LDAP 인증

config/gitlab.yml에서 LDAP 인증을 구성할 수 있습니다. 이 파일을 편집한 후 GitLab을 다시 시작하세요.

사용자 정의 OmniAuth 공급자 사용

OmniAuth 통합 문서를 참조하세요.

프로젝트 빌드

GitLab은 여러분의 프로젝트를 빌드할 수 있습니다. 이 기능을 활성화하려면 러너가 필요합니다. 설치하려면 GitLab 러너 섹션을 참조하세요.

신뢰하는 프록시 추가

별도의 기계에서 역방향 프록시를 사용하는 경우 사용자가 프록시의 IP 주소에서 로그인한 것처럼 보이지 않도록 신뢰할 수 있는 프록시 목록에 프록시를 추가할 수 있습니다.

config/gitlab.yml에 신뢰할 수 있는 프록시를 추가하여 변경 사항이 적용되려면 파일을 저장하고 GitLab 재구성을 수행하세요.

사용자 지정 Redis 연결

비표준 포트나 다른 호스트의 Redis 서버에 연결하려면 config/resque.yml 파일을 통해 연결 문자열을 구성할 수 있습니다. 

# 예시
production:
  url: redis://redis.example.tld:6379

Redis 서버를 소켓을 통해 연결하려면 config/resque.yml 파일에서 unix: URL scheme 및 Redis 소켓 파일의 경로를 사용하십시오. 

# 예시
production:
  url: unix:/path/to/redis/socket

또한 config/resque.yml 파일에서 환경 변수를 사용할 수 있습니다. 

# 예시
production:
  url: <%= ENV.fetch('GITLAB_REDIS_URL') %>

사용자 정의 SSH 연결

SSH를 비표준 포트에서 실행하고 있다면 GitLab 사용자의 SSH 구성을 변경해야 합니다. 

# /home/git/.ssh/config에 추가
host localhost          # 설정에 이름을 지정합니다 (여기서는 localhost로 지정)
    user git             # 원격 git 사용자
    port 2222            # 포트 번호
    hostname 127.0.0.1;  # 서버 이름 또는 IP

이에 상응하는 옵션(예: ssh_user, ssh_host, admin_uri)을 config/gitlab.yml 파일에서 변경해야 합니다.

추가 마크업 스타일

항상 지원되는 Markdown 스타일 외에 GitLab이 표시할 수 있는 다른 리치 텍스트 파일이 있습니다. 하지만 이를 표시하려면 종속성을 설치해야 할 수 있습니다. 자세한 정보는 github-markup gem README를 참조하세요.

프로메테우스 서버 설정

config/gitlab.yml에서 프로메테우스 서버를 구성할 수 있습니다. 

# 예시
prometheus:
  enabled: true
  server_address: "10.1.2.3:9090"

문제 해결

“빈 저장소를 복제한 것으로 보입니다.”

GitLab에서 호스팅하는 저장소를 복제하려고 시도할 때 이 메시지가 나타나면 이는 오래된 NGINX 또는 Apache 구성, 또는 필요한 GitLab Workhorse 인스턴스의 누락 또는 잘못된 구성으로 인한 것입니다. Go를 설치하였는지, GitLab Workhorse를 설치하였는지, 그리고 NGINX를 올바르게 구성하였는지 다시 확인하세요.

google-protobuf “LoadError: /lib/x86_64-linux-gnu/libc.so.6: version ‘GLIBC_2.14’ not found”

google-protobuf 젬의 일부 버전에 대해 특정 플랫폼에서 발생할 수 있습니다. 이 문제를 해결하기 위한 방안은 이 젬의 소스 전용 버전을 설치하는 것입니다.

먼저, GitLab 설치에 필요한 정확한 google-protobuf 버전을 찾아야 합니다. 

cd /home/git/gitlab

# 다음 두 명령 중 하나만 출력합니다. 출력은 다음과 같을 것입니다: * google-protobuf (3.2.0)
bundle list | grep google-protobuf
bundle check | grep google-protobuf

위에서 찾은 버전 번호를 사용하기 위해 아래와 같이 3.2.0을 예로 들었습니다. 실제 번호로 바꿔주세요. 

cd /home/git/gitlab
sudo -u git -H gem install google-protobuf --version 3.2.0 --platform ruby

마지막으로 google-protobuf이 올바르게 로드되는지 테스트할 수 있습니다. 다음과 같이 ‘OK’가 출력되어야 합니다. 

sudo -u git -H bundle exec ruby -rgoogle/protobuf -e 'puts :OK'

만약 gem install 명령이 실패한다면, OS의 개발 도구를 설치해야 할 수 있습니다.

Debian/Ubuntu의 경우: 

sudo apt-get install build-essential libgmp-dev

RedHat/CentOS의 경우: 

sudo yum groupinstall 'Development Tools'

GitLab 자산 컴파일 오류

자산을 컴파일하는 동안 다음과 같은 오류 메시지를 받을 수 있습니다. 

Killed
error Command failed with exit code 137.

이 오류는 Yarn이 메모리를 모두 소진하여 컨테이너를 종료할 때 발생할 수 있습니다. 이를 해결하려면 다음을 수행하세요:

  1. 시스템 메모리를 최소 8GB로 늘리세요.

  2. 다음 명령을 실행하여 자산을 정리하세요: 

    sudo -u git -H bundle exec rake gitlab:assets:clean RAILS_ENV=production NODE_ENV=production

  3. 충돌을 해결하기 위해 yarn 명령을 다시 실행하세요: 

    sudo -u git -H yarn install --production --pure-lockfile

  4. 자산을 다시 컴파일하세요: 

    sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production NODE_ENV=production