Cluster configuration ===================== TPAでは、クラスターの構成を変更する方法は、\ ``config.yml`` を編集し、プロビジョニング/展開/テストサイクルを実行することです。このプロセスは、べき等であり、構成またはインスタンスの変更に応じてのみ変更を行うように注意深く設計されています。 :ref:`tpaexec configure ` コマンドは、賢明な\ ``config.yml`` ファイルを生成しますが、最も一般的なトポロジと構成オプションのみをカバーしています。デフォルト以外のものが必要な場合、またはクラスターをプロビジョニングした後に変更を行う必要がある場合は、\ ``config.yml`` を編集する必要があります。 使用可能な構成メカニズムの概要を以下に示します。デプロイメントプロセスをカスタマイズするために設定できる特定の変数の詳細については、 :ref:`Instance configuration ` を参照してください。 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つのインスタンスまたはクラスター全体に設定された\ ``instances`` と\ ``vars`` のリストは、すべてのTPA構成の基本ビルディングブロックです。 すべて :ref:`tpaexec configure ` オプションは何らかの方法で\ ``config.yml`` 変数に変換されます。 1つのオプションが複数の変数に影響を与える可能性があります。 (たとえば、\ ``--bdr-version`` は\ ``postgres_version`` 、\ ``tpa_2q_repositories`` 、\ ``edb_repositories`` 、\ ``extra_postgres_extensions`` などを設定する場合があります。)ただし、コマンドを実行してできることと同じことをエディタでいつでも実行できます。 YAML構文の観点では、\ ``config.yml`` 全体が\ ``cluster_vars`` や\ ``instances`` などのキーを使用したハッシュを表します。 .. Note:: 各キーは1回のみ定義されていることを確認する必要があります。たとえば、誤って`cluster_vars` を繰り返した場合、2番目の定義が最初の定義を完全にオーバーライドし、次の展開でシャドウされた変数が不足しているために意図しない変更を行う可能性があります。 TPAは、クラスタートポロジ全体の一貫性をチェックします。たとえば、レプリカロールでインスタンスを宣言する場合、その上流インスタンスの名前も宣言する必要があり、そのインスタンスは存在する必要があります。ただし、TPAは、インスタンスに変数を設定することを妨げるものではありません。十分な注意を払い、変更を運用環境にロールアウトする前に、テスト環境で変更を試してください。 変数 ---- Ansibleの用語では、ほとんどの構成設定は「インベントリ変数」です。 TPAは、プロビジョニング中にインベントリ内のクラスター全体に適用される\ ``cluster_vars`` を\ ``group_vars`` に変換し、各インスタンスの\ ``vars`` を\ ``host_vars`` に変換します。展開では、インベントリの値を使用します。 .. Note:: `config.yml` を変更した後、 `tpaexec deploy` の前に`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`` としてインベントリにコピーされます。ただし、これらの設定は代わりに\ ``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`` に何かを配置するかどうかを決定しようとしている場合、変数として定義できない限り ``platform`` または\ ``type`` などの場合を除き、おそらく前者に属します。これは、プロビジョニングのみで使用され、展開中は使用されない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は、特定の解釈を想定または強制しません。