TPA custom tests

TPA custom tests#

環境とアプリケーションに固有の詳細なテストを簡単に定義して、TPAの tpaexec test を強化できます。

どんなに単純なタスクでも、クラスターで実行するテストを作成して、すべてが期待どおりに動作していることを確認することを強くお勧めします。このようなテストを実行する統一的で反復可能な方法があると、危機に対処する場合でも、日常的なクラスター管理を行う場合でも、重要な点を見逃すことがありません。

構成されたロールまたはその他のプロパティによってクラスターインスタンスをターゲットとするテストを記述する場合、該当するすべてのテストが適切なインスタンスで実行されることを保証できます。レプリケーションステータスを確認するレプリカの数、pgbouncerを実行しているサーバー、または手動で確認するときに間違いを招きやすいその他の詳細を調べたり覚えたりする必要はありません。

テストはクラスターに重要な変更を加えてはなりません。実稼働サーバーで実行することを考えない場合、おそらくテストすべきではありません。

クイックスタート#

  • クラスターディレクトリ内にtests/mytest.yml を作成します

  • tpaexec test /path/to/cluster mytest を実行します

tpaexec test への--include-tests-from /other/path オプションを使用して、他の場所にテストを作成し、クラスター全体で使用することもできます。

使用方法については、 tpaexec help test を実行してください。

例#

次に、すべてのPostgresインスタンスで実行されるテストを記述する方法を示します。hosts: all の代わりにhosts: role_postgres に注意してください。

任意のAnsibleタスクを使用して、クラスターから情報を収集し、テストを実行できます。いくつかの期待が満たされない場合に失敗するタスクを書くだけですassert 、fail … when など。

- --

-  name: Perform my custom tests
  hosts: role_postgres
  tasks:

  # Always start with this
  - include_role:
      name: test
      tasks_from: prereqs.yml

  # Make sure that the PGDATA/PG_VERSION file exists. (This is just a
  # simplified example, not something that actually needs testing.)
  - name: Perform simple test
    command: "test -f {{ postgres_data_dir }}/PG_VERSION"
    become_user: "{{ postgres_user }}"
    become: yes

  - name: Run pg_controldata
    command: >
      {{ postgres_bin_dir }}/pg_controldata {{ postgres_data_dir }}
    register: controldata
    become_user: "{{ postgres_user }}"
    become: yes

  # Write output to clusterdir/$timestamp/$hostname/pg_controldata.txt
  - name: Record pg_controldata output
    include_role:
        name: test
        tasks_from: output.yml
    vars:
      output_file: pg_controldata.txt
      content: |
        {{ controldata.stdout }}

上記のようにビルトインoutput.yml を使用して、クラスターディレクトリのタイムスタンプ付きテストディレクトリに任意のテスト出力を記録できます。

各テストは、完全なAnsibleプレイブックつまり、タスクのリストではなくプレイのリストである必要があります。これは、基本的なTPAセットアップタスクの後にインポートおよび実行されます。

破壊的テスト#

デフォルトでは、テストはクラスターに重要な変更を加えないでください。レプリケーションをテストするテーブルを作成するようなことをする場合でも、自分自身の後のクリーンアップに注意する必要があります。

実稼働クラスターでは受け入れられないクラスターに変更を加えるテストは、destructive としてマークされなければなりません。これらは、開発時、または初期クラスターの「バーンイン」プロセス中にのみ実行するテストである場合があります。

テストにprereqs.yml を含める場合、destructive: yes を設定することにより、「破壊的」テストを定義できます。

- hosts: …
  tasks:
  - include_role:
      name: test
      tasks_from: prereqs.yml
    vars:
      destructive: yes

誰かがtpaexec test /path/to/cluster mytest を実行すると、 --destroy-this-cluster オプションを使用して実行を確認するように求めるエラーが発生します。

--destroy-this-cluster の使用は、コマンドを実行するリスクを認識することを示します。テストが実際にクラスターを破壊することを保証するものではありません。

目次