Skip to content

Database Access Patterns

Before You Read

This guide covers connection patterns. For database configuration and topology see Databases. For migrations see Migrations.

Cloud SQL MySQL

From a Microservice (In-Cluster)

Each microservice connects using its dedicated database user and DNS hostname:

Host:     microservice-{name}-db.{env}.orofi.xyz
Port:     3306
Database: db_microservice_{name}
User:     microservice-{name}
Password: (from secret {env}-microservice-{name}-db-connection)
SSL:      Required (ENCRYPTED_ONLY mode)

Connection string examples:

# JDBC (Java/Kotlin)
jdbc:mysql://microservice-identity-db.dev.orofi.xyz:3306/db_microservice_identity?useSSL=true&requireSSL=true

# Python (SQLAlchemy)
mysql+pymysql://microservice-identity:{password}@microservice-identity-db.dev.orofi.xyz:3306/db_microservice_identity?ssl_ca=/etc/ssl/certs/ca-certificates.crt

[NEEDS TEAM INPUT: confirm the exact connection string format used by each service's framework (Spring Boot, Hibernate, etc.).]

From Local Development

Option A: Cloud SQL Auth Proxy

# Install Cloud SQL Auth Proxy
# https://cloud.google.com/sql/docs/mysql/connect-auth-proxy#install

# Start proxy (listens on localhost:3306)
cloud_sql_proxy \
  -instances=orofi-dev-cloud:us-central1:orofi-dev-cloud-dev-oro-mysql-instance=tcp:3306

# Connect with mysql client
mysql -u microservice-identity -h 127.0.0.1 -P 3306 -p db_microservice_identity

Option B: Port-forward from Dev Cluster

# Port-forward Cloud SQL proxy sidecar if running in dev cluster
# [NEEDS TEAM INPUT: is there a Cloud SQL proxy pod in the dev cluster?]
kubectl port-forward -n microservice-identity \
  deployment/microservice-identity 3306:3306

Option C: Direct internal DNS (if in VPN)

[NEEDS TEAM INPUT: does the team use a VPN that routes *.dev.orofi.xyz to the GCP private network? If yes, document the VPN connection procedure.]

Flyway Admin Access

The migration runner uses a dedicated admin user. All migrations run through the Bitbucket Pipeline — see Migrations for the full workflow.

Host:     db-int.{env}.orofi.xyz  (resolves to 10.128.0.11 staging / 10.128.0.12 dev)
Port:     3306 (reached via SSH tunnel through bastion 35.226.57.140)
User:     flyway_admin
Password: (Bitbucket repository secret FLYWAY_PASSWORD / FLYWAY_STAGING_PASSWORD)
Access:   All microservice databases (for running migrations)

MongoDB

From a Microservice (In-Cluster)

URI: (from secret {env}-mongodb-connection)

The connection URI format: 

mongodb://{username}:{password}@mongo-db-0.mongo-db.mongo-db.svc.cluster.local:27017,mongo-db-1.mongo-db.mongo-db.svc.cluster.local:27017,mongo-db-2.mongo-db.mongo-db.svc.cluster.local:27017/?replicaSet=rs0&authSource=admin

[NEEDS TEAM INPUT: confirm exact MongoDB connection URI format, especially replica set name and auth database. Staging uses 3 replicas, dev uses 1.]

From Local Development

Option A: Mongo Express Web UI

Browse collections at https://mongoexpress.dev.orofi.xyz (requires @orofi.xyz Google login).

Option B: Port-forward

# Port-forward MongoDB service
kubectl port-forward -n mongo-db svc/mongo-db 27017:27017

# Connect with mongosh
mongosh "mongodb://localhost:27017" --authenticationDatabase admin -u {username} -p {password}

Option C: External Hostname

mongodb-ext.dev.orofi.xyz:32017  ← External access via Istio (port 32017)

mongosh "mongodb://mongodb-ext.dev.orofi.xyz:32017" \
  --authenticationDatabase admin \
  -u {username} -p {password}

Credentials from {env}-mongodb-system-users secret.

Redis

From a Microservice (In-Cluster)

Redis connections bypass the Istio sidecar (port 6379 is excluded). Services connect directly:

Host:     redis.{env}.orofi.xyz
Port:     6379
Auth:     (from secret {env}-redis-auth-password)

Istio sidecar exclusion

Redis traffic bypasses mTLS because port 6379 is in traffic.sidecar.istio.io/excludeOutboundPorts. Redis uses its own AUTH mechanism for security.

Connection string: redis://:{password}@redis.{env}.orofi.xyz:6379

[NEEDS TEAM INPUT: is Redis using TLS in addition to AUTH? Confirm ssl=true requirement.]

From Local Development

# Port-forward (if Redis is not reachable directly)
kubectl port-forward -n redis svc/redis 6379:6379  # [NEEDS TEAM INPUT: confirm namespace for Redis port-forward — Redis is Cloud Memorystore, not in cluster]

# Or connect directly to Cloud Memorystore private IP if in VPN
redis-cli -h redis.dev.orofi.xyz -p 6379 -a {password}

Kafka

From a Microservice (In-Cluster)

Bootstrap servers: kafka.kafka.svc.cluster.local:9092
Protocol: PLAINTEXT (internal)

[NEEDS TEAM INPUT: do services use SASL for internal Kafka connections, or only for external connections? Confirm auth configuration for in-cluster clients.]

From Local Development / External Tools

Bootstrap servers: kafka.dev.orofi.xyz:39092  (via Istio external port)
Protocol: SASL_PLAIN
SASL credentials: from {env}-kafka-secrets

Or browse via Kafka UI: https://kafka-ui.dev.orofi.xyz

Emergency Root DB Access

Emergency only

Root database access should only be used during critical incidents. All changes must be documented in the incident report.

# Get root password
ROOT_PW=$(gcloud secrets versions access latest \
  --secret={env}-cloudsql-root-password \
  --project=orofi-{env}-cloud)

# Connect via Cloud SQL Auth Proxy
cloud_sql_proxy -instances=orofi-{env}-cloud:us-central1:orofi-{env}-cloud-{env}-oro-mysql-instance=tcp:3307

mysql -u root -h 127.0.0.1 -P 3307 -p"$ROOT_PW"

See Also