Building from source ==================== TPAは、Postgresおよびその他の必要なコンポーネントをソースからビルドし、デフォルトのパッケージインストールとまったく同じ構成でクラスターをデプロイできます。これにより、ソースから繰り返し展開して、アーキテクチャやプラットフォームに関係なく、特定のセットアップのあらゆる側面を再現する現実的で完全に構成されたクラスターで変更をすばやくテストできます。 特定のコンポーネントのパッケージインストールを他のソースビルドと組み合わせることもできます。たとえば、パッケージからPostgresをインストールし、ソースからpglogicalとPGDをコンパイルできますが、パッケージの依存関係により、ソースからpglogical、パッケージからPGDをインストールできません。 ソースビルドは、開発、テスト、およびサポートオペレーションでの使用を目的としています。 クイックスタート ---------------- すべて安定したブランチからビルドされた2ndQPostgres、pglogical3、およびbdrを使用してクラスターをスピンアップします。 .. code:: bash $ tpaexec configure ~/clusters/speedy -a BDR-Always-ON \ --layout bronze \ --harp-consensus-protocol etcd \ --install-from-source \ 2ndqpostgres:2QREL_13_STABLE_dev \ pglogical3:REL3_7_STABLE \ bdr3:REL3_7_STABLE 上記と同じですが、公式のgitリポジトリから2ndQPostgresソースコードをビルドし、指定されたローカルワークツリーを使用して pglogical およびBDRをビルドするクラスターをセットアップします。この機能はDockerに固有です。 .. code:: bash $ tpaexec configure ~/clusters/speedy \ --architecture BDR-Always-ON --layout bronze \ --harp-consensus-protocol etcd \ --platform docker \ --install-from-source 2ndqpostgres:2QREL_13_STABLE_dev \ pglogical3 bdr3 \ --local-source-directories \ pglogical3:~/src/pglogical bdr3:~/src/bdr クラスターをデプロイした後、後続の実行で\ ``tpaexec deploy … --skip-tags build-clean`` を使用して、ビルドディレクトリを再利用できます。 （それ以外の場合、ビルドを開始する前にビルドディレクトリが空になります。） カスタムの場所とビルドパラメーターを使用してPostgres、 pglogical、 BDR、およびその他のコンポーネントをビルドする方法の詳細な説明をお読みください。 構成 ---- ソースビルドの構成には2つの側面があります。 ソースの特定の組み合わせを実行するクラスターが必要な場合は、 ``tpaexec configure`` を実行して、選択したコンポーネントをダウンロード、コンパイル、およびインストールするための適切なデフォルトで構成を生成します。上記の例に示すように、 PostgresまたはPostgres Extended、 pglogical、およびBDRをビルドし、ビルド元のブランチ名を指定できます。 基になるメカニズムは、コマンドラインオプションが許可するよりもはるかに多くのことができます。 config.ymlを編集することにより、さまざまなソースリポジトリのクローンを作成したり、ビルドの場所を変更したり、さまざまな構成またはビルドパラメーターを指定したり、ビルドコマンド全体を再定義したりできます。したがって、 Postgres、 pglogical、およびBDR以外のものをビルドできます。 利用可能なオプションはここに文書化されています： - :ref:`Building Postgres from source ` - :ref:`Building extensions with `install_from_source` ` ローカルソースディレクトリ -------------------------- TPAを使用して、Gitリポジトリからではなく、ローカルソースディレクトリからPostgresおよび/または拡張機能をビルドするDockerコンテナをプロビジョニングできます。 ``--install-from-source`` を使用して、ビルドするものを宣言しているとします。 .. code:: bash $ tpaexec configure ~/clusters/speedy \ --architecture BDR-Always-ON --layout bronze \ --harp-consensus-protocol etcd \ --platform docker \ --install-from-source 2ndqpostgres:2QREL_13_STABLE_dev \ pglogical3:REL3_7_STABLE bdr3:REL3_7_STABLE \ … デフォルトでは、これはPostgres Extended、pglogical3、およびbdr3の既知のリポジトリのクローンを作成し、指定されたブランチをチェックアウトしてビルドします。ただし、 ``--local-source-directories`` を追加して、代わりにホストマシンからソースを直接取得することを指定できます。 .. code:: bash $ tpaexec configure ~/clusters/speedy \ --architecture BDR-Always-ON --layout bronze \ --harp-consensus-protocol etcd \ --platform docker \ --install-from-source 2ndqpostgres:2QREL_13_STABLE_dev \ pglogical3 bdr3 \ --local-source-directories \ pglogical3:~/src/pglogical bdr3:~/src/bdr \ … この構成でも、リポジトリからPostgres Extendedをインストールしますが、ホスト上の指定されたディレクトリからpglogical3およびbdr3ソースを取得します。これらのディレクトリは、 gitリポジトリが複製されるのと同じ場所にあるDockerコンテナに読み取り専用でバインドマウントされ、デフォルト（ツリー外）のビルドが通常どおり続行されます。 コンポーネントのローカルソースディレクトリを指定する場合、ビルドするブランチを指定することはできません（上記の例の\ ``--install-from-source`` の\ ``pglogical3:REL3_7_STABLE`` と\ ``pglogical3`` を参照）。ソースディレクトリはコンテナに読み取り専用でマウントされるため、TPAはそれを変更することはできません。\ ``git pull`` も\ ``git checkout`` もです。ローカルにチェックアウトしたブランチ、コミットされていない変更などをすべて取得します。 ``--local-source-directories`` を使用すると、 config.ymlにDockerボリューム定義のリストが含まれます。 .. code:: yaml local_source_directories: - /home/ams/src/pglogical:/opt/postgres/src/pglogical:ro - /home/ams/src/bdr:/opt/postgres/src/bdr:ro - ccache-bdr_src_36-20200828200021:/root/.ccache:rw ccache ^^^^^^ TPAは、すべての種類のソースビルドに対してデフォルトでccacheをインストールします。ローカルソースディレクトリでDockerクラスターを使用している場合、デフォルトでは、新しいDockerボリュームがクラスターのコンテナにアタッチされ、共有ccacheディレクトリとして機能します。このボリュームはホストから完全に分離され、クラスターのプロビジョニングが解除されると削除されます。 ``--shared-ccache /path/to/host/ccache`` 構成オプションを使用して、より寿命の長い共有ccacheディレクトリを指定します。このディレクトリはコンテナにr / wバインドマウントされ、その内容はホストとコンテナの間で共有されます。 （設計上、ホストでコンパイルされたバイナリをコンテナに直接インストールする方法はありません。） リビルド -------- ソースからビルドされたコンポーネントを使用してクラスターをデプロイした後、 ``tpaexec rebuild-sources`` コマンドを使用して、 ``tpaexec deploy`` を再実行せずにこれらのコンポーネントをすばやくリビルドできます。これにより、コンテナのgitリポジトリからビルドされたコンポーネントに対して\ ``git pull`` が実行され、すべてのコンポーネントがリビルドされます。