Cluster configuration ===================== TPAを使用して、クラスターの構成を変更する方法は、 config.ymlを編集し、プロビジョニング/デプロイ/テストサイクルを実行することです。このプロセスは、べき等であり、構成の変更またはインスタンスの変更に応じてのみ変更を加えるように慎重に設計されています。 :ref:`tpaexec configure ` コマンドは、適切なconfig.ymlファイルを生成しますが、最も一般的なトポロジと構成オプションのみをカバーしています。デフォルトを超えるものが必要な場合、またはクラスターのプロビジョニング後に変更を加える必要がある場合は、とにかくconfig.ymlを編集する必要があります。 このページは、利用可能な構成メカニズムの概要です。特定の :ref:`variables you can set to customise the deployment process ` に関する詳細を記載した別のページがあります。 config.yml ---------- ``config.yml`` ファイルは、目的のクラスター構成のすべての側面を表す `YAML format `_ テキストファイルです。次に、2つのインスタンスを持つクラスターの最小限の例を示します。 .. code:: yaml 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つのインスタンスまたはクラスター全体に対して\ ``vars`` が設定された\ ``instances`` のリストは、すべてのTPA構成の基本的なビルディングブロックです。 すべて :ref:`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を変更した後、 **``tpaexecdeploy``** 前に*\* ``tpaexec provision`` を実行することを忘れないでください。 変数は、クラスター全体、または個々のホスト、またはその両方に設定できます。ホスト変数はグループ変数をオーバーライドします。実際には、 ``cluster_vars`` に\ ``x: 42`` を設定することは、すべてのホストの\ ``vars`` に設定することと同じです。展開中に\ ``x`` を必要とするホストには、いずれかの方法で値42が表示されます。ホストは常に最も具体的な値を参照するため、グループにデフォルト値を設定し、必要に応じて特定のインスタンスでオーバーライドすると便利です。 可能な場合はいつでも、 ``cluster_vars`` で変数を定義し、特定のインスタンスに対してそれらをオーバーライドすると、確認と変更が容易な簡潔な構成になります（繰り返しが少なくなります）。それを超えて、特定の設定がグループ変数またはホスト変数としてより理にかなっているかどうかを判断するのはあなた次第です。 クラスター変数 -------------- ``cluster_vars`` の下のキーは、有効なYAMLタイプにマップでき、Ansibleインベントリーのグループ変数に直接変換されます。 .. code:: yaml cluster_vars: postgres_version: 14 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の特定のインスタンスに対して定義された変数を参照します。例、一般的なインスタンス定義は次のとおりです。 .. code:: yaml 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`` として定義できないインスタンス設定に最も役立ちます。たとえば、次のように記述できます。 .. code:: yaml 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`` のリストを指定することもできます。 .. code:: yaml 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は、特定の解釈を想定または強制しません。