유지 관리 Rake 작업

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

GitLab은 일반 유지 관리를 위한 Rake 작업을 제공합니다.

GitLab 및 시스템 정보 수집

이 명령은 GitLab 설치 및 실행 중인 시스템에 대한 정보를 수집합니다.
이 정보는 도움을 요청하거나 문제를 보고할 때 유용할 수 있습니다.
다중 노드 환경에서는 PostgreSQL 소켓 오류를 피하기 위해 GitLab Rails를 실행 중인 노드에서 이 명령을 실행하세요.

  • Linux 패키지 설치:

    sudo gitlab-rake gitlab:env:info

  • 직접 컴파일한 설치:

    bundle exec rake gitlab:env:info RAILS_ENV=production

예제 출력:

시스템 정보  
시스템:         Ubuntu 20.04  
프록시:          아니오  
현재 사용자:   git  
RVM 사용:      아니오  
루비 버전:   2.7.6p219  
젬 버전:    3.1.6  
번들러 버전:2.3.15  
Rake 버전:   13.0.6  
Redis 버전:  6.2.7  
Sidekiq 버전:6.4.2  
Go 버전:     알 수 없음  

GitLab 정보  
버전:        15.5.5-ee  
리비전:       5f5109f142d  
디렉터리:      /opt/gitlab/embedded/service/gitlab-rails  
DB 어댑터:     PostgreSQL  
DB 버전:     13.8  
URL:            https://app.gitaly.gcp.gitlabsandbox.net  
HTTP 클론 URL: https://app.gitaly.gcp.gitlabsandbox.net/some-group/some-project.git  
SSH 클론 URL:  git@app.gitaly.gcp.gitlabsandbox.net:some-group/some-project.git  
Elasticsearch:  아니오  
Geo:            아니오  
LDAP 사용:     아니오  
Omniauth 사용: 예  
Omniauth 공급자:  

GitLab 셸  
버전:        14.12.0  
저장소 저장 경로:  
- 기본:      /var/opt/gitlab/git-data/repositories  
- gitaly:       /var/opt/gitlab/git-data/repositories  
GitLab 셸 경로:              /opt/gitlab/embedded/service/gitlab-shell  

Gitaly  
- 기본 주소:      unix:/var/opt/gitlab/gitaly/gitaly.socket  
- 기본 버전:      15.5.5  
- 기본 Git 버전:  2.37.1.gl1  
- gitaly 주소:       tcp://10.128.20.6:2305  
- gitaly 버전:       15.5.5  
- gitaly Git 버전:   2.37.1.gl1

GitLab 라이선스 정보 표시

Tier: Premium, Ultimate Offering: Self-managed

이 명령은 GitLab 라이선스 및
사용된 좌석 수에 대한 정보를 표시합니다. GitLab 엔터프라이즈
설치에서만 사용할 수 있습니다: 라이선스는 GitLab 커뮤니티 에디션에 설치할 수 없습니다.

이 정보는 지원에 티켓을 제기할 때나 프로그래밍 방식으로
라이선스 매개변수를 확인할 때 유용할 수 있습니다.

  • Linux 패키지 설치:

    sudo gitlab-rake gitlab:license:info

  • 직접 컴파일한 설치:

    bundle exec rake gitlab:license:info RAILS_ENV=production

예제 출력:

오늘 날짜: 2020-02-29  
현재 사용자 수: 30  
최대 역사적 수: 30  
라이선스 최대 사용자 수: 40  
라이선스 유효 기간: 2019-11-29부터 2020-11-28까지  
라이선스와 연결된 이메일: user@example.com

GitLab 구성 확인

gitlab:check Rake 작업은 다음 Rake 작업을 실행합니다:

  • gitlab:gitlab_shell:check
  • gitlab:gitaly:check
  • gitlab:sidekiq:check
  • gitlab:incoming_email:check
  • gitlab:ldap:check
  • gitlab:app:check
  • gitlab:geo:check (당신이 Geo를 실행하고 있을 경우에만)

각 구성 요소가 설치 가이드에 따라 설정되었는지 확인하고 발견된 문제에 대한 수정 사항을 제안합니다.

이 명령은 애플리케이션 서버에서 실행해야 하며 Gitaly와 같은 구성 요소 서버에서는 제대로 작동하지 않습니다.

다음에 대한 문제 해결 가이드를 참조할 수도 있습니다:

또한 현재 비밀을 사용하여 데이터베이스 값을 복호화할 수 있는지 확인해야 합니다.

gitlab:check를 실행하려면 다음을 실행하세요:

  • 리눅스 패키지 설치:

    sudo gitlab-rake gitlab:check

  • 자체 컴파일한 설치:

    bundle exec rake gitlab:check RAILS_ENV=production

출력에서 프로젝트 이름을 제외하려면 gitlab:check에 SANITIZE=true를 사용할 수 있습니다.

예시 출력:

환경 확인 중 ...

Git 사용자를 위한 설정이 되었나요? ... yes
python2가 있나요? ... yes
python2가 지원되는 버전인가요? ... yes

환경 확인 중 ... 완료

GitLab Shell 확인 중 ...

GitLab Shell 버전? ... OK (1.2.0)
리포지토리 기본 디렉토리가 존재하나요? ... yes
리포지토리 기본 디렉토리가 심볼릭 링크인가요? ... no
리포지토리 기본 소유자가 git:git인가요? ... yes
리포지토리 기본 접근 권한이 drwxrws---인가요? ... yes
post-receive 훅이 최신인가요? ... yes
리포지토리의 post-receive 훅이 링크인가요? ... yes

GitLab Shell 확인 중 ... 완료

Sidekiq 확인 중 ...

실행 중인가요? ... yes

Sidekiq 확인 중 ... 완료

GitLab 애플리케이션 확인 중...

데이터베이스 설정이 존재하나요? ... yes
데이터베이스가 SQLite인가요 ... no
모든 마이그레이션이 완료되었나요? ... yes
GitLab 설정이 존재하나요? ... yes
GitLab 설정이 최신인가요? ... no
Cable 설정이 존재하나요? ... yes
Resque 설정이 존재하나요? ... yes
로그 디렉토리가 쓸 수 있나요? ... yes
Tmp 디렉토리가 쓸 수 있나요? ... yes
초기화 스크립트가 존재하나요? ... yes
초기화 스크립트가 최신인가요? ... yes
Redis 버전이 >= 2.0.0인가요? ... yes

GitLab 확인 중 ... 완료

authorized_keys 파일 재구성

경우에 따라 authorized_keys 파일을 재구성해야 할 필요가 있습니다.

예를 들어, 업그레이드 후 SSH를 통해 푸시할 때 Permission denied (publickey) 오류가 발생하고 gitlab-shell.log 파일에서 404 Key Not Found 오류를 찾을 때입니다.

authorized_keys를 재구성하려면 다음을 실행하세요:

  • 리눅스 패키지 설치:

    sudo gitlab-rake gitlab:shell:setup

  • 자체 컴파일한 설치:

    cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production

예시 출력:

authorized_keys 파일을 재구성합니다.
authorized_keys 파일에 저장된 모든 데이터가 손실됩니다.
계속하시겠습니까 (예/아니요)? 예

Redis 캐시 비우기

어떤 이유로 대시보드에 잘못된 정보가 표시되면 Redis의 캐시를 비우고 싶을 수 있습니다. 이를 위해 다음 명령어를 실행하세요:

  • 리눅스 패키지 설치:

    sudo gitlab-rake cache:clear

  • 셀프 컴파일 설치:

    cd /home/git/gitlab
sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production

자산 미리 컴파일하기

버전 업그레이드 중에 잘못된 CSS가 생기거나 아이콘이 누락될 수 있습니다. 그런 경우, 자산을 다시 미리 컴파일해보세요.

이 Rake 작업은 셀프 컴파일 설치에만 적용됩니다. 더 알아보기 자산 문제를 해결하는 방법에 대해 리눅스 패키지를 실행할 때 이 문제에 대해 설명합니다.

리눅스 패키지에 대한 지침은 GitLab의 Kubernetes 및 Docker 배포에 적용될 수 있지만, 일반적으로 컨테이너 기반 설치는 자산 누락 문제를 겪지 않습니다.

  • 셀프 컴파일 설치:

    cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production

리눅스 패키지 설치의 경우, 최적화되지 않은 자산(자바스크립트, CSS)은 업스트림 GitLab의 릴리즈 시점에서 동결됩니다. 리눅스 패키지 설치는 이러한 자산의 최적화된 버전을 포함합니다. 패키지를 설치한 후에 프로덕션 머신에서 자바스크립트/CSS 코드를 수정하지 않는다면, 프로덕션 머신에서 rake gitlab:assets:compile을 다시 실행할 이유가 없습니다. 자산이 손상된 것으로 의심되면 리눅스 패키지를 다시 설치해야 합니다.

원격 사이트에 대한 TCP 연결 확인

때때로 GitLab 설치가 다른 머신(예: PostgreSQL 또는 웹 서버)의 TCP 서비스에 연결될 수 있는지 알아야 할 때가 있습니다. 프록시 문제를 해결하기 위해 Rake 작업이 포함되어 있습니다.

  • 리눅스 패키지 설치:

    sudo gitlab-rake gitlab:tcp_check[example.com,80]

  • 셀프 컴파일 설치:

    cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production

독점 잠금 해제 (위험)

GitLab은 공유 리소스에서 동시에 작업이 이루어지지 않도록 하기 위해 ExclusiveLease라는 공유 잠금 메커니즘을 사용합니다. 예를 들어, 리포지토리에서 주기적인 가비지 수집을 실행하는 경우입니다.

특정 상황에서는 Exclusive Lease에 의해 잠금된 작업이 잠금을 해제하지 않고 실패할 수 있습니다. 만약 잠금이 만료될 때까지 기다릴 수 없다면, 이 작업을 실행하여 수동으로 잠금을 해제할 수 있습니다.

모든 독점 잠금을 해제하려면:

경고: GitLab 또는 Sidekiq가 실행 중일 때는 실행하지 마세요.

sudo gitlab-rake gitlab:exclusive_lease:clear

잠금 type 또는 잠금 type + id를 지정하려면 범위를 지정하세요:

# 리포지토리 가비지 수집을 위한 모든 잠금을 해제하려면:
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:*]

# 특정 프로젝트( id=4)의 리포지토리 가비지 수집을 위한 잠금을 해제하려면:
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]

데이터베이스 마이그레이션 상태 표시

GitLab 업그레이드 시 마이그레이션이 완료되었는지 확인하기 위한 백그라운드 마이그레이션 문서를 참조하세요.

특정 마이그레이션의 상태를 확인하려면 다음 Rake 작업을 사용할 수 있습니다:

sudo gitlab-rake db:migrate:status

Geo 보조 사이트에서 추적 데이터베이스 확인을 원한다면 다음 Rake 작업을 사용할 수 있습니다:

sudo gitlab-rake db:migrate:status:geo

이것은 각각의 마이그레이션에 대해 up 또는 down의 상태를 가진 테이블을 출력합니다. 예:

database: gitlabhq_production

 Status   Migration ID    Type     Milestone    Name
--------------------------------------------------
   up     20240701074848  regular  17.2         AddGroupIdToPackagesDebianGroupComponents
   up     20240701153843  regular  17.2         AddWorkItemsDatesSourcesSyncToIssuesTrigger
   up     20240702072515  regular  17.2         AddGroupIdToPackagesDebianGroupArchitectures
   up     20240702133021  regular  17.2         AddWorkspaceTerminationTimeoutsToRemoteDevelopmentAgentConfigs
   up     20240604064938  post     17.2         FinalizeBackfillPartitionIdCiPipelineMessage
   up     20240604111157  post     17.2         AddApprovalPolicyRulesFkOnApprovalGroupRules

GitLab 17.1부터 마이그레이션은 GitLab 릴리즈 주기에 맞는 순서로 실행됩니다.

불완전한 데이터베이스 마이그레이션 실행

데이터베이스 마이그레이션이 불완전 상태에 빠질 수 있으며, sudo gitlab-rake db:migrate:status 명령의 출력에서 down 상태로 표시됩니다.

  1. 이러한 마이그레이션을 완료하려면 다음 Rake 작업을 사용하세요:

    sudo gitlab-rake db:migrate

  2. 명령이 완료되면 sudo gitlab-rake db:migrate:status를 실행하여 모든 마이그레이션이 완료되었는지(up 상태인지) 확인하세요.

  3. puma와 sidekiq 서비스를 핫 리로드합니다:

    sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq

GitLab 17.1부터 마이그레이션은 GitLab 릴리스 주기에 맞춰 순서가 적용되어 실행됩니다.

데이터베이스 인덱스 재구성

Status: Experiment
caution
이 기능은 실험적이며 기본적으로 활성화되어 있지 않습니다. 프로덕션 환경에서 실행할 때 주의하고 비사용 시간 동안 실행하세요.

데이터베이스 인덱스는 정기적으로 재구성하여 공간을 회수하고 인덱스 부풀림을 건강하게 유지할 수 있습니다. 재인덱싱은 또한 정기 크론 작업으로 실행할 수 있습니다. “건강한” 부풀림 수준은 특정 인덱스에 따라 다르지만 일반적으로 30% 이하이어야 합니다.

사전 요구사항:

  • 이 기능은 PostgreSQL 12 이상이 필요합니다.
  • 다음 인덱스 유형은 지원되지 않습니다: 표현 인덱스, 분할 인덱스 및 제약조건 제외에 사용되는 인덱스.

데이터베이스 인덱스를 수동으로 재구성하려면:

  1. 선택 사항. Grafana (4.6 이상) 엔드포인트에 주석을 전송하려면 다음 사용자 지정 환경 변수를 사용하여 주석을 활성화하세요 (자세한 내용은 사용자 지정 환경 변수 설정을 참조):

    1. GRAFANA_API_URL: 예를 들어 http://some-host:3000과 같은 Grafana의 기본 URL입니다.
    2. GRAFANA_API_KEY: 최소 Editor role을 가진 Grafana API 키입니다.

  2. 가장 높은 추정 부풀림을 가진 두 개의 인덱스를 재구성하는 Rake 작업을 실행합니다:

    sudo gitlab-rake gitlab:db:reindex

  3. 재인덱싱 작업(gitlab:db:reindex)은 각 데이터베이스에서 가장 높은 부풀림을 가진 두 개의 인덱스만 재구성합니다. 두 개 이상의 인덱스를 재구성하려면 원하는 모든 인덱스가 재구성될 때까지 작업을 다시 실행하세요.

주의 사항

  • 데이터베이스 인덱스 재구성은 디스크 집약적인 작업이므로 비사용 시간에 수행해야 합니다. 피크 시간에 작업을 실행하면 _부풀림이 증가_할 수 있으며 특정 쿼리의 성능이 느려질 수 있습니다.
  • 작업은 복원하는 인덱스에 대한 여유 디스크 공간이 필요합니다. 생성된 인덱스는 _ccnew로 추가됩니다. 재인덱싱 작업이 실패하면 작업을 다시 실행하여 임시 인덱스를 정리합니다.
  • 데이터베이스 인덱스 재구성이 완료되는 데 걸리는 시간은 대상 데이터베이스의 크기에 따라 다르며, 몇 시간에서 몇 일까지 소요될 수 있습니다.

데이터베이스 스키마 덤프

드물게 데이터베이스 스키마가 모든 데이터베이스 마이그레이션이 완료되었음에도 불구하고 애플리케이션 코드에서 예상하는 것과 다를 수 있습니다. 이러한 일이 발생하면 GitLab에서 이상한 오류가 발생할 수 있습니다.

데이터베이스 스키마를 덤프하려면:

SCHEMA=/tmp/structure.sql gitlab-rake db:schema:dump

Rake 작업은 /tmp/structure.sql 파일을 생성하여 데이터베이스 스키마 덤프를 포함합니다.

차이점을 확인하려면:

  1. gitlab 프로젝트의 db/structure.sql 파일로 이동하세요. 귀하의 GitLab 버전과 일치하는 브랜치를 선택하세요. 예를 들어, GitLab 16.2의 파일: https://gitlab.com/gitlab-org/gitlab/-/blob/16-2-stable-ee/db/structure.sql.
  2. /tmp/structure.sql와 귀하의 버전의 db/structure.sql 파일을 비교하세요.

데이터베이스에서 스키마 불일치 확인

이 Rake 작업은 데이터베이스 스키마에 불일치가 있는지 확인하고 이를 터미널에 출력합니다.

이 작업은 GitLab 지원의 안내에 따라 사용되는 진단 도구입니다.

데이터베이스 불일치는 예상할 수 있으므로, 이 작업을 일상적인 점검에 사용해서는 안 됩니다.

gitlab-rake gitlab:db:schema_checker:run

문제 해결

조언 잠금 연결 정보

db:migrate Rake 작업을 실행한 후에는 다음과 같은 출력이 표시될 수 있습니다:

main: == [advisory_lock_connection] object_id: 173580, pg_backend_pid: 5532
main: == [advisory_lock_connection] object_id: 173580, pg_backend_pid: 5532

반환된 메시지는 정보성으로 무시할 수 있습니다.

gitlab:env:info Rake 작업을 실행할 때 PostgreSQL 소켓 오류

Gitaly 또는 기타 비 Rails 노드에서 sudo gitlab-rake gitlab:env:info를 실행한 후 다음과 같은 오류가 표시될 수 있습니다:

PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/opt/gitlab/postgresql/.s.PGSQL.5432"?

이는 다중 노드 환경에서 gitlab:env:info Rake 작업이 GitLab Rails가 실행되는 노드에서만 실행되어야 하기 때문입니다.