GitLab 유지 보수 모드
- GitLab 13.9에서 소개되었습니다.
유지 보수 모드를 사용하면 관리자가 유지 관리 작업이 수행되는 동안 쓰기 작업을 최소화할 수 있습니다. 주요 목표는 내부 상태를 변경하는 외부 작업을 차단하는 것입니다. 내부 상태에는 PostgreSQL 데이터베이스뿐만 아니라 파일, Git 리포지터리, Container 리포지터리가 특히 포함됩니다.
유지 보수 모드가 활성화되면 진행 중인 작업은 새로운 작업이 들어오지 않기 때문에 비교적 빨리 완료되며 내부 상태 변경도 최소화됩니다. 이 상태에서 다양한 유지 관리 작업이 쉬워집니다. 서비스를 완전히 중지하거나 그렇지 않은 경우보다 짧은 시간 동안 더 많이 저하될 수 있습니다. 예를 들어 cron 작업을 중지하고 대기열을 비우는 것이 상당히 빠를 것입니다.
유지 보수 모드를 사용하면 내부 상태를 변경하지 않는 대부분의 외부 작업을 허용합니다. 고수준에서 HTTP POST
, PUT
, PATCH
, DELETE
요청이 차단되고 특수한 경우가 처리되는 방법에 대한 자세한 개요가 제공됩니다.
유지 보수 모드 활성화
관리자로서 유지 보수 모드를 다음 중 하나의 방법으로 활성화할 수 있습니다.
-
웹 UI:
- 왼쪽 사이드바에서 맨 아래에서 Admin Area를 선택합니다.
- 왼쪽 사이드바에서 Settings > General을 선택합니다.
- Maintenance Mode를 확장하고 Enable Maintenance Mode를 토글합니다. 선택적으로 배너에 메시지를 추가할 수도 있습니다.
- Save changes를 선택합니다.
-
API:
curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?maintenance_mode=true"
-
::Gitlab::CurrentSettings.update!(maintenance_mode: true) ::Gitlab::CurrentSettings.update!(maintenance_mode_message: "새 메시지")
유지 보수 모드 비활성화
유지 보수 모드를 다음 세 가지 방법 중 하나로 비활성화할 수 있습니다.
-
웹 UI:
- 왼쪽 사이드바에서 맨 아래에서 Admin Area를 선택합니다.
- 왼쪽 사이드바에서 Settings > General을 선택합니다.
- Maintenance Mode를 확장하고 Enable Maintenance Mode를 토글합니다. 선택적으로 배너에 메시지를 추가할 수도 있습니다.
- Save changes를 선택합니다.
-
API:
curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?maintenance_mode=false"
-
::Gitlab::CurrentSettings.update!(maintenance_mode: false)
유지 보수 모드에서의 GitLab 기능 동작
유지 보수 모드가 활성화되면 페이지 상단에 배너가 표시됩니다. 배너는 특정 메시지로 사용자 정의할 수 있습니다.
사용자가 허용되지 않는 쓰기 작업을 수행하려고 하면 오류가 표시됩니다.
관리자 기능
시스템 관리자는 애플리케이션 설정을 편집할 수 있습니다. 이를 통해 활성화된 후 유지 보수 모드를 비활성화할 수 있습니다.
인증
모든 사용자는 GitLab 인스턴스에 로그인하거나 로그아웃할 수 있지만 새 사용자를 만들 수는 없습니다.
해당 시간에 LDAP 동기화 작업이 예약된 경우 사용자 생성이 비활성화되므로 실패합니다. 마찬가지로, SAML 기반의 사용자 생성도 실패합니다.
Git 동작
모든 읽기 전용 Git 작업은 계속해서 작동합니다. 예를 들어 git clone
및 git pull
. 모든 쓰기 작업은 CLI 및 Web IDE를 통해 실패하며 오류 메시지가 표시됩니다: Git push is not allowed because this GitLab instance is currently in (read-only) maintenance mode.
Geo가 활성화된 경우 기본 및 보조에 Git push가 실패합니다.
Merge Request, 이슈, 에픽
언급된 작업 외의 모든 쓰기 작업은 실패합니다. 예를 들어 사용자는 Merge Request이나 이슈를 업데이트할 수 없습니다.
수신 이메일
이메일을 통한 새로운 이슈 응답, 이슈 생성 (Service Desk 이슈 포함), 이메일을 통한 Merge Request이 실패합니다.
송신 이메일
알림 이메일은 계속 수신되지만 비밀번호 재설정과 같은 데이터베이스 쓰기를 필요로 하는 이메일은 도착하지 않습니다.
REST API
대부분의 JSON 요청에 대해 POST
, PUT
, PATCH
, DELETE
이 차단되고 API는 You cannot perform write operations on a read-only instance
라는 오류 메시지와 함께 403 응답을 반환합니다. 다음과 같은 요청만 허용됩니다:
HTTP 요청 | 허용된 라우트 | 참고 |
---|---|---|
POST
| /admin/application_settings/general
| 관리자 UI에서 애플리케이션 설정을 업데이트하기 위해 |
PUT
| /api/v4/application/settings
| API를 통해 애플리케이션 설정을 업데이트하기 위해 |
POST
| /users/sign_in
| 사용자가 로그인할 수 있도록 |
POST
| /users/sign_out
| 사용자가 로그아웃할 수 있도록 |
POST
| /oauth/token
| 사용자가 Geo 보조에 처음으로 로그인할 수 있도록 |
POST
|
/admin/session , /admin/session/destroy
| GitLab 관리자를 위한 관리자 모드 |
POST
|
/compare 로 끝나는 경로
| Git 리비전 라우트 |
POST
| .git/git-upload-pack
| Git pull/clone을 허용하기 위해 |
POST
| /api/v4/internal
| 내부 API 라우트 |
POST
| /admin/sidekiq
| Admin Area에서 백그라운드 작업을 관리하기 위해 |
POST
| /admin/geo
| 관리자 UI에서 Geo 노드를 업데이트하기 위해 |
POST
| /api/v4/geo_replication
| 보조 사이트에서 특정 Geo 관련 관리자 UI 작업을 허용하기 위해 |
GraphQL API
GeoRegistriesUpdate
뮤테이션 추가는 GitLab 16.2에서 도입되었습니다.
POST /api/graphql
요청은 허용되지만 뮤테이션은 읽기 전용 인스턴스에서 쓰기 작업을 수행할 수 없음을 나타내는 오류 메시지와 함께 차단됩니다.
GeoRegistriesUpdate
뮤테이션은 레지스트리를 재동기화하고 다시 확인하는 데 사용됩니다.
지속적 통합
- 새 작업 또는 파이프라인이 시작되지 않습니다(예약되었든 아니든).
- 이미 실행 중인 작업은 GitLab UI에서 여전히
running
상태를 유지하지만 GitLab Runner에서 실행을 완료하더라도 그렇습니다. - 프로젝트의 시간 제한을 초과한 상태로
running
상태의 작업은 타임 아웃되지 않습니다. - 파이프라인을 시작, 다시 시도 또는 취소할 수 없습니다. 새 작업도 생성할 수 없습니다.
-
/admin/runners
에서 러너의 상태가 업데이트되지 않습니다. -
gitlab-runner verify
는ERROR: Verifying runner... is removed
오류를 반환합니다.
유지보수 모드가 비활성화된 후에는 새 작업이 다시 시작됩니다. 유지보수 모드를 활성화하기 전에 running
상태에 있는 작업을 다시 시작해야 합니다.
배포
파이프라인이 완료되지 않았기 때문에 배포가 진행되지 않습니다.
유지보수 모드 중에는 자동 배포를 비활성화하고, 비활성화된 후에는 다시 활성화해야 합니다.
Terraform 통합
Terraform 통합은 실행 중인 CI 파이프라인에 의존하므로 차단됩니다.
컨테이너 레지스트리
docker push
가 denied: requested access to the resource is denied
오류로 실패하지만 docker pull
은 작동합니다.
패키지 레지스트리
패키지 레지스트리를 통해 패키지를 설치할 수는 있지만 게시할 수는 없습니다.
백그라운드 작업
백그라운드 작업(크론 작업, Sidekiq)은 자동으로 비활성화되지 않기 때문에 계속 실행됩니다. 백그라운드 작업은 인스턴스의 내부 상태를 변경할 수 있는 작업을 수행하므로 유지보수 모드가 활성화된 동안 일부 또는 전체 작업을 비활성화할 수 있습니다.
계획된 Geo 장애 교체 중에는 Geo 관련 크론 작업을 제외한 모든 크론 작업을 비활성화해야 합니다.
대기열을 모니터링하고 작업을 비활성화하려면:
- 왼쪽 사이드바에서 가장 아래쪽에 관리 영역을 선택합니다.
- 모니터링 > 백그라운드 작업을 선택합니다.
- Sidekiq 대시보드에서 Cron을 선택하여 개별적으로 작업을 비활성화하거나 전체 비활성화를 선택합니다.
사건 관리
사건 관리 기능이 제한됩니다. 알림 및 사건의 생성이 완전히 일시 중지됩니다. 따라서 알림 및 사건에 대한 알림 및 호출이 비활성화됩니다.
피처 플래그
- 개발 피처 플래그는 API를 통해 활성화 또는 비활성화할 수 없지만, Rails 콘솔을 통해 토글할 수 있습니다.
- 피처 플래그 서비스는 피처 플래그 확인에 응답하지만 피처 플래그를 토글할 수는 없습니다.
Geo secondaries
기본이 유지보수 모드에 있으면 보조도 자동으로 유지보수 모드로 전환됩니다.
유지보수 모드를 활성화하기 전에 복제를 비활성화하지 않아야 합니다.
복제, 확인 및 레지스트리를 매뉴얼으로 동기화하고 다시 확인하는 작업은 계속 작동하지만 프록시로 연결된 Git 푸시는 기본으로 전달되지 않습니다.
보안 기능
이슈를 생성하거나 Merge Request을 생성하거나 승인하는 데 의존하는 기능이 작동하지 않습니다.
취약점 보고서 페이지에서 취약점 디렉터리을 내보내는 작업이 작동하지 않습니다.
UI에 오류가 표시되지 않더라도, 발견이나 취약점 개체의 상태를 변경하는 작업이 작동하지 않습니다.
SAST 및 시크릿 감지는 아티팩트를 생성하는 CI 작업을 통과해야 하기 때문에 시작할 수 없습니다.
예시 시나리오: 계획된 장애 교체
계획된 장애 교체 시나리오에서, 기본 데이터베이스에 대한 일부 쓰기 작업은 수용 가능하며, 이러한 작업은 빠르게 복제되므로 중요하지 않습니다.
이와 같은 이유로 유지보수 모드가 활성화되면 자동으로 백그라운드 작업을 차단하지 않습니다.
결과적으로 발생하는 데이터베이스 쓰기 작업은 수용 가능합니다. 여기서 trade-off는 더 많은 서비스 약화와 복제 완료 사이의 균형을 맞추는 데 있습니다.
그러나 계획된 장애 교체 중에는 사용자에게 Geo와 관련이 없는 크론 작업을 매뉴얼으로 비활성화할 것을 요구합니다. 데이터베이스 쓰기 작업과 Geo와 무관한 크론 작업이 없는 상태에서는 새로운 백그라운드 작업이 생성되지 않거나 매우 제한적으로 생성됩니다.