유지보수 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
Proxy:          no
현재 사용자:   git
RVM 사용:      no
루비 버전:   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 Clone URL: https://app.gitaly.gcp.gitlabsandbox.net/some-group/some-project.git
SSH Clone URL:  git@app.gitaly.gcp.gitlabsandbox.net:some-group/some-project.git
Elasticsearch:  no
Geo:            no
LDAP 사용:     no
Omniauth 사용: yes
Omniauth 제공자:

GitLab Shell
버전:        14.12.0
저장소 저장 위치:
- 기본:      /var/opt/gitlab/git-data/repositories
- gitaly:       /var/opt/gitlab/git-data/repositories
GitLab Shell 경로:              /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 Enterprise 설치에서만 사용할 수 있으며 GitLab Community Edition에는 라이선스를 설치할 수 없습니다.

지원팀에 티켓을 열거나 라이선스 매개변수를 프로그래밍적으로 확인할 때 유용할 수 있습니다.

  • 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를 실행하려면:

  • Linux 패키지 설치: 

    sudo gitlab-rake gitlab:check

  • 자체 컴파일 설치: 

    bundle exec rake gitlab:check RAILS_ENV=production

프로젝트 이름을 출력에서 생략하려면 SANITIZE=true를 사용하세요.

예시 출력: 

환경 확인 중 ...

git 사용자에 대해 Git이 구성되었나요? ... 예
python2가 있나요? ... 예
python2는 지원되는 버전인가요? ... 예

환경 확인 ... 완료

GitLab Shell 확인 중...

GitLab Shell 버전? ... OK (1.2.0)
저장소 기본 디렉토리가 존재하는가? ... 예
저장소 기본 디렉토리가 심볼릭 링크인가? ... 아니요
저장소 기본 디렉토리의 소유자가 git:git인가? ... 예
저장소 기본 디렉토리 접근 권한이 drwxrws---인가? ... 예
post-receive 후크가 최신인가? ... 예
저장소의 post-receive 후크는 링크인가: ... 예

GitLab Shell 확인 ... 완료

Sidekiq 확인 중...

실행 중? ... 예

Sidekiq 확인 ... 완료

GitLab 앱 확인 중...

데이터베이스 구성이 있는가? ... 예
데이터베이스가 SQLite인가? ... 아니요
모든 마이그레이션이 완료되었는가? ... 예
GitLab 구성이 있는가? ... 예
GitLab 구성이 최신 상태인가? ... 아니요
Cable 구성이 있는가? ... 예
Resque 구성이 있는가? ... 예
로그 디렉토리에 기록할 수 있는가? ... 예
임시 디렉토리에 기록할 수 있는가? ... 예
초기 스크립트가 있는가? ... 예
초기 스크립트가 최신 상태인가? ... 예
Redis 버전 >= 2.0.0? ... 예

GitLab 확인 ... 완료

authorized_keys 파일 다시 빌드

일부 경우에는 authorized_keys 파일을 다시 빌드해야 할 수 있습니다. 예를 들어, 업그레이드 후 SSH를 통해 푸시할 때 Permission denied (publickey) 오류가 발생하고 gitlab-shell.log 파일에서 404 Key Not Found 오류를 찾은 경우입니다. authorized_keys를 다시 빌드하려면 다음을 실행하세요:

  • Linux 패키지 설치: 

    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 파일에 저장된 모든 데이터가 손실됩니다.
계속하시겠습니까 (예/아니요)? yes


## Redis 캐시 지우기

대시보드에 잘못된 정보가 표시되는 경우, Redis의 캐시를 지우고 싶을 수 있습니다. 이를 위해 다음을 실행하세요.

- Linux 패키지 설치:

  ```shell
  sudo gitlab-rake cache:clear

  • 직접 컴파일한 설치: 

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

에셋 사전 컴파일

때때로 버전 업그레이드 중에 잘못된 CSS가 생성되거나 일부 아이콘이 누락될 수 있습니다. 이 경우, 에셋을 다시 사전 컴파일해 보세요.

이 Rake 작업은 직접 컴파일한 설치에만 적용됩니다. Linux 패키지를 실행하는 경우에 이 문제를 해결하는 데 도움이 되는 자세한 정보를 확인하세요. Linux 패키지 설치에대한 안내는 GitLab의 Kubernetes 및 Docker 배포에도 적용될 수 있지만 일반적으로 컨테이너 기반 설치는 잃어버린 에셋 문제가 없습니다.

  • 직접 컴파일한 설치: 

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

Linux 패키지 설치의 경우, 최적화되지 않은 에셋(JavaScript, CSS)은 upstream GitLab 릴리스에서 고정됩니다. Linux 패키지 설치에는 해당 에셋의 최적화된 버전이 포함되어 있습니다. 패키지를 설치한 후에 프로덕션 머신에서 JavaScript/CSS 코드를 수정하지 않는 한, 프로덕션 머신에서 rake gitlab:assets:compile을 다시 실행할 필요가 없어야 합니다. 에셋이 손상되었다고 의심되는 경우 Linux 패키지를 재설치해야 합니다.

원격 사이트로의 TCP 연결 확인

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

  • Linux 패키지 설치: 

    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

특정 유형 또는 유형 + 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

이는 각 마이그레이션에 대한 Status가 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. 명령이 완료되면 모든 마이그레이션이 완료되었는지 (up 상태인지) 확인하려면 sudo gitlab-rake db:migrate:status 명령을 실행하세요.

  3. puma 및 sidekiq 서비스를 핫 리로드하기: 

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

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

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

Status: Experiment

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

데이터베이스 인덱스는 정기적으로 재구축하여 공간을 회수하고 시간이 지남에 따라 색인 팽창의 건강한 수준을 유지할 수 있습니다. Reindexing은 또한 정기적인 cron 작업으로 실행할 수도 있습니다. “건강한” 팽창 수준은 특정 인덱스에 매우 의존적이지만 일반적으로 30% 미만이어야 합니다.

전제 조건:

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

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

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

    1. GRAFANA_API_URL: http://some-host:3000과 같은 Grafana의 기본 URL.
    2. GRAFANA_API_KEY: 최소한 Editor 역할을 갖는 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

문제 해결

Advisory lock connection 정보

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나 다른 비-레일즈 노드에서 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 레일즈를 실행 중인 노드에서만 실행되어야 합니다.