Skip to main content

Pre-provisioned database and users

Use this approach when a DBA or customer provisioning service owns database creation and access control, but nevisOperator is allowed to run schema migrations during deployments and upgrades. Configure component database patterns with Database Management set to schema.

Prepare the database

For each database, the DBA must:

  1. Create the empty database and schema.
  2. Create the schema-owner user and the application user.
  3. Grant the schema-owner user the permissions required to run the component's migrations.
  4. Grant the application user the permissions required by the running component.
  5. Grant the required database connection and schema usage privileges.
  6. Create required extensions before the deployment. For PostgreSQL, this includes citext where required by the component.
  7. Store the credentials as nevisAdmin secrets or Kubernetes Secrets, and reference them from the database pattern. If a vault integration is used, synchronize the credentials into a Kubernetes Secret consumed by the pattern.

The schema-owner user is used only by the dbschema job. The application user is the only database user written into the running component configuration.

Install nevisAdmin 4

Follow Kubernetes-based installation. Configure the chart with the existing database service and a database root credential Secret:

--set database.type=postgresql \
--set database.port=5432 \
--set database.host=$DATABASE_HOST \
--set database.root.preparedCredentialSecret=nevis-database-credential

For nevisAdmin 4, pre-provision the nevisAdmin 4 database and the citext extension as the actual database administrator before installing the chart:

CREATE DATABASE nevisadmin4 OWNER <database.root user>;
\connect nevisadmin4;
CREATE EXTENSION IF NOT EXISTS citext;

With these objects pre-provisioned, the database.root user needs only CREATEROLE for the chart dbschema job to create the nevisAdmin 4 schema and application users. It does not need CREATEDB or azure_pg_admin membership for this path.

The chart still creates the nevisAdmin 4 schema and application users and runs their migrations. The pre-provisioning requirement is therefore specific to the database and extension; it does not mean that the nevisAdmin 4 chart is completely external.

Deploy Nevis components

For each component database pattern:

  1. Configure the database connection.
  2. Set Database Management to schema.
  3. Provide the schema-owner and application-user credentials in the root credential Secret or through the supported pattern fields.
  4. Deploy the project.

nevisOperator skips database creation, user creation, and role manipulation. It starts the dbschema job and runs Flyway migrations with the pre-created schema-owner user.

Trade-offs

This approach provides a clear separation of duties and avoids giving the deployment a fully privileged provisioning credential. It retains automatic schema migrations, so the deployment process must still be authorized to connect as the schema-owner user. If that is not acceptable, use fully external database management instead.