Skip to content

DbInstance

Currently, DbInstances are more or less a meta resource that connects the operator to a database server.

There are actually two types of databases: generic and gsql, and the gsql one is supposed to bootstrap an sql instance in GCP, but they are going to be deprecated soon, and hence I don't feel like writing docs for them. The only important thing about them is that you shouldn't use them

Here we only talk about the generic instances

How to configure a DbInstance

You need to have a PostgreSQL or a MySQL server running, and it has to be accessible by the operator. You also need a user with sufficient permissions, if it's fine in your environment, I would suggest to use an admin user.

Now let's get started:

apiVersion: kinda.rocks/v1beta1
kind: DbInstance
metadata:
  name: cloudnative-pg
spec:
  adminSecretRef:
    Name: cnpg17-admin-creds
    Namespace: databases
  # -- Legacy settings, please set it like this
  # -- it's going to be removed in the next api version
  backup:
    bucket: ""
  engine: postgres
  generic:
    hostFrom:
      key: host
      kind: ConfigMap
      name: cloudnative-pg-config
      namespace: databases
    portFrom:
      key: port
      kind: ConfigMap
      name: cloudnative-pg-config
      namespace: databases
  monitoring:
    enabled: false

Let's quickly go through the yaml

With .adminSecretRef you are pointing the operator to a secret, where the admin credentials are stored. They must be stored in a following format

kind: Secret
data:
  # -- user might be omitted, then the following values will be used
  # -- for PostgreSQL - postgres
  # -- for MySQL      - root
  user: < base64 encoded admin username >
  password: < base64 encoded admin password >

With .engine you let the operator know, if it should treat a server as a PostgreSQL or a MySQL one. Possible values are postgres and mysql

Then you need to configure a URL and a port that the operator should try to connect to, there are two options to do that, you can set them directly in the manifest:

spec:
  generic:
    host: ${HOST}
    port: ${PORT}

Or you can read them from a ConfigMap or a Secret:

spec:
  generic
    hostFrom:
      key: host
      kind: ConfigMap
      name: cloudnative-pg-config
      namespace: databases
    portFrom:
      key: port
      kind: ConfigMap
      name: cloudnative-pg-config
      namespace: databases

Additional configurations

Extra Grants

To use the .extraGrants feature of Databases, you need to enabled it on the instance level. To do so, set the .spec.allowExtraGrants to true

Allowed Privileges

To use the .extraPrivileges feature of DbUsers, you also need to enabled the privileges on the instance level. Extra privileges is a list of roles that can be granteed to DbUsers. For example:

spec:
  generic:
    allowedPriveleges:
      - readOnlyAdmin
      - rds-iam

Then you will be able to assigned these roles to DbUsers. The roles are not managed by the operator, they must be already on a server when a user is created.

Instance Vars

It may happen that you need to share the same variable in the Database/DbUser templates. Let's say you have a RW and RO urls, and your application need two env variables to connect: one - for actibely writing, and another - only for reading.

The RW URL will be available anyway, but how to set a RO one.

Without the instance vars you could just create a template with a hardcoded string in it:

templates:
  - name: PG_READONLYHOST
    secret: false
    template: "my-read-only-postgres-url.test"

Or you can use the instance variables.

kind: DbInstance
spec:
  instanceVars:
    PG_READONLYHOST: my-read-only-postgres-url.test

And then later use it in a template like that:

templates:
  - name: PG_READONLYHOST
    secret: false
    template: '{{ .instanceVar "PG_READONLYHOST" }}'

If a value of a variable is changed on the instance, it will be also synced for each Database and User.