• メンテナンス・モードの有効化
• メンテナンスモードの無効化
• メンテナンスモードでの GitLab 機能の動作
  • 管理者機能
  • 認証
  • Git アクション
  • マージリクエスト、イシュー、エピック
  • 受信メール
  • 送信メール
  • REST API
  • GraphQL API
  • 継続的インテグレーション
  • デプロイメント
    • Terraformインテグレーション
  • コンテナレジストリ
  • パッケージ・レジストリ
  • バックグラウンドジョブ
  • インシデント管理
  • フィーチャーフラグ
  • Geoセカンダリー
  • セキュリティ機能
• 使用例：計画的なフェイルオーバー

GitLab メンテナンスモード

GitLab 13.9 で導入されました。

メンテナンスモードでは、管理者がメンテナンスタスクを実行する間、書き込みオペレーションを最小限に抑えることができます。主な目的は、内部状態を変更するすべての外部アクションをブロックすることです。内部状態には、PostgreSQLデータベース、特にファイル、Gitリポジトリ、コンテナリポジトリが含まれます。

メンテナンスモードが有効な場合、新しいアクションが入ってこないため、進行中のアクションは比較的早く終了し、内部状態の変化も最小限になります。この状態では、さまざまなメンテナンス作業が簡単になります。サービスを完全に停止したり、必要な期間よりも短い期間でさらにデグレードしたりできます。例えば、cronジョブの停止やキューの排出はかなり短時間で行えるはずです。

メンテナンス・モードでは、内部状態を変更しないほとんどの外部アクションを許可します。高レベルでは、HTTPPOST 、PUT、PATCH、DELETE リクエストがブロックされ、特別なケースがどのように処理されるかの詳細な概要が利用可能です。

メンテナンス・モードの有効化

以下のいずれかの方法で、管理者としてメンテナンスモードを有効にします：

• Web UI：
  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、設定 > 一般を選択します。
  4. メンテナンスモード]を展開し、[メンテナンスモードを有効にする]を切り替えます。オプションでバナーにメッセージを追加することもできます。
  5. 変更を保存を選択します。

• APIを選択します：

   curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?maintenance_mode=true"
  

• Rails コンソール:

   ::Gitlab::CurrentSettings.update!(maintenance_mode: true)
   ::Gitlab::CurrentSettings.update!(maintenance_mode_message: "New message")
  

メンテナンスモードの無効化

メンテナンスモードを無効にするには、次の3つの方法があります：

• Web UI：
  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、設定 > 一般を選択します。
  4. メンテナンスモード]を展開し、[メンテナンスモードを有効にする]を切り替えます。オプションでバナーにメッセージを追加することもできます。
  5. 変更を保存を選択します。

• APIを選択します：

   curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?maintenance_mode=false"
  

• Rails コンソール:

   ::Gitlab::CurrentSettings.update!(maintenance_mode: false)
  

メンテナンスモードでの GitLab 機能の動作

メンテナンスモードを有効にすると、ページの上部にバナーが表示されます。バナーは特定のメッセージでカスタマイズすることができます。

ユーザーが許可されていない書き込みオペレーションを実行しようとすると、エラーが表示されます。

管理者機能

システム管理者は、アプリケーションの設定を編集できます。これにより、メンテナンスモードを有効にした後に無効にすることができます。

認証

全てのユーザーはGitLabインスタンスにサインイン、サインアウトすることができますが、新しいユーザーを作成することはできません。

その時間にLDAP同期が予定されていたとしても、ユーザー作成が無効になっているため失敗します。同様に、SAMLに基づくユーザー作成も失敗します。

Git アクション

例えばgit clone やgit pullのような、読み取り専用の Git オペレーションはすべて動作します。CLI や Web IDE を使ったすべての書き込みオペレーションはエラーメッセージとともに失敗します：Git push is not allowed because this GitLab instance is currently in (read-only) maintenance mode.

Geoが有効になっていると、プライマリとセカンダリの両方へのGitプッシュに失敗します。

マージリクエスト、イシュー、エピック

上記以外のすべての書き込みアクションは失敗します。例えば、ユーザーはマージリクエストやイシューを更新できません。

受信メール

電子メールによる新しいissue返信、issue（新しいサービスデスクissueを含む）、マージリクエストの作成に失敗しました。

送信メール

通知メールは引き続き届きますが、パスワードのリセットなどデータベースの書き込みが必要なメールは届きません。

REST API

ほとんどのJSONリクエストでは、POST 、PUT、PATCH、DELETE がブロックされ、APIはエラーメッセージとともに403レスポンスを返します：You cannot perform write operations on a read-only instance.以下のリクエストのみが許可されます：

GraphQL API

allowlist のGeoRegistriesUpdate mutation 追加は GitLab 16.2 で導入されました。

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 Maintenance Mode をオフにした後は、running 以前のパイプラインを再開する必要があります。

デプロイメント

パイプラインが未完成のため、デプロイが進みません。

メンテナンスモード中は自動デプロイを無効にし、無効になったら有効にしてください。

Terraformインテグレーション

TerraformインテグレーションはCIパイプラインの実行に依存しているため、ブロックされています。

コンテナレジストリ

docker push はこのエラーで失敗します：denied: requested access to the resource is deniedしかし、docker pull は動作します。

パッケージ・レジストリ

パッケージレジストリでは、パッケージをインストールすることはできますが、公開することはできません。

バックグラウンドジョブ

バックグラウンドジョブ（cronジョブ、Sidekiq）は、バックグラウンドジョブが自動的に無効化されないため、そのまま実行され続けます。バックグラウンドジョブはインスタンスの内部状態を変更するオペレーションを実行するため、メンテナンスモードが有効になっている間、一部またはすべてのジョブを無効にしたい場合があります。

Geoのフェイルオーバーが計画されている間は、Geoに関連するもの以外のすべてのcronジョブを無効にする必要があります。

キューを監視し、ジョブを無効にするには：

1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
2. Admin Areaを選択します。
3. 左サイドバーで、[監視] > [バックグラウンドジョブ]を選択します。
4. Sidekiqダッシュボードで、[Cron]を選択し、[Disable All]を選択してジョブを個別に、または一度にすべて無効にします。

インシデント管理

インシデント管理機能は制限されています。アラートと インシデントの作成は完全に一時停止されます。そのため、アラートとインシデントに関するページングと通知は無効になります。

フィーチャーフラグ

• 開発機能フラグはAPIでオン/オフすることはできませんが、Railsコンソールで切り替えることができます。
• 機能フラグサービスは機能フラグチェックに応答しますが、機能フラグを切り替えることはできません。

Geoセカンダリー

プライマリがメンテナンスモードになると、セカンダリも自動的にメンテナンスモードになります。

Maintenance Modeを有効にする前にレプリケーションを無効にしないことが重要です。

レプリケーション、検証、管理者UIを通じたレジストリの再同期と再変換の手動アクションは引き続き機能しますが、プライマリへのプロキシされたGitプッシュは機能しません。

セキュリティ機能

イシューの作成やマージリクエストの作成・承認に依存する機能は動作しません。

脆弱性レポートページから脆弱性リストをエクスポートできません。

発見または脆弱性オブジェクトのステータスを変更すると、UIにエラーが表示されないにもかかわらず、ステータスが変更されません。

アーティファクトを作成する CI ジョブの通過に依存するため、SAST と秘密検出を開始できません。

使用例：計画的なフェイルオーバー

計画的なフェイルオーバーの使用例では、プライマリ・データベースに書き込みがいくつかあってもかまいません。

同じ理由で、メンテナンス・モードが有効な場合、バックグラウンド・ジョブを自動的にブロックしません。

結果として生じるデータベースの書き込みは許容範囲内です。ここでは、より多くのサービス低下とレプリケーションの完了の間のトレードオフです。

しかし、計画的なフェイルオーバーの間、Geo に関係のない cron ジョブを手動でオフにするようユーザーに依頼します。新しいデータベース書き込みと Geo 以外の cron ジョブがない場合、新しいバックグラウンドジョブはまったく作成されないか、最小限のものになります。