Overview ======== © Copyright EnterpriseDB UK Limited 2015-2024 - 無断複写・転載を禁じます。 はじめに -------- TPAは、Ansibleを使用してEDBの推奨事項に従ってPostgresクラスターを展開するオーケストレーションツールです。 TPAは、Postgresの展開とサポートに関する長年の苦労して得た経験に基づいて、EDBが追従するベストプラクティスを具体化しています。これらの推奨事項は、迅速なテストベッドのセットアップと運用環境に適用されます。 TPAでは何ができますか? ---------------------- TPAは、トポロジから構成の最小の詳細までPostgresクラスターを記述するために使用できる宣言的構成メカニズムを中心に構築されています。 まず ``tpaexec configure`` を実行して、インストールするPostgresバージョンなどのいくつかの高レベルの選択に基づいて、初期クラスター構成を生成します。デフォルト構成はそのまま使用できますが、ニーズに合わせて編集できます。生成される構成はテキストファイル\ ``config.yml`` です。 この構成を使用して、TPAは次のことを行うことができます。 1. AWS EC2インスタンスまたはDockerコンテナなどのサーバー、およびクラスターをホストするために必要なその他のリソースをプロビジョニングします。または、接続の詳細を指定するだけで、既存のサーバーまたはVMに展開できます。 2. オペレーティングシステムの構成。たとえば、カーネル設定の調整、ユーザーとSSHキーの作成、パッケージのインストール、systemdサービスの定義、ログローテーションの設定など。 3. Postgresと、 PGD、 Barman、pgbouncer、repmgr、さまざまなPostgres拡張機能などの関連コンポーネントをインストールおよび構成します。 4. 展開後にクラスターで自動テストを実行します。 5. Postgres設定の変更、パッケージのインストールとアップグレード、新しいサーバーの追加など、構成に将来の変更を展開します。 どのように使用しますか？ ------------------------ TPAを使用するには、TPAをインストールし、\ ``tpaexec setup`` コマンドを実行する必要があります。ご使用のプラットフォームの :ref:`installation instructions ` に従ってください。 TPAは4つのステージで動作して、Postgresクラスターを起動します。 - クラスター :ref:`クラスター構成 <クラスター構成>` を生成します。 - クラスターをホストする :ref:`デプロイメントのプロビジョニング <デプロイメントのプロビジョニング>` サーバーVM、コンテナ。 - プロビジョニングされたインスタンスへの :ref:`A first cluster deployment ` ソフトウェア。 - :ref:`テスト <テスト>` デプロイされたクラスター。 .. code:: bash # 1. Configuration: decide what kind of cluster you want [tpa]$ tpaexec configure clustername --architecture M1 --platform aws \ --postgresql 14 \ --failover-manager repmgr # 2. Provisioning: create the servers needed to host the cluster [tpa]$ tpaexec provision clustername # 3. Deployment: install and configure the necessary software [tpa]$ tpaexec deploy clustername # 4. Testing: make sure everything is working as expected [tpa]$ tpaexec test clustername TPAは、ラップトップ、EC2インスタンス、またはネットワーク経由でクラスターのサーバーに到達できるマシンから実行できます。 詳細については、 :ref:`TPA capabilities and supported software ` を参照してください。 構成 ^^^^ :ref:`tpaexec configure ` コマンドは、選択したオプションに基づいて、クラスターを記述する単純なYAML構成ファイルを生成します。この構成はすぐに使用できますが、ニーズに合わせて変更できます。構成ファイルの編集は、 :ref:`make any configuration changes to your cluster ` の作成前と作成後の両方での通常の方法です。 この段階で、クラスターのアーキテクチャとプラットフォームを選択する必要があります。 *アーキテクチャ* は、特定の目的にPostgresをセットアップするためのサーバーとソフトウェアの推奨レイアウトです。例には、M1プライマリおよびストリーミングレプリカを備えたPostgresおよびPGD-Always-ON Always On構成のEDB Postgres分散5が含まれます。 *プラットフォーム* は、AWS、Docker、ベアメタルサーバーなどのアーキテクチャを展開するサーバーをホストする手段です。 プロビジョニング ^^^^^^^^^^^^^^^^ :ref:`tpaexec provision ` コマンドは、クラスターに必要なインスタンスとその他のリソースを作成します。プロセスの詳細は、クラスターの構成中に選択したアーキテクチャM1などとプラットフォームAWSなどによって異なります。 たとえば、必要な特権を持つAWSアクセスが与えられると、TPAはEC2インスタンス、VPC、サブネット、ルーティングテーブル、インターネットゲートウェイ、セキュリティグループ、EBSボリューム、Elastic IPなどをプロビジョニングします。 ベアプラットフォームを選択し、接続の詳細を提供することにより、既存のサーバーをプロビジョニングすることもできます。これらはベアメタルサーバーであるか、クラウドプラットフォームで別途プロビジョニングされたサーバーであるかにかかわらず、TPAによって作成されたかのように使用できます。 単一のプラットフォームに制限されません。必要に応じて、クラスターをいくつかのAWSインスタンスマルチプルのリージョンと一部のオンプレミスサーバーまたは他のデータセンターのサーバーに分散できます。 プロビジョニングステージの最後には、基本的なオペレーティングシステムがインストールされた必要な数のインスタンスがあり、TPAはSSHルートにsudoを介してアクセスできます。 導入 ^^^^ :ref:`tpaexec deploy ` コマンドは、プロビジョニングされたサーバーにPostgresおよびその他のソフトウェアをインストールおよび構成します。 (これらのサーバーはTPAで作成できますが、その必要はありません。SSHとsudoアクセスが利用できる限り、どのアプリケーションがそれらを作成したかは関係ありません。)これには、レプリケーション、バックアップなどの設定が含まれます。 展開段階の最後に、Postgresが起動して実行されます。 テスト ^^^^^^ :ref:`tpaexec test ` コマンドは、展開されたクラスターに対してさまざまなアーキテクチャとプラットフォーム固有のテストを実行して、予想通りに動作していることを確認します。 テスト段階の最後に、完全に機能するクラスターが完成します。 インクリメンタルな変更 ^^^^^^^^^^^^^^^^^^^^^^ TPAは、プロビジョニング、展開、およびテストがべき等であるように注意深く設計されています。それらを実行し、\ ``config.yml`` を変更し、プロセスを再度実行して変更を展開できます。構成またはインスタンスで何も変更されない場合、プロセス全体を再実行しても何も変更されません。 クラスター管理 ^^^^^^^^^^^^^^ クラスターが起動して実行されると、TPAは、構成変更、スイッチオーバー、ゼロダウンタイムのマイナーバージョンのアップグレードなどの便利なクラスター管理機能を提供します。これらの機能により、手動で変更を行うよりもクラスターの管理が簡単かつ安全になります。 Ansibleを介して拡張可能 ^^^^^^^^^^^^^^^^^^^^^^^ TPAは :ref:`variety of configuration options ` をサポートしているため、 ``config.yml`` を編集し、プロビジョニング/展開/テストを再実行するだけで、多くのことができます。 TPAが既にサポートしているものを超える必要がある場合は、次のように書くことができます。 - :ref:`TPA custom commands ` 、クラスターで実行するプレイブックの作成を簡単にします。クラスターディレクトリに\ ``commands/xyz.yml`` を作成し、 ``tpaexec xyz /path/to/cluster`` を使用して呼び出します。カスタムコマンドは、自動化する必要がある管理タスクまたはプロセスに最適です。 - :ref:`TPA custom tests ` 、環境とアプリケーションに固有の詳細な検証でビルトインテストを強化します。 ``tpaexec test`` を使用してすべてのテストを均一で反復可能な方法で実行すると、危機に対処するときも日常的なクラスター管理中にも、重要な要素を見逃すことがありません。 - :ref:`Hook scripts ` 、展開のさまざまな段階で呼び出されます。たとえば、\ ``hooks/pre-deploy.yml`` のタスクは、メイン展開の前に実行されます。 ``post-deploy`` を含む他にも多くのフックがあります。フックスクリプトを使用すると、Ansibleの全機能に簡単にアクセスできます。 それはただのPostgresです ------------------------ TPAは、多くの機能が構成された複雑なクラスターを作成できますが、結果は単なるPostgresです。インストールは、生活を簡素化するように設計されたいくつかの規則に従いますが、あなたとデータベースの間には、隠された魔法も何も存在しません。他のPostgresインストールで実行できることはすべてTPAクラスターで実行できます。 TPAでのバージョニング --------------------- TPAは、以前にメジャーバージョンが年から派生する日付ベースのバージョン管理スキームを使用していました。バージョン23から、セマンティックバージョニングの派生に移行しました。歴史的な理由から、私たちは3つの部分からなる完全なセマンティックバージョン番号を使用していません。代わりに、TPAは2つの部分からなる\ ``major.minor`` フォーマットを使用します。マイナーバージョンは、リリースごとにインクリメントされます。メジャーバージョンは、以下の下位互換性の原則に準拠する必要がある場合にのみインクリメントされます。 下位互換性 ^^^^^^^^^^ TPAの重要な開発原則は、下位互換性を維持することであるため、ユーザーがTPAの最新バージョン以外のものが必要になる理由はありません。下位互換性を次のように定義します。 - TPA X.aで作成された\ ``config.yml`` は、TPA X.bで有効です。ここで、 b>=a。 - その\ ``config.yml`` から作成されたクラスターは、TPA X.bで維持および再展開できます。 したがって、新しいメジャーバージョンは、 下位互換性の中断を意味します。そのため、私たちはメジャーバージョンのリリースを回避し、例外的な場合にのみリリースすることを目指しています。 .. _はじめに-1: はじめに -------- ご使用のシステムの :ref:`TPA installation instructions ` に従ってください。次に、 :ref:`configure your first cluster ` 。