유지 보수 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 사용:      아니요
Ruby 버전:   2.7.6p219
Gem 버전:    3.1.6
Bundler 버전: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 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

각 컴포넌트가 설치 가이드에 따라 설정되었는지 확인하고 발견된 문제에 대한 수정 사항을 제안합니다. 이 명령은 애플리케이션 서버에서 실행해야 하며 Gitaly와 같은 구성 서버에서 정상적으로 작동하지 않습니다. Geo를 실행 중인 경우 Geo Health check Rake 작업도 참조하십시오.

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

또한 현재 비밀로 값을 복호화할 수 있는지 확인하려면 데이터베이스 값을 검증해야 합니다.

gitlab:check를 실행하려면 다음을 실행하십시오:

  • Linux 패키지 설치:

    sudo gitlab-rake gitlab:check
    
  • 자체 컴파일된 설치:

    bundle exec rake gitlab:check RAILS_ENV=production
    

프로젝트 이름을 출력에서 생략하려면 SANITIZE=truegitlab:check에 사용하십시오.

예시 출력:

환경 확인 중 ...

git 사용자용 git 구성? ... 예
python2를 사용 중? ... 예
python2는 지원되는 버전? ... 예

환경 확인 중 ... 완료

GitLab Shell 확인 중 ...

GitLab Shell 버전? ... OK (1.2.0)
리포지터리 기본 디렉터리는 존재합니다? ... 예
리포지터리 기본 디렉터리가 심볼릭 링크입니까? ... 아니요
리포지터리 기본 디렉터리가 git:git 소유입니까? ... 예
리포지터리 기본 디렉터리 접근 권한은 drwxrws---입니까? ... 예
post-receive 후크가 최신 상태입니까? ... 예
리포지터리의 post-receive 후크는 링크입니다: ... 예

GitLab Shell 확인 중 ... 완료

Sidekiq 확인 중 ...

실행 중? ... 예

Sidekiq 확인 중 ... 완료

GitLab App 확인 중...

DB 구성이 존재합니다? ... 예
DB는 SQLite가 아닙니다 ... 아니요
모든 마이그레이션이 완료됨? ... 예
GitLab 구성이 존재합니다? ... 예
GitLab 구성이 최신 상태인가? ... 아니요
케이블 구성이 존재합니다? ... 예
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 패키지 설치:

    sudo gitlab-rake cache:clear
    
  • 자체 컴파일된 설치:

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

자산 사전 컴파일

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

이 Rake 작업은 자체 컴파일된 설치에만 해당됩니다. 리눅스 패키지를 실행할 때 문제가 발생하면 자산 파일이 누락된 경우 에 대한 문제 해결에 대해 더 읽어보세요. 일반적으로 리눅스 패키지는 누락된 자산 문제가 발생하지 않지만 Kubernetes 및 Docker 배포의 GitLab에 대해서는 유사하게 적용될 수 있습니다. 일반적으로 컨테이너 기반 설치에서는 자산이 누락되는 문제가 발생하지 않습니다.

  • 자체 컴파일된 설치:

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

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

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

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

  • 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)를 사용하여 공유 리소스에서 동시 작업을 방지합니다. 예를 들어 리포지터리에서 주기적으로 가비지 수집을 실행하는 것입니다.

매우 특정한 상황에서, 독점 임대에 의해 잠겨 있는 작업이 잠금을 해제하지 않고 실패할 수 있습니다. 이를 기다릴 수 없는 경우 매뉴얼으로 해제하기 위해 이 작업을 실행할 수 있습니다.

모든 독점 임대를 해제하려면:

caution
GitLab이나 Sidekiq이 실행 중일 때는 실행하지 마십시오.
sudo gitlab-rake gitlab:exclusive_lease:clear

임대 type 또는 임대 type + id를 지정하려면 scope를 지정합니다.

# 리포지터리 가비지 수집을 위한 모든 임대를 지우려면:
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:*]

# 특정 프로젝트에서 리포지터리 가비지 수집 임대를 지우려면: (id=4)
sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]

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

GitLab을 업그레이드할 때 마이그레이션이 완료되었는지 확인하는 방법에 대한 문서 백그라운드 마이그레이션을 참조하세요.

특정 마이그레이션 상태를 확인하려면 다음과 같은 Rake task를 사용할 수 있습니다.

sudo gitlab-rake db:migrate:status

Geo 보조 사이트의 추적 데이터베이스를 확인하려면 다음과 같은 Rake task를 사용할 수 있습니다.

sudo gitlab-rake db:migrate:status:geo

이는 각 마이그레이션 ID에 대한 Statusup 또는 down을 출력하는 표를 생성합니다.

database: gitlabhq_production
 
 Status   Migration ID    Migration Name
--------------------------------------------------
   up     migration_id    migration_name

미완료 데이터베이스 마이그레이션 실행

데이터베이스 마이그레이션은 sudo gitlab-rake db:migrate:status 명령의 출력에서 down 상태로 남아 있는 미완료 상태에 갇힐 수 있습니다.

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

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

  3. pumasidekiq 서비스를 핫 리로드하세요:

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

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

Status: 실험
caution
이 기능은 실험적이며 기본적으로 사용되지 않습니다. 프로덕션 환경에서 실행할 때 주의하십시오. 유동 시간이 적은 시간에 실행하세요.

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

전제 조건:

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

매뉴얼으로 데이터베이스 인덱스를 재구축하려면:

  1. 선택 사항. Grafana(4.6 이상) 엔드포인트로 주석을 보내려면 사용자 지정 환경 변수를 사용하여 주석을 활성화합니다(사용자 정의 환경 변수 설정 참조):

    1. GRAFANA_API_URL: Grafana의 기본 URL(예: http://some-host:3000).
    2. GRAFANA_API_KEY: 적어도 Editor role이 있는 Grafana API 키.
  2. 두 가장 높은 추정 팽창을 가진 두 인덱스를 재구축하기 위해 다음과 같은 Rake task를 실행하세요:

    sudo gitlab-rake gitlab:db:reindex
    
  3. 재인덱싱 작업(gitlab:db:reindex)은 각 데이터베이스에서 두 가지 이상의 인덱스만 재구축합니다. 더 많은 인덱스를 재구축하려면 목표하는 모든 인덱스가 재구축될 때까지 작업을 다시 실행하세요.

참고사항

  • 데이터베이스 인덱스 재구축은 디스크 집중적 작업이므로 유동 시간 동안 실행해야 합니다. 피크 시간에 작업 실행은 팽창을 증가시킬 수 있으며 특정 쿼리를 느리게 수행할 수도 있습니다.
  • 작업에는 복원해야 할 인덱스에 대한 무료 디스크 공간이 필요합니다. 생성된 인덱스는 _ccnew로 끝납니다. 재인덱싱 작업에 실패하면 작업을 다시 실행하면 임시 인덱스가 정리됩니다.
  • 데이터베이스 인덱스 재구축이 완료되는 데 필요한 시간은 대상 데이터베이스의 크기에 따라 다릅니다. 몇 시간에서 몇 일이 걸릴 수 있습니다.

데이터베이스 스키마 덤프

드물게 데이터베이스 스키마가 모든 데이터베이스 마이그레이션이 완료되었음에도 응용 프로그램 코드가 예상하는 것과 다를 수 있습니다. 이런 경우 GitLab에서 이상한 오류가 발생할 수 있습니다.

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

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

Rake task는 데이터베이스 스키마 덤프를 포함하는 /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. 버전에 대한 db/structure.sql 파일과 /tmp/structure.sql을 비교합니다.

공통 메트릭스 가져오기

가끔은 메트릭스 대시보드를 지원하는 공통 메트릭스를 다시 가져와야 할 수 있습니다.

이는 기존 메트릭스 업데이트의 결과로 발생할 수 있습니다.

메트릭스를 다시 가져오려면 다음과 같이 실행할 수 있습니다:

sudo gitlab-rake metrics:setup_common_metrics

문제 해결

조언적인 락 연결 정보

db:migrate Rake task를 실행한 후 다음과 같은 출력을 볼 수 있습니다:

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 task를 실행할 때 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 task는 GitLab Rails를 실행 중인 노드에서만 실행해야 하기 때문입니다.