• 서비스 상태 가져오기
• 프로세스 로그 테일
• 시작 및 중지
• Rake 작업 호출
• Rails 콘솔 세션 시작
• PostgreSQL 슈퍼 유저 psql 세션 시작
  • Geo 추적 데이터베이스의 PostgreSQL 슈퍼 유저 psql 세션 시작
• 컨테이너 레지스트리 가비지 수집
• 사용자가 GitLab으로 로깅되는 것을 제한
• 시크릿 파일 회전

유지 보수 명령어

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

서비스 상태 가져오기

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 리소스를 통해 시작되는 runsvdir 서비스 디렉터리 (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에 대해 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 콘솔을 참조하십시오.

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로 이동하면 임의의 배포 진행 중 페이지가 표시됩니다.

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

참고로, GitLab으로의 로깅을 제한하고 프로젝트에 대한 변경을 제한하려면 프로젝트를 읽기 전용으로 설정하여 배포 진행 중 페이지를 표시할 수 있습니다.

시크릿 파일 회전

보안 목적으로 필요한 경우 /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이 예상대로 작동하는지 확인하십시오. 예상대로 작동하면 이전 시크릿을 안전하게 삭제해도 됩니다.