# Architecture > Pigsty's modular, declarative infrastructure design for PostgreSQL --- > Modular Architecture and Declarative Interface! - Pigsty deployment is described by config inventory and materialized with ansible playbooks. - Pigsty works on [Linux](/docs/prepare/linux/) common nodes, i.e., bare metals or virtual machines. - Pigsty uses a modular design that can be freely composed for different scenarios. - The config controls **where** & **how** to install modules with **parameters** - The playbooks will adjust nodes into the desired status in an idempotent manner. ------ ## Modules Pigsty uses a modular design, and there are six default modules: [`PGSQL`](/docs/pgsql/), [`INFRA`](/docs/infra/), [`NODE`](/docs/node/), [`ETCD`](/docs/etcd/), [`REDIS`](/docs/redis/), and [`MINIO`](/docs/minio/). - [`PGSQL`](/docs/pgsql/): Autonomous HA Postgres cluster powered by Patroni, Pgbouncer, HAproxy, PgBackrest, etc… - [`INFRA`](/docs/infra/): Local yum/apt repo, Prometheus, Grafana, Loki, AlertManager, PushGateway, Blackbox Exporter… - [`NODE`](/docs/node/): Tune node to desired state, name, timezone, NTP, ssh, sudo, haproxy, docker, promtail, keepalived - [`ETCD`](/docs/etcd/): Distributed key-value store will be used as DCS for high-available Postgres clusters. - [`REDIS`](/docs/redis/): Redis servers in standalone master-replica, sentinel, cluster mode with Redis exporter. - [`MINIO`](/docs/minio/): S3 compatible simple object storage server, can be used as an optional backup center for Postgres. You can compose them freely in a declarative manner. If you want host monitoring, [`INFRA`](/docs/infra/) & [`NODE`](/docs/node/) will suffice. Additional [`ETCD`](/docs/etcd/) and [`PGSQL`](/docs/pgsql/) are used for HA PG Clusters. Deploying them on multiple nodes will form an HA cluster. You can reuse pigsty infra and develop your modules, considering optional [`REDIS`](/docs/redis/) and [`MINIO`](/docs/minio/) as examples. [![pigsty-sandbox.jpg](/img/pigsty/sandbox.jpg)](/docs/prepare/sandbox) ------ ## Singleton Meta Pigsty will install on a single **node** (BareMetal / VirtualMachine) by default. The [`install.yml`](https://github.com/pgsty/pigsty/blob/v3.7.0/install.yml) playbook will install [`INFRA`](/docs/infra/), [`ETCD`](/docs/etcd/), [`PGSQL`](/docs/pgsql/), and optional [`MINIO`](/docs/minio/) modules on the **current** node, which will give you a full-featured observability infrastructure (Prometheus, Grafana, Loki, AlertManager, PushGateway, BlackboxExporter, etc… ) and a battery-included PostgreSQL Singleton Instance (Named `meta`). This node now has a self-monitoring system, visualization toolsets, and a Postgres database with autoconfigured PITR. You can use this node for devbox, testing, running demos, and doing data visualization & analysis. Or, furthermore, adding more nodes to it! [![pigsty-arch.jpg](/img/pigsty/infra.png)](/docs/infra/) ------ ## Monitoring The installed [Singleton Meta](/docs/intro/arch#singleton-meta) can be used as an **admin node** and **monitoring center**, to take more nodes & Database servers under it’s surveillance & control. If you want to install the Prometheus / Grafana observability stack, Pigsty just deliver the best practice for you! It has fine-grained dashboards for [Nodes](https://g.pgsty.com/d/node-overview) & [PostgreSQL](https://g.pgsty.com/d/pgsql-overview), no matter these nodes or PostgreSQL servers are managed by Pigsty or not, you can have a production-grade monitoring & alerting immediately with simple configuration. [![pigsty-dashboard.jpg](/img/pigsty/dashboard.gif)](/docs/pgsql/dashboard/) ------ ## HA PG Cluster With Pigsty, you can have your own local production-grade HA PostgreSQL RDS as much as you want. And to create such a HA PostgreSQL cluster, All you have to do is describe it & run the playbook: ```yaml pg-test: hosts: 10.10.10.11: { pg_seq: 1, pg_role: primary } 10.10.10.12: { pg_seq: 2, pg_role: replica } 10.10.10.13: { pg_seq: 3, pg_role: replica } vars: { pg_cluster: pg-test } ``` ```bash $ bin/pgsql-add pg-test ``` Which will give you the following cluster with monitoring, replica, backup all set. [![pigsty-ha.png](/img/pigsty/ha.png)](/docs/feat/ha) Hardware failures are covered by self-healing HA architecture powered by `patroni`, `etcd`, and `haproxy`, which will perform auto failover in case of leader failure under 30 seconds. With the self-healing traffic control powered by haproxy, the client may not even notice there’s a failure at all, in case of a switchover or replica failure. Software Failures, human errors, and DC Failure are covered by `pgbackrest`, and optional `MinIO` clusters. Which gives you the ability to perform point-in-time recovery to anytime (as long as your storage is capable) ------ ## Database as Code Pigsty follows IaC & GitOPS philosophy: Pigsty deployment is described by declarative [Config Inventory](/docs/config/inventory) and materialized with idempotent playbooks. The user describes the desired status with [Parameters](/docs/config/inventory) in a declarative manner, and the playbooks tune target nodes into that status in an idempotent manner. It’s like Kubernetes CRD & Operator but works on Bare Metals & Virtual Machines. [![pigsty-iac.jpg](/img/pigsty/iac.jpg)](/docs/feat/iac) Take the default config snippet as an example, which describes a node `10.10.10.10` with modules [`INFRA`](/docs/infra/), [`NODE`](/docs/node/), [`ETCD`](/docs/etcd/), and [`PGSQL`](/docs/pgsql/) installed. ```yaml # infra cluster for proxy, monitor, alert, etc... infra: { hosts: { 10.10.10.10: { infra_seq: 1 } } } # minio cluster, s3 compatible object storage minio: { hosts: { 10.10.10.10: { minio_seq: 1 } }, vars: { minio_cluster: minio } } # etcd cluster for ha postgres DCS etcd: { hosts: { 10.10.10.10: { etcd_seq: 1 } }, vars: { etcd_cluster: etcd } } # postgres example cluster: pg-meta pg-meta: { hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary }, vars: { pg_cluster: pg-meta } } ``` To materialize it, use the following playbooks: ```bash ./infra.yml -l infra # init infra module on group 'infra' ./etcd.yml -l etcd # init etcd module on group 'etcd' ./minio.yml -l minio # init minio module on group 'minio' ./pgsql.yml -l pg-meta # init pgsql module on group 'pgsql' ``` It would be straightforward to perform regular administration tasks. For example, if you wish to add a new replica/database/user to an existing HA PostgreSQL cluster, all you need to do is add a host in config & run that playbook on it, such as: ```yaml pg-test: hosts: 10.10.10.11: { pg_seq: 1, pg_role: primary } 10.10.10.12: { pg_seq: 2, pg_role: replica } 10.10.10.13: { pg_seq: 3, pg_role: replica } # <-- add new instance vars: { pg_cluster: pg-test } ``` ```bash $ bin/pgsql-add pg-test 10.10.10.13 ``` You can even manage many PostgreSQL Entities using this approach: User/Role, Database, Service, HBA Rules, Extensions, Schemas, etc… Check [PGSQL Config](/docs/pgsql/config) for details.