クラスタの使用¶

Bastion サーバーの設定¶

クラスタを作成するには、まず Genvid bastion サーバーが実行されているかを確認してください。Bastion サーバーは、 genvid-bastion スクリプトを使用して設定および管理することができます。次のコマンドを実行すると、必要最小限のサービスで設定できます。

Shell から

genvid-bastion install --bastionid mybastion --checkmodules --update-global-tfvars --loadconfig

--bastionid mybastion

Bastion の一意の識別子です。次の形である必要があります。

3 ～ 64 文字。
小文字、数字、ハイフンのみで構成。
冒頭は必ずアルファベット。

--checkmodules

このオプションを使用して、インストールされていない場合に新しいモジュールをインストールしたり、既にインストールされている場合は更新を行います。

--update-global-tfvars

このオプションを使用してグローバル Terraform 変数を更新します。

--loadconfig

このオプションを使用して Bastion にジョブとログをロードします。

重要

Windows ファイルシステムのディレクトリの長さには制限があるため、システムユーザー名と Bastion ID もクラスタ名の最大文字数に影響します。名前の長さの制限は適度に安全な設定になっていますが、技術的には、ユーザーが特に長いユーザー名や Bastion ID を使用した場合、この制限でも問題が発生する可能性があります。

次のステップで、クラスタを管理するための Bastion-UI の Web サイトを開きます。

genvid-bastion monitor

Bastion-UI ページで、Bastion 名を変更できます。

Bastion の名前を変更します。

Update をクリックします

Terraform ページで:

Add Config をクリックします。

一意の ID を入力します。

カテゴリに cluster を選択します。

注釈

クラスタ ID の長さは、技術的な制約から 64 文字に制限されています。

必要に応じて、他の backend を選択することができますが、現時点ではデフォルトのままにしておきます。バックエンドによっては、変数の設定が必要になる場合があります。

クラスタのクローン¶

似た構成の異なるクラスタを作成する場合、クローン機能を使うと便利です。Terraform 構成画面の Clone ボタンをクリックするとクローン機能を使用できます。

クラスタのステータス¶

クラスタ作成後、ステータスは EMPTY になっています。これは、クラスタにモジュールが必要であることを意味しています。クラスタのステータスには、次のようなものがあります。

VOID: クラスタが存在しない。
EMPTY: クラスタは存在するが、モジュールがない。
DOWN: クラスタを初期化したが、リソースがない。
UP: Terraform apply 処理が成功。
BUSY: コマンドを実行中。
ERROR: クラスタのチェックでエラーが発生。
INVALID: クラスタが無効、またはステータスが不明。

Terraform モジュールのインポート¶

クラスタを構成する前に、モジュールを初期化する必要があります。そうすることで、モジュールのテンプレートがコピーされ、必要なモジュール、プラグインがダウンロードされます。

Commands をクリックします。
SDK-{version}/basic/basic_cluster のモジュールを選択します。
Import module をクリックします。

初期化ログが表示されます。このステップは数秒間で終わります。

タグ¶

クラスタ用に作成されたすべてのリソースには、それらを識別するための以下のタグが付いています:

genvid:cluster-name: クラスタ名。genvid:creator-service-id: Bastion UI で作成したときの Bastion ID。

重要

v1.26 より、リソースに名前が付与されなくなります。識別はタグで行います。

すべての番号付きリソースは、インデックスのオフセットも削除され、単純化のために 1 ではなく 0 から始まります。

encoding-1 -> encoding-0
game-1 -> game-0
internal-1 -> internal-0
public-1 -> public-0
server-1 -> server-0

Terraform 設定¶

Terraform は、クラスタのインフラストラクチャをビルドするために使用します。設定値は、クラスタのインフラストラクチャのビルドに使用されます。クラスタの Settings のサブリンクをクリックして、設定を編集します。

注釈

Studio 固有の設定については、 Studio 設定ページを参照してください。
Tick 固有の設定については、 Tick Setup page を参照してください。

使いやすさのため、ページの設定を JSON ファイルにダウンロードすることもできます。編集したファイルをフォーム上でドラッグ&ドロップして、複数の設定を一度に編集したり、以前の構成に戻すことができます。保存されていない構成は失われるため、注意してください。

設定	説明	デフォルト値
admin_password	Windows マシンの管理者パスワードです。Windows マシンは、他のサーバーインスタンス、または [1] に同じ外部 IP が設定された他のマシンからのみ、アクセス可能です。	1genvid6
ami_prefix	ゲーム AMI の共通プレフィックスです。 AMI の保存のセクションで使用したプレフィックスです。自分の AMI でテストしたい場合は、変更することができます。	default
ami_version	AMI の正しいバージョンを探すためのプレフィックスフィルタ。クラスタを異なる SDK バージョンにバインドしたい場合は変更可能。	Current SDK version
azs	(オプション) 使用する AZ リストを指定します。指定しない場合、すべてを使用します。ゲームインスタンスは、ここに記載されている最初の az で実行されるため、ゲームを実行するために使用する ec2 インスタンスタイプがサポートされていることを確認してください。AWS のロードバランサーを使用する場合、少なくとも 2 つのアベイラビリティゾーンを提供する必要があります。	[]
custom_tags	Map of user defined tags to add to all cloud resources. [*] [4]	{}
datacenter	Nomad がローカルエージェントのグループ化に使用するデータセンター名です。	default
instance_encoding_count	Terraform が作成するエンコーディングサーバー数を指定します。	1
instance_encoding_type	Terraform がサーバーのエンコードに使用する AWS インスタンスのタイプを指定します。	c5.2xlarge
instance_game_count	Terraform が作成するゲームサーバー数を指定します。	1
instance_game_type	Terraform がゲームサーバーに使用する AWS インスタンスのタイプを指定します。	g2.2xlarge
instance_internal_count	Terraform が作成する内部サーバー数を指定します。	1
instance_internal_type	Terraform が内部サーバーに使用する AWS インスタンスのタイプを指定します。	t2.small
instance_public_count	Terraform が作成するパブリックサーバー数を指定します。	1
instance_public_type	Terraform がパブリックサーバーに使用する AWS インスタンスのタイプを指定します。	t2.small
instance_server_count	Terraform が作成する admin サーバー数を指定します。	1
instance_server_type	Terraform が admin サーバーに使用する AWS インスタンスのタイプを指定します。	t2.small
leaf_port	Leaf サービスがリッスンしているポートです。	30001
region	クラスタを作成する AWS 領域です。G2 インスタンスを含むすべてのリージョンを使用できます。	us-east-1
subnet_cidr_block_size	サブネットの CIDR ブロックのサイズを設定します。サブネットはアベイラビリティゾーンにまたがっており、すべてのサブネットの合計サイズが VPC の CIDR ブロック (10.0.0.0/16) 内に収まっている必要があります。	28
trusted_cidr	信頼する CIDR。少なくともローカルマシンの外部 CIDR (<ip>/32) が含まれている必要があります。含まれていない場合、Consul/Nomad への提供とアクセスは失敗します。注釈: これは bastion が実行されている場所の外部 IP に予約されています。コマンド `genvid-bastion update-global-tfvars` で制御します。他の値を追加するには、`trusted_cidrs` 設定を使用してください。	<yourip>/32
trusted_cidrs	信頼する CIDR リスト。	null
trusted_security_groups	信頼するセキュリティグループの一覧。	null
use_drive_encryption	暗号化された EBS を持っていることを検出するためのブール値。暗号化された EBS にしたい場合は true を選択します。EBS を暗号化したくない場合や、SDK のバージョンを 1.24 以下から 1.25 にアップグレードする場合は、false を選択してください。警告: 1.25 以前の SDK バージョンで EBS が暗号化されていない既存のクラスタがある場合に true を選択すると、すべてのデータを失うことになります。 [2]	true
web_health_check_path	Web サービスのヘルスチェックのエンドポイントパス。web.nomad.tmpl で定義したパスと一致させる必要があります。 [2]	/health
web_port	web サービスがリッスンしているポートです。	30000

[*]	カスタムタグに加えて、Genvid はリソースに独自のタグを追加する権利を有します。文書化されていない場合は、後方互換性を保証することなく、Genvid で使用することを意図しています。

[1]	セキュリティ向上のため、将来のクラスタのバージョンでは bastion ホストを使用する予定です。

[2]	(1, 2) バージョン 1.25.0 で追加.

それぞれのクラスタの詳細な説明は、こちらをご覧ください。: Terraform 基本モジュール

必要に応じて、負荷バランスと SSL を有効にできるクラスタを用意しておくと良いでしょう。モジュールは basic_cluster_alb_ssl と命名されます。 basic_cluster の変数に加えて、以下の変数が利用可能です。

設定	説明	デフォルト値
domain_name	ルートドメイン名	acme.com
subdomain_name	サブドメイン名。AWS (twitch.acme.com) にゾーンを作成するのに使用します。注釈: サブドメインの変更/更新を行う場合、古いサブドメインの NS を AWS Route53 のメインドメインから手作業で削除する必要があります。古い NS レコードは自動で削除されません。	twitch
leaf_stickiness_ttl	Leaf ターゲットグループの粘着性のタイムアウトを設定します。	600
leaf_tg_stickiness_enabled	Leaf ターゲットグループの粘着性を有効または無効に設定します。	600
validation_method	AWS からの SSL 発行証明書の検証方法 (DNS、メール、なし)。	DNS
web_stickiness_ttl	Web ターゲットグループの粘着性のタイムアウトを設定します。	600
web_tg_stickiness_enabled	Web ターゲットグループの粘着性を有効または無効に設定します。	600

次の 2 つの設定値は、環境変数をもとに自動的に設定されます。手動で設定する必要はありません。

cluster は使用するクラスタの名称です。

bastionid は、使用する Bastion の名称です。

basic_cluster および basic_cluster_alb_ssl の構成は、新しい VPC やキーペアを作成したりなどのあらゆる処理を行います。より細かな制御を行いたい場合や、限られた権限のため AWS VPC や Role の作成が行えない場合は、 minimal_cluster と minimal_cluster_alb_ssl の構成を行って、以下の要素を得られます。

設定	説明	デフォルト値
key_pair_private	EC2 インスタンスの管理に使用する SSH キーのプライベートな部分を指定します。キーは、次のようになります。—–BEGIN RSA PRIVATE KEY—–n… n—–END RSA PRIVATE KEY—–n	null
key_pair_public	EC2 インスタンスの管理に使用する SSH key のパブリックな部分を指定します。キーは、次のようになります。 ssh-rsa …	null
game_instance_profile_name	Terraform のゲームサーバー接続のインスタンスプロフィールを指定します。デフォルト値が Terraform に新しいロールを作成させます。	null
server_instance_profile_name	Terraform の Genvid サーバー接続のインスタンスプロフィールを指定します。デフォルト値が Terraform に新しいロールを作成させます。	null
vpc_id	新しく作成する代わりに使用する VPC ID を指定します。これにより、クラスタ間で VPC を共有できます。VPC のサブネットは namespace-stage-public-az で命名しないと成功しません。vpc_id は次のようになります。 vpc-…	null

ALB/SSL をサポートする最小限のクラスタが必要な場合は、 minimal_cluster_alb_ssl を使用することで、これらの要素を使えるようになります。

サブネットの選択は、この順序で行われます。最初に該当するものが使用されます。

1- var.subnet_ids が提供される場合は使用します。

2- var.subnet_ids が提供されておらず、var.azs が提供されている場合は、関連する subnet_id を見つけて、それを使用してサーバーをデプロイし、各アベイラビリティゾーンの既存のサブネットに ALB を割り当てます。

どちらの場合も vpc_id が必要となります。ALB は、少なくとも 2 つのアベイラビリティゾーンで 2 つ以上のパブリックサブネットが必要であることにご注意ください。したがって、少なくとも 2 つの AZ または少なくとも 2 つの subnet_id を指定する必要があります。両方の変数を空のままにしている場合、提供された VPC が 2 つ以上のアベイラビリティゾーンを持ち、各アベイラビリティゾーンには、パブリックの 1 つの (および 1 つの) サブネットがあることを確認してください。

設定	説明	デフォルト値
azs	(オプション \| 必須) 使用する AZ リストを指定します。AZ は2 つ以上必要です。subnet_ids が渡される場合は無視されます。	[]
subnet_ids	(オプション \| 必須) 使用可能なパブリックサブネットの順番リスト。指定しない場合、すべての AZ のすべてのサブネットとなります。注釈: AZ に対してサブネットは一つのみ。したがって、AZ に複数のサブネットが存在する場合、この変数は必須であり、各 AZ で使用するパブリックサブネットの ID を指定する必要があります。subnet_ids が az よりも優先されます。[3]
domain_name	(必須) 使用する Route53 ホストゾーン (ドメイン) を指定します。Route53 のゾーンの値に設定しないと、「no matching Route53Zone found」というメッセージが表示されます。	null
reusable_delegation_sets_id	(オプション) 既存の Reusable Delegation Set の ID を指定します。次のようなものです: NXXXXXXXXXXXXXXXXXXXX。指定しなかった場合、デフォルトでは、 Route 53 はホストゾーンにネームサーバーのランダムな選択を割り当てます。[4]	null
subdomain_name	(必須) Route53 に作成するサブドメイン名を指定します。注釈: 既存のクラスタでサブドメインの変更/更新を行う場合、古いサブドメインの NS を AWS Route53 のメインドメインから手作業で削除する必要があります。古い NS レコードは自動で削除されません。	twitch
vpc_id	(必須) 新しく作成する代わりに使用する VPC ID を指定します。これにより、クラスタ間で VPC を共有できます。提供された VPC が AZ ごとに 1 つのサブネットしか存在しないことが重要です。そうでない場合は、有効な subnet_ids のリストが設定されていることを確認してください。設定されていない場合は、アカウント内に 1 つだけ存在しなければなりません。vpc_id は次のようになります。 vpc-…	null

[3]	バージョン 1.23.0 で追加.

[4]	(1, 2) バージョン 1.26.0 で追加.

変数の設定方法の詳細については、Terraform 設定解説書を参照してください。

重要

subnet_ids リストは順番リストであり、その順序はサーバーの配置場所に影響を与えます。subnet_ids リストにサーバーを割り当てるには modulo 関数を使用します。

サーバーのデプロイは、ラウンドロビンアルゴリズムを使用してサブネットリスト (subnet_ids) 内で行われます。例として、subnet_ids = [「SN1」, 「SN2」, 「SN3」], instance_encoding_count = 「2」, instance_internal_count = 「5」の場合、サーバーはこのスキーマに従って以下のようにデプロイされます。

instance_encoding-1: 「SN1」
instance_encoding-2: 「SN2」
instance_internal-1: 「SN1」
instance_internal-2: 「SN2」
instance_internal-3: 「SN3」
instance_internal-4: 「SN1」
instance_internal-5: 「SN2」

サーバーの割り当てにはリスト「subnet_ids」の順番が重要なので、上記のリストからサブネット SN2 が削除された場合、Terraform は残りのサブネット「SN1」と「SN3」にサーバーを再作成し、新しいディストリビューションスキーマは以下のようになります。

instance_encoding-1: 「SN1」
instance_encoding-2: 「SN3」
instance_internal-1: 「SN1」
instance_internal-2: 「SN3」
instance_internal-3: 「SN1」
instance_internal-4: 「SN3」
instance_internal-5: 「SN1」

削除したサーバーを、削除したサブネットに属するものだけに限定するには、subnet_ids の中で、そのサーバーを別のサブネットに置き換える必要があります。これにより、元のサブネットに残っているサーバーのディストリビューションがそのまま維持されます。上の例と同じように、新たに順番付けされた subnet_ids は、subnet_ids = [「SN1」, 「SN1」, 「SN3」] となります。リストの2番目のサブネットは、任意のサブネットにすることができます。ディストリビューションスキーマは以下のようになります。

instance_encoding-1: 「SN1」
instance_encoding-2: 「SN1」
instance_internal-1: 「SN1」
instance_internal-2: 「SN1」
instance_internal-3: 「SN3」
instance_internal-4: 「SN1」
instance_internal-5: 「SN1」

サーバーのディストリビューションを充実させたい場合は、 [『SN1』, ‘SN2’, ‘SN3’] のような “subnet_ids” アウトプットを使用し、[『SN1』, ‘SN1’, ‘SN3’, ‘SN1’, ‘SN3’, ‘SN3’] のように変更します。この処理は modulo が行います。

Terraform プロバイダ¶

プロバイダはクラスタ、より具体的にはそのクラスタにインポートされたモジュールに固有のものです。したがって、新しいクラスタを作成し、そこにモジュールをインポートすることから始めましょう。

../_images/bastion_ui_basic_cluster_init.png

図 26 最初のインポートで、ダウンロードされているプロバイダプラグインが表示されます。特定のモジュールで使用されているプロバイダを確認するのに最適な方法です。

すべてのプロバイダには、識別用に独自の引数セットが付いています。特定のプロバイダをカスタマイズする方法を知る最良の方法は、Terraform Providers のページにアクセスし、興味のある特定のプロバイダを検索してください。

重要

モジュールをインポートするときに、各プロバイダに使用するバージョンを常に指定する必要があります。これを実行しないと、terraform init コマンドがそれぞれに利用可能な最新バージョンを使用するために、大幅な変更が実施された場合に、環境が不安定になる可能性があります。

詳細は Terraform documentation を参照してください。

Terraform プロバイダのカスタマイズ¶

(グローバル) デフォルト構成¶

プロバイダの構成は２つのレベルでカスタマイズできます。グローバル (bastion) レベル、またはモジュールをインポートした直後のクラスタです。グローバル構成は、新しいクラスタに (またはモジュールの再インポート時に) デフォルト構成を提供することを目的としています。

../_images/bastion_ui_global_terraform_providers.png

bastion のインストール中に、こうした構成をセットアップして、提供されるモジュールのいずれかを使用してクラスタがそのまま動作するようにします。情報は、bastion-services/terraform/providers/default.json に保存されているファイルから読み込まれます。

モジュールをクラスタにインポートすると、このモジュールが使用するプロバイダのデフォルト構成のみが適用されます。そのため、すべてのモジュールで使用されないプロバイダ構成を追加しても安全です。

../_images/bastion_ui_global_terraform_provider_add.png

プロバイダに新しいデフォルト構成を追加するには:

Bastion UI ページを開く。
Settings をクリックします。
Providers をクリックします。
+ NEW PROVIDER をクリックします。
カスタマイズするプロバイダを識別するために、Provider 、Alias にユニークな名前を入力する。
- オプション: そのプロバイダで使用する指定のデフォルト Version を設定することもできます。
重要

Provider と Alias に使用する識別子は、モジュールをクラスタにインポートするときにチェックされます。そのモジュールで使用されるプロバイダと一致しない場合、デフォルト構成は適用されません。
プロバイダに設定する引数が複数存在する場合は、+ をクリックしてそれぞれを追加します。
SAVE をクリックしてプロバイダ構成を保存します。

クラスタごとの構成¶

クラスタにモジュールをインポートした後、(Terraform の) Provider タブに移動して、現在の構成を確認できます。

../_images/bastion_ui_provider_need_module.png

図 27 Settings タブと同様に、モジュールをまだインポートしていない場合は、 Commands ページに移動して、インポートするように促されます。

一部のプロバイダがこの時点までに自動的に適用されるグローバル構成を持つものでない限り、デフォルトでは構成は空でなければなりません。クラスタのプロバイダに加えられた変更は、そのクラスタにのみ影響します。

警告

クラスタのモジュールが再インポートされると、グローバル構成がその構成をオーバーライドします。

../_images/bastion_ui_initial_provider_configuration.png

図 28 この例から分かるように、プロバイダの引数の値を指定するために Terraform 変数の補間がサポートされています。

クラスタが作成され、カスタマイズするプロバイダが確認できたら、トップメニューから Terraform に移動し、左側のメニューからクラスタ名の下の Provider に移動できます。

重要

プロバイダのバージョンを変更した後、新しいバージョンをダウンロードするには、新しい terraform init コマンドを実行する必要があります。

プロバイダをカスタマイズする作業は、グローバルな場合と非常によく似ています。+ ADD PROVIDER ボタンは、まだリストされていないプロバイダの構成を追加するために使用します。それ以外の場合は、編集ボタン (左の Action ボタン) を使用して、既存の構成をカスタマイズできます。

警告

プロバイダ構成の変更は、Refresh コマンドを実行するまで有効にならない場合があります。

Terraform プロバイダの引数¶

バージョン、エイリアス、引数などのメタ引数を区別していることにお気付きかもしれません。

これらのメタ引数はすべてのプロバイダに存在し、Terraform の init フェーズで参照されます。他の引数は plan または apply フェーズで使用され、プロバイダによって異なります。

注釈

plan フェーズでいくつかの引数が無視されている場合、Refresh を実行して Terraform の状態を新しい構成で更新してみてください。

独自の Terraform モジュールを作成しない場合、プロバイダエイリアスは有用ではありませんが、上記で確認したように、バージョンは非常に重要です。詳細については、Terraform Provider Configuration ページをご覧ください。

Terraform プロバイダのツールボックスのサポート¶

ツールボックスには、プロバイダの管理に役立つサブコマンドが用意されています。次の表は、使用可能なコマンドをまとめたものです。

コマンド	説明
genvid-bastion get-default-terraform-providers	現在のグローバルプロバイダ構成を JSON で表示する。
genvid-bastion set-default-terraform-providers	get-default-terraform-providers の形式と一致する JSON ファイルからグローバルプロバイダ構成を設定する。
genvid-bastion delete-default-terraform-providers	既存のグローバルプロバイダ構成を削除する。
genvid-clusters get-terraform-providers	指定のクラスタの指定の現在のプロバイダ構成を表示する。
genvid-clusters set-terraform-providers	get-terraform-providers の形式と一致する JSON ファイルから指定クラスタのプロバイダ構成を設定する。
genvid-clusters delete-terraform-providers	指定のクラスタの指定の既存のプロバイダ構成を削除する。

最も簡単に新しいプロバイダ構成を作成する方法は、bastion UI を使用後にツールボックスを使用して構成をファイルにリダイレクトすることですが、手動で構成する場合の例を次に示します。

[
    {
        "provider": "aws",
        "meta": {
            "alias": null,
            "version": "~> 2.17"
        },
        "arguments": {
            "region": "us-west-2"
        }
    },
    {
        "provider": "template",
        "meta": {
            "alias": null,
            "version": "~> 2.1"
        },
        "arguments": {}
    },
    {
        "provider": "tls",
        "meta": {
            "alias": "myalias",
            "version": null,
        },
        "arguments": {}
    }
]

Terraform インフラストラクチャの適用¶

Terraform Apply は、クラスタのインフラストラクチャをビルドするための処理です。

Plan Apply をクリックして、実行プランを作成します。
変更内容が、必要な内容と一致しているかを検証します。
変更内容の検証後、Apply をクリックしてプランを実行します。

ログが表示されます。

Terraform によるインフラストラクチャのビルドに失敗した場合:

エラーメッセージを確認します。
設定を更新します。
もう一度適用します。

この手順が完了すると、クラウド上でクラスタが動作します。Terraform ページの All Configs を確認すると、ステータスは UP になっています。これは、インフラストラクチャがビルドされていて、Genvid SDK が存在していないことを表しています。

重要

バージョン 1.19.0 より、Terraform がインスタンスを作成した後、バックグラウンドでインスタンスのプロビジョンを行います。ただ、インスタンスを使用する前に、インスタンスがクラスタ UI に Nomad クライアントとして登録されるまで少し時間がかかります。特に、Windows インスタンスは準備が整うまでに最長 30 分かかることがあります。

注釈

パブリック IP は、AMI 設定時に使用した IP とは違います。

ゲーム機にアクセスするには、AMI 設定中に設定したものと同じパスワードで game_public_ips の IP を使用します。

game_public_ips の取得方法:

クラスタが UP であることを確認します。
クラスタの Commands ページに移動します。
OUTPUT ボタンをクリックします。

game_public_ips は、JSON ファイル内に記述されています。

実行中のクラスタで SDK を設定¶

クラスタのステータスが UP になってから、Genvid SDK を設定して、プロジェクトを実行します。

クラウドの SDK ガイドの手順に従ってください。

Terraform インフラストラクチャの破棄¶

terraform destroy コマンドは、クラスタ設定からすべてのリソースを削除します。そのクラスタでプロジェクトを実行する必要がなくなった場合は、クラスタの Terraform インフラストラクチャだけを破棄してください。Terraform インフラストラクチャを破棄するには、Plan destroy ボタンをクリックします。

現在の Terraform インフラストラクチャの破棄を確実に実行したい場合は、Destroy ボタンをクリックします。

詳細はインフラストラクチャの破棄を参照してください。

クラスタの削除¶

クラスタを削除するには、まず、Terraform インフラストラクチャを破棄します。All Configs で、 Delete ボタンをクリックします。

カスタムレポジトリの使用¶

bastion の Terraform のレポジトリは、追加や削除を行うことができます。各レポジトリには、クラスタのインスタンスを作成するモジュールが含まれています。現在のレポジトリを一覧表示するには、以下のコマンドを使用します。

genvid-clusters module-list

新規モジュールを追加するには、以下のコマンドを実行します。

genvid-clusters module-add -u {URL} {name}

{URL} には go-getter と互換性のあるすべてのソースを指定できます (ローカルファイルを含みます)。
{name} は、bastion でのこのレポジトリの保存フォルダです。

bastion レポジトリで URL をクローン後、modules/module のソースとして利用できるようになります。モジュールの使用方法についての詳細は、Terraform’s Module Configuration を参照してください。

Bastion は、モジュールの起源を記憶しているため、以下のコマンドでアップデートできます。

genvid-clusters module-update [name]

名前の指定はオプションです。指定しない場合、すべてのレポジトリが更新されます。

以下のコマンドを使用して、モジュールを削除できます。

genvid-clusters module-remove {name}

参考

genvid-clusters: Genvid Cluster-Management スクリプト解説書。
Terraform の Bastion API: Terraform の Bastion API
Terraform のモジュール設定: Terraform のモジュールの解説書
go-getter: Go で URL を取得するライブラリ。

Related Topics

目次