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
Example Postgres Environment Template
MySQL
Example MySQL Application Template
Example MySQL Environment Template
Notes
Change the value for
name:
to a more specific name if you have more than one database. This is especially important for App Imports.Change the value for
image:
to match the version number of the database you want and the Cloud provider you use. See AWS Public Gallery, Dockerhub Registries, and GCP registry. When using DockerHub or a private registry, be sure to configure the integrations with your credentials.
Last updated