- 서비스 상태 가져오기
- 프로세스 로그 끝 부분 보기
- 시작 및 중지
- Rake 작업 호출
- Rails 콘솔 세션 시작
-
PostgreSQL superuser
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 자원을 통해 시작되는 runit 서비스 디렉터리 (runsvdir
) 프로세스가 실행됩니다. runsvdir
프로세스를 직접 처리할 필요는 없으며 대신 gitlab-ctl
프론트 엔드를 사용할 수 있습니다.
다음 명령어로 GitLab과 모든 컴포넌트를 시작, 중지, 또는 재시작할 수 있습니다.
# 모든 GitLab 컴포넌트 시작
sudo gitlab-ctl start
# 모든 GitLab 컴포넌트 중지
sudo gitlab-ctl stop
# 모든 GitLab 컴포넌트 재시작
sudo gitlab-ctl restart
단일 코어 서버의 경우 Puma 및 Sidekiq 재시작에 최대 1분이 걸릴 수 있다는 점에 유의하세요. Puma가 다시 가동될 때까지 GitLab 인스턴스는 502 오류가 발생할 것입니다.
개별 컴포넌트를 시작, 중지 또는 재시작하는 것도 가능합니다.
sudo gitlab-ctl restart sidekiq
Puma는 거의 0 다운타임 리로드를 지원합니다. 다음과 같이 트리거할 수 있습니다:
sudo gitlab-ctl hup puma
hup
명령어가 완료될 때까지 기다려야 합니다. 이 과정은 시간이 소요될 수 있습니다. 이 과정이 완료될 때까지 풀에서 노드를 제외시키고, 이 명령어가 실행된 노드에서 서비스를 재시작해서는 안 됩니다. 또한 Puma 리로드를 사용하여 Ruby 런타임을 업데이트할 수 없습니다.
Puma는 애플리케이션 동작을 제어하기 위해 다음과 같은 시그널을 갖고 있습니다:
시그널 | Puma |
---|---|
HUP
| 정의된 로그 파일 다시 열거나 프로세스를 강제로 재시작 |
INT
| graceful하게 요청 처리 중지 |
USR1
| 워커를 단계적으로 재시작, 구성 리로딩 없이 롤링 재시작 |
USR2
| 워커를 재시작하고 구성 리로딩 |
QUIT
| 주 프로세스 종료 |
Puma에 대해, gitlab-ctl hup puma
는 SIGINT
와 SIGTERM
(프로세스가 재시작되지 않을 경우) 시그널을 순차적으로 보냅니다. SIGINT
를 수신했을 때 Puma는 새로운 연결을 받지 않게 됩니다. 모든 실행 중인 요청을 완료하고, 그 후 runit
이 서비스를 재시작합니다.
Rake 작업 호출
GitLab Rake 작업을 호출하려면 gitlab-rake
를 사용하세요. 예를 들면:
sudo gitlab-rake gitlab:check
git
사용자인 경우 sudo
를 빼도 됩니다.
전통적인 GitLab 설치와 달리 사용자나 RAILS_ENV
환경 변수를 변경할 필요가 없습니다. 이 작업은 gitlab-rake
래퍼 스크립트에 의해 처리됩니다.
Rails 콘솔 세션 시작
자세한 정보는 Rails 콘솔을 확인하세요.
PostgreSQL superuser psql
세션 시작
묶음된 PostgreSQL 서비스에 대한 슈퍼유저 액세스가 필요한 경우 gitlab-psql
명령어를 사용할 수 있습니다. 이는 일반적인 psql
명령어와 동일한 인수를 사용합니다.
# GitLab의 데이터베이스에 대한 슈퍼유저 psql 액세스
sudo gitlab-psql -d gitlabhq_production
이 명령어는 적어도 한 번은 gitlab-ctl reconfigure
를 실행한 후에만 작동합니다. gitlab-psql
명령어는 원격 PostgreSQL 서버에 연결하거나 Omnibus가 아닌 로컬 PostgreSQL 서버에 연결하는 데 사용할 수 없습니다.
Geo 추적 데이터베이스 내의 PostgreSQL superuser psql
세션 시작
이전 명령어와 유사하게, 묶음된 Geo 추적 데이터베이스 (geo-postgresql
)에 대한 슈퍼유저 액세스가 필요한 경우 gitlab-geo-psql
을 사용할 수 있습니다. 이는 일반적인 psql
명령어와 동일한 인수를 사용합니다. HA에 대해서는 다음을 참고하세요: Checking Configuration
# 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 노드 중 하나를 선택하세요.
시크릿을 회전하려면:
- 데이터베이스 값이 현재 시크릿을 사용하여 복호화될 수 있는지 확인하고 표시된 복호화 오류를 메모하거나 해결하세요.
-
권장 사항. 이전
gitlab_rails
시크릿을 추출하세요. 이 정보는 나중에 필요합니다:sudo grep "secret_key_base\|db_key_base\|otp_key_base\|encrypted_settings_key_base\|openid_connect_signing_key\|ci_jwt_signing_key" /etc/gitlab/gitlab-secrets.json
-
현재 시크릿 파일을 다른 위치로 이동하세요:
sudo mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.old
-
GitLab을 재구성하세요. GitLab은 새로운 시크릿 값을 갖는
/etc/gitlab/gitlab-secrets.json
파일을 생성합니다. -
이전
gitlab_rails
시크릿을 추출했다면, 이전에 얻은 이전 시크릿 출력으로 새/etc/gitlab/gitlab-secrets.json
파일을 편집하고gitlab_rails
아래에 있는 키/값 쌍을 대체하세요. -
시크릿 파일의 변경 사항이 적용되도록 GitLab을 재구성하세요.
-
새 시크릿을 사용하도록 GitLab을 재시작하여 모든 서비스가 새 시크릿을 사용하도록 하세요.
-
GitLab 환경에 여러 노드가 있는 경우, 다른 GitLab 노드에도 시크릿을 복사해야 합니다:
-
다른 모든 노드에서 현재 시크릿 파일을 다른 위치로 이동하세요:
sudo mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.old
-
Rails 노드에서 새
/etc/gitlab/gitlab-secrets.json
파일을 모든 다른 GitLab 노드로 복사하세요. -
각 노드에서 GitLab을 재구성하세요.
-
각 노드에서 GitLab을 재시작하여 모든 서비스가 새 시크릿을 사용하도록 하세요.
-
파일의
md5sum
으로/etc/gitlab/gitlab-secrets.json
파일의 체크섬이 일치하는지 확인하세요:sudo md5sum /etc/gitlab/gitlab-secrets.json
-
-
데이터베이스 값이 현재 시크릿을 사용하여 복호화될 수 있는지 확인하세요. 출력은 이전 실행과 일치해야 합니다.
- GitLab이 예상대로 작동하는지 확인하세요. 정상적으로 작동하면 이전 시크릿을 삭제해도 안전할 것입니다.