GitLabメンテナンスモード
- プラン: Premium、Ultimate
- 提供形態: GitLab Self-Managed
メンテナンスモードを使用すると、管理者は、メンテナンスタスクの実行中に書き込み操作を最小限に抑えることができます。主な目標は、内部状態を変更するすべての外部アクションをブロックすることです。内部状態には、PostgreSQLデータベースだけでなく、特にファイル、Gitリポジトリ、コンテナレジストリが含まれます。
メンテナンスモードが有効になっている場合、新しいアクションが実行されず、内部状態の変更が最小限であるため、進行中のアクションは比較的早く完了します。その状態では、さまざまなメンテナンスタスクが容易になります。サービスを完全に停止したり、必要以上に短い時間でさらに低下させたりすることができます。たとえば、cronジョブを停止し、キューをドレインすると、かなり速くなります。
メンテナンスモードでは、内部状態を変更しないほとんどの外部アクションが許可されます。大まかに言うと、HTTP POST、PUT、PATCH、およびDELETEリクエストはブロックされ、特別なケースの処理方法の詳細な概要が利用可能です。
メンテナンスモードを有効にする
次のいずれかの方法で、管理者としてメンテナンスモードを有効にします:
WEB UI:
- 左側のサイドバーの下部で、管理者を選択します。
- 左側のサイドバーで、設定 > 一般を選択します。
- メンテナンスモードを展開し、メンテナンスモードを有効にする を切り替えます。オプションで、バナーのメッセージを追加することもできます。
- 変更を保存を選択します。
API:
curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?maintenance_mode=true"
メンテナンスモードを無効にする
次の3つのいずれかの方法で、メンテナンスモードを無効にします:
WEB UI:
- 左側のサイドバーの下部で、管理者を選択します。
- 左側のサイドバーで、設定 > 一般を選択します。
- メンテナンスモードを展開し、メンテナンスモードを有効にするを切り替えます。オプションで、バナーのメッセージを追加することもできます。
- 変更を保存を選択します。
API:
curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?maintenance_mode=false"
メンテナンスモードでのGitLab機能の動作
メンテナンスモードが有効になっている場合、バナーがページの上部に表示されます。バナーは特定のメッセージでカスタマイズできます。
許可されていない書き込み操作をユーザーが実行しようとすると、エラーが表示されます。
場合によっては、アクションからの視覚的なフィードバックが誤解を招く可能性があります。たとえば、プロジェクトにStarを付けると、Star付きボタンがStar付き解除アクションを示すように変わります。ただし、これはフロントエンドの更新のみであり、POSTリクエストの失敗ステータスは考慮されていません。これらの視覚的なバグは、フォローアップイテレーションで修正される予定です。
管理者機能
システム管理者は、アプリケーション設定を編集できます。これにより、有効にした後でメンテナンスモードを無効にできます。
認証
すべてのユーザーは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プッシュは失敗します。
マージリクエスト、イシュー、エピック
前述したものを除くすべての書き込みアクションは失敗します。たとえば、ユーザーはマージリクエストまたはイシューを更新できません。
受信
新しいイシューの返信、イシュー (サービスデスクの新しいイシューを含む)、メールによるマージリクエストの作成は失敗します。
送信メール
通知メールは引き続き届きますが、パスワードのリセットなど、データベースの書き込みを必要とするメールは届きません。
REST API
ほとんどのJSONリクエストでは、POST、PUT、PATCH、およびDELETEがブロックされ、APIはエラーメッセージGitLab Maintenance: system is in maintenance modeで503応答を返します。次のリクエストのみが許可されています:
| 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プル/クローンを許可する。 |
POST | /api/v4/internal | 内部APIルート |
POST | /admin/sidekiq | 管理者エリアでバックグラウンドジョブの管理を許可する |
POST | /admin/geo | 管理者UIでGeoノードを更新できるようにする |
POST | /api/v4/geo_replication | セカンダリサイトで特定のGeo固有の管理者UIアクションを許可する |
GraphQL API
POST /api/graphqlリクエストは許可されていますが、ミューテーションはエラーメッセージYou cannot perform write operations on a read-only instanceでブロックされます。
許可されている唯一のミューテーションは、GeoRegistriesUpdateであり、レジストリの再同期と再検証に使用されます。
継続的インテグレーション
- 新しいジョブまたはパイプラインは、スケジュールされているかどうかに関係なく開始されません。
- すでに実行中のジョブは、GitLab Runnerでの実行が終了した場合でも、GitLab UIで
runningステータスを引き続き保持します。 - プロジェクトの制限時間を超えて
running状態のジョブは、タイムアウトしません。 - パイプラインを開始、再試行、またはキャンセルすることはできません。新しいジョブも作成できません。
/admin/runnersのRunnerのステータスは更新されません。gitlab-runner verifyはエラーERROR: Verifying runner... is removedを返します。
メンテナンスモードが無効になると、新しいジョブが再び選択されます。メンテナンスモードを有効にする前にrunning状態にあったジョブは再開され、ログの更新が再び開始されます。
メンテナンスモードをオフにした後、以前にrunningだったパイプラインを再起動する必要があります。
デプロイ
パイプラインが未完了のため、デプロイは完了しません。
メンテナンスモード中は自動デプロイを無効にし、無効になっている場合は有効にする必要があります。
Terraformのインテグレーション
TerraformのインテグレーションはCIパイプラインの実行に依存するため、ブロックされます。
コンテナレジストリ
docker pushはこのエラーで失敗します：denied: requested access to the resource is denied、ただしdocker pullは機能します。
パッケージレジストリ
パッケージレジストリでは、パッケージをインストールできますが、公開することはできません。
バックグラウンドジョブ
バックグラウンドジョブ (cronジョブ、Sidekiq) は、バックグラウンドジョブが自動的に無効にならないため、そのまま実行され続けます。バックグラウンドジョブはインスタンスの内部状態を変更する可能性のある操作を実行するため、メンテナンスモードが有効になっている間は、それらの一部またはすべてを無効にすることをお勧めします。
計画されたGeoフェイルオーバーの間、Geoに関連するものを除くすべてのcronジョブを無効にする必要があります。
キューを監視してジョブを無効にするには:
- 左側のサイドバーの下部で、管理者を選択します。
- 左側のサイドバーで、モニタリング > バックグラウンドジョブを選択します。
- Sidekiqダッシュボードで、Cronを選択し、Disable All（すべて無効にする）を選択して、ジョブを個別にまたは一度にすべて無効にします。
インシデント管理
インシデント管理機能は制限されています。アラートとインシデントの作成は完全に一時停止されます。したがって、アラートとインシデントの通知と呼び出しは無効になります。
機能フラグ
- 開発機能フラグは、APIを介してオンまたはオフにすることはできませんが、Railsコンソールを介して切替できます。
- 機能フラグサービスは機能フラグチェックに応答しますが、機能フラグを切り替えることはできません。
Geoセカンダリ
プライマリがメンテナンスモードの場合、セカンダリも自動的にメンテナンスモードになります。
メンテナンスモードを有効にする前に、レプリケーションを無効にしないことが重要です。
AdminUIを介したレプリケーション、検証、およびレジストリを再同期および再検証するための手動アクションは引き続き機能しますが、プロキシされたGitプッシュはプライマリには機能しません。
セキュア機能
イシューの作成、またはマージリクエストの作成または承認に依存する機能は機能しません。
脆弱性レポートページから脆弱性リストをエクスポートすることはできません。
UIにエラーが表示されない場合でも、検出または脆弱性オブジェクトのステータスを変更しても機能しません。
SASTおよびシークレット検出は、アーティファクトを作成するためにCIジョブを渡すことに依存するため、開始できません。
ユースケースの例: 計画的なフェイルオーバー
計画されたフェイルオーバーのユースケースでは、プライマリデータベース内の一部の書き込みは、すばやくレプリケートされ、数が重要ではないため、許容されます。
同じ理由で、メンテナンスモードが有効になっているときにバックグラウンドジョブを自動的にブロックしません。
結果として得られるデータベースの書き込みは許容されます。ここで、トレードオフは、より多くのサービスの低下とレプリケーションの完了との間にあります。
ただし、計画的なフェイルオーバー中に、Geoに関連しないcronジョブを手動でオフにするようにユーザーに依頼します。新しいデータベースの書き込みと非Geo cronジョブがない場合、新しいバックグラウンドジョブはまったく作成されないか、最小限になります。