Cluster configuration¶

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

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

このページは、使用可能な構成メカニズムの概要です。特定の variables you can set to customise the deployment process に関する詳細を記載した別のページがあります。

config.yml¶

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

cluster_name: speedy

cluster_vars:
  postgres_version: 9.6

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つのインスタンスまたはクラスター全体に対してvars が設定されたinstances のリストは、すべてのTPA構成の基本的なビルディングブロックです。

すべて tpaexec configure

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

YAML構文に関しては、 config.yml全体は cluster_vars や instances などのキーを持つハッシュを表します。 各キーが1回だけ定義されていることを確認する必要があります。 誤ってcluster_vars を繰り返した場合、たとえば、2番目の定義が前者を完全にオーバーライドし、次の展開で不足している（シャドウされた）変数が原因で意図しない変更が行われる可能性があります。。

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

変数¶

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: 11
  tpa_2q_repositories:
  - products/bdr3/release
  - products/pglogical3/release
  postgres_conf_settings:
    bdr.trace_replay: true

この場合、 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 に何かを入れるかどうかを決定しようとしている場合、多くのプラットフォーム固有のプロパティ（ 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は、特定の解釈を想定または強制しません。