Playbook

Pigsty implements core control functions at the bottom through the Ansible Playbook, and Pigsty provides pre-built playbooks in four main categories:

: Use the series of playbooks to install Pigsty singleton on the meta node with optional features.
nodes: Use the nodes series of playbooks to include more nodes in Pigsty monitoring and management and for subsequent use.
: Use the redis series of playbooks to deploy and manage various modes of Redis clusters on existing nodes.

The typical use process is as follows：

Use the infra series of playbooks to install Pigsty on the meta node/local machine and deploy the infra.

All playbooks initiate execution on the meta node, and the infra series of playbooks only works on the meta node.
Use the series of playbooks to include or remove other nodes from Pigsty.

After a node is managed, node monitoring and logging can be accessed from the meta node Grafana, and the node joins the Consul cluster.
Use the pgsql series of playbooks to deploy a PostgreSQL cluster on managed nodes.
Use the series of playbooks to deploy a Redis cluster on managed nodes.

After deployment on the managed node, Redis monitoring and logs can be accessed from the meta node.

Most playbooks are idempotent, meaning that some deployment playbooks may erase existing databases and create new ones without the protection option turned on.

Please read the documentation carefully, proofread the commands several times, and operate with caution. The author is not responsible for any loss of databases due to misuse.

Ansible Quick Start

The Pigsty playbooks are written in Ansible.

: How to install Ansible? (Pigsty users usually don’t have to worry about）
Limit Host: How to execute a playbook for a limit host?
: How to perform certain specific tasks in the playbook？

The Ansible playbook requires the ansible-playbook executable command, and Ansible can be installed on EL7-compatible systems with the following command.

Pigsty will attempt to install ansible from the offline package when using offline packages during the Configure phase.

The target of execution can be selected with the -l|-limit <selector> param. When this param is not specified, most playbooks default to all hosts defined in the configuration file as the target of execution. It is highly recommended to specify the execution object when executing the playbook.

There are two types of objects commonly used, clusters and hosts.

You can select the task subset to be executed with -t|--tags <tags>. When this param is not specified, the full playbook will be executed, and the selected task subset will be executed when set.

./pgsql.yml -t pg_hba                            # Regenerate and apply cluster HBA rules

Users can separate each task by , and perform multiple tasks at once. For example, you can adjust the cluster LB configuration using the following command when the cluster role members change.

Extra command-line params can be passed in via -e|-extra-vars KEY=VALUE to override existing params or control some special behavior.

For example, some of the behavior of the following playbooks can be controlled via command-line params.


./pgsql.yml -e pg_clean=clean        # Force erase existing running database instances when installing PG (dangerous)
./infra-remove.yml -e rm_metadata=true       # Remove data when uninstalling Pigsty
./infra-remove.yml -e rm_metadpkgs=true      # Uninstall the software when uninstalling Pigsty
./nodes-remove.yml -e rm_dcs_server=true     # When removing a node, force removal even if there is a DCS server on it
./pgsql-remove.yml -e rm_pgdata=true         # When removing PG, remove data together