InfoGrab DocsInfoGrab Docs

GitLab을 재시작하는 방법

요약

GitLab을 설치한 방식에 따라 서비스를 재시작하는 방법이 다릅니다. 어떤 방법을 쓰더라도 짧은 다운타임이 발생합니다. Linux 패키지로 GitLab을 설치했다면 이미 PATH에 gitlab-ctl 이 포함되어 있습니다.

GitLab을 설치한 방식에 따라 서비스를 재시작하는 방법이 다릅니다.

Note

어떤 방법을 쓰더라도 짧은 다운타임이 발생합니다.

Linux 패키지 설치#

Linux 패키지로 GitLab을 설치했다면 이미 PATH에 gitlab-ctl 이 포함되어 있습니다.

gitlab-ctl은 Linux 패키지 설치본과 상호작용하며, GitLab Rails 애플리케이션(Puma)과 다음과 같은 다른 구성 요소를 재시작하는 데 사용합니다.

  • GitLab Workhorse
  • Sidekiq
  • PostgreSQL(번들 제공본을 사용하는 경우)
  • NGINX(번들 제공본을 사용하는 경우)
  • Redis(번들 제공본을 사용하는 경우)
  • Mailroom
  • Logrotate

Linux 패키지 설치 재시작#

문서에서 GitLab을 재시작 하라고 안내하는 경우가 있습니다. Linux 패키지 설치본을 재시작하려면 다음을 실행합니다.

sudo gitlab-ctl restart

출력은 다음과 비슷합니다.

ok: run: gitlab-workhorse: (pid 11291) 1s
ok: run: logrotate: (pid 11299) 0s
ok: run: mailroom: (pid 11306) 0s
ok: run: nginx: (pid 11309) 0s
ok: run: postgresql: (pid 11316) 1s
ok: run: redis: (pid 11325) 0s
ok: run: sidekiq: (pid 11331) 1s
ok: run: puma: (pid 11338) 0s

개별 구성 요소만 재시작하려면 restart 명령 뒤에 해당 서비스 이름을 붙입니다. 예를 들어 NGINX만 재시작하려면 다음을 실행합니다.

sudo gitlab-ctl restart nginx

GitLab 서비스의 상태를 확인하려면 다음을 실행합니다.

sudo gitlab-ctl status

모든 서비스가 ok: run으로 표시되는지 확인합니다.

재시작 과정에서 구성 요소가 시간 초과되거나(로그에서 timeout을 확인합니다) 멈추는 경우가 있습니다. 이때는 gitlab-ctl kill <service>로 해당 서비스에 SIGKILL 시그널을 보낼 수 있습니다. 예를 들어 sidekiq에 보낼 수 있습니다. 그런 다음 재시작하면 정상적으로 동작합니다.

그래도 해결되지 않으면 마지막 방법으로 GitLab을 재구성해 볼 수 있습니다.

Linux 패키지 설치 재구성#

문서에서 GitLab을 재구성 하라고 안내하는 경우가 있습니다. 이 방법은 Linux 패키지 설치본에만 적용됩니다.

Linux 패키지 설치본을 재구성하려면 다음을 실행합니다.

sudo gitlab-ctl reconfigure

GitLab 재구성은 구성 파일(/etc/gitlab/gitlab.rb)의 내용이 변경되었을 때 수행합니다.

gitlab-ctl reconfigure를 실행하면 Linux 패키지 설치본의 기반이 되는 구성 관리 애플리케이션인 Chef가 몇 가지 검사를 수행합니다. Chef는 디렉터리, 권한, 서비스가 제자리에 있고 정상 동작하는지 확인합니다.

또한 구성 파일이 변경된 GitLab 구성 요소가 있으면 Chef가 해당 구성 요소를 재시작합니다.

Chef가 관리하는 /var/opt/gitlab의 파일을 직접 편집한 경우 reconfigure를 실행하면 변경 사항이 되돌려지고 해당 파일에 의존하는 서비스가 재시작됩니다.

직접 컴파일 설치#

공식 설치 가이드에 따라 직접 컴파일하여 설치했다면 다음 명령을 실행하여 GitLab을 재시작합니다.

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

이 명령은 Puma, Sidekiq, GitLab Workhorse, Mailroom(활성화된 경우)을 재시작합니다.

Helm 차트 설치#

클라우드 네이티브 Helm 차트로 설치한 GitLab 애플리케이션 전체를 한 번에 재시작하는 명령은 없습니다. 보통은 특정 구성 요소(예: gitaly, puma, workhorse, gitlab-shell)와 관련된 모든 pod를 삭제하여 해당 구성 요소만 재시작하면 충분합니다.

kubectl delete pods -l release=<helm release name>,app=<component name>

릴리스 이름은 helm list 명령의 출력에서 확인할 수 있습니다.

Docker 설치#

Docker 설치본의 구성을 변경했다면 변경 사항을 적용하기 위해 다음을 재시작해야 합니다.

  • 기본 gitlab 컨테이너.
  • 별도로 실행 중인 구성 요소 컨테이너.

예를 들어 Sidekiq을 별도 컨테이너에 배포했다면 컨테이너를 재시작하기 위해 다음을 실행합니다.

sudo docker restart gitlab
sudo docker restart sidekiq

GitLab을 재시작하는 방법

GitLab v19.5
Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

GitLab을 설치한 방식에 따라 서비스를 재시작하는 방법이 다릅니다. 어떤 방법을 쓰더라도 짧은 다운타임이 발생합니다. Linux 패키지로 GitLab을 설치했다면 이미 PATH에 gitlab-ctl 이 포함되어 있습니다.

GitLab을 설치한 방식에 따라 서비스를 재시작하는 방법이 다릅니다.

Note

어떤 방법을 쓰더라도 짧은 다운타임이 발생합니다.

Linux 패키지 설치#

Linux 패키지로 GitLab을 설치했다면 이미 PATH에 gitlab-ctl 이 포함되어 있습니다.

gitlab-ctl은 Linux 패키지 설치본과 상호작용하며, GitLab Rails 애플리케이션(Puma)과 다음과 같은 다른 구성 요소를 재시작하는 데 사용합니다.

  • GitLab Workhorse
  • Sidekiq
  • PostgreSQL(번들 제공본을 사용하는 경우)
  • NGINX(번들 제공본을 사용하는 경우)
  • Redis(번들 제공본을 사용하는 경우)
  • Mailroom
  • Logrotate

Linux 패키지 설치 재시작#

문서에서 GitLab을 재시작 하라고 안내하는 경우가 있습니다. Linux 패키지 설치본을 재시작하려면 다음을 실행합니다.

sudo gitlab-ctl restart

출력은 다음과 비슷합니다.

ok: run: gitlab-workhorse: (pid 11291) 1s
ok: run: logrotate: (pid 11299) 0s
ok: run: mailroom: (pid 11306) 0s
ok: run: nginx: (pid 11309) 0s
ok: run: postgresql: (pid 11316) 1s
ok: run: redis: (pid 11325) 0s
ok: run: sidekiq: (pid 11331) 1s
ok: run: puma: (pid 11338) 0s

개별 구성 요소만 재시작하려면 restart 명령 뒤에 해당 서비스 이름을 붙입니다. 예를 들어 NGINX만 재시작하려면 다음을 실행합니다.

sudo gitlab-ctl restart nginx

GitLab 서비스의 상태를 확인하려면 다음을 실행합니다.

sudo gitlab-ctl status

모든 서비스가 ok: run으로 표시되는지 확인합니다.

재시작 과정에서 구성 요소가 시간 초과되거나(로그에서 timeout을 확인합니다) 멈추는 경우가 있습니다. 이때는 gitlab-ctl kill <service>로 해당 서비스에 SIGKILL 시그널을 보낼 수 있습니다. 예를 들어 sidekiq에 보낼 수 있습니다. 그런 다음 재시작하면 정상적으로 동작합니다.

그래도 해결되지 않으면 마지막 방법으로 GitLab을 재구성해 볼 수 있습니다.

Linux 패키지 설치 재구성#

문서에서 GitLab을 재구성 하라고 안내하는 경우가 있습니다. 이 방법은 Linux 패키지 설치본에만 적용됩니다.

Linux 패키지 설치본을 재구성하려면 다음을 실행합니다.

sudo gitlab-ctl reconfigure

GitLab 재구성은 구성 파일(/etc/gitlab/gitlab.rb)의 내용이 변경되었을 때 수행합니다.

gitlab-ctl reconfigure를 실행하면 Linux 패키지 설치본의 기반이 되는 구성 관리 애플리케이션인 Chef가 몇 가지 검사를 수행합니다. Chef는 디렉터리, 권한, 서비스가 제자리에 있고 정상 동작하는지 확인합니다.

또한 구성 파일이 변경된 GitLab 구성 요소가 있으면 Chef가 해당 구성 요소를 재시작합니다.

Chef가 관리하는 /var/opt/gitlab의 파일을 직접 편집한 경우 reconfigure를 실행하면 변경 사항이 되돌려지고 해당 파일에 의존하는 서비스가 재시작됩니다.

직접 컴파일 설치#

공식 설치 가이드에 따라 직접 컴파일하여 설치했다면 다음 명령을 실행하여 GitLab을 재시작합니다.

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

이 명령은 Puma, Sidekiq, GitLab Workhorse, Mailroom(활성화된 경우)을 재시작합니다.

Helm 차트 설치#

클라우드 네이티브 Helm 차트로 설치한 GitLab 애플리케이션 전체를 한 번에 재시작하는 명령은 없습니다. 보통은 특정 구성 요소(예: gitaly, puma, workhorse, gitlab-shell)와 관련된 모든 pod를 삭제하여 해당 구성 요소만 재시작하면 충분합니다.

kubectl delete pods -l release=<helm release name>,app=<component name>

릴리스 이름은 helm list 명령의 출력에서 확인할 수 있습니다.

Docker 설치#

Docker 설치본의 구성을 변경했다면 변경 사항을 적용하기 위해 다음을 재시작해야 합니다.

  • 기본 gitlab 컨테이너.
  • 별도로 실행 중인 구성 요소 컨테이너.

예를 들어 Sidekiq을 별도 컨테이너에 배포했다면 컨테이너를 재시작하기 위해 다음을 실행합니다.

sudo docker restart gitlab
sudo docker restart sidekiq