GitLab Delivery: Operate

Operate チームは、標準化されたツール、リファレンスアーキテクチャ、運用エクセレンスフレームワークを通じて、オペレーターがあらゆる規模で GitLab 環境をデプロイおよびメンテナンスできるよう支援します。GitLab デプロイのためのデプロイインフラと運用ツールを提供します。

概要

Operate チームは、GitLab をさまざまな環境と規模でデプロイできるようにするデプロイツールと運用インフラを構築・維持します。私たちは GitLab のデプロイを実現可能でメンテナンス可能にするツール、自動化、ガイダンスを開発しており、開発チームは GitLab のアプリケーション機能と機能性の所有権を保持しています。

ミッション

Operate チームは、GitLab をさまざまな環境で信頼性高くインストールおよび運用できるようにするデプロイ自動化、インフラツール、運用フレームワークを構築・維持します。私たちは GitLab のパッケージ化されたコンポーネントと多様なインフラ環境での成功したデプロイのギャップを埋めるツールを開発します。

私たちのフォーカスは、GitLab のデプロイを簡素化し、運用の複雑さを軽減する標準化されたデプロイツール、インフラ自動化、運用ガイダンスを作成することです。

戦略的ビジョン

私たちは複数のデプロイパターンをサポートするデプロイツールを開発・維持します:

シングルノードデプロイ

ツール: Build チームとの Omnibus デプロイメカニクスの共同所有
フォーカス: シンプルなインストール自動化、アップグレードプロセス、運用ガイダンス
サポート: シングルノード構成のドキュメントとトラブルシューティング

マルチノードおよびクラウドネイティブデプロイ

ツール: Omnibus、GitLab Charts、GitLab Operator、GitLab Environment Toolkit (GET)、リファレンスアーキテクチャ
フォーカス: インフラ自動化、大規模なオーケストレーション、ゼロダウンタイム運用
サポート: マルチノード構成のドキュメントとトラブルシューティング

チームメンバー

以下の人々がチームのメンバーです:

チームメンバー情報は原文 (英語) を参照してください。

プロダクトマネージャー: Martin Brümmer

主要責任

デプロイツール開発

Omnibus 統合: Build チームとのデプロイメカニクスの共同開発
GitLab Charts (Helm): 包括的な設定オプションを持つプライマリ Kubernetes デプロイメソッド
GitLab Operator: OpenShift と vanilla Kubernetes に GitLab をデプロイするための Kubernetes オペレーター（新バージョン開発中）
GitLab Environment Toolkit (GET): インフラプロビジョニングと設定自動化
リファレンスアーキテクチャ: デプロイパターン、サイジングガイダンス、アーキテクチャ仕様

インフラ自動化

プロビジョニング自動化: クラウドプロバイダー全体で一貫したインフラセットアップのためのツール
設定管理: GitLab デプロイの自動設定
スケーリング自動化: 水平および垂直スケーリングのためのツールとプロセス

運用ガイダンスと標準

ドキュメント: インストール手順、運用ランブック、トラブルシューティングガイド
ベストプラクティス: 運用標準とデプロイガイダンス

主要プロジェクトとツール

GitLab Charts (Helm) - プライマリ Kubernetes デプロイ

リポジトリ: gitlab-org/charts/gitlab ドキュメント: docs.gitlab.com/charts/

Kubernetes 上に GitLab をデプロイするための主要な方法であり、以下を提供します:

すべての GitLab コンポーネントの包括的な Helm チャート
さまざまなデプロイシナリオ向けの柔軟な設定オプション
クラウドネイティブエコシステム（Ingress、cert-manager など）との統合
広範なカスタマイズ機能を持つ本番対応のデフォルト設定
GitLab リリースに合わせた定期的な更新

GitLab Operator（限定提供）

リポジトリ: gitlab-org/cloud-native/gitlab-operator

現在、置き換えの計画を持つ限定提供:

Kubernetes ネイティブのライフサイクル管理（限定スコープ）
新しいオペレーターバージョンで置き換え予定
本番 Kubernetes デプロイには現在 GitLab Charts を推奨

GitLab Environment Toolkit (GET)

リポジトリ: gitlab-org/gitlab-environment-toolkit

リファレンスアーキテクチャに従ってスケールされた GitLab 環境をデプロイするための意見のある Terraform および Ansible スクリプト。GET は以下を提供します:

クラウドプロバイダー全体での標準化されたインフラプロビジョニング
クラウドネイティブ環境向けの GitLab Operator との統合
自動設定管理
デプロイモデル間の明確な移行パス

リファレンスアーキテクチャ

リポジトリ: gitlab-org/quality/reference-architectures

以下を提供するスケールされたデプロイパターン:

実際の使用メトリクスに基づいたリアルワールドのサイジングガイダンス
さまざまな規模と要件に対する検証済みの設定
新しいサービスの統合パターン

Operate チームとの連携

Slack チャンネル

#g_operate - ディスカッションとリクエストのためのプライマリチャンネル
#gitlab_environment_toolkit - GET 固有のディスカッションと質問
#reference-architectures - リファレンスアーキテクチャのディスカッションとリクエスト
チームハンドル: @gitlab-org/software-delivery/operate

サポートヘルプリクエスト

GitLab は顧客をサポートするためのヘルプリクエスト（RFH）を開くための統合プロセスを提供しています。このプロセスはシングルソースオブトゥルースを確保し、多くの場合リクエストは製品の複数の領域の専門知識を必要とするか、最初はどの領域が顧客をサポートするのに適しているか明確でないため、クロスファンクショナルな協力をより良く行えるようにします。同じサポートリクエストプロセス内で複数の関連グループと情報を共有することで、より効率的にソリューションに到達できます。

RFH を開くには、ヘルプの入手方法ハンドブックページの手順を参照してください。

このプロセスにより、関与した時間を追跡し、正しい関係者が適切なタイミングで関与することを確保できます。

環境構築リクエスト

Operate チームはキャパシティの制約により、カスタム環境構築リクエストを受け付けられません。 また、GET を使用して大規模なサンドボックス環境を構築することは、厳密に必要でない限りコストへの影響から一般的に推奨されません。ただし、これらのタイプの環境をセルフサービスで構築するためのいくつかのオプションがあります:

GET ドキュメントを使用したセルフサービス
- チームは包括的な GET ドキュメントに従って独自の環境を構築できます。これはカスタム環境が必要なチームにとって推奨される主要なアプローチです。
- テストと開発目的でクラウドアカウントをセットアップするには、自動化された Sandbox Cloud の利用が推奨されています。
GitLab をローカルで実行する: よりシンプルなニーズには、コストと複雑さを軽減するために大規模な環境を構築するのではなく、GDK や Docker をローカルで実行することをお勧めします。
インフラからの共有環境を使用する: インフラチームが提供する既存の共有環境を活用します。

コミュニティとの連携

インストールとアップグレードプロセスは、GitLab を使用するすべてのシステム管理者が最初に経験する機能です。その結果、Operate チームが管理するプロジェクトはユーザーベースから高いエンゲージメントを受けています。GitLab コミュニティはコード貢献者だけでなく、Issue や機能リクエストを記録するユーザーも含まれており、常に私たちを前進させ、より良い体験を生み出す手助けをしています。

私たちは公開プロジェクトで以下を目指しています: