クラスタの使用¶
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 は ROOTDIR/bastion-services/
以下にある利用可能なファイルで構成されます。
ROOTDIR/bastion-services/init
このフォルダには、
bastion
ジョブの起動前に読み込まれたファイルが含まれます。コンテンツが key-value ストアに追加され、各オブジェクトがフォルダを記述し、それぞれの値が文字列に変換されて、キーとして挿入されます。フォルダの場所は
GENVID_BASTION_INIT_FOLDER
を使用して変更できます。詳細については、setup_jobs()
を参照してください。
次のステップで、クラスタを管理するための Bastion-UI の Web サイトを開きます。
genvid-bastion monitor
Bastion-UI ページで、Bastion 名を変更できます。
- Bastion の名前を変更します。
- Update をクリックします
Terraform ページで:
Add Config
をクリックします。- 一意の
ID
を入力します。- カテゴリに
cluster
を選択します。
注釈
クラスタ ID の長さは、技術的な制約から 64 文字に制限されています。
必要に応じて、他の backend
を選択することができますが、現時点ではデフォルトのままにしておきます。バックエンドによっては、変数の設定が必要になる場合があります。
クラスタのステータス¶
クラスタ作成後、ステータスは 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。
重要
Terraform 設定¶
Terraform は、クラスタのインフラストラクチャをビルドするために使用します。設定値は、クラスタのインフラストラクチャのビルドに使用されます。クラスタの Settings のサブリンクをクリックして、設定を編集します。
注釈
- Studio 固有の設定については、 Studio 設定ページ を参照してください。
- Tick 固有の設定については、 Tick Setup page を参照してください。
使いやすさのため、ページの設定を JSON ファイルにダウンロードすることもできます。編集したファイルをフォーム上でドラッグ & ドロップして、複数の設定を一度に編集したり、以前の構成に戻すことができます。保存されていない構成は失われるため、注意してください。
クラスタ変数の詳細はこちら: Terraform Modules
必要に応じて、負荷バランスと SSL を有効にできるクラスタを用意しておくと良いでしょう。モジュールは basic_cluster_alb_ssl
と命名されます。 basic_cluster
の変数に加えて、以下の変数が利用可能です。
次の 2 つの設定値は、環境変数をもとに自動的に設定されます。手動で設定する必要はありません。
cluster
は使用するクラスタの名称です。bastionid
は使用する Bastion の名称です。
basic_cluster
および basic_cluster_alb_ssl
の構成は、新しい VPC やキーペアを作成したりなどのあらゆる処理を行います。より細かな制御を行いたい場合や、限られた権限のため AWS VPC や Role の作成が行えない場合は、 minimal_cluster
や minimal_cluster_alb_ssl
の構成を行って、以下の要素を直接得られます。
basic_cluster_alb_ssl
構成が基本クラスタに行うように、 minimal_cluster_alb_ssl
構成はミニマムクラスタに 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 つの) サブネットがあることを確認してください。
変数の設定方法の詳細については、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 プロバイダ¶
プロバイダはクラスタ、より具体的にはそのクラスタにインポートされたモジュールに固有のものです。したがって、新しいクラスタを作成し、そこにモジュールをインポートすることから始めましょう。
すべてのプロバイダには、識別用に独自の引数セットが付いています。特定のプロバイダをカスタマイズする方法を知る最良の方法は、Terraform Providers のページにアクセスし、興味のある特定のプロバイダを検索してください。
Terraform プロバイダのカスタマイズ¶
(グローバル) デフォルト構成¶
プロバイダの構成は 2つのレベルでカスタマイズできます。グローバル (bastion) レベル、またはモジュールをインポートした直後のクラスタです。グローバル構成は、新しいクラスタに (またはモジュールの再インポート時に) デフォルト構成を提供することを目的としています。
bastion のインストール中に、こうした構成をセットアップして、提供されるモジュールのいずれかを使用してクラスタがそのまま動作するようにします。情報は、bastion-services/terraform/providers/default.json
に保存されているファイルから読み込まれます。
モジュールをクラスタにインポートすると、このモジュールが使用するプロバイダのデフォルト構成のみが適用されます。そのため、すべてのモジュールで使用されないプロバイダ構成を追加しても安全です。
プロバイダに新しいデフォルト構成を追加するには:
Bastion UI ページを開く。
Settings をクリックします。
Providers をクリックします。
+ NEW PROVIDER をクリックします。
カスタマイズするプロバイダを識別するために、 Provider 、 Alias にユニークな名前を入力する。
重要
Provider と Alias に使用する識別子は、モジュールをクラスタにインポートするときにチェックされます。そのモジュールで使用されるプロバイダと一致しない場合、デフォルト構成は適用されません。
プロバイダに設定する引数が複数存在する場合は、+ をクリックしてそれぞれを追加します。
SAVE をクリックしてプロバイダ構成を保存します。
クラスタごとの構成¶
クラスタにモジュールをインポートした後、(Terraform の) Provider タブに移動して、現在の構成を確認できます。
一部のプロバイダがこの時点までに自動的に適用されるグローバル構成を持つものでない限り、デフォルトでは構成は空でなければなりません。クラスタのプロバイダに加えられた変更は、そのクラスタにのみ影響します。
警告
クラスタのモジュールが再インポートされると、グローバル構成がその構成をオーバーライドします。
クラスタが作成され、カスタマイズするプロバイダが確認できたら、トップメニューから Terraform に移動し、左側のメニューからクラスタ名の下の Provider に移動できます。
プロバイダをカスタマイズする作業は、グローバルな場合と非常によく似ています。 + ADD PROVIDER ボタンは、まだリストされていないプロバイダの構成を追加するために使用します。それ以外の場合は、編集ボタン (左の Action ボタン) を使用して、既存の構成をカスタマイズできます。
警告
プロバイダ構成の変更は、Refresh コマンドを実行するまで有効にならない場合があります。
Terraform プロバイダの引数¶
異なるプロバイダの設定に aliases を与えることができます。Terraform の init
フェーズでは設定を検討し、 plan
および apply
フェーズでは引数を使用します。引数はプロバイダによって異なります。
注釈
plan
フェーズでいくつかの引数が無視されている場合、 Refresh を実行して Terraform の状態を新しい構成で更新してみてください。
独自の Terraform モジュールを作成しない場合、プロバイダエイリアスは有用ではありません。詳細については、Terraform Provider Configuration ページをご覧ください。
Terraform プロバイダバージョン¶
重要
Genvid SDK バージョン 1.28.0 以降、は、Bastion UI からプロバイダのバージョンを直接変更することができなくなります。
カスタムモジュールでプロバイダバージョンを指定する方法については Terraform Provider Requirements を参照してください。
提供されたクラスタ上のプロバイダのバージョンを手動で変更したい場合、 bastion-services/terraform/modules/basic/cluster/versions.tf
に宣言があります。
Terraform ファイルを変更する場合、変更を反映するには、Bastion UI でモジュールを更新してください。詳細は モジュールセクション を参照してください。
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",
"alias": null,
"arguments": {
"region": "us-west-2"
}
},
{
"provider": "template",
"alias": null,
"arguments": {}
},
{
"provider": "tls",
"alias": "myalias",
"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 ファイル内に記述されています。
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 を取得するライブラリ。