Redis 비감시 실행#

시스템이 SysV init을 사용하는 경우 다음 명령어를 실행합니다:

# Create the directory which contains the socket
sudo mkdir -p /var/run/redis
sudo chown redis:redis /var/run/redis
sudo chmod 755 /var/run/redis

# Persist the directory which contains the socket, if applicable
if [ -d /etc/tmpfiles.d ]; then
  echo 'd  /var/run/redis  0755  redis  redis  10d  -' | sudo tee -a /etc/tmpfiles.d/redis.conf
fi

# Activate the changes to redis.conf
sudo service redis-server restart

9. GitLab#

# We'll install GitLab into the home directory of the user "git"
cd /home/git

소스 클론#

Community Edition 클론:

# Clone GitLab repository
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-foss.git -b <X-Y-stable> gitlab

Enterprise Edition 클론:

# Clone GitLab repository
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`를 설치하지 마세요!

설정하기#

# Go to GitLab installation folder
cd /home/git/gitlab

# Copy the example GitLab config
sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml

# Update GitLab config file, follow the directions at top of the file
sudo -u git -H editor config/gitlab.yml

# Copy the example secrets file
sudo -u git -H cp config/secrets.yml.example config/secrets.yml
sudo -u git -H chmod 0600 config/secrets.yml

# Make sure GitLab can write to the log/ and tmp/ directories
sudo chown -R git log/
sudo chown -R git tmp/
sudo chmod -R u+rwX,go-w log/
sudo chmod -R u+rwX tmp/

# Make sure GitLab can write to the tmp/pids/ and tmp/sockets/ directories
sudo chmod -R u+rwX tmp/pids/
sudo chmod -R u+rwX tmp/sockets/

# Create the public/uploads/ directory
sudo -u git -H mkdir -p public/uploads/

# Make sure only the GitLab user has access to the public/uploads/ directory
# now that files in public/uploads are served by gitlab-workhorse
sudo chmod 0700 public/uploads

# Change the permissions of the directory where CI job logs are stored
sudo chmod -R u+rwX builds/

# Change the permissions of the directory where CI artifacts are stored
sudo chmod -R u+rwX shared/artifacts/

# Change the permissions of the directory where GitLab Pages are stored
sudo chmod -R ug+rwX shared/pages/

# Copy the example Puma config
sudo -u git -H cp config/puma.rb.example config/puma.rb

# Refer to https://github.com/puma/puma#configuration for more information.
# You should scale Puma workers and threads based on the number of CPU
# cores you have available. You can get that number via the `nproc` command.
sudo -u git -H editor config/puma.rb

# Configure Redis connection settings
sudo -u git -H cp config/resque.yml.example config/resque.yml
sudo -u git -H cp config/cable.yml.example config/cable.yml

# Change the Redis socket path if you are not using the default Debian / Ubuntu configuration
sudo -u git -H editor config/resque.yml config/cable.yml

설정에 맞게 gitlab.yml과 puma.rb 모두 편집하세요.

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

GitLab DB 설정 구성#

[GitLab 15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/387898)부터 `main:` 섹션만 있는 `database.yml`은 더 이상 사용되지 않습니다.

GitLab 17.0 이상에서는 database.yml에 main:과 ci: 두 섹션이 반드시 있어야 합니다.

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

# Remove host, username, and password lines from config/database.yml.
# Once modified, the `production` settings will be as follows:
#
#   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

# Remote PostgreSQL only:
# Update username/password in config/database.yml.
# You only need to adapt the production settings (first part).
# If you followed the database guide then please do as follows:
# Change 'secure password' with the value you have given to $password
# You can keep the double quotes around the password
sudo -u git -H editor config/database.yml

# Uncomment the `ci:` sections in config/database.yml.
# Ensure the `database` value in `ci:` matches the database value in `main:`.

# Make config/database.yml readable to git only
sudo -u git -H chmod o-rwx config/database.yml

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

Gem 설치#

Bundler 1.5.2부터 `bundle install -jN` (여기서 `N`은 프로세서 코어 수)을 실행하여 병렬 젬 설치를 즐길 수 있으며, 완료 시간에 측정 가능한 차이가 있습니다 (약 60% 빠름). `nproc`으로 코어 수를 확인하세요. 자세한 내용은 이 [게시물](https://thoughtbot.com/blog/parallel-gem-installing-using-bundler)을 참조하세요.

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 Shell 설치#

GitLab Shell은 GitLab을 위해 특별히 개발된 SSH 접근 및 리포지터리 관리 소프트웨어입니다.

# Run the installation task for gitlab-shell:
sudo -u git -H bundle exec rake gitlab:shell:install RAILS_ENV=production

# By default, the gitlab-shell config is generated from your main GitLab config.
# You can review (and modify) the gitlab-shell config as follows:
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

Enterprise Edition에서 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 데몬이 여러 다른 방법으로 실행될 수 있으므로 GitLab 버전에 맞는 관리 가이드를 참조하세요.

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 설치#

# Create and restrict access to the git repository data directory
sudo install -d -o git -m 0700 /home/git/repositories

# Fetch Gitaly source with Git and compile with 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가 설정되어 있는지 확인합니다:

# Restrict Gitaly socket access
sudo chmod 0700 /home/git/gitlab/tmp/sockets/private
sudo chown git /home/git/gitlab/tmp/sockets/private

# If you are using non-default settings, you need to update 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 스크립트 단계를 따르세요.

서비스를 복사하고 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을 다른 디렉터리에 설치하거나 기본값 이외의 사용자로 설치한 경우, 유닛에서도 이 값들을 변경해야 합니다.

예를 들어, GitLab과 동일한 머신에서 Redis와 PostgreSQL을 실행하는 경우 다음을 수행해야 합니다:

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 init 스크립트 설치#

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

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
# or if running this on a machine running 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
# Type 'yes' to create the database tables.

# or you can skip the question by adding force=yes
sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production force=yes

# When done, you see 'Administrator account created:'

환경 변수 GITLAB_ROOT_PASSWORD와 GITLAB_ROOT_EMAIL로 관리자/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 인스턴스 시작#

# For systems running systemd
sudo systemctl start gitlab.target

# For systems running 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 경로가 일치하는지 확인하세요:

# Change YOUR_SERVER_FQDN to the fully-qualified
# domain name of your host serving GitLab.
#
# Remember to match your paths to GitLab, especially
# if installing for a user other than 'git'.
#
# If using Ubuntu default nginx install:
# either remove the default_server from the listen line
# or else 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 사용자가 소유한 소켓을 읽을 수 있어야 합니다. 이는 소켓이 world-readable인 경우, 예를 들어 기본값인 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

재시작#

# For systems running systemd
sudo systemctl restart nginx.service

# For systems running SysV init
sudo service nginx restart

설치 후 작업#

애플리케이션 상태 재확인#

놓친 것이 없는지 더 철저한 확인을 실행합니다:

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

모든 항목이 녹색이라면, GitLab 설치를 성공적으로 완료한 것을 축하합니다!

확인 명령어 출력에서 프로젝트 이름을 생략하려면 `gitlab:check`에 `SANITIZE=true` 환경 변수를 제공하세요.

초기 로그인#

웹 브라우저에서 YOUR_SERVER를 방문하여 처음으로 GitLab에 로그인하세요.

설정 중 root 비밀번호를 제공하지 않은 경우, 초기 관리자 계정의 비밀번호를 설정하기 위한 비밀번호 재설정 화면으로 리디렉션됩니다. 원하는 비밀번호를 입력하면 로그인 화면으로 다시 리디렉션됩니다.

기본 계정의 사용자명은 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 사용하기#

GitLab에 HTTPS를 사용하려면:

• gitlab.yml에서:

섹션 1의 port 옵션을 443으로 설정합니다.

• 섹션 1의 https 옵션을 true로 설정합니다.

• GitLab Shell의 config.yml에서:

gitlab_url 옵션을 GitLab의 HTTPS 엔드포인트로 설정합니다 (예: https://git.example.com).

• ca_file 또는 ca_path 옵션을 사용하여 인증서를 설정합니다.

• gitlab 설정 대신 gitlab-ssl NGINX 예제 설정을 사용합니다.

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은 프로젝트를 빌드할 수 있습니다. 이 기능을 활성화하려면 빌드를 수행할 runner가 필요합니다. 설치 방법은 GitLab Runner 섹션을 참조하세요.

신뢰할 수 있는 프록시 추가#

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

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

URL에서 잘못 인코딩된 문자 문제가 발생하면 리버스 프록시 사용 시 404 Not Found 오류를 참조하세요.

커스텀 Redis 연결#

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

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

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

# example
production:
  url: unix:/path/to/redis/socket

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

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

커스텀 SSH 연결#

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

# Add to /home/git/.ssh/config
host localhost          # Give your setup a name (here: override localhost)
    user git            # Your remote git user
    port 2222           # Your port number
    hostname 127.0.0.1; # Your server name or IP

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

추가 마크업 스타일#

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

Prometheus 서버 설정#

config/gitlab.yml에서 Prometheus 서버를 설정할 수 있습니다:

# example
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

# Only one of the following two commands will print something. It
# will look like: * 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이 종료할 때 발생할 수 있습니다. 이를 해결하려면:

시스템 메모리를 최소 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