Cluster configuration¶
tpaexec configure
コマンドは、プロビジョニング/デプロイ/テストサイクルの後続のステージで必要なYAMLクラスター構成ファイルを生成します。
クイックスタート¶
[tpa]$ tpaexec configure ~/clusters/speedy --architecture M1
このコマンドは、 ~/clusters/speedy
という名前のディレクトリを作成し、M1という名前のアーキテクチャー（シングルプライマリ、N個のレプリカ）のレイアウトに従うconfig.yml
という名前の構成ファイルを生成します。新しいディレクトリにgitリポジトリを作成し、生成されたconfig.yml
を含む最初のコミットを行います。
このコマンドは、構成を変更するためのさまざまなオプション（選択したアーキテクチャまたはプラットフォームに固有のオプション）も受け入れますが、デフォルトは賢明であり、すぐに使用できるようになっています。生成された config.yml を読んで、ニーズに合わせて構成を微調整することをお勧めします。 （これがconfiguration settings that affect the deploymentの概要です。）
config.ymlを完全に手で書くことは可能ですが、生成されたファイルを編集する方がはるかに簡単です。
構成オプション¶
最初の引数は、クラスターディレクトリ、たとえば、 speedy
または~/clusters/speedy
である必要があります（クラスターにはどちらの場合もspeedyという名前が付けられます）。すべてのクラスターを共通のディレクトリ（上記の例の
~/clusters ）に保持することをお勧めします。
アーキテクチャ、たとえば M1 または BDR-Always-ON
を選択するには、次の引数を --architecture <name>
にする必要があります。アーキテクチャの完全なリストについては、
tpaexec info architectures を実行してください。
上記の引数は常に必須です。ここで説明する残りのオプションは、上の例のように安全に省略できます。デフォルトは使用可能な結果につながります。
一般的なオプションのリストについては、
tpaexec help configure-options を実行してください。
アーキテクチャ固有のオプション¶
選択するアーキテクチャによって、他のどのオプションが受け入れられるかが決まります。通常、各アーキテクチャはいくつかの一意のオプションと、以下で説明する汎用オプションを受け入れます。
たとえば、M1では、 --num-cascaded-replicas 3
を使用して3つのカスケードレプリカでクラスターを作成できます。受け入れられる（または場合によっては必要な）オプションのリストについては、アーキテクチャのドキュメントを参照してください。
プラットフォームオプション¶
- 次に、
--platform <name>を使用して、 aws または bare(-metal servers) などのプラットフォームを選択できます。
アーキテクチャは、特定のプラットフォームをサポートする場合とサポートしない場合があります。そうでない場合、クラスターの構成に失敗します。
プラットフォームの選択は、特定のオプションの解釈に影響します。たとえば、awsを選択した場合、
--region <region> および--instance-type <type>
への引数は有効な AWS region name
それぞれ。詳細については、プラットフォームのドキュメントを参照してください。
プラットフォームを明示的に選択しない場合、デフォルトは現在awsです。
注：
TPAは、異なるプラットフォーム上のインスタンスを使用したクラスターの作成を完全にサポートしていますが、現在
tpaexec configure
はそのような構成を生成できません。複数のプラットフォームを指定するには、
config.ymlを編集する必要があります。
所有者¶
--owner <name>
を指定して、クラスターを（AWSタグなどのプラットフォーム固有の手段で）責任者の名前に関連付けます。これは、クラウドプラットフォームでは特に重要です。デフォルトでは、所有者はtpaexec provision
を実行しているユーザーのログイン名に設定されます。
（自分のイニシャル、「ファーストネーム ラストネーム」、またはあなたを一意に識別するものを使用できます。）
地域¶
--region <region> を指定してリージョンを選択します。
このオプションは、クラウド プラットフォームでのみ意味があります。 AWSのデフォルトはeu-west-1です。
注：
TPAは複数のリージョンにまたがるクラスターの作成を完全にサポートしていますが、現在
tpaexec configure
はそのような構成を生成できません。複数のリージョンを指定するには、
config.ymlを編集する必要があります。
ネットワーク構成¶
デフォルトでは、各クラスターは、選択したアーキテクチャに応じて、
CIDR範囲10.33.0.0/16 からランダムに選択された多数の/28
サブネットで構成されます。
別のネットワークからサブネットを割り当てるには、
--network 192.168.0.0/16 を指定します。
- 注： AWSクラスターでは、これはVPC CIDRに対応します。詳細については、
aws のドキュメントを参照してください。
--subnet-prefix 26
を指定して、別のサイズのサブネット、この場合は/28ではなく/26を割り当てます。
--no-shuffle-subnets
を指定して、ネットワークCIDR範囲の先頭からサブネットをランダム化せずに割り当てます（例、10.33.0.0/28
、10.33.0.16/28 など）。
既存のクラスターconfig.ymlファイルで既に使用されているサブネットを除外するには、
--exclude-subnets-from <directory>
を指定します。この引数は、ディレクトリごとに複数回指定できます。
注： これらのオプションは、TPAが既存のサーバーのネットワーク構成を変更しない「ベア」プラットフォームでは意味がありません。
インスタンスタイプ¶
インスタンスタイプを選択するには--instance-type <type>
を指定します。
このオプションは、クラウド プラットフォームでのみ意味があります。 AWSのデフォルトはt3.microです。
ディスク領域¶
--root-volume-size 64
を指定して、ルートボリュームのサイズをGB単位で設定します。
（プラットフォームによっては、ルートボリュームに最小サイズが必要な場合があります。）
--postgres-volume-size <size>
および--barman-volume-size <size> オプションを使用して、
PostgresおよびBarmanの個別のボリュームをサポートするアーキテクチャおよびプラットフォームでPostgresおよびBarmanのボリュームのサイズを設定できます。
これらのオプションは、TPAでボリュームサイズを制御できない「ベア」プラットフォームでは意味がありません。
ホスト名¶
デフォルトでは、 tpaexec configure
は数十の名前の事前承認リストから必要な数のホスト名をランダムに選択します。ほとんどのクラスターではこれで十分です。
--hostnames-from <filename>
を指定して、ファイルから1行に1つの名前でホスト名を選択します。ファイルには、少なくともクラスター内のインスタンスと同じ数の有効なホスト名が含まれている必要があります。各行には、名前の後にオプションのIPアドレスを含めることができます。存在する場合、このアドレスはconfig.yml
の対応するインスタンスのip_address として設定されます。
--hostnames-pattern '…pattern…'
を使用して、選択をegrepパターンに一致する行に制限します。
--hostnames-sorted-by="--dictionary-order" を使用して、
--random-sort （デフォルト）以外のsort(1)オプションを選択します。
--hostnames-unsorted
を使用して、ホスト名をまったくソートしません。この場合、hostnamesファイルで見つかった順序で割り当てられます。これは、hostnamesファイルが明示的に指定された場合のデフォルトです。
ホスト名に使用できるのは、文字（a〜z）、数字（0〜9）、および「-」のみです。選択したプラットフォームによっては、FQDNの場合があります。ホスト名は小文字にする必要があります。大文字は内部で小文字に変換され、
config.yml (例、 upstream: hostname )
でこれらのホスト名への参照は小文字バージョンを使用する必要があります。
ソフトウェアの選択¶
配布¶
--distribution <name> を指定してディストリビューションを選択します。
選択したプラットフォームによって、使用可能なディストリビューションとデフォルトで使用されるディストリビューションが決まります。
一般に、「Debian」、「RedHat」、および「Ubuntu」を使用して、Postgresおよびその他のソフトウェアがプリインストールされているTPAイメージを選択できるはずです（展開時間を短縮するため）。代わりに在庫配布画像を使用するには、ラベルに「-minimal」を追加します（例、「Debian-minimal」）。
このオプションは、TPAがインストールするディストリビューションを制御できない「ベア」プラットフォームでは意味がありません。
2ndQuadrantおよびEDBリポジトリ¶
TPAは、サブスクリプションを介してアクセスできる2ndQuadrantまたはEDBソフトウェアリポジトリを有効にできます。
デフォルトでは、 2ndQuadrantパブリックリポジトリ（サブスクリプションは必要ありません）をインストールし、アーキテクチャに必要な製品リポジトリ（ BDRリポジトリなど）を追加します。
TPAが2ndQuadrantおよびEDBリポジトリを使用する方法のより詳細な説明は here
--2Q-repositories source/name/maturity …
または--edb-repositories repository … を指定して、
2ndQuadrantパブリックリポジトリに加えて各インスタンスにインストールする2ndQuadrantまたはEDBリポジトリの完全なリストを指定します。
EDBリポジトリが指定されている場合、 2ndQuadrantのリポジトリは無視されます。
このオプションは注意して使用してください。 TPAは、組み合わせが適切であることを確認せずに、名前付きリポジトリを構成します。
これらのオプションを使用するには、tpaexecを実行する前にexport TPA_2Q_SUBSCRIPTION_TOKEN=xxx
またはexport EDB_SUBSCRIPTION_TOKEN=xxx を行う必要があります。
2ndQuadrantポータルの左側メニュー「Company
info」から「Company」から2ndQuadrantトークンを取得できます。
enterprisedb.com/reposからEDBトークンを取得できます。
ローカルリポジトリのサポート¶
--enable-local-repo
を使用して、ターゲットインスタンスにパッケージを配布するローカルパッケージリポジトリを作成します。
ネットワークアクセスが制限されている環境では、代わりに
--use-local-repo-only
を使用してローカルリポジトリを作成し、ターゲットインスタンスで他のすべてのパッケージリポジトリを無効にして、パッケージがローカルリポジトリからのみインストールされるようにすることができます。
ローカルリポジトリのサポート に関するページに詳細があります。
ソフトウェアバージョン¶
オプションで--postgres-version 13
または他のサポートされているPostgresのメジャーバージョンを指定できます。
デフォルトでは、常にすべてのパッケージの最新バージョンをインストールします。通常、これは望ましい動作ですが、一部のテストシナリオでは、次のいずれかのオプションを使用して特定のパッケージバージョンを選択する必要があります。
--postgres-package-version 10.4-2.pgdg90+1
2.--repmgr-package-version 4.0.5-1.pgdg90+1
3.--barman-package-version 2.4-1.pgdg90+1
4.--pglogical-package-version '2.2.0*'
--bdr-package-version '3.0.2*'--pgbouncer-package-version '1.8*'
aptまたはyumが受け入れる任意のバージョン指定子を使用できます。
バージョンが一致しない場合は、 *
ワイルドカードを追加してみてください。これは、パッケージバージョンに2:...
のようなエポック修飾子がある場合に必要になることがよくあります。
生成されたconfig.ymlでpostgresql_flavour をepas
に設定する--epas をオプションで指定できます。これは、 tpaexec
がコミュニティPostgres（デフォルト）の代わりにEDB Postgres Advanced
Server
（EDBリポジトリへのアクセスが必要）をインストールすることを意味します。
EPASはOracleとpostgresの両方の互換性機能をサポートしているため、デフォルトでは、EPASはクラスターをredwood
、つまりOracle互換性モードで初期化します。
postgresモードでクラスターを初期化するには、オプションで--no-redwood
を指定して、生成されたconfig.ymlでepas_redwood_compat
をFalseに設定します。
--extra-packages p1 p2 …
または--extra-postgres-packages p1 p2 …
を指定して、追加のパッケージをインストールすることもできます。前者はシステムパッケージとともにインストールするパッケージをリストし、後者はpostgresパッケージとともに後でインストールするパッケージをリストします。
（前のリストでPostgresに依存するパッケージに言及した場合、Postgresはまだインストールされないため、インストールは失敗します。）引数は変更なしでインストールのためにパッケージマネージャーに渡されます。
--extra-optional-packages p1 p2 … オプションは--extra-packages
と同様に動作しますが、指定されたパッケージをインストールできなくてもエラーではありません。
ワイルドカードの使用に関する既知の問題¶
config.yml に永続的に追加されたときに*_package_version
でワイルドカードを使用すると、RHEL 8以降のノード（またはRocky
Linuxなどのdnfを使用する派生OS）でtpaexec deploy
中にインストールされたソフトウェアが予期せず更新される可能性があることに注意してください。パッケージが既にインストールされている既存のクラスターで
deploy
を実行すると、ansibleは完全なパッケージバージョンと一致しない場合があります。たとえば、
bdr_package_version の値が 3.6*
に設定されている場合、ansibleはこれをインストールされているバージョンのBDRと一致させることができません。設定されたリポジトリ内の同じ名前、例
3.7。
私たちはこの制限をansible dnfモジュールのバグとして認識しており、TPAの将来のリリースでこれに対処したいと考えています。
ソースからのビルドとインストール¶
--install-from-source postgres
を指定すると、Postgresはパッケージからインストールするのではなく、gitリポジトリからビルドしてインストールします。
postgres の代わりに2ndqpostgres
を使用して、2ndQPostgresをビルドおよびインストールします。デフォルトでは、これにより適切なREL_nnn_STABLE
ブランチがビルドされます。
--install-from-source 2ndqpostgres pglogical3 bdr3
を使用して3つのコンポーネントすべてをソースからビルドしてインストールするか、単に
--install-from-source pglogical3 bdr3
を使用して2ndQPostgresのパッケージを使用しますが、ソースからpglogical
v3およびBDR v3をビルドしてインストールします。デフォルトでは、これは
pglogical およびBDRの master ブランチをビルドします。
別のブランチをビルドするには、対応する引数に :branchname
を追加します。たとえば、--install-from-source 2ndqpostgres:dev/xxx
またはpglogical:bug/nnnn 。
代わりにソースインストールで置き換えることを選択したパッケージに依存するパッケージをインストールできない場合があります。たとえば、 BDR v3パッケージはpglogical v3パッケージに依存しているため、ソースリポジトリからpglogicalをインストールし、パッケージからBDRをインストールすることはできません。同様に、ソースからPostgresをインストールし、パッケージからpglogicalをインストールすることはできません。
オーバーライド¶
オプションで --overrides-from a.yml …
を指定して、生成されたconfig.ymlにマージする設定を含む1つ以上のYAMLファイルをロードできます。
ここで指定されたファイルは最初にJinja2テンプレートとして展開され、結果はYAMLデータ構造としてロードされ、 config.ymlの生成に使用される引数に再帰的にマージされます（アーキテクチャとプラットフォームのデフォルトとコマンドラインからの引数）。このプロセスは、指定された追加のオーバーライドファイルごとに繰り返されます。これは、1つのファイルで定義された設定が後続のファイルから見えることを意味します。
たとえば、オーバーライドファイルには次のものが含まれる場合があります。
cluster_tags:
some_tag: "{{ lookup(env, SOME_ENV_VAR) }}"
cluster_vars:
synchronous_commit: remote_write
postgres_conf_settings:
effective_cache_size: 4GB
これらの設定は、そうでなければconfig.ymlにあるcluster_tags
とcluster_vars を拡張します。設定は再帰的にマージされるため、
cluster_tags にはデフォルトのOwnerタグとsome_tag
の両方が含まれます。同様に、 effective_cache_size
設定はその変数をオーバーライドし、他のpostgres_conf_settings
（存在する場合）は影響を受けません。言い換えれば、
config.ymlで特定のサブキーを設定またはオーバーライドできますが、
cluster_tags
または他のハッシュを完全に空にしたり置き換えたりすることはできません。
マージはハッシュ構造にのみ適用されるため、このメカニズムを使用してconfig.yml内のinstances
のリストを変更することはできません。 cluster_vars
とinstance_defaults を環境に共通の設定で拡張すると最も役立ちます。
とはいえ、このメカニズムは制限を強制するものではないため、十分に注意してください。オーバーライドの有無にかかわらず2つの構成を生成し、2つのconfig.ymlファイルを比較して、すべてのオーバーライドの効果を理解することをお勧めします。
アンシブルタワー¶
--use-ansible-tower および --tower-git-repository
オプションを使用して、Ansible
Towerでのデプロイメントに適したクラスターを作成します。詳細はAnsible
Towerを参照してください。
gitリポジトリ¶
デフォルトでは、クラスターの名前を付けた最初のブランチでgitリポジトリが作成され、コミットメッセージで使用した構成オプションを使用して単一のコミットが作成されます。
$PATH
にgitがない場合、tpaexecでエラーは発生しませんが、リポジトリは作成されません。
gitリポジトリの作成を抑制するには、 --no-git
オプションを使用します。 (Ansible Tower クラスターでは、 git
リポジトリーが必要であり、まだ存在しない場合は tpaexec provision
によって作成されることに注意してください。)
例¶
次のコマンドを実行するとどうなるかを見てみましょう。
[tpa]$ tpaexec configure ~/clusters/speedy --architecture M1 \
--num-cascaded-replicas 2 --distribution Debian-minimal \
--platform aws --region us-east-1 --subnet-pattern 10.33.x.x/28 \
--instance-type t2.medium --root-volume-size 32 \
--postgres-volume-size 64 --barman-volume-size 128 \
--postgres-version 9.6
[tpa]$
出力がないため、エラーはありませんでした。クラスターディレクトリが作成され、設定されました。
$ ls ~/clusters/speedy
total 8
drwxr-xr-x 2 ams ams 4096 Aug 4 16:23 commands
- rw-r--r-- 1 ams ams 1374 Aug 4 16:23 config.yml
lrwxrwxrwx 1 ams ams 51 Aug 4 16:23 deploy.yml ->
/home/ams/work/2ndq/TPA/architectures/M1/deploy.yml
クラスター構成はconfig.ymlにあり、その近隣には直接対話する必要のないアーキテクチャ固有のサポートファイルへのリンクがあります。構成は次のとおりです。
- --
architecture: M1
cluster_name: speedy
cluster_tags: {}
ec2_vpc:
Name: Test
cidr: 10.33.0.0/16
ec2_ami:
Name: debian-stretch-hvm-x86_64-gp2-2018-08-20-85640
Owner: 379101102735
ec2_vpc_subnets:
us-east-1:
10.33.161.64/28:
az: us-east-1a
10.33.189.80/28:
az: us-east-1b
cluster_vars:
postgres_version: 9.6
tpa_2q_repositories: []
vpn_network: 192.168.33.0/24
instance_defaults:
platform: aws
type: t2.medium
region: us-east-1
default_volumes:
- device_name: root
volume_type: gp2
volume_size: 32
- device_name: /dev/xvdf
volume_type: gp2
volume_size: 64
vars:
volume_for: postgres_data
vars:
ansible_user: admin
instances:
- node: 1
Name: quirk
role: primary
subnet: 10.33.161.64/28
- node: 2
Name: keeper
role: replica
upstream: quirk
backup: zealot
subnet: 10.33.161.64/28
- node: 3
Name: zealot
role:
- barman
- log-server
- openvpn-server
- monitoring-server
- witness
volumes:
- device_name: /dev/xvdf
volume_type: gp2
volume_size: 128
vars:
volume_for: barman_data
subnet: 10.33.189.80/28
- node: 4
Name: quaver
role: replica
upstream: keeper
subnet: 10.33.189.80/28
- node: 5
Name: quavery
role: replica
upstream: keeper
subnet: 10.33.189.80/28
次のステップは、 tpaexec provision
- または、 the cluster as a whole の構成をカスタマイズする方法または
individual instance を構成する方法の詳細を学習してください。
