Instance configuration#
This is an overview of the TPA settings you can use to customize the deployment process on cluster instances.
There’s also an overview of configuring a cluster , which explains how to use cluster and
instance variables together to write a concise, easy-to-review
config.yml .
System-level configuration#
The first thing TPA does is to ensure that Python is bootstrapped and ready to execute Ansible modules (a distribution-specific process). Then it completes various system-level configuration tasks before it configures Postgres .
Setting up the TPA Python environment (preferred_python_version )
Environment variables (for example, https_proxy )
Package repositories#
You can use the pre-deploy hook
to execute tasks before any package repositories are configured.
(for RHEL, Rocky, and AlmaLinux)
(for Debian and Ubuntu)
(on any system)
(to ship packages to target instances)
You can use the post-repo hook
to execute tasks after package repository configuration. For example, you can use it to correct a problem with the repository configuration before installing any packages.
Package installation#
Once the repositories are configured, packages are installed at various stages throughout the deployment, beginning with a batch of system packages:
(for example, acl, openssl, sysstat)
Postgres and other components (for example, Barman, repmgr, pgbouncer) are installed separately according to the cluster configuration. See Other components .
Other system-level tasks#
Create and mount file systems (including RAID, LUKS setup)
Upload artifacts (files, directories, tar archives)
Skipping deployment completely#
To prevent TPA from doing any part of the deployment process on an
instance - in other words, if you want TPA to provision the instance and
then leave it alone - set the provision_only setting for the
instance to true in config.yml . This setting will make TPA omit
the instance entirely from the inventory which tpaexec deploy sees.
Postgres#
Postgres configuration is an extended process that’s interleaved with the configuration of other components like repmgr and pgbouncer. The first step is to install Postgres.
Version selection#
Use the configure options to select a Postgres flavor and version, or set
postgres_version in config.yml to specify the Postgres major
version you want to install.
That’s all you need to do to set up a working cluster. Everything else described here is optional. You can control every aspect of the deployment if you want to, but the defaults are carefully selected to give you a sensible cluster as a starting point.
Installation#
The default postgres_installation_method is to install packages for
the version of Postgres you selected, along with various extensions,
according to the architecture’s needs:
(for example, pglogical, BDR, and so on)
(for development and testing)
Whichever installation method you choose, TPA can give you the same cluster configuration with a minimum of effort.
Configuration#
You can use the postgres-config hook
to execute tasks after the Postgres configuration files are installed (for example, to install additional configuration files).
Once the Postgres configuration is in place, TPA installs and configures other components, such as Barman, repmgr, pgbouncer, and haproxy, according to the details of the architecture.
Other components#
Configuring and starting services#
TPA installs systemd service unit files for each service. The service
for Postgres is named postgres.service . You can use
systemctl start postgres to start it and systemctl stop postgres
to stop it.
If you’re deploying a cluster for the first time, TPA starts the Postgres service at this point. On an existing cluster, if there are any relevant configuration changes, TPA reloads or restarts the Postgres service as appropriate. If there are no changes and Postgres is already running, it leaves the service alone. (If Postgres isn’t running on an existing cluster, TPA starts it.)
In any case, Postgres is running at the end of this step.
After starting Postgres#
You can use the postgres-config-final hook
to execute tasks after the post-startup Postgres configuration is complete (for example, to perform SQL queries to create objects or load data).
You can use the post-deploy hook
to execute tasks after the deployment process is complete.