Deploy on Juju Spaces
Charmed PostgreSQL Operator has spaces support for separation of network traffic for:
- Client - PostgreSQL instance to client data
- Instance-replication - cluster instances replication data
- Cluster-replication - cluster to cluster replication data
- Backup - backup and restore data
To make use of spaces in the Charmed PostgreSQL Operator, it’s necessary to have network spaces previously configured. Make sure to refer to juju documentation on how to manage network spaces. Then, on application deployment, constraints are required to ensure the unit(s) have address(es) on the specified network space(s), and endpoint binding(s) for the space(s). For example, with spaces configured for instance replication and client traffic:
❯ juju spaces
Name Space ID Subnets
alpha 0 10.163.154.0/24
client 1 10.0.0.0/24
peers 2 10.10.10.0/24
The space alpha is default and cannot be removed. To deploy Charmed PostgreSQL Operator using the spaces:
juju deploy postgresql --channel 16/edge \
--constraints spaces=client,peers \
--bind "database-peers=peers database=client"
Note: currently there’s no support for the juju
bindcommand. Network space binding must be defined at deploy time only.
Consequently, a client application must use the client space on the model, or a space for the same subnet in another model, for example:
juju deploy client-app \
--constraints spaces=client \
--bind database=client
The two application can be then related using:
juju integrate postgresql:database client-app:database
The client application will receive network endpoints on the 10.0.0.0/24 subnet.
The Charmed PostgreSQL Operator endpoints are:
| Endpoint | Traffic |
|---|---|
| database | Client |
| database-peers | Instance-replication |
| replication-offer, replication | Cluster-replication |
| s3-parameters | Backup |
Note: If using a network space for the backup traffic, the user is responsible for ensuring that the target object storage URL traffic is routed via the specified network space.