유지 관리 명령어

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

설치 후에 다음 명령어를 실행할 수 있습니다.

서비스 상태 가져오기

sudo gitlab-ctl status를 실행하여 각 GitLab 구성 요소의 현재 상태와 가동 시간을 확인하세요.

출력 결과는 다음과 비슷하게 나타날 것입니다:

run: nginx: (pid 972) 7s; run: log: (pid 971) 7s  
run: postgresql: (pid 962) 7s; run: log: (pid 959) 7s  
run: redis: (pid 964) 7s; run: log: (pid 963) 7s  
run: sidekiq: (pid 967) 7s; run: log: (pid 966) 7s  
run: puma: (pid 961) 7s; run: log: (pid 960) 7s

예제의 첫 번째 줄은 다음과 같이 해석할 수 있습니다:

  • Nginx는 프로세스 이름입니다.
  • 972는 프로세스 식별자입니다.
  • NGINX는 7초 동안 실행 중입니다(7s).
  • log는 이전 프로세스에 연결된 svlogd 로깅 프로세스를 나타냅니다.
  • 971은 로깅 프로세스의 프로세스 식별자입니다.
  • 로깅 프로세스는 7초 동안 실행 중입니다(7s).

프로세스 로그 보기

settings/logs.md. 참조

시작 및 중지

Omnibus GitLab이 설치되고 구성된 후에는 부팅 시 /etc/inittab 또는 /etc/init/gitlab-runsvdir.conf Upstart 리소스를 통해 시작되는 runit 서비스 디렉토리(runsvdir) 프로세스가 서버에서 실행됩니다.

runsvdir 프로세스를 직접 다루어야 할 필요는 없습니다. 대신 gitlab-ctl 프런트 엔드를 사용할 수 있습니다.

다음 명령어를 사용하여 GitLab 및 모든 구성 요소를 시작, 중지 또는 재시작할 수 있습니다.

# 모든 GitLab 구성 요소 시작
sudo gitlab-ctl start

# 모든 GitLab 구성 요소 중지
sudo gitlab-ctl stop

# 모든 GitLab 구성 요소 재시작
sudo gitlab-ctl restart

# 주어진 서비스를 제외한 모든 GitLab 구성 요소 재시작 ... (예: gitaly, redis)
sudo gitlab-ctl restart-except gitaly redis

단일 코어 서버에서는 Puma 및 Sidekiq를 재시작하는 데 최대 1분이 걸릴 수 있습니다. Puma가 다시 시작될 때까지 GitLab 인스턴스는 502 오류를 발생시킵니다.

개별 구성 요소를 시작, 중지 또는 재시작하는 것도 가능합니다.

sudo gitlab-ctl restart sidekiq

Puma는 거의 중단 없는 재시작을 지원합니다. 이는 다음과 같이 트리거될 수 있습니다:

sudo gitlab-ctl hup puma

hup 명령이 완료될 때까지 기다려야 합니다. 이 과정은 시간이 걸릴 수 있습니다. 이 명령이 완료될 때까지 노드를 풀에서 제외하고 이 명령이 실행된 노드에서 서비스를 재시작하지 마세요. Puma 재시작을 사용하여 Ruby 런타임을 업데이트할 수도 없습니다.

Puma에는 애플리케이션 동작을 제어하기 위한 다음과 같은 신호가 있습니다:

신호 Puma
HUP 정의된 로그 파일을 다시 열거나 프로세스를 강제로 재시작
INT 요청 처리를 정상적으로 중지합니다.
USR1 단계적으로 워커를 재시작하며, 구성 파일 재로드 없이 롤링 재시작합니다.
USR2 워커를 재시작하고 구성을 재로드합니다.
QUIT 메인 프로세스를 종료합니다.

Puma의 경우, gitlab-ctl hup puma는 SIGINT와 SIGTERM(프로세스가 재시작되지 않을 경우) 신호를 순차적으로 보냅니다. Puma는 SIGINT 신호를 수신하는 즉시 새로운 연결을 받지 않기 시작합니다. 모든 실행 중인 요청이 완료된 후, runit은 서비스를 재시작합니다.

Rake 작업 호출

GitLab Rake 작업을 호출하려면 gitlab-rake를 사용하세요. 예를 들어:

sudo gitlab-rake gitlab:check

git 사용자라면 sudo를 생략하세요.

전통적인 GitLab 설치와 달리, 사용자나 RAILS_ENV 환경 변수를 변경할 필요가 없습니다. 이는 gitlab-rake 래퍼 스크립트가 처리합니다.

Rails 콘솔 세션 시작하기

자세한 내용은 Rails console을 참조하세요.

PostgreSQL 슈퍼유저 psql 세션 시작하기

번들로 제공된 PostgreSQL 서비스에 슈퍼유저 액세스가 필요하다면 gitlab-psql 명령을 사용할 수 있습니다. 이 명령은 일반 psql 명령과 동일한 인수를 사용합니다.

# GitLab 데이터베이스에 대한 슈퍼유저 psql 액세스
sudo gitlab-psql -d gitlabhq_production

이 작업은 최소한 한 번 gitlab-ctl reconfigure를 실행한 후에만 작동합니다. gitlab-psql 명령은 원격 PostgreSQL 서버에 연결하거나 로컬 비-Omnibus PostgreSQL 서버에 연결하는 데 사용될 수 없습니다.

Geo 추적 데이터베이스에서 PostgreSQL 슈퍼유저 psql 세션 시작하기

앞선 명령과 유사하게, 번들로 제공된 Geo 추적 데이터베이스(geo-postgresql)에 슈퍼유저 액세스가 필요하면 gitlab-geo-psql을 사용할 수 있습니다. 이 명령도 일반 psql 명령과 동일한 인수를 사용합니다. HA에 대한 필수 인수에 대해서는 구성 확인을 참조하세요.

# GitLab의 Geo 추적 데이터베이스에 대한 슈퍼유저 psql 액세스
sudo gitlab-geo-psql -d gitlabhq_geo_production

컨테이너 레지스트리 가비지 수집

컨테이너 레지스트리는 상당한 양의 디스크 공간을 사용할 수 있습니다. 사용하지 않는 레이어를 정리하려면 레지스트리에서 가비지 수집 명령을 사용할 수 있습니다.

GitLab 로그인 제한

사용자가 GitLab에 로그인하는 것을 일시적으로 제한해야 하는 경우 sudo gitlab-ctl deploy-page up을 사용할 수 있습니다. 사용자가 GitLab URL로 이동하면 임의의 Deploy in progress 페이지가 표시됩니다.

페이지를 제거하려면 sudo gitlab-ctl deploy-page down을 실행하면 됩니다. 또한 sudo gitlab-ctl deploy-page status로 배포 페이지의 상태를 확인할 수 있습니다.

참고로 GitLab에 로그인을 제한하고 프로젝트에 대한 변경을 제한하려면 프로젝트를 읽기 전용으로 설정한 다음 Deploy in progress 페이지를 표시할 수 있습니다.

비밀 파일 회전

보안 목적으로 필요한 경우 /etc/gitlab/gitlab-secrets.json 비밀 파일을 회전할 수 있습니다. 이 파일에서:

  • gitlab_rails 비밀을 회전하지 마세요. 이 비밀은 데이터베이스 암호화 키를 포함합니다. 이 비밀이 회전되면 비밀 파일이 손실되었을 때의 행동과 동일한 행동을 보게 됩니다.
  • 모든 다른 비밀은 회전할 수 있습니다.

GitLab 환경에 여러 노드가 있는 경우 초기 단계를 수행할 Rails 노드를 선택하세요.

비밀을 회전하려면:

  1. 데이터베이스 값을 복호화할 수 있는지 확인하고 복호화 오류를 기록하거나 진행하기 전에 해결합니다.

  2. 추천 항목. gitlab_rails의 현재 비밀을 추출합니다. 나중에 필요하므로 출력을 저장합니다:

    sudo grep "secret_key_base\|db_key_base\|otp_key_base\|encrypted_settings_key_base\|openid_connect_signing_key" /etc/gitlab/gitlab-secrets.json

  3. 현재 비밀 파일을 다른 위치로 이동합니다:

    sudo mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.old

  4. GitLab 재구성. 그러면 GitLab이 새로운 비밀 값으로 새로운 /etc/gitlab/gitlab-secrets.json 파일을 생성합니다.

  5. 이전 gitlab_rails 비밀을 추출했다면, 새로운 /etc/gitlab/gitlab-secrets.json 파일을 편집하고 앞서 얻은 이전 비밀 출력을 기준으로 gitlab_rails 하위의 키/값 쌍을 바꿉니다.

  6. GitLab 재구성을 다시 실행하여 비밀 파일에 대한 변경 사항을 적용합니다.

  7. GitLab 재시작하여 모든 서비스가 새로운 비밀을 사용하도록 합니다.

  8. GitLab 환경에 여러 노드가 있는 경우 비밀을 모든 다른 노드에 복사해야 합니다:

    1. 모든 다른 노드에서 현재 비밀 파일을 다른 위치로 이동합니다:

      sudo mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.old

    2. Rails 노드에서 새로운 /etc/gitlab/gitlab-secrets.json 파일을 모든 다른 GitLab 노드로 복사합니다.

    3. 모든 다른 노드에서 GitLab 재구성을 각 노드에서 실행합니다.

    4. 모든 다른 노드에서 GitLab 재시작을 각 노드에서 실행하여 모든 서비스가 새로운 비밀을 사용하도록 합니다.

    5. 모든 노드에서 /etc/gitlab/gitlab-secrets.json 파일의 체크섬을 일치시켜 비밀이 일치하는지 확인합니다:

      sudo md5sum /etc/gitlab/gitlab-secrets.json

  9. 데이터베이스 값을 복호화할 수 있는지 확인. 출력이 이전 실행과 일치해야 합니다.

  10. GitLab이 예상대로 작동하는지 확인합니다. 만약 그렇다면, 이전 비밀을 삭제해도 안전해야 합니다.