유지 보수 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 라이선스 및 사용 중인 seats에 대한 정보를 표시합니다. 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 task도 참고하십시오.

아울러 다음을 위한 문제 해결 가이드를 확인할 수 있습니다:

또한 현재의 secrets를 사용하여 데이터베이스 값이 해독될 수 있는지 확인하려면 데이터베이스 값이 현재의 secrets를 사용하여 해독될 수 있는지 확인하십시오.

gitlab:check 실행 방법:

  • Linux 패키지 설치: 

    sudo gitlab-rake gitlab:check

  • 자체 컴파일된 설치: 

    bundle exec rake gitlab:check RAILS_ENV=production

gitlab:check에 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 App 확인 중...

데이터베이스 구성이 존재? ... 예
데이터베이스는 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 파일에 저장된 모든 데이터가 손실될 수 있습니다.
계속 하시겠습니까 (예/아니오)? 예

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 작업은 자체 컴파일 설치에만 적용됩니다. 리눅스 패키지를 실행할 때 이 문제가 발생하면 추가 알아보기 링크를 참고하세요. 리눅스 패키지 설치에 대한 안내는 일반적으로 컨테이너 기반 설치에서 문제가 생기지 않지만, GitLab의 Kubernetes 및 Docker 배포에 적용될 수 있습니다.

  • 자체 컴파일 설치: 

    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 작업이 포함되어 있습니다.

  • 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’에 의해 잠긴 작업이 락을 해제하지 않고 실패할 수 있습니다. 만약 락이 만료되기를 기다릴 수 없다면, 이 작업을 매뉴얼으로 클리어하는 데 도움을 주는 작업을 실행할 수 있습니다.

모든 전용 락을 지우려면:

caution
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 secondary site의 트래킹 데이터베이스를 확인하려면 다음 Rake 작업을 사용할 수 있습니다: 

sudo gitlab-rake db:migrate:status:geo

이는 각 마이그레이션 ID에 대한 상태가 up 또는 down으로 출력됩니다. 

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

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

데이터베이스 마이그레이션은 down 상태로 고정된 불완전한 상태에 갇힐 수 있습니다. 이러한 마이그레이션을 완료하려면 다음 Rake 작업을 사용하십시오:

  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

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

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. 자신의 버전에 대한 db/structure.sql 파일과 /tmp/structure.sql을 비교하세요.

공통 지표 가져오기

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

이는 기존 메트릭을 업데이트하는 결과일 수 있습니다.

메트릭을 다시 가져오려면 다음 명령을 실행할 수 있습니다: 

sudo gitlab-rake metrics:setup_common_metrics

문제 해결

자문 잠금 연결 정보

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