- GitLab 및 시스템 정보 수집
- GitLab 라이선스 정보 표시
- GitLab 구성 확인
authorized_keys
파일 재구축- Redis 캐시 지우기
- 에셋 사전 컴파일
- 원격 사이트로의 TCP 연결 확인
- 독점 레이스 지우기 (위험)
- 데이터베이스 마이그레이션 상태 표시
- 완료되지 않은 데이터베이스 마이그레이션 실행
- 데이터베이스 인덱스 재구축
- 데이터베이스 스키마 덤프
- 공통 메트릭 임포트
- 문제 해결
유지보수 Rake 작업
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 라이선스 정보 표시
- GiLab 12.6에 도입.
- 13.9에서 GitLab 프리미엄으로 이동.
이 명령은 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 task도 참고하십시오.
다음과 같이 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)
오류가 발생하거나 the 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/no)? 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 작업은 직접 컴파일한 설치에만 적용됩니다. Linux 패키지를 실행하는 경우에는 추가 정보를 읽으세요. Linux 패키지에 대한 안내는 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
를 다시 실행할 필요가 없어야 합니다. 에셋이 손상되었다고 의심되는 경우, 해당 패키지를 다시 설치해야 합니다.
원격 사이트로의 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
를 사용하여 공유 리소스에서 동시 작업을 방지하는 공유 잠금 메커니즘을 사용합니다. 예시로는 저장소의 주기적인 가비지 수집이 있습니다.
매우 특수한 상황에서, 독점 레이스에 의해 잠겨 있는 동작이 락을 해제하지 못할 수 있습니다. 이 것이 만료되길 기다릴 수 없다면, 이 작업을 수동으로 지우는 데 이 명령을 실행할 수 있습니다.
모든 독점 레이스를 지우려면:
경고: 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
이 명령은 각 마이그레이션 ID에 대한 상태
가 up
또는 down
인 표를 출력합니다.
database: gitlabhq_production
상태 마이그레이션 ID 마이그레이션 이름
--------------------------------------------------
up migration_id migration_name
완료되지 않은 데이터베이스 마이그레이션 실행
데이터베이스 마이그레이션이 down
상태로 남아 있는 완료되지 않은 상태에 있을 수 있습니다.
-
이러한 마이그레이션을 완료하려면 다음 Rake 작업을 사용하세요:
sudo gitlab-rake db:migrate
-
명령이 완료되면,
sudo gitlab-rake db:migrate:status
를 실행하여 모든 마이그레이션이 완료되었는지 (up
상태인지) 확인하세요. -
puma
및sidekiq
서비스를 재로드하세요:sudo gitlab-ctl hup puma sudo gitlab-ctl restart sidekiq
데이터베이스 인덱스 재구축
경고: 이 기능은 실험적이며 기본적으로 활성화되지 않습니다. 프로덕션 환경에서 실행할 때 주의하고, 오프 피크 시간에 실행하세요.
시간이 지남에 따라 공간을 회수하고 색인 팽창의 건강한 수준을 유지하기 위해 데이터베이스 인덱스를 정기적으로 다시 작성할 수 있습니다. 재색인을 정기적으로 크론 작업으로 실행할 수도 있습니다. “건강한” 색인 팽방의 수준은 특정 색인에 매우 의존적이지만, 일반적으로 30% 미만이어야 합니다.
필수 구성 요소:
- 이 기능은 PostgreSQL 12 이상을 필요로 합니다.
- 이러한 색인 유형은 지원되지 않습니다: 표현 색인, 분할된 색인, 제약 조건용으로 사용되는 색인
데이터베이스 인덱스를 수동으로 다시 작성하려면:
-
선택 사항. Grafana (4.6 이상) 엔드포인트로 주석을 보내려면 다음 사용자 정의 환경 변수를 활성화하세요(자세한 내용은 사용자 정의 환경 변수 설정 참조):
-
GRAFANA_API_URL
: ‘http://some-host:3000’과 같은 Grafana의 기본 URL -
GRAFANA_API_KEY
: 적어도 ‘Editor’ 역할을 가진 Grafana API 키
-
-
두 가장 높은 추정 색인 팽창으로 색인을 다시 작성하기 위해 Rake 작업을 실행하세요:
sudo gitlab-rake gitlab:db:reindex
-
재색인 작업 (
gitlab:db:reindex
)은 각 데이터베이스의 두 가장 높은 팽창을 가진 색인만 다시 작성합니다. 두 개 이상의 색인을 다시 작성하려면 모든 원하는 색인이 다시 작성될 때까지 작업을 다시 실행하세요.
참고 사항
- 데이터베이스 인덱스를 다시 작성하는 것은 디스크 집약적인 작업이므로 반드시 오프 피크 시간에 작업을 수행해야 합니다. 피크 시간에 작업을 실행하면 _팽창이 증가_하고, 일부 쿼리가 느리게 실행될 수도 있습니다.
- 작업은 복원 중인 색인의 무료 디스크 공간을 필요로 합니다. 생성된 색인은
_ccnew
로 끝납니다. 재색인 작업이 실패하면 작업을 다시 실행하여 임시 색인을 정리할 수 있습니다. - 데이터베이스 인덱스 재구축이 완료되기까지 걸리는 시간은 대상 데이터베이스의 크기에 따라 다릅니다. 몇 시간부터 몇 일까지 걸릴 수 있습니다.
데이터베이스 스키마 덤프
드물게, 데이터베이스 스키마가 모든 데이터베이스 마이그레이션을 완료했음에도 응용 프로그램 코드가 예상하는 것과 다를 수 있습니다. 이런 경우 GitLab에서 이상한 오류가 발생할 수 있습니다.
데이터베이스 스키마를 덤핑하려면:
SCHEMA=/tmp/structure.sql gitlab-rake db:schema:dump
이 Rake 작업은 데이터베이스 스키마 덤프가 포함된 /tmp/structure.sql
파일을 생성합니다.
어떤 차이가 있는지 확인하려면:
-
gitlab
프로젝트의db/structure.sql
파일로 이동하세요. GitLab 버전과 일치하는 브랜치를 선택하세요. 예를 들어 GitLab 16.2용 파일: https://gitlab.com/gitlab-org/gitlab/-/blob/16-2-stable-ee/db/structure.sql. -
/tmp/structure.sql
을 해당 버전의db/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 또는 다른 비-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을 실행 중인 노드에서만 실행되어야 하기 때문입니다.