• AWS 実装パターン情報
  • GitLab サイト信頼性エンジニアリング(SRE) for AWS
  • GitLab Cloud Native HybridをAWS EKSにインストールするパターン(HA)
  • AWS EC2にLinuxパッケージを使ってGitLabをインストールするパターン(HA)
  • EKSクラスタ・プロビジョニングのパターン
  • AWS EC2 Auto ScalingグループでHA GitLab Runnerをスケーリングするパターン(ASG)
  • AWSでGitLabを使うためのパターン
• AWS既知のイシューリスト
• GitLabインスタンスをAWSにプロビジョニングします。
  • マーケットプレイスの購読
  • GitLab公式のAMIリリース
• 実装パターンの詳細
  • クラウドプラットフォームのコンプライアンス
  • プラットフォーム・パートナーの特異性
  • PaaS（Platform as a Service）の仕様と使い方
  • コスト最適化エンジニアリング
  • アクション性と自動化志向
• 補足的な実装パターン
• 対象者と貢献者

AWSの実装パターン

GitLabリファレンスアーキテクチャは、様々なワークロードのパフォーマンス要件を満たすために推奨されるGitLabの設定方法について、適格かつテストされたガイダンスを提供します。リファレンスアーキテクチャは、できるだけ多くの環境に外挿できるように、実装に特化しないように設計されています。これは一般に、「マシン」から「サーバー・ロール」までの粒度の高い仕様を持ち、性能に影響を与えるシステム要素に焦点を当てていることを意味します。これによって、リファレンスアーキテクチャは、サポートされる実装の最も広い数に適応することができます。

実装パターンは、リファレンス・アーキテクチャのために行われた基礎的な情報とテストの上に構築されており、GitLab、GitLabカスタマー、GitLabパートナーのアーキテクトや実装者が、より少ない実験で、より高い信頼性で、期待通りのパフォーマンスを発揮するデプロイを構築することを可能にします。実装パターンについてのより詳細な議論は、実装パターンについての追加の詳細で後述します。

AWS 実装パターン情報

GitLabをAWS上に実装する場合、現在利用可能な実装パターンは以下の通りです。

GitLab サイト信頼性エンジニアリング(SRE) for AWS

GitLab Site Reliability Engineering(SRE)for AWS - AWS上のGitLabインスタンスとRunnerの計画、実装、アップグレード、長期管理のための情報です。

GitLab Cloud Native HybridをAWS EKSにインストールするパターン(HA)

AWS EKS(HA) に GitLab Cloud Native Hybrid をプロビジョニングします。このドキュメントには、AWS EKS上にGitLab Cloud Native Hybridをインストールするための手順、パターン、自動化が含まれています。また、部品表のリストやInfrastructure as Codeへのリンクも含まれています。GitLab Cloud Native Hybridは、KubernetesにGitLabを可能な限り入れるためのサポートされた方法です。

AWS EC2にLinuxパッケージを使ってGitLabをインストールするパターン(HA)

Amazon Web Services(AWS) に GitLab POC をインストールする- EC2 インスタンスに GitLab をインストールする手順。GitLabインスタンスを構築したり、独自のInfrastructure as Code (IaC)を作成するための手動手順。

EKSクラスタ・プロビジョニングのパターン

EKSクラスタ・プロビジョニング・パターン- Runnerおよびインテグレーション用にEKSクラスタをセットアップする際の考慮事項。

AWS EC2 Auto ScalingグループでHA GitLab Runnerをスケーリングするパターン(ASG)

以下のリポジトリは、このパターンを有効にすることに関して自己完結しています：GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG.この実装パターンの機能リストは、それが提供できる完全な価値を理解するためにレビューするのが良いでしょう。

AWSでGitLabを使うためのパターン

AWSのGuided Explorationsサブグループには、様々なサンプルプロジェクトがあります：

• GitLab と AWS の併用。
• AWS上でGitLabインフラストラクチャを実行します。
• AWSサービスにアクセスするための一時的な認証情報を取得します。

AWS既知のイシューリスト

既知のイシューはGitLabの内部やレポーターから集められたものです。顧客は、GitLabが特別に設計されていない様々な “as a Service “コンポーネントとGitLabをうまく実装しています。GitLabはパートナーの技術を非常に重要視していますが、ここで既知のイシューを強調しているのは実装者の便宜のためであり、GitLabがそのイシューが発生するパートナーの技術との互換性を目標としていることを意味するものではなく、またその技術での動作を保証するものでもありません。GitLabの既知の問題に対するスタンスや計画を理解するには、個々のイシューを参照してください。

完全なリストはGitLab AWS既知のイシューリストをご覧ください。

GitLabインスタンスをAWSにプロビジョニングします。

AWS上で単一のGitLabインスタンスをプロビジョニングしたい場合、2つの選択肢があります：

• マーケットプレイスのサブスクリプション
• GitLab 公式 AMI

マーケットプレイスの購読

GitLabは、AWS Marketplaceサブスクリプションとして5ユーザーサブスクリプションを提供し、あらゆる規模のチームが記録的な速さでUltimateライセンスインスタンスを開始できるよう支援します。Marketplaceサブスクリプションは、AWS Marketplaceの非公開オファーを介して、AWSの課金を継続する利便性で、任意のGitLabライセンスに簡単にアップグレードすることができます。GitLabからより大きな、時間ベースでないライセンスを取得するためのマイグレーションは必要ありません。非公開オファーを受け入れると、分単位のライセンスは自動的に削除されます。

Marketplace Subscriptionを使ったGitLabインスタンスのプロビジョニングについては、こちらのチュートリアルをご覧ください。このチュートリアルはGitLab Ultimate Marketplace Listing にリンクしていますが、GitLab Premium Marketplace Listingを使ってインスタンスをプロビジョニングすることもできます。

GitLab公式のAMIリリース

GitLabは通常のリリースプロセスでAmazon Machine Images(AMI) を作成します。AMIはシングルインスタンスのGitLabインストールに使用することもできますし、/etc/gitlab/gitlab.rbを設定することで、特定のGitLabサービスのロール（例えばGitalyサーバ）に特化させることもできます。古いリリースも引き続き利用可能で、古いGitLabサーバーをAWSにマイグレーションするために利用できます。

初期ライセンスは、無料のエンタープライズ・ライセンス(EE) か、オープンソースのコミュニティ・エディション(CE) のどちらかになります。Enterprise Editionは、必要な場合にライセンス版への最も簡単なパスを提供します。

現在、Amazon AMIは、Amazonが準備したUbuntu AMI（x86とARMが利用可能）を出発点として使用しています。

Community Edition(CE) で稼働しているインスタンスは、GitLab PremiumまたはUltimateプランに加入するためにEnterprise Edition(EE) へのマイグレーションが必要です。サブスクリプションを利用する場合は、Enterprise EditionのFree-foreverプランを利用するのが最も混乱が少ない方法です。

1. AWS Web Consoleにログインして、次のステップでリンクを選択するとAMIリストに直接移動できるようにしましょう。

2. 必要なエディションを選択します：

   • GitLab Enterprise Edition：エンタープライズ機能をアンロックしたい場合、ライセンスが必要です。
   • GitLab Community Edition：GitLabのオープンソース版。
   • GitLabプレミアムまたはアルティメットマーケットプレイス（プリライセンス）：分単位の課金に組み込まれた5ユーザーライセンス。
3. AMI IDは地域ごとに一意です。これらのエディションのいずれかをロードした後、コンソールの右上隅で、適切なAMIを表示するために希望のターゲットリージョンを選択します。
4. コンソールがロードされたら、検索条件を追加してさらに絞り込むことができます。例えば、13. と入力すると、13.x バージョンのみを検索できます。
5. リストされたAMIの1つを使ってEC2マシンを起動するには、該当する行の先頭にあるチェックボックスをオンにし、ページの左上付近にあるLaunchを選択します。

実装パターンの詳細

GitLabの実装パターンは、以下の方法でGitLabリファレンスアーキテクチャをベースにしています。

クラウドプラットフォームのコンプライアンス

テストに裏打ちされたアーキテクチャの適格性は、実装パターンの基本概念です：

• 実装パターンはGitLabリファレンスアーキテクチャへの準拠を維持し、GitLabパフォーマンスツール (GPT) 。
• 実装パターンは、テクノロジーベンダーによって認定されたり、貢献したりすることがあります。例えば、AWS用の実装パターンは、AWSによって公式にレビューされるかもしれません。
• 実装パターンは、Cloud Platform PaaSサービスがGitLabに適しているかどうかを指定し、テストするかもしれません。このテストは調整することができ、リファレンスアーキテクチャのためにこれらのテクノロジーを適格にするのに役立ちます。例えば、PostgreSQLやRedisのようなトップレベルのPaaSのランタイム・バージョンとの互換性や可用性の検証などです。
• 例えば、Gitalyクラスタが特定のクラウドプラットフォームのアベイラビリティゾーンのレイテンシとスループットの特性で正しくオペレーションできることを確認したり、Gitalyサーバが整合性を持って動作するために、利用可能なプラットフォームパートナーのローカルディスクのパフォーマンスがどのレベルまで動作可能であるかを確認したりします。

プラットフォーム・パートナーの特異性

実装パターンは、プラットフォーム固有の用語、ベストプラクティスアーキテクチャ、プラットフォーム固有のビルドマニフェストを可能にします：

• 実装パターンは、よりベンダー固有のものです。例えば、vCPUやその他の一般的な指標ではなく、特定のコンピュートインスタンス/VM/ノードを推奨するインスタンスンスンス。
• インプリメンテーション・パターンは、ベンダーの視点に立った優れたアーキテクチャを実装することを指向しています。
• 実装パターンは、その実装パターンが対象としているインフラストラクチャでの構築に精通している読者に向けて書かれています。例えば、実装パターンがGCPのためのものであれば、GCP特有の用語が使われます。
• 実装パターンは、利用可能なPaaSのバージョンがGitLabと互換性があるかどうかをテストし、認定することができます（例えば、PostgreSQL、Redisなど）。

PaaS（Platform as a Service）の仕様と使い方

Platform as a Serviceオプションは、運用の複雑さを簡素化し、高度で可用性の高いテクノロジー・サービスを運用するために必要なSREやセキュリティのスキルを軽減するため、クラウド・プラットフォームが提供する価値の大部分を占めています。実装パターンは、パートナーのPaaSオプションに対して事前に検証することができます。

• 実装パターンは、実装者が、どのPaaSオプションが機能することが知られているのか、また、1つのプラットフォームが同じGitLabのロールに対して複数のPaaSオプションを持っている場合、PaaSソリューション間でどのように選択すればよいのかを理解するのに役立ちます。
• 例えば、リファレンス・アーキテクチャーがGitLabの送信メール・サービスにどのようなテクノロジーを活用するか、あるいはどのようなサイジングにすべきかについて具体的な推奨を持っていない場合、リファレンス・インプリメンテーションはクラウド・プロバイダーのEmail as a Service（PaaS）の利用を勧めるかもしれません。

コスト最適化エンジニアリング

コストエンジニアリングはクラウドアーキテクチャの基本的な側面であり、プラットフォームで利用可能な節約機能は、スケーリングされたコンピューティングの構築方法に強い影響を与えることがよくあります。

• 実装パターンは、最小アイドリング設定やスケーリング速度など、GitLabインフラの様々な側面に対してGPTテスト済みのオートスケーリングを定義することができます。
• 実装パターンは、リファレンスアーキテクチャの範囲を超えるアドバイスされた設定のためのGPTテストを提供することができます。例えば、クラウドネイティブハイブリッドのためのGPTテストされた弾力的なスケーリング設定は、使用量が少ない期間（例えば週末）にリソースを少なくすることを可能にします。
• 実装パターンは、プラットフォーム・プロバイダで利用可能な節約モデルに特化したエンジニアリングを行うことができます。AWSの例では、リザーブドインスタンスを活用するために特定のインスタンスタイプの発生を最大化します。
• 実装パターンは、適切な顧客ガイドラインがあれば、エフェメラル・コンピューティングを活用することができます。例えば、エフェメラル・コンピュート上のRunner専用のKubernetesノード・グループ（コンピュート・タイプを示す適切なGitLab Runnerタグ付き）。
• 実装パターンには、ベンダー固有のコスト計算機を含めることができます。

アクション性と自動化志向

実装パターンは、ビルド手順や自動化コードのソースとして使用できる仕様に一歩近づいたものです：

• インプリメンテーション・パターンを使うことで、ビルダーは与えられたリファレンス・アーキテクチャに対してGitLabを実装するために必要なベンダー固有のリソースのリストを生成することができます。
• 実装パターンによって、構築者は手動による指示を使用したり、リファレンス実装を構築するための自動化を作成したりすることができます。

補足的な実装パターン

実装パターンは、リファレンスアーキテクチャに準拠する範囲を超えた特殊な実装を提供することもできます。

使用例：

• 小規模で自己完結型のGitLabインスタンスで、一人一人の管理トレーニングを行うことができます。おそらくKubernetes上で、デプロイクラスターも自己完結型になります。
• GitLab Runnerの実装パターン（プラットフォーム固有のPaaSの利用を含む）。

対象者と貢献者

この情報の主な対象者および貢献者は、少なくとも以下のメンバーで構成される GitLabImplementation Eco Systemです：

GitLab実装コミュニティ：

• お客様
• GitLabチャネルパートナー(インテグレーション)
• プラットフォームパートナー

GitLab 内部実装チーム：

• 品質 / ディストリビューション / 自己管理
• アライアンス
• トレーニング
• サポート
• プロフェッショナルサービス
• 公開セクター