Linux 패키지 설치 고려
설치할 버전 선택
소프트웨어 요구 사항
GitLab 디렉토리 구조
개요
1. 패키지 및 의존성
- sudo
- 빌드 의존성
- Git
- GraphicsMagick
- Mail server
- ExifTool
2. Ruby
3. RubyGems
4. Go
5. Node
6. 시스템 사용자
7. 데이터베이스
8. Redis
- systemd로 Redis 감독하기
- Redis를 감독하지 않음
9. GitLab
10. NGINX
설치 후
고급 설정 팁
문제 해결

자체 컴파일 설치

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

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

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

이 가이드에서 버그/오류를 발견한 경우, 머지 요청을 제출하세요
기여 가이드를 참조하세요.

Linux 패키지 설치 고려

자체 컴파일 설치는 많은 작업과 오류가 발생할 가능성이 높기 때문에 빠르고 신뢰할 수 있는 Linux 패키지 설치 (deb/rpm)를 강력히 권장합니다.

Linux 패키지가 더 신뢰할 수 있는 이유 중 하나는 하나의 프로세스가 크래시될 경우 runit을 사용하여 GitLab 프로세스를 재시작하기 때문입니다.
빈번하게 사용되는 GitLab 인스턴스에서는 Sidekiq 백그라운드 작업자의 메모리 사용량이 시간이 지남에 따라 증가합니다.
Linux 패키지는 메모리를 너무 많이 사용할 경우 Sidekiq를 정상 종료하게 함으로써 이 문제를 해결합니다.
이 종료 후 runit은 Sidekiq가 실행되지 않는 것을 감지하고 이를 시작합니다.
자체 컴파일 설치는 프로세스 감독을 위해 runit을 사용하지 않기 때문에 Sidekiq를 종료할 수 없으며 메모리 사용량이 시간이 지남에 따라 증가합니다.

설치할 버전 선택

설치하려는 GitLab의 브랜치(버전)에서 이 설치 가이드를 반드시 보세요 (예: 16-0-stable).
GitLab의 좌측 상단 모서리에 있는 버전 드롭다운 목록에서 브랜치를 선택할 수 있습니다.

최신 안정 버전이 불명확할 경우, GitLab 블로그에서 버전별 설치 가이드 링크를 확인하세요.

소프트웨어 요구 사항

소프트웨어	최소 버전	비고
Ruby	`3.2.x`	GitLab 17.5 이상에서 Ruby 3.2가 필요합니다. 표준 MRI 구현의 Ruby를 사용해야 합니다. JRuby와 Rubinius를 좋아하지만, GitLab은 네이티브 확장이 있는 여러 Gem이 필요합니다.
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 설치는 다음 구성 요소를 설정하는 것으로 이루어집니다:

패키지 및 의존성.
루비.
루비젬.
고.
노드.
시스템 사용자.
데이터베이스.
레디스.
GitLab.
NGINX.

1. 패키지 및 의존성

sudo

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

# 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

다음의 Git의 Gitaly에서 제공하는 버전을 사용해야 합니다:

GitLab에서 요구하는 버전으로 항상 유지됩니다.
올바른 작동을 위한 사용자 지정 패치가 포함될 수 있습니다.

필요한 의존성을 설치하세요:

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

Gitaly 저장소를 클론하고 Git을 컴파일하세요. <X-Y-stable>를 설치하려는 GitLab 버전에 맞는 안정적인 브랜치로 교체하세요. 예를 들어, 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
```
선택적으로, 시스템 Git와 그 의존성을 제거할 수 있습니다:
```
sudo apt remove -y git-core
sudo apt autoremove
```

나중에 editconfig/gitlab.yml할 때, Git 경로를 변경하는 것을 잊지 마세요:

이전:
```
git:
  bin_path: /usr/bin/git
```
이후:
```
git:
  bin_path: /usr/local/bin/git
```

GraphicsMagick

Custom Favicon가 작동하려면 GraphicsMagick가 설치되어 있어야 합니다.

sudo apt-get install -y graphicsmagick

Mail server

메일 알림을 받으려면 메일 서버를 설치해야 합니다.

기본적으로 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. Ruby

GitLab을 실행하려면 Ruby 인터프리터가 필요합니다.

최소 Ruby 요구 사항은 요구 사항 섹션을 참조하세요.

생산에서 GitLab과 함께 RVM(https://rvm.io/), rbenv(https://github.com/rbenv/rbenv) 또는 chruby(https://github.com/postmodern/chruby)와 같은 Ruby 버전 관리자를 사용하면 진단하기 어려운 문제로 이어질 수 있습니다. 버전 관리자는 지원되지 않으며, 시스템 Ruby를 사용하도록 아래의 지침을 따르는 것을 강력히 권장합니다.

리눅스 배포판은 일반적으로 오래된 Ruby 버전을 제공하므로 이러한 지침은 공식 소스 코드에서 Ruby를 설치하도록 설계되었습니다.

Ruby 설치하기 .

3. RubyGems

때때로 Ruby에 포함된 것보다 더 최신 버전의 RubyGems가 필요합니다.

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

gem update --system 3.4.12

아니면 최신 버전으로:

gem update --system

4. Go

GitLab은 Go로 작성된 여러 데몬을 가지고 있습니다. GitLab을 설치하려면 Go 컴파일러가 필요합니다. 아래 지침은 64비트 리눅스를 사용할 것을 가정합니다. 다른 플랫폼에 대한 다운로드는 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 자산을 컴파일하기 위해 Node를 필요로 하며, JavaScript 종속성을 관리하기 위해 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+가 필요합니다.

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

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

설치 중인 GitLab 버전에서 지원하는 PostgreSQL 버전인지 확인합니다:
```
psql --version
```
PostgreSQL 서비스를 시작하고 서비스가 실행 중인지 확인합니다:
```
sudo service postgresql start
sudo service postgresql status
```

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

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

pg_trgm 확장 기능을 생성합니다:

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

btree_gist 확장 기능을 생성합니다:

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

plpgsql 확장 기능을 생성합니다:

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

GitLab 생산 데이터베이스를 생성하고 데이터베이스에 대한 모든 권한을 부여합니다:
```
sudo -u postgres psql -d template1 -c "CREATE DATABASE gitlabhq_production OWNER git;"
```
새 사용자로 새 데이터베이스에 연결해 봅니다:
```
sudo -u git -H psql -d gitlabhq_production
```

pg_trgm 확장 기능이 활성화되어 있는지 확인합니다:

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

확장 기능이 활성화되어 있으면 다음과 같은 결과가 출력됩니다:

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

btree_gist 확장 기능이 활성화되어 있는지 확인합니다:

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

확장 기능이 활성화되어 있으면 다음과 같은 결과가 출력됩니다:

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

plpgsql 확장 기능이 활성화되어 있는지 확인합니다:

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

확장 기능이 활성화되어 있으면 다음과 같은 결과가 출력됩니다:

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

데이터베이스 세션을 종료합니다:
```
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 유닛 파일에도 동일한 변경 사항 적용
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

# 'git' 사용자 홈 디렉토리에 GitLab을 설치합니다.
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

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

경고: 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 사용자만 public/uploads/ 디렉토리에 접근할 수 있도록 설정
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 설정 구성

참고: 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에서 호스트, 사용자 이름 및 비밀번호 라인 제거.
# 수정 후 `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에서 사용자 이름/비밀번호 업데이트.
# production 설정(첫 번째 부분)만 조정하면 됩니다.
# 데이터베이스 가이드를 따랐다면 다음과 같이 하세요:
# 'secure password'를 $password에 제공한 값으로 변경하세요.
# 비밀번호 주위의 따옴표를 유지할 수 있습니다.
sudo -u git -H editor config/database.yml

# config/database.yml에서 `ci:` 섹션의 주석 해제.
# `ci:`의 `database` 값이 `main:`의 데이터베이스 값과 일치하는지 확인하세요.

# 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이 설치되어 있는지 확인하세요 (명령어 실행: bundle -v):

>= 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 셸 설치

GitLab 셸은 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 작업 추적기 설치

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-인덱서 설치

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 버전에 맞는 관리자 가이드를 참조하세요. 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 배포판에서 사용됩니다. 자동 재시작, 더 나은 샌드박싱 및 리소스 제어의 혜택을 받으려면 가능한 경우 기본 systemd 서비스를 사용하는 것이 좋습니다.

systemd 유닛 설치

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

서비스를 복사하고 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/<name of the unit>.d/override.conf에 드롭인 구성 파일을 설치하므로, 나중에 유닛 파일을 업데이트할 때 로컬 구성이 덮어쓰여지지 않습니다. 드롭인 구성 파일을 나누려면 위의 스니펫을 /etc/systemd/system/<name of the unit>.d/의 .conf 파일에 추가할 수 있습니다.

유닛 파일에 수동으로 변경을 하거나 드롭인 구성 파일을 추가한 경우(systemctl edit를 사용하지 않고), 다음 명령을 실행하여 적용하도록 합니다:

sudo systemctl daemon-reload

부팅 시 GitLab이 시작되도록 설정:

sudo systemctl enable gitlab.target

SysV init 스크립트 설치

SysV init 스크립트를 사용하는 경우 이 단계를 따르세요. systemd를 사용하는 경우 systemd unit 단계를 따르세요.

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

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

비기본 폴더나 사용자로 설치하는 경우 기본값 파일을 복사하고 수정하세요:

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

Logrotate 설정

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

Gitaly 시작

다음 섹션을 위해 Gitaly가 실행 중이어야 합니다.

systemd를 사용하여 Gitaly를 시작하려면:
```
sudo systemctl start gitlab-gitaly.service
```

SysV에서 Gital리를 수동으로 시작하려면:

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을 공개 인터넷에 노출하지 마세요. 첫 로그인 시 기본 비밀번호를 변경해야 합니다. 이때 GITLAB_ACTIVATION_CODE 환경 변수에 활성화 코드를 제공하여 Enterprise Edition 구독을 활성화할 수도 있습니다.

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

구성 파일을 편집하여 설정에 맞게 조정해야 합니다. 또한, 다른 사용자를 위해 설치하는 경우 GitLab에 대한 경로가 일치하는지 확인하세요, 특히 git 사용자 외의 사용자로 설치하는 경우:

# YOUR_SERVER_FQDN을 GitLab을 제공하는 호스트의
# 완전한 도메인 이름으로 변경하세요.
#
# GitLab에 대한 경로가 일치하는지 확인하세요, 특히
# '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 소켓을 읽을 수 있도록 하려면, www-data 사용자가 GitLab 사용자가 소유한 소켓을 읽을 수 있도록 해야 합니다. 이는 세계적으로 읽을 수 있는 경우에 달성됩니다. 예를 들어, 기본적으로 0755 권한이 설정되어 있어야 합니다. www-data는 또한 상위 디렉터리를 나열할 수 있어야 합니다.

구성 테스트

다음 명령어를 사용하여 gitlab 또는 gitlab-ssl NGINX 구성 파일을 검증하세요:

sudo nginx -t

syntax is okay 및 test is successful 메시지를 받아야 합니다. 오류 메시지가 발생할 경우, 제공된 오류 메시지에 따른 gitlab 또는 gitlab-ssl NGINX 구성 파일에서 오타를 확인하세요.

설치된 버전이 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 설치가 성공적으로 완료된 것을 축하합니다!

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

초기 로그인

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

만약 설치 중에 루트 비밀번호를 제공하지 않았다면, 비밀번호를 제공하는 초기 관리자 계정의 비밀번호 초기화 화면으로 리디렉션됩니다. 원하는 비밀번호를 입력하면 로그인 화면으로 돌아갑니다.

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

즐기세요!

GitLab을 시작하고 중지하려면 다음을 사용하세요:

systemd 유닛: sudo systemctl start gitlab.target 또는 sudo systemctl stop gitlab.target를 사용합니다.
SysV init 스크립트: sudo service gitlab start 또는 sudo service gitlab stop를 사용합니다.

고급 설정 팁

상대 URL 지원

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

HTTPS 사용

HTTPS로 GitLab을 사용하려면:

gitlab.yml에서:
1. 섹션 1의 port 옵션을 443으로 설정합니다.
2. 섹션 1의 https 옵션을 true로 설정합니다.
GitLab Shell의 config.yml에서:
1. gitlab_url 옵션을 GitLab의 HTTPS 엔드포인트로 설정합니다(예: https://git.example.com).
2. ca_file 또는 ca_path 옵션을 사용하여 인증서를 설정합니다.
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 Runner 섹션을 참조하세요.

신뢰할 수 있는 프록시 추가

별도의 머신에서 리버스 프록시를 사용하는 경우,
프록시를 신뢰할 수 있는 프록시 목록에 추가할 수 있습니다.
그렇지 않으면 사용자가 프록시의 IP 주소에서 로그인한 것으로 표시됩니다.

신뢰할 수 있는 프록시는 config/gitlab.yml 파일에서
trusted_proxies 옵션을 사용자 정의하여 추가할 수 있습니다.
파일을 저장하고 GitLab 재구성하기
변경 사항이 적용되도록 하세요.

사용자 정의 Redis 연결

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

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

소켓을 통해 Redis 서버에 연결하려면,
unix: URL 스킴과 Redis 소켓 파일의 경로를
config/resque.yml 파일에 사용하세요.

# 예시
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'

문제 해결

“빈 저장소를 복제한 것 같습니다.”

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 명령이 실패할 경우,
운영 체제의 개발 도구를 설치해야 할 수 있습니다.

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이 메모리 부족으로 인해 컨테이너를 종료할 때 발생할 수 있습니다. 이를 해결하려면:

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

자산을 정리하기 위해 다음 명령어를 실행하세요:

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

충돌을 해결하기 위해 yarn 명령을 다시 실행하세요:
```
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

자체 컴파일 설치

Linux 패키지 설치 고려

설치할 버전 선택

소프트웨어 요구 사항

GitLab 디렉토리 구조

개요

1. 패키지 및 의존성

sudo

빌드 의존성

Git

GraphicsMagick

Mail server

ExifTool

2. Ruby

3. RubyGems

4. Go

5. Node

6. 시스템 사용자

7. 데이터베이스

8. Redis

systemd로 Redis 감독하기

Redis를 감독하지 않음

9. GitLab

소스 복제

구성하기

GitLab DB 설정 구성

젬 설치

GitLab 셸 설치

GitLab 작업 추적기 설치

기업 에디션의 GitLab-Elasticsearch-인덱서 설치

GitLab Pages 설치

Gitaly 설치

서비스 설치

systemd 유닛 설치

SysV init 스크립트 설치

Logrotate 설정

Gitaly 시작

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

secrets.yml 보호

애플리케이션 상태 확인

자산 컴파일

GitLab 인스턴스 시작

10. NGINX

설치

사이트 구성

구성 테스트

재시작

설치 후

애플리케이션 상태 재확인

초기 로그인

추천 다음 단계

고급 설정 팁

상대 URL 지원

HTTPS 사용

이메일로 회신 활성화

LDAP 인증

사용자 정의 OmniAuth 공급자 사용

프로젝트 빌드

신뢰할 수 있는 프록시 추가

사용자 정의 Redis 연결

사용자 정의 SSH 연결

추가 마크업 스타일

Prometheus 서버 설정

문제 해결

“빈 저장소를 복제한 것 같습니다.”

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

GitLab 자산 컴파일 오류

도움말

기능 사용 가능성과 제품 평가판

도움받기

`secrets.yml` 보호

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