インフラストラクチャ環境

環境

環境の Terraform 設定は config-mgmt にあります。

開発

開発はローカルマシンで行われます。そのため、SLA を提供する方法はありません。アクセスは個別の開発者に限定されます。開発者が取り組んでいる内容によって EE/CE のいずれかになります。

デモ

現在の EE リリースの完全な機能を持つバージョンである必要があります。常にセールスで利用できるようにするため、高い SLA と厳格なアクセス制限が設けられています。出荷しない機能（機能フラグ/カナリア/等）はありません。

.org

.org 環境の主な用途:

• 公式アーティファクトのビルド
• SOX コンプライアンスのためのビルド分離の提供（異なるインスタンスとインフラ上に配置）
• SBOM とプロベナンスの認証
• リリースの公開管理
• 公開後の Canonical との同期管理
• GitLab.com の完全な障害発生時にセルフマネージドの顧客に対して GitLab をリリースする能力の確保

これはビルドアーティファクトにより常に増大し続ける重要なインフラです。ナイトリーの CE/EE ビルドをデプロイできる新しいビルドサーバーを作成するか、インフラリポジトリを別のホスト（gitlab.com とは別の EE インスタンス）に移動する議論があります。環境名のドメインに dev が含まれていますが、ローカル開発環境と混同される可能性があるため dev と呼ばないでください。

Ops

ops 環境は GitLab.com インフラの管理に重要なすべてのインフラを保持しています。

現在は以下が含まれています:

• ElasticCloud のプロキシ。
• dashboards.gitlab.net を提供する内部監視インフラ。
• すべての運用関連 GitLab リポジトリのバックアップとして機能する分離された GitLab デプロイ。
• バックアップやメンテナンスなどの重要な運用タスクの CI/CD ジョブ。
• GitLab chatops などの本番インフラへの接続が必要なランナー。

本番

本番はカナリアデプロイの能力を持つフルスケールおよびサイズです。本番へのアクセスは制限されています。 2 つのステージで構成されています:

• カナリアステージはコミュニティの限られたメンバーに到達するインフラのサブセットです。まずこのステージにデプロイします。詳細はカナリアステージとその使用方法を参照してください。
• メインステージはより広い GitLab コミュニティの残りのトラフィックを処理します。

Production-Canary

Production-Canary は本番環境の環境サブセットまたはデプロイ「ステージ」であり、本番とほとんど同じインフラを共有しています。この追加ステージは、新しいリリースをエンドユーザーにより制御された方法でロールアウトし、ユーザーへの影響を最小化する形で問題を早期発見できるよう設計されています。

本番カナリアへのアクセス方法、使用方法、対象サービスについての情報はカナリアステージ環境に関するハンドブックページに記載されています。

ステージング

ステージングは本番と同じトポロジーを持ち、同じ Terraform 設定 を共有しているため、同じコンポーネントを含んでいます。

本番と同様のカナリア環境を持ち、新しいリリースはそれ以上進む前にまずその環境にデプロイされて検証されます。Staging-Canary 環境にはデプロイと使用に関して特記すべき追加機能があり、それ自身の環境エントリに詳細が記載されています。

ステージングのデプロイはリリースに説明されているように本番デプロイに先行しますが、ステージングははるかに頻繁にデプロイされます（ビルドがグリーンであれば少なくとも数時間ごとに）。これは仮名化された本番データベースを持つ静的環境です。DB は本番 DB のスナップショットです（マイグレーション時間を最小限に抑えるために必要な頻度でのみ更新）。

ステージングで自分に割り当てられた QA Issue をテストするためのアカウントが必要な場合、本番アカウントがステージングに移行されているため、すでにアカウントを持っている可能性があります。それ以外の場合、アカウントを作成する必要がある場合は access-request プロジェクト に Issue を作成し、マネージャーにレビューを依頼してください。データベースとサーバー環境へのアクセスリクエストには、マネージャーと Infrastructure マネージャーのいずれかの承認が必要です。このタイプのアクセスを申請するためにも同じ access-request トラッカー を使用してください。

Staging-Canary

Staging-Canary はステージング環境の環境サブセットまたはデプロイ「ステージ」であり、ステージングとほとんど同じインフラを共有しています。この追加ステージは、データベースなどのサービスを共有する GitLab の複数バージョンを持つ混合デプロイ環境で発生する問題を早期発見するよう設計されています。アクセス方法、使用方法、対象サービスについての情報はカナリアステージ環境に関するハンドブックページに記載されています。

Staging-Canary のデプロイはリリースに説明されているようにステージングのデプロイに先行し、ステージングと同じ頻度でデプロイされます。デプロイ時に 2 セットのブロッキング smoke テストスイートが実行されることを注意してください。1 セットは Staging-Canary を対象としています。もう 1 セットはステージングを対象としています。両セットのテストが合格する必要があります。Staging-Canary のデプロイを成功させるために、これは混合バージョンのデプロイ環境から発生する問題を洗い出すために特別に設計されています。Downstream QA パイプラインを検査することで、どの環境でテストが失敗しているか判断できます。

Staging Ref

Staging Ref は最新の Staging Canary コードの本番前テストに使用されるサンドボックス環境です。3k Cloud Native Hybrid リファレンスアーキテクチャ環境です。Staging Ref は Staging Canary と並行して Deployer と GitLab Environment Toolkit を使用してデプロイされます。環境は必要に応じて自動的に破棄・再構築できます。初期テストデータはデプロイ時に投入されます。詳細は Staging Ref ドキュメントを参照してください。

Staging Ref で自分に割り当てられた QA Issue をテストするためのアカウントが必要な場合、本番アカウントを使用してログインできます。それ以外でアカウントを作成する必要がある場合は access-request プロジェクト に Issue を作成し、マネージャーにレビューを依頼してください。データベースとサーバー環境へのアクセスリクエストには、マネージャーと Infrastructure マネージャーのいずれかの承認が必要です。このタイプのアクセスを申請するためにも同じ access-request トラッカー を使用してください。

Pre

pre 環境は、最終的なセルフマネージドリリースと本番パッチの準備に使用するリリース候補の検証に使用される環境です。完全な本番 HA トポロジーや本番データベースのコピーを持っていません。

さらに、pre 環境は SRE がインフラの変更を検証するためにも使用されるため、staging と production の設定と一致していることが重要です。

リリース

リリース環境はセキュリティリリース、セルフマネージドの最終月次・パッチバージョンの検証に使用される環境です。完全な本番 HA トポロジーや本番データベースのコピーを持っていません。

release 環境は現在のマイルストーンのすべてのパッケージ、つまり 16.2.0 がタグ付けされるまでのすべての 16.1.X パッケージを受け取り、テストします。

GitLab チームサービス

GitLab チームサービス環境は GitLab が運営するさまざまなサイトのサービスグループです。上記のサイトで構成されています。これらは Terraform で管理されておらず、Auto DevOps や GitLab Pages などの GitLab 機能をドッグフーディングしています。

GitLap

GitLap 環境はサポートテスト用に主に使用される古いドメインです。 *.dev.gitlap.com と *.do.gitlap.com 配下のすべての DNS レコードは dev-resources リポジトリ の Terraform で管理されています。

唯一重要なシステムは gitlab-runner-builder.gitlap.com で、 gitlab-runner プロジェクト の CI ランナーとして使用されています。

Env-Projects

この環境は、gitlab.com のサポート/管理/ホスティングに使用されるすべての GCP プロジェクトがプロビジョニングされる起点プロジェクトとして使用されます。プロジェクトにコンピュートリソースは存在せず、GCP プロジェクトを一元管理し、それらのプロジェクト内でのインフラデプロイのための IAM ロール/サービスアカウントをプロビジョニングし、Infrastructure as Code（Terraform）を通じて各 GCP プロジェクトで有効になっている API を制御するためのメカニズムを提供するためにのみ使用されます。

参考: https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/tree/main/environments/env-projects

セルフマネージド

これらはエンドユーザーによりオンプレミスで運用される環境です。私たちはこれらの環境に対して影響、アクセス、制御を持ちません。

ページのソースコードを見る - ページの編集 - please contribute.