Cluster configuration#

TPAでは、クラスターの構成を変更する方法は、config.ymlを編集し、プロビジョニング/展開/テストサイクルを実行することです。このプロセスは、べき等であるように、構成の変更またはインスタンスの変更に応じてのみ変更を行うように注意深く設計されています。

クラスター構成コマンドは、賢明なconfig.ymlファイルを生成しますが、最も一般的なトポロジと構成オプションのみをカバーしています。デフォルト以外のものが必要な場合、またはクラスターをプロビジョニングした後に変更を行う必要がある場合は、とにかくconfig.ymlを編集する必要があります。

このページは、使用可能な構成メカニズムの概要を示しています。特定の Instance configuration の詳細を含む別のページがあります。

config.yml#

config.yml ファイルは、目的のクラスター構成のすべての側面を表す YAML format テキストファイルです。次に、2つのインスタンスを持つクラスターの最小限の例を示します。

cluster_name: speedy

cluster_vars:
  postgres_version: 14

instances:

- node: 1
  Name: one
  role: primary
  platform: docker
  vars:
    ansible_user: root
    x: 42


- node: 2
  Name: two
  role: replica
  platform: docker
  upstream: one
  vars:
    ansible_user: root
    x: 53

これら3つの定義は、クラスター構成の中心となります。ファイルには、他の多くの定義プラットフォーム固有の詳細を含む場合がありますが、1つのインスタンスまたはクラスター全体に設定されたinstances とvars のリストは、すべてのTPA構成の基本ビルディングブロックです。

すべてクラスター構成

オプションは、何らかの方法でconfig.yml変数に変換されます。 1つのオプションは複数の変数に影響を与える場合がありますたとえば、 --bdr-version はpostgres_version 、edb_repositories 、extra_postgres_extensions などを設定できますが、コマンドを実行してできることはエディターでいつでも実行できます。

YAML構文の観点では、config.yml全体がcluster_vars やinstances などのキーを含むハッシュを表します。 各キーが1度だけ定義されていることを確認する必要があります。 誤ってcluster_vars を繰り返した場合、2番目の定義が前者を完全にオーバーライドし、次の展開はシャドウされた変数が欠落しているために意図しない変更を行う可能性があります。

TPAは、クラスタートポロジ全体の一貫性をチェックしますたとえば、ロール「レプリカ」でインスタンスを宣言する場合、その上流インスタンスの名前も宣言し、そのインスタンスが存在する必要があります。ただし、それは妨げるものではありませんインスタンスに好きな変数を設定します。十分な注意を払い、変更を運用環境にロールアウトする前にテスト環境で変更を試す必要があります。

変数#

Ansibleの用語では、ほとんどの構成設定は「インベントリー変数」です。TPAは、プロビジョニング中にインベントリーでcluster_vars をgroup_vars クラスター全体に適用し、各インスタンスのvars をhost_vars に変換し、デプロイメントはインベントリー値を使用します。 config.ymlを変更した後、 ``tpaexec deploy`` の前に tpaexec provision を実行することを忘れないでください。

クラスター全体、個々のホスト、またはその両方に変数を設定できます。ホスト変数はグループ変数をオーバーライドします。実際には、 cluster_vars でx: 42 を設定することは、すべてのホストのvars で設定することと同じです。デプロイメント中にx を必要とするホストには、いずれの場合も値42が表示されます。ホストは常に最も具体的な値を参照するため、グループにいくつかのデフォルト値を設定し、必要に応じて特定のインスタンスにオーバーライドすると便利です。

可能な限り、 cluster_vars で変数を定義し、特定のインスタンスでそれらをオーバーライドすると、確認と変更が簡単な簡潔な構成が得られます。繰り返しが少なくなります。それを超えて、特定の設定がグループ変数またはホスト変数としてより意味があるかどうかは、あなたが決定する必要があります。

クラスター変数#

cluster_vars の下のキーは、有効なYAMLタイプにマップでき、Ansibleインベントリのグループ変数に直接変換されます。

cluster_vars:
  postgres_version: 14
  edb_repositories:
  - enterprise
  - postgres_distributed
  postgres_conf_settings:
    bdr.trace_replay: true

!!!警告

テンプレートで使用される変数は、 config.yml のトップレベル cluster_name 変数と同じレベルで定義する必要があります

以下の例を参照してください。

この場合、tpaexec provision は3つの変数文字列、リスト、およびハッシュをgroup_vars/tag_Cluster_name/01-cluster_name.yml のインベントリに書き込みます。

インスタンス変数#

このドキュメントでは、config.ymlの特定のインスタンスに対して定義された変数を参照するために「インスタンス変数」という用語を使用しています。例、これは一般的なインスタンス定義です。

instances:

- Name: unwind
  node: 1
  backup: unkempt
  location: a
  role:
  - primary
  - bdr
  volumes:
  - device_name: root
    encrypted: true
    volume_size: 16
    volume_type: gp2
  - device_name: /dev/xvdf
    encrypted: true
    vars:
      volume_for: postgres_data
    volume_size: 64
    volume_type: gp2
  platform: aws
  type: t3.micro
  vars:
    ansible_user: ec2-user
    postgres_conf_directory: /opt/postgres/conf

このインスタンスのvars で定義された変数はすべてインベントリーのホスト変数になりますが、インベントリー内のすべてのホスト変数はvars のみから取得されるわけではありません。 platform 、location 、volumes 、role などの他の一部のインスタンス設定もホスト変数としてインベントリにコピーされますが、代わりにvars またはcluster_vars でこれらの設定を定義することはできません。

vars の外部の設定は、インスタンスのプロパティたとえばName およびnode またはクラスターのトポロジ内のその場所たとえばrole 、backup またはそれらはプラットフォーム固有の属性たとえばインスタンスtype およびvolumes などを記述する場合があります。。 vars では定義できないことを除き、これらのインスタンスの「設定」とインスタンス「変数」を区別する必要があることはほとんどありません。

この場合、tpaexec provision は多くのホスト変数をhost_vars/unwind/01-instance_vars.yml のインベントリに書き込みます。

instance_defaults#

これは、config.ymlの繰り返しをさらに削減するメカニズムです。 cluster_vars として定義できないインスタンス設定に最も役立ちます。例、次のように書くことができます。

instance_defaults:
  platform: aws
  type: t3.micro
  tags:
    AWS_ENVIRONMENT_SPECIFIC_TAG_KEY: some_mandated_value

instances:

- node: 1
  Name: one

- node: 2
  Name: two

- …

instance_defaults の下で指定したものは、 instances のすべてのエントリーのデフォルトとして機能します。この例では、各インスタンスのplatform およびtype のスペルアウトを保存し、すべてのインスタンスを別のタイプに変更するのが簡単になります。インスタンスが別の値を指定している場合、もちろんデフォルトより優先されます。

instance_defaults は、instances を定義する際に使用するマクロ機能であると考えると役立つでしょう。最終的にインベントリに書き込まれるものは、instances の展開された定義のみから来ます。 cluster_vars またはinstance_defaults に何かを入れるかどうかを決定しようとしている場合、それはおそらく前者に属します変数たとえば、platform またはtype などとして定義できません。これは、多くのプラットフォーム固有のプロパティに当てはまりますAWSリソースタグなど)は、プロビジョニングでのみ使用され、展開中は使用されません。

instance_defaults メカニズムは、インスタンスのvars を埋めるために使用することを妨げるものではありません。デフォルトのハッシュ値は、instances エントリーで指定されたハッシュとマージされます。ただし、 cluster_vars で同じデフォルトを設定し、必要に応じてインスタンスにオーバーライドするよりもこれを行うことに特に利点はありません。よくわからない場合は、 cluster_vars を使用してください。

ロケーション#

config.ymlでlocations のリストを指定することもできます。

locations:

- Name: first
  az: eu-west-1a
  region: eu-west-1
  subnet: 10.33.110.128/28


- Name: second
  az: us-east-1b
  region: us-east-1
  subnet: 10.33.75.0/24

instances:

- node: 1
  Name: one
  location: first
…

インスタンスがlocation: first またはlocation: 0 を指定する場合、その場所の設定はそのインスタンスのデフォルトとして機能します。ここでも、 instance_defaults と同様に、インスタンスはその場所から継承するデフォルトをオーバーライドできます。また、この機能を使用して、インスタンスのvars を入力できます。これは、インスタンスの半分にのみ適用されるデフォルトと、残りの半分に異なる値がある場合に役立ちます。上記の例のプラットフォーム固有の設定の場合。

ロケーションは、インスタンスが「オプトイン」できる設定のコレクションを表します。それらを使用して、さまざまなデータセンター、AWSリージョン、Dockerホスト、または完全に他のものを表すことができます。 TPAは、特定の解釈を想定または強制しません。

Cluster configuration

目次