자체 컴파일 설치

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

이것은 소스 파일을 사용하여 프로덕션 GitLab 서버를 설정하는 공식 설치 가이드입니다. 이 가이드는 Debian/Ubuntu 운영 체제에서 생성되었으며 테스트되었습니다. 하드웨어 및 운영 체제 요구 사항에 대해서는 requirements.md를 확인하세요. RHEL/CentOS에서 설치하려면 Linux packages를 사용해야 합니다. 다른 많은 설치 옵션에 대해서는 main installation page를 참조하세요.

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

이 가이드에서 버그/오류를 발견하면 기여 가이드를 따라 Merge Request을 제출해주세요.

Linux 패키지 설치 고려

자체 컴파일 설치는 많은 작업과 오류가 발생하기 쉬우므로 빠르고 신뢰할 수 있는 Linux package installation (deb/rpm)를 강력히 권장합니다.

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

설치할 버전 선택

설치하려는 GitLab 버전(예: 16-0-stable)의 이 설치 가이드를 반드시 확인하세요. GitLab의 왼쪽 상단 모서리(메뉴 바 아래)에있는 버전 드롭다운 디렉터리에서 브랜치(버전)를 선택할 수 있습니다.

가장 높은 숫자의 안정적인 브랜치가 명확하지 않다면, 버전별 GitLab 블로그에서 설치 가이드 링크를 확인하세요.

소프트웨어 요구 사항

소프트웨어 최소 버전 참고 사항
Ruby 3.1.x GitLab 16.7부터 Ruby 3.1이 필요합니다. 표준 MRI Ruby 구현을 사용해야 합니다. JRuby, Rubinius을 좋아합니다. 하지만 GitLab에는 네이티브 확장을 가진 여러 Gem이 필요합니다.
RubyGems 3.4.x 특정 RubyGems 버전이 완전히 필요하지는 않지만, 알려진 성능 향상을 누릴 수 있도록 업데이트하는 것이 좋습니다.
Go 1.20.x GitLab 16.4부터 Go 1.20 이상이 필요합니다.
Git 2.42.x GitLab 16.5부터 Git 2.42.x 이상이 필요합니다. Gitaly가 제공하는 Git 버전을 사용해야 합니다.
Node.js 18.17.x GitLab 16.3부터 Node.js 18.17 이상이 필요합니다.

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가 설치되어 있지 않습니다. 시스템이 최신 상태인지 확인하고 설치해야 합니다. 

# 루트로 실행!
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
note
GitLab은 OpenSSL 버전 1.1이 필요합니다. Linux 배포판에 따라 다른 버전의 OpenSSL이 포함되어 있으면 매뉴얼으로 1.1을 설치해야 할 수 있습니다.

Git

GitLab 13.6부터는 항상 GitLab에서 필요로하는 버전으로 제공되는 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 버전과 일치하는 안정적인 브랜치를 사용하여 <X-Y-stable>을(를) 대체하세요. 예를 들어, GitLab 13.6을 설치하려면 브랜치 이름을 13-6-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

그런 다음 ‘Internet Site’를 선택하고 호스트 이름을 확인하려면 Enter를 누르세요.

ExifTool

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

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

2. Ruby

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

RVM(https://rvm.io/), rbenv(https://github.com/rbenv/rbenv) 또는 chruby(https://github.com/postmodern/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.20.8.linux-amd64.tar.gz"
echo 'cc97c28d9c252fbf28f91950d830201aa403836cbed702a05932e63f7f0c7bc4  go1.20.8.linux-amd64.tar.gz' | shasum -a256 -c - && \
  sudo tar -C /usr/local -xzf go1.20.8.linux-amd64.tar.gz
sudo ln -sf /usr/local/go/bin/{go,gofmt} /usr/local/bin/
rm go1.20.8.linux-amd64.tar.gz

5. Node

GitLab은 JavaScript를 컴파일하고 JavaScript 의존성을 관리하기 위해 Node를 사용해야 합니다. 요구 사항은 다음과 같습니다:

  • node 18.x 릴리스 (v18.17.0 이상). Node.js의 다른 LTS 버전이 자산을 빌드할 수는 있지만 우리는 Node.js 18.x만을 보장합니다.
  • yarn = v1.22.x (Yarn 2는 아직 지원되지 않습니다)

공식 패키지 리포지터리에서 제공하는 버전이 오래된 경우가 많으므로 다음 명령어를 사용하여 설치하세요: 

# node v18.x 설치
curl --location "https://deb.nodesource.com/setup_18.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. 데이터베이스

note
GitLab 12.1 이상에서는 PostgreSQL만 지원됩니다. GitLab 16.0 이상에서는 PostgreSQL 13+이 필요합니다.

  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. 사용 중인 GitLab 버전과 호환되는 PostgreSQL 버전이 있는지 확인하세요: 

    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 확장을 생성하세요 (GitLab 13.1+에서 필요): 

    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 감독하에 동작하도록 구성하고 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 unit 파일에 동일한 변경 사항을 적용합니다.
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

소스 복제

Community Edition을 복제하십시오. 

# GitLab 리포지터리를 복제합니다.
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-foss.git -b <X-Y-stable> gitlab

Enterprise Edition을 복제하십시오. 

# GitLab 리포지터리를 복제합니다.
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab.git -b <X-Y-stable-ee> gitlab

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

caution
프로덕션 서버에는 절대로 master를 설치하지 마십시오! bleeding edge 버전을 사용하려면 <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-workhorse에 의해 제공되므로 GitLab 사용자만 액세스할 수 있도록합니다.
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 워커 및 스레드를 확장해야 합니다. `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를 사용하려면 HTTPS 사용을 참조하십시오.

GitLab DB 설정 구성

note
GitLab 15.9부터는 main: 섹션만 있는 database.yml이 사용되지 않습니다. 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

젬 설치

note
Bundler 1.5.2부터 bundle install -jN (여기서 N은 프로세서 코어의 숫자입니다)를 호출하여 병렬 젬 설치를 실행할 수 있으며 완료 시간에서 메트릭 가능한 차이를 경험할 수 있습니다 (~60% 빠르게). nproc로 코어의 숫자를 확인하세요. 자세한 정보는 이 포스트를 참조하세요.

bundle가 설치되어 있는지 확인하세요 (다음 명령 실행):

  • >= 1.5.2, 왜냐하면 1.5.2에서 몇가지 issues가 fixed되었습니다.
  • < 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

기업 버전용 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 init 스크립트를 지원했지만, 이제 systemd가 서비스 감시의 표준이며 모든 주요 Linux 배포판에서 사용되므로 native systemd 서비스를 사용해야 합니다. 이렇게 하면 자동 재시작, 더 좋은 샌드박싱 및 리소스 제어를 활용할 수 있습니다.

systemd 단위 설치

시스템 초기화로 systemd를 사용하는 경우 이 단계를 따르세요. 그렇지 않으면 SysV 초기화 스크립트 단계를 따르세요.

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

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를 다른 디렉터리에 설치했거나 기본 사용자가 아닌 사용자로 설치했을 경우 이러한 값을 단위 파일에서도 변경해야 합니다.

예를 들어, 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/<단위 이름>.d/override.conf에 드롭-인 구성 파일을 설치합니다. 드롭-인 구성 파일을 분리하려면 상기 스니펫을 /etc/systemd/system/<단위 이름>.d/ 아래에 .conf 파일에 추가할 수 있습니다.

매뉴얼으로 단위 파일을 변경하거나 systemctl edit을 사용하지 않고 드롭-인 구성 파일을 추가한 경우 이러한 변경 사항이 적용되도록 다음 명령을 실행합니다: 

sudo systemctl daemon-reload

GitLab을 부팅 시 자동으로 시작하도록 설정합니다: 

sudo systemctl enable gitlab.target

SysV 초기화 스크립트 설치

SysV 초기화 스크립트를 사용하는 경우 이 단계를 따르세요. systemd를 사용하는 경우 systemd 단위 설치 단계를 따르세요.

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

cd /home/git/gitlab
sudo cp lib/support/init.d/gitlab /etc/init.d/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

# 완료되면 '관리자 계정이 생성됨:'이 표시됩니다

환경 변수 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' 이외의 사용자를 위해 설치하는 경우 경로를 일치시키십시오.
#
# 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 사용를 참조하십시오.

NGINX가 GitLab-Workhorse 소켓을 읽을 수 있도록하려면, GitLab 사용자가 소유한 소켓을 읽을 수 있도록 해야 합니다. 이것은 예를 들어 기본값인 권한 0755를 가지고 있어서 세계에서 읽을 수 있도록 하는 것으로 달성됩니다. 또한 www-data도 상위 디렉터리를 나열할 수 있어야 합니다.

구성 테스트

다음 명령어로 gitlab 또는 gitlab-ssl NGINX 구성 파일을 유효성을 검증합니다: 

sudo nginx -t

syntax is okay 및 test is successful 메시지를 받아야 합니다. 오류 메시지를 받는 경우, 제공된 오류 메시지에 따라 오타가 있는지 확인하십시오.

설치된 버전이 1.12.1보다 큰지 확인합니다: 

nginx -v

만약 작은 경우, 아래와 같은 오류를 받을 수 있습니다: 

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을 성공적으로 설치했다는 축하를 받아라!

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

최초 로그인

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

설정 중에 루트 암호를 제공하지 않은 경우, 초기 관리자 계정의 암호를 제공하도록 암호 재설정 화면으로 리디렉션됩니다. 원하는 암호를 입력한 후 로그인 화면으로 리디렉션됩니다.

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

즐겨라!

사용할 때 GitLab을 시작하고 중지하려면:

  • systemd 단위: 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 구성 대신 gitlab-ssl NGINX 예제 구성을 사용하십시오.
    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에 신뢰할 수 있는 프록시를 추가하여 trusted_proxies 옵션을 사용자 정의하십시오. 파일을 저장하고 변경사항이 적용되도록 GitLab을 다시 구성하십시오.

사용자 정의 Redis 연결

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

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

Redis 서버를 소켓을 통해 연결하려면, unix: URL scheme 및 config/resque.yml 파일의 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입니다

또한, config/gitlab.yml 파일에서 해당 옵션(예: ssh_user, ssh_host, admin_uri)을 변경해야 합니다.

추가 마크업 스타일

항상 지원되는 Markdown 스타일 외에도, GitLab이 표시할 수 있는 다른 리치 텍스트 파일이 있습니다. 하지만 이를 위해 의존성을 설치해야 할 수도 있습니다. 자세한 내용은 github-markup gem README를 참조하세요.

Prometheus 서버 설정

config/gitlab.yml에서 Prometheus 서버를 구성할 수 있습니다. 

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

Troubleshooting

“You appear to have cloned an empty repository.”

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 gem을 지원하지 않는 플랫폼에서 발생할 수 있습니다. 이 문제를 해결하기 위해 이 gem의 소스 전용 버전을 설치해야 합니다.

먼저, 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