デモシステム
デモシステムの概要
GitLab デモシステムは、GitLab の Customer Success・Marketing・Sales・Training チームが、様々な非同期・ライブの場面で GitLab の機能・価値・ワークフローをデモするためのインフラを提供します。
デモシステムは、Jeff Martin が 2019 年 10 月にシニアデモシステムエンジニアとして設計を開始したものです。現在は (デモアーキテクチャ) チームの Logan Stucker と Seraphine Young、そして Scott Cosentino(GitLab University)がデモシステムの主要メンテナーとして引き継ぎ、トレーニングインストラクターや受講生の GitLab Learn Labs サポートも担当しています。
利用可能なデモサンプルプロジェクトに関するご質問や、失敗したパイプラインジョブのトラブルシューティングについては、#demo-architect-partners Slack チャンネルでお問い合わせください。
インフラやアクセスリクエストに関するご質問は、以下の Slack チャンネルで @Logan Stucker にタグ付けしてください。
#demo-systems— SA・CSM・PSE チームメンバーのご質問や技術サポート用。トレーニング・ワークショップ関連の投稿は対象外です。#demo-architect-partners— ワークショップ関連の議論用。#demo-systems-ps-education— Professional Services の ILT/SPT 等に関する議論用。#sandbox-cloud-questions— Sandbox Cloud(AWS アカウントおよび GCP プロジェクト)のサポート用。
このハンドブックドキュメントを、gitlabdemo.com・gitlabdemo.cloud・gitlabtraining.cloud ドメイン名を使用するすべてのリソースに関する唯一の信頼できる情報源(SSOT)としてください。
デモシステムが必要な理由
GitLab.com を使えばよいのでは? GitLab.com のほとんどの価値はデモできますが、AWS・GCP・ローカル VM/コンテナへの GitLab Omnibus インフラのデプロイが必要な管理機能が一部存在します。また、多くのエンタープライズ顧客がセルフマネージドを選択しているため、「顧客が本番環境で見るものを見せる」ことを意識しています。
インフラに特別な点はありますか? デモシステムのインフラ自体は、適切な人員と技術投資があれば顧客やパートナー企業でも実現できる内容です。
トレーニングクラスやワークショップには特別なスケーラビリティ上の考慮事項がありますか? はい。GitLab 製品は、ユーザーが一日を通じてさまざまな操作を行うことを想定して設計されており、小規模なリファレンスアーキテクチャは、数十人から数百人のユーザーが同じボタンを同時にクリックしたり、同じバックグラウンドジョブやパイプラインジョブを同時に実行したりするようには設計されていません。また、ユーザーはエフェメラルで、通常の GitLab 製品のユースケースでは一般的でない自動ガベージコレクション要件があります。これにより、特に Container Registry・Sidekiq・Kubernetes に関して特別なスケーラビリティの考慮が必要です。スケーラビリティの課題として以下の点が挙げられます。
- 10 秒で起動する 500 の同時パイプライン向けのオートスケーリングランナー
- 60 秒で 500 の同時レビューアプリ/デプロイ向けのオートスケーリング Kubernetes ノード
- 大量のリソースを消費する Auto DevOps パイプライン
- 不要な Kubernetes サービス(例:Postgres データベース)
- ワークショップ中に不要な集中テストジョブ(例:Code Quality・Dependency Scanning 等)
- 500 の同時プロジェクトインポートで失敗するプロジェクトのエクスポート/インポートのキュージョブ
- インポート/エクスポートプロセスで既知の問題がある機能(例:Wiki)
- 受講生への管理者アクセス権限(代替ユースケース)
- パッケージレジストリのキャッシュとガベージコレクション
- コンテナレジストリのキャッシュとガベージコレクション
- レート制限のある Docker Hub からの CI イメージのプル
- 非互換またはバグ修正でアップグレードされた CI イメージバージョン
.gitlab-ci.ymlでテンプレートを使用する際の基礎的なジョブ負荷の見落とし- 実行するアクションのコメントのないカスタム
.gitlab-ci.ymlファイルの使用 - Dependency Proxy の設定(特に npm および maven の依存関係)
- ステップバイステップの手順の欠如による受講生の設定ミスとエラー
共有環境
これらの共有環境は、デモクラウドまたはトレーニングクラウドと呼ばれます。歴史的に、トレーニングユーザーはデモクラウドを使用していたため、会話によっては名前が混用されることがあります。
gitlab-core.us.gitlabdemo.cloud インスタンスは 2021-04-20 に廃止され、2021-06-03 に削除されました。データのバックアップはありません。cs.gitlabdemo.cloud インスタンス(直接の置き換え)へのアクセス手順については、共有 Omnibus インスタンスへのアクセスをご参照ください。
cs.gitlabdemo.cloud— すべてのチームメンバーがアクセスできる主要な GitLab Omnibus インスタンスです。セルフマネージド Omnibus インスタンス上でグループ・プロジェクト・サンドボックスを作成できます。これは全チームメンバーが共有する環境ですので、管理者エリアは読み取り専用として扱ってください。cs-gitlabamazonq.com— Amazon Q を中心としたイネーブルメントとデモに使用されます。gitlab-amazonq.com— Amazon Q の公開インスタンスとして使用されます。ilt.gitlabtraining.cloud— インストラクター主導のトレーニングクラスに使用されます。インストラクターでサンプルプロジェクトのインポートやクラス内の全受講生のグループを確認するための管理者アクセスが必要な場合は、このインスタンスの資格情報を生成してください。spt.gitlabtraining.cloud— EdCast で公開されているセルフペーストレーニングクラスに使用されます。教材設計または自習型の受講生コースの認定採点に関わる場合のみ、このインスタンスの資格情報を生成してください。自習型トレーニングに登録している場合は、招待コードの引き換えの手順に従い、トレーニングラボガイドの手順のために設定済みのインスタンスにアクセスするための一時的な資格情報を生成してください。workshop.gitlabtraining.cloud— 定期的に開催されるイネーブルメントおよびフィールドマーケティングのワークショップに使用されます。ラボサンプルプロジェクトやラボガイドの作成、プレゼンテーション、またはワークショップのサポートに関わる場合は、このインスタンスの資格情報を生成してください。
独立した環境
- AWS アカウント: GitLab Sandbox Cloud を使用して独自の独立した AWS アカウントをプロビジョニングするための手順をご覧ください。
- GCP プロジェクト: GitLab Sandbox Cloud を使用して独自の独立した GCP プロジェクトをプロビジョニングするための手順をご覧ください。
- AWS Elastic Kubernetes Service (EKS) クラスター: AWS アカウントを使用して、GitLab ドキュメントの EKS クラスターの追加に従い EKS クラスターをプロビジョニングできます。
- GCP Google Kubernetes Engine (GKE) クラスター:
group-csGCP プロジェクトのクラスターについては Jeff Martin にメッセージを送ってください。クラスターを GitLab グループに追加するには、グループレベルの Kubernetes クラスターで GitLab を設定するチュートリアルをご参照ください。
はじめ方
これらの手順は、gitlabdemo.cloud ポータルを使用するデモシステム v2 向けです。gitlabdemo.com を使用していたデモシステム v1 インフラは、トレーニングクラスの招待コードを除いて廃止されました。
共有 Omnibus インスタンスへのアクセス
以下の手順により、共有環境(Omnibus セルフマネージドインスタンス)の 1 つ以上にアクセスできます。
デモクラウドポータルとプロビジョニングシステムは、Jeff Martin が作成したオープンソースプロジェクト gitlabdemo-cloud-app によって提供されています。
- GitLab Demo Cloud ポータル(https://gitlabdemo.cloud)にアクセスし、Okta の資格情報でサインインします。
- ナビゲーションの Environments リンクをクリックするか、ダッシュボードの View Environments ボタンをクリックします。
- アクセスしたいインスタンスを探し、Generate Credentials ボタンをクリックします。
- 資格情報が生成されたら、View Credentials ボタンをクリックします。
- 生成された資格情報を 1Password の Vault に新しいレコードとして保存します。
- Access Instance ボタンをクリックすると、GitLab Omnibus インスタンスの URL が新しいタブで開きます。
- インスタンスをブックマークしておくと、次回以降のアクセスが簡単になります。資格情報の生成(アクセスリクエスト)時のみ https://gitlabdemo.cloud ポータルにアクセスする必要があります。
- サインイン後、プロジェクトを保存するためのグループが事前に作成されています。名前空間の一貫性とセキュリティのベストプラクティスのため、カスタム名の他のトップレベルグループは作成しないでください。事前作成されたグループまたは個人の名前空間の下であれば、サブグループやプロジェクトを自由に作成できます。
- 各インスタンスには、共有 GitLab Runner と Kubernetes クラスターが事前設定されています。これらは CI/CD パイプライン実行時に使用するためのもので、共有環境では管理アクセスはありません。
#cs-questionsSlack チャンネルで他のメンバーに質問できます。
AWS アカウントまたは GCP プロジェクト(Sandbox Cloud)
独自の AWS アカウントおよび/または GCP プロジェクトを作成し、集中課金のメリットを享受しながら独自のインフラをデプロイするための手順については、Sandbox Realm ハンドブックページをご参照ください。
招待コードの作成
https://cloud.gitlabdap.com/ にアクセスし、GitLab チームメンバーとしてサインインして、ニーズに応じたコンテンツ/ラボリクエストフォームに入力してください。ご質問は #demo-architect-partners Slack チャンネルまでお問い合わせください。
招待コードの引き換え
GitLab チームメンバーへの警告: このプロセスでは既存の GitLab.com アカウントを使用するため、事前に準備が完了していることを確認してください。
- https://cloud.gitlabdap.com/ にアクセスし、Workshop/Lab Redemption ボタンをクリックします。
- Sign In With GitLab をクリックします。
- インストラクターまたはコース資料から提供された招待コードを入力します。
- Submit Code を押します。
- 青い My Group ボタンをクリックすると、Learn Labs 上の GitLab グループの URL が新しいタブで開きます。
ワークショップの準備
ワークショップのプロセスは複数回イテレーションされました。最新バージョンのワークショップ準備プロセスは、セルフサービスモデルとして簡略化されています。
ワークショッププレゼンターおよびサポートチームメンバーとして、サンプルプロジェクトとラボガイドコンテンツのインポートとテストを行う責任があります。プロジェクトや CI ジョブの設定ミス、パイプラインの失敗、GitLab Runner のエラーメッセージに対するサポートは提供されません。
フィールドマーケティングチームとのスケジュール調整以外に、ピアレビューや承認プロセスはありません。これらの手順はベストプラクティスのガイダンスです。サポートが必要な場合は、#demo-architect-partners Slack チャンネルで同様のワークショップを実施した経験のある他のチームメンバーに相談してください。
ワークショップの準備手順は、こちらのリクエストフォームに記入すると作成される Issue にリンクされます。
ワークショップラボガイドカタログ
公式に作成されたワークショップコンテンツはすべて、デモアーキテクトポータルのコンテンツディスカバリーセクションで確認できます。
バージョンアップグレードとメンテナンス
月次リリース翌週の週末にバージョンアップグレードを実施します。週末のアップグレードは、エンジニアの都合に合わせて土曜日または日曜日のランダムな時間に行われ、約 30 分かかります。
リスクが高いと判断したアップデートや休暇期間中のアップデートは、アップグレードウィンドウを延期します。これは毎年 5 月の米国メモリアルデーの休日、12 月のクリスマス休暇、そして 1 月の年度末(販売デモが完了するまで設定フリーズ期間)に発生します。
パッチおよびセキュリティアップデートについては、通常、重要なアップデートのみアップグレードを実施し、Slack の #demo-systems チャンネルでメンテナンスウィンドウをアナウンスします。
レガシーバージョンサポート
私たちは、最新の機能とソリューションが提供する価値を紹介するために、共有環境を最新バージョンに保ちます。
古いバージョンが必要なデモやサンドボックスのユースケースについては、コンテナサンドボックスのコンテナや、コンピュートサンドボックスの Omnibus を使用して GitLab インスタンスをデプロイできます。データの移行やパリティ設定のサポートは提供しません。
GitLab Duo 機能
GitLab Duo はデモクラウド環境で有効化されています。管理者設定で自分や他のユーザーにシートを割り当てることができます。
チュートリアル
サンプルデータ
これまで、一貫したデモデータのセットは存在していませんでした。Solutions Architects はそれぞれ独自のデモデータを作成するか、他のチームメンバーのプロジェクトをフォークしています。
はじめるには、ハンドブックの デモ準備 および 既存のデモ ページをご参照ください。
進行中のクラウドソース OKR や Communities of Practice の開発に関する詳細は、Solutions Architecture Initiatives Issue トラッカーをご参照ください。
プロジェクトとコードリポジトリ
以下は、デモシステムを裏側で支えるプロジェクトです。ソースコードを自由に調べて学ぶことができます。各プロジェクトは、ソースコードや含まれる情報のセキュリティリスクに応じて Public(公開)または Private(非公開)に分類されています。
デモシステム v2(廃止済み)
Public基礎となる Terraform モジュールと Ansible ロールPublic組み立て済み Terraform モジュールと環境Private環境の IaC —terraform/terraform.tfvars.jsonと CI パイプラインを参照Public管理アプリケーション- management-apps/gitlabdemo-cloud-app
- gitlab.com/hackystack/hackystack-portal(オープンソース名前空間)
- sandbox-cloud/apps-tools/hackystack-portal(Ultimate 機能用ミラー)
Private - OpsSandbox Cloud インフラPrivateランブック
デモシステム v1(廃止済み)
デモシステム v1 のリポジトリは gitlab.com/gitlab-com/customer-success/demo-systems にあります。
PrivateTerraform モノリス環境とモジュールPrivateAnsible モノリス設定とロールPrivate管理アプリケーション(gitlabdemo.com)- Issue トラッカー
関連インフラのハンドブックリンク
- GitLab Sandbox Cloud
- GitLab インフラ標準
- GitLab インフラ標準 — ラベルとタグ
- デモシステム Kubernetes アーキテクチャドキュメント
- デモシステムネットワークアーキテクチャとサブネットドキュメント
ヘルプとサポート
リアルタイムのサポートや迅速な対応には Slack を使用します。サポートの問い合わせ方法に迷った場合は、#demo-systems にお問い合わせください。30 分以上かかるタスクやプロジェクトには Issue トラッカーを使用します。内部チームコミュニケーションにメールは使用しません。
- デモシステム Issue トラッカー
#demo-systemsSlack チャンネル(デモクラウドのアナウンス・質問・技術サポート用)#demo-systems-ps-educationSlack チャンネル(ILT/SPT トレーニングラボの議論用)#demo-systems-workshopsSlack チャンネル(ワークショップの議論用)#sandbox-cloudSlack チャンネル(Sandbox Cloud のアナウンス用)#sandbox-cloud-questionsSlack チャンネル(Sandbox Cloud の質問と技術サポート用)[email protected](Slack を使用しないユーザー向け)
