- 리눅스 패키지 설치 고려
- 설치할 버전 선택
- 소프트웨어 요구 사항
- GitLab 디렉터리 구조
- 개요
- 1. 패키지 및 의존성
- 2. 루비
- 3. RubyGems
- 4. Go
- 5. Node
- 6. 시스템 사용자
- 7. 데이터베이스
- 8. Redis
- 9. GitLab
- 10. NGINX
- 설치 후
- 권장 다음 단계
- 고급 설정 팁
- 문제 해결
직접 컴파일하여 설치하기
이것은 공식 설치 가이드로, 소스 파일을 사용하여 프로덕션 GitLab 서버를 설정하는 방법을 안내합니다. Debian/Ubuntu 운영 체제에서 생성되었으며 테스트되었습니다. 하드웨어 및 운영 체제 요구 사항에 대해서는 requirements.md를 참조하십시오. RHEL/CentOS에서 설치하려는 경우, Linux packages를 사용해야 합니다. 기타 많은 설치 옵션에 대해서는 main installation page를 참조하십시오.
이 가이드는 다양한 경우를 다루고 필요한 모든 명령을 포함하고 있기 때문에 길지만, 실제로 작동하는 몇 안 되는 설치 스크립트 중 하나입니다(여기 참조). 다음 단계는 작동하는 것으로 알려져 있습니다. 이 안내서와 다르게 작업할 때 주의하십시오. GitLab이 환경에 대한 가정을 위반하지 않도록 주의하십시오. 예를 들어, 많은 사람들이 디렉터리 위치를 변경하거나 잘못된 사용자로 서비스를 실행하여 권한 문제에 직면합니다.
이 안내서에서 버그/오류를 발견하면, 기여 가이드에 따라 Merge Request을 제출하십시오.
리눅스 패키지 설치 고려
직접 컴파일하여 설치하는 것은 많은 작업이 필요하며 오류가 발생하기 쉽기 때문에, 빠르고 안정적인 Linux 패키지 설치 (deb/rpm)를 강력히 추천합니다.
Linux 패키지가 더 신뢰할 수 있는 이유 중 하나는, GitLab 프로세스 중 하나가 충돌하는 경우 runit을 사용하여 해당 GitLab 프로세스를 다시 시작합니다. 많이 사용되는 GitLab 인스턴스에서는 백그라운드 워커인 Sidekiq의 메모리 사용량이 시간이 지남에 따라 증가합니다. Linux 패키지는 메모리 사용량이 너무 많은 경우 Sidekiq를 gracefull하게 중단시키고, 이 종료 후 runit은 Sidekiq가 실행되지 않는 것을 감지하고 시작합니다. 직접 컴파일하여 설치하는 경우 프로세스를 지원하기 위해 runit을 사용하지 않기 때문에 Sidekiq를 종료할 수 없으며 메모리 사용량이 시간이 지남에 따라 증가합니다.
설치할 버전 선택
GitLab을 설치하고자 하는 GitLab 버전(예: 16-0-stable)의 브랜치(버전)에서 이 설치 가이드를 확인하십시오. GitLab 왼쪽 상단 모서리(메뉴 바 아래)에 있는 버전 드롭다운 디렉터리에서 브랜치를 선택할 수 있습니다.
가장 높은 번호의 안정적인 브랜치가 불분명한 경우, 버전에 따른 GitLab 블로그의 설치 가이드 링크를 확인하십시오.
소프트웨어 요구 사항
| 소프트웨어 | 최소 버전 | 참고 |
|---|---|---|
| Ruby | 3.1.x
| GitLab 16.7부터 Ruby 3.1이 필요합니다. 반드시 표준 MRI 구현을 사용해야 합니다. JRuby와 Rubinius를 좋아하지만, GitLab에서는 몇 가지 네이티브 익스텐션을 가진 Gems가 필요합니다. |
| RubyGems | 3.5.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 cloning 및 기타 기능을 유지합니다. -
/home/git/repositories- 모든 프로젝트에 대해 네임스페이스로 구성된 베어 리포지터리입니다. 이 곳은 모든 프로젝트에 대해 푸시/풀된 Git 리포지터리가 유지되는 곳입니다. 프로젝트에 대한 중요한 데이터가 포함되어 있습니다. 백업을 유지하세요.
리포지터리에 대한 기본 위치는 GitLab의 config/gitlab.yml 및 GitLab Shell의 config.yml에서 구성할 수 있습니다.
현재 이러한 디렉터리를 매뉴얼으로 생성할 필요는 없으며, 이렇게 하면 설치 중에 나준에러를 유발할 수 있습니다.
더 자세한 내용은 GitLab architecture 문서에서 확인할 수 있습니다.
개요
GitLab 설치는 다음 컴포넌트를 설정하는 것으로 구성됩니다:
1. 패키지 및 의존성
sudo
Debian에는 기본으로 sudo가 설치되어 있지 않습니다. 시스템을 최신 상태로 유지하고 설치하십시오.
# root로 실행!
apt-get update -y
apt-get upgrade -y
apt-get install sudo -y
빌드 의존성
필요한 패키지를 설치하십시오 (Ruby 및 Ruby gem의 네이티브 익스텐션을 컴파일하기 위해 필요합니다):
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
Git
Gitaly가 제공하는 Git 버전을 사용하여야 합니다:
- 항상 GitLab에서 필요로하는 버전입니다.
- 적절한 작동을 위해 필요한 사용자 정의 패치를 포함할 수 있습니다.
-
필요한 의존성을 설치합니다:
sudo apt-get install -y libcurl4-openssl-dev libexpat1-dev gettext libz-dev libssl-dev libpcre2-dev build-essential git-core -
Gitaly 리포지터리를 복제하고 Git을 컴파일합니다.
16-7-stable와 같은 GitLab 버전과 일치하는 stable branch를 사용하십시오: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
나중에 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, 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.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 자산을 컴파일하려면 Node를, JavaScript 의존성을 관리하려면 Yarn을 필요로 합니다. 현재 이러한 작업에 필요한 최소 요구 사항은 다음과 같습니다:
-
node18.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. 데이터베이스
-
데이터베이스 패키지 설치.
Ubuntu 22.04 이상의 경우:
sudo apt install -y postgresql postgresql-client libpq-dev postgresql-contribUbuntu 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 -
설치한 PostgreSQL 버전이 설치 중인 GitLab 버전에서 지원되는지 확인하세요:
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
# redis 그룹에 git 추가
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
# 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
원하는 버전에 해당하는 안정적인 브랜치로 <X-Y-stable>을 대체하십시오. 예를 들어, 11.8을 설치하려면 브랜치 이름을 11-8-stable로 사용해야 합니다.
<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
# 예제 secrets 파일 복사
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 artifacts가 저장되는 디렉터리의 권한 변경
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
# 사용하는 Redis 소켓 경로가 기본 Debian / Ubuntu 구성과 다른 경우 Redis 소켓 경로 변경
sudo -u git -H editor config/resque.yml config/cable.yml
설정에 맞게 gitlab.yml 및 puma.rb를 편집하십시오.
HTTPS를 사용하려면 HTTPS 사용에서 추가 단계를 확인하십시오.
GitLab DB 설정 구성
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 settings (첫 부분)을 적응하십시오.
# 데이터베이스 가이드에 따라 설정한 경우 다음을 수행하십시오:
# 'secure password'를 $password에 지정된 값으로 변경하십시오.
# password 주변에는 이중 따옴표를 유지할 수 있습니다.
sudo -u git -H editor config/database.yml
# config/database.yml에서 `ci:` 섹션 주석 제거
# `ci:`의 `database` 값이 `main:`의 `database` 값과 일치하는지 확인.
# Ensure the `database` value in `ci:` matches the database value in `main:`.
sudo -u git -H chmod o-rwx config/database.yml
젬 설치
bundle install -jN (여기서 N은 프로세서 코어의 수입니다)을 호출하여 병렬 젬 설치를 활용하고 완료 시간에 현저한 차이를 느낄 수 있습니다(~60% 빨라짐). nproc으로 코어 수를 확인하세요. 자세한 내용은 이 포스트를 참조하세요.bundle가 있는지 확인하세요 (bundle -v 실행):
만약 사용자 인증에 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 호스트 이름”). 예를 들어, 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 설치
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가 서비스 감독의 표준이며 모든 주요 리눅스 배포판에서 사용되기 때문에 기본적으로 체제를 사용해야 합니다. 자동 재시작, 더 나은 샌드박싱 및 자원 제어를 위해 systemd 서비스를 사용하세요.
systemd 단위 설치
시스템드가 이니셜라이저로 사용된다면 이 단계를 따르세요. 그렇지 않으면 SysV init 스크립트 단계를 따르세요.
서비스를 복사하고 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/<단위 이름>.d/override.conf에 드롭인 구성 파일을 설치합니다. 드롭인 구성 파일을 분리하려면 .conf 파일에 위의 스니펫들을 추가하세요.
단위 파일을 매뉴얼으로 변경하거나 systemctl edit를 사용하지 않고 드롭인 구성 파일을 추가한 경우(사용하지 않은 경우), 효력을 발휘하도록 다음 명령을 실행하세요:
sudo systemctl daemon-reload
GitLab이 부팅될 수 있도록 설정하세요:
sudo systemctl enable gitlab.target
SysV init 스크립트 설치
SysV init 스크립트를 사용하는 경우 이 단계를 사용하십시오. systemd를 사용하는 경우 systemd unit steps을(를) 따르십시오.
init 스크립트를 다운로드합니다 (/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
Logrotate 설정
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:'을 볼 수 있습니다.
환경 변수를 제공하여 관리자/root 암호와 이메일을 설정할 수 있습니다. 암호를 설정하지 않는 경우(기본 암호로 설정된 경우), 설치가 완료되고 서버에 처음으로 로그인한 후 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 recipes를 참조하십시오.
설치
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를 제거하거나 else sudo rm -f /etc/nginx/sites-enabled/default 명령을 실행하십시오
sudo editor /etc/nginx/sites-available/gitlab
GitLab Pages를 활성화하려는 경우 별도의 NGINX 구성 파일을 사용해야 합니다. 필요한 구성에 대해서는 GitLab Pages administration guide를 참조하십시오.
HTTPS를 사용하려는 경우 gitlab NGINX 구성을 gitlab-ssl로 대체하십시오. HTTPS 구성 세부 정보는 HTTPS 사용를 참조하십시오.
NGINX가 GitLab-Workhorse 소켓을 읽을 수 있도록 하려면, GitLab 사용자의 소켓을 읽을 수 있는 www-data 사용자를 확인해야 합니다. 이는 기본적으로 소켓이 공개 읽기 가능하도록 설정된 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을 성공적으로 설치했다고 축하드립니다!
gitlab:check에 SANITIZE=true 환경 변수를 제공하여 출력에서 프로젝트 이름을 제외할 수 있습니다.초기 로그인
처음 GitLab에 로그인하려면 웹 브라우저에서 YOUR_SERVER를 방문하십시오.
설치 과정 중에 root 암호를 제공하지 않은 경우 초기 관리자 계정의 암호를 제공하도록 초기화된 암호 재설정 화면으로 이동합니다. 원하는 암호를 입력한 후 다시 로그인 화면으로 리디렉션됩니다.
기본 계정의 사용자 이름은 root입니다. 이전에 생성한 암호를 제공하고 로그인합니다. 로그인한 후에는 원하는대로 사용자 이름을 변경할 수 있습니다.
즐겁게 사용하세요!
다음과 같은 경우 GitLab을 시작하고 중지할 수 있습니다:
-
sudo systemctl start gitlab.target또는sudo systemctl stop gitlab.target을 사용하여 systemd 유닛을 실행하는 시스템의 경우. - SysV init 스크립트를 실행 중인 경우
sudo service gitlab start또는sudo service gitlab stop을 사용하십시오.
권장 다음 단계
설치를 완료한 후 인증 옵션 및 가입 제한 사항을 포함한 추천 다음 단계를 고려해 보세요.
고급 설정 팁
상대 URL 지원
상대 URL로 GitLab을 구성하는 방법에 대한 자세한 내용은 상대 URL 문서를 참조하십시오.
HTTPS 사용
HTTPS를 사용하려면:
-
gitlab.yml에서:- 섹션 1의
port옵션을443으로 설정합니다. - 섹션 1의
https옵션을true로 설정합니다.
- 섹션 1의
- GitLab Shell의
config.yml에서:-
gitlab_url옵션을 GitLab의 HTTPS 엔드포인트로 설정합니다(예:https://git.example.com). -
ca_file또는ca_path옵션을 사용하여 인증서를 설정합니다.
-
-
gitlab-sslNGINX 예제 구성을 사용합니다.-
YOUR_SERVER_FQDN을 업데이트합니다. -
ssl_certificate및ssl_certificate_key를 업데이트합니다. - 구성 파일을 검토하고 다른 보안 및 성능 향상 기능을 적용을 고려해 보세요.
-
자체 서명된 인증서를 사용하는 것은 권장하지 않습니다. 그럼에도 사용해야 한다면 표준 지침을 따르고 자체 서명 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 서버를 소켓을 통해 연결하려면 config/resque.yml 파일에서 unix: URL 체계와 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)을 변경해야 합니다.
추가 마크업 스타일
GitLab은 항상 지원되는 Markdown 스타일 외에도 다른 리치 텍스트 파일을 표시할 수 있습니다. 그러나 이를 위해 의존성을 설치해야 할 수 있습니다. 자세한 내용은 github-markup gem README를 참조하십시오.
프로메테우스 서버 설정
config/gitlab.yml에서 프로메테우스 서버를 구성할 수 있습니다.
# 예시
prometheus:
enabled: true
server_address: '10.1.2.3:9090'
문제 해결
“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이 메모리를 소진하여 컨테이너를 종료할 때 발생할 수 있습니다. 이를 해결하려면:
-
시스템 메모리를 적어도 8GB로 늘립니다.
-
다음 명령을 실행하여 에셋을 정리합니다:
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
도움말