-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.md.gotmpl
57 lines (44 loc) · 2.13 KB
/
README.md.gotmpl
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
{{ template "chart.header" . }}
{{ template "chart.description" . }}
{{ template "chart.versionBadge" . }}{{ template "chart.typeBadge" . }}{{ template "chart.appVersionBadge" . }}
## Commonly used values
Most users will want to specify a database name and user names:
```yaml
pgEdge:
dbSpec:
dbName: my_application
users:
- username: my_application
superuser: false
service: postgres
type: application
- username: admin
# Note this user will only have a subset of superuser privileges to exclude the abilities to
# read files and execute programs on the host.
superuser: true
service: postgres
type: admin
```
> [!WARNING]
> Do not update database users via the Helm chart after they're created. Instead, you should either
> modify the `pgedge-users` secret directly or create a new secret with updated values and specify
> it via the `pgEdge.existingUsersSecret` value. See the [Limitations](#limitations) section below
> for additional caveats on user management.
## Examples
See the [examples README](./examples/README.md) for instructions to try this chart using local
Kubernetes clusters created with [`kind`](https://kind.sigs.k8s.io/).
## Limitations
Most of the pgEdge cluster configuration is set when it's first initialized, and further changes to
the configuration are not read. This behavior affects two main areas:
- Horizontal scaling
- Increasing the number of nodes in the cluster beyond its initial configuration requires
additional work to notify the existing pgEdge nodes about the new pgEdge nodes.
- User management
- After initialization, the only user that's read from the users secret at startup is the internal
`pgedge` user.
- New users can be created via SQL, but note that they must be created on every pgEdge separately.
- Similarly, credential rotation must be performed on each pgEdge node individually. In the case
of the `pgedge` user, the password in `pgedge-users` secret should also be updated.
{{ template "chart.requirementsSection" . }}
{{ template "chart.valuesSection" . }}
{{ template "helm-docs.versionFooter" . }}