Introduction

Introduction#

はじめに#

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 コマンドを実行する必要があります。ご使用のプラットフォームの TPA installation に従ってください。

TPAは4つの異なるステージで動作して、Postgresクラスターを起動します。

#  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インスタンス、またはネットワーク経由でクラスターのサーバーに到達できるマシンから実行できます。

これは TPA capabilities and supported software です。

構成#

クラスター構成

コマンドは、選択したオプションに基づいて、クラスターを記述する単純なYAML構成ファイルを生成します。この構成はすぐに使用できますが、ニーズに合わせて変更できます。構成ファイルの編集は、 クラスター構成 の作成前と作成後の両方での通常の方法です。

この段階で、クラスターのアーキテクチャとプラットフォームを選択する必要があります。 アーキテクチャ は、特定の目的にPostgresをセットアップするためのサーバーとソフトウェアの推奨レイアウトです。例には、「M1」プライマリおよびストリーミングレプリカを備えたPostgresおよび「PGD-Always-ON」 Always On構成のEDB Postgres分散5が含まれます。 プラットフォーム は、AWS、Docker、ベアメタルサーバーなどのアーキテクチャを展開するサーバーをホストする手段です。

プロビジョニング#

tpaexec provision

コマンドは、クラスターに必要なインスタンスとその他のリソースを作成します。プロセスの詳細は、クラスターの構成中に選択したアーキテクチャM1などとプラットフォームAWSなどによって異なります。

たとえば、必要な特権でAWSアクセスが与えられると、TPAはEC2インスタンス、VPC、サブネット、ルーティングテーブル、インターネットゲートウェイ、セキュリティグループ、EBSボリューム、Elastic IPなどをプロビジョニングします。

「ベア」プラットフォームを選択し、接続の詳細を提供することにより、既存のサーバーを「プロビジョニング」することもできます。これらはベアメタルサーバーであるか、クラウドプラットフォームで別途プロビジョニングされたサーバーであるかにかかわらず、TPAによって作成されたかのように使用できます。

単一のプラットフォームに制限されません。必要に応じて、クラスターをいくつかのAWSインスタンスマルチプルのリージョンと一部のオンプレミスサーバー、または他のデータセンターのサーバーに分散できます。

プロビジョニングステージの最後に、基本的なオペレーティングシステムがインストールされた必要な数のインスタンスができます。TPAは、SSH経由でルートにsudoを使用してアクセスできます。

導入#

tpaexec deploy

コマンドは、プロビジョニングされたサーバーにPostgresおよびその他のソフトウェアをインストールおよび構成しますTPAによって作成された場合とされていない場合があります。ただし、SSHとsudoアクセスが利用できる限り誰が作成したかは関係ありません。これには、レプリケーション、バックアップなどの設定が含まれます。

展開段階の最後に、Postgresが起動して実行されます。

テスト#

tpaexec test コマンドは、展開されたクラスターに対してさまざまなアーキテクチャとプラットフォーム固有のテストを実行して、予想通りに動作していることを確認します。

テスト段階の最後には、完全に機能するクラスターが完成します。

インクリメンタルな変更#

TPAは、プロビジョニング、展開、およびテストがべき等であるように注意深く設計されています。それらを実行し、config.ymlを変更し、プロセスを再度実行して変更を展開できます。構成またはインスタンスで何も変更されない場合、プロセス全体を再実行しても何も変更されません。

クラスター管理#

クラスターが起動して実行されると、TPAは、構成変更、スイッチオーバー、ゼロダウンタイムのマイナーバージョンのアップグレードなどの便利なクラスター管理機能を提供します。これらの機能により、手動で変更を行うよりもクラスターの管理が簡単かつ安全になります。

Ansibleを介して拡張可能#

TPAは Instance configuration をサポートしているため、 config.ymlを編集し、プロビジョニング/展開/テストを再実行するだけで、多くのことができます。 TPAが既にサポートしているものを超える必要がある場合は、次のように書くことができます

  • TPA custom commands 、クラスターで実行するプレイブックの作成を簡単にします。クラスターディレクトリにcommands/xyz.yml を作成し、 tpaexec xyz /path/to/cluster を使用して呼び出すだけです。自動化する必要がある管理タスクまたはプロセスに最適です。

  • TPA custom tests 、環境とアプリケーションに固有の詳細な検証でビルトインテストを強化します。 tpaexec test を使用してすべてのテストを均一で反復可能な方法で実行すると、危機に対処するときも、日常的なクラスター管理中にも、重要な要素を見逃すことがありません。

  • TPA hooks 、展開のさまざまな段階で呼び出されます。たとえば、 hooks/pre-deploy.yml のタスクは、メイン展開の前に実行されます。 post-deploy を含む他にも多くのフックがあります。これにより、Ansibleの全機能を自由に利用できます。

それはただのPostgresです#

TPAは、多くの機能が構成された複雑なクラスターを作成できますが、結果は単なるPostgresです。インストールは、生活を簡素化するように設計されたいくつかの規則に従いますが、あなたとデータベースの間には、隠された魔法も何も存在しません。他のPostgresインストールで実行できることはすべてTPAクラスターで実行できます。

TPAでのバージョニング#

TPAは、以前にメジャーバージョンが年から派生する日付ベースのバージョン管理スキームを使用していました。バージョン23からTPAはセマンティックバージョニングに移行し、最初は2部のmajor-minor パターンを使用して、バージョン23.34.1で完全な3部セマンティックバージョニングを採用しました。このスキームでは、メジャーバージョンは、以下の下位互換性の原則に準拠するために必要な場合にのみインクリメントされます。

下位互換性#

TPAの重要な開発原則は、下位互換性を維持することであるため、ユーザーがTPAの最新バージョン以外のものが必要になる理由はありません。下位互換性を次のように定義します。

  • TPA X.aで作成されたconfig.ymlは、TPA X.bで有効です。ここで、 b>=a

  • そのconfig.ymlから作成されたクラスターは、TPA X.bで保守および再展開が可能です。

したがって、新しいメジャーバージョンは、 下位互換性の中断を意味します。そのため、私たちはメジャーバージョンのリリースを回避することを目指しており、例外的な状況でのみそうします。

はじめに#

システムの TPA installation に従って、次に クラスター構成 に従います。

目次