For the complete documentation index, see llms.txt. This page is also available as Markdown.

Adding database containers to the Application Template

Best practices for running your application's database in a container

This document should cover the basics for adding a database to your application.

A few caveats that come with running databases in containers:

  • Containers and pods in Kubernetes can be restarted, deleted, or moved at any time, so you should not rely on them for any critical services. For mySQL, the main pod cannot be running when a new one is deployed or restarted. We mitigate this risk by recommending you use a Stateful Set with stateful: true for mySQL. (Postres does not have this issue that we have noticed.)

  • Containers are ephemeral and can move around, so it is vital to use a persistent storage volume so that restarting a container does not erase the database.

  • Kubernetes may start a container before the database is completely initialized or ready, so you should use readiness probes to ensure deployments wait for the database to be ready to receive traffic.

  • Passwords can be randomized and the database connections should be kept internal only so that external people cannot access the data or store their own data in your tables, even if it is a test database.

Postgres

Example Postgres Application Template

services:
- name: db
  image: public.ecr.aws/lts/postgres:12-20.04_edge
  volumes:
  - type: persistent
    name: db_data
    mount_path: "/var/lib/postgresql/data"
  ports:
  - type: container_port
    port: '5432'
  readiness_probe:
    exec:
      command:
      - psql
      - "-h"
      - localhost
      - "-U"
      - postgres
      - "-c"
      - SELECT 1
    period_seconds: 2
    timeout_seconds: 2
    failure_threshold: 30
  storage:
    size: 10Gi
    type: aws-efs

Example Postgres Environment Template

MySQL

Example MySQL Application Template

Example MySQL Environment Template

Notes

Last updated

Was this helpful?