Managing databases
Overview
We currently support the following databases, with no need for additional configuration after deployment.
- MySQL (or Percona if configured via Manifest
- Postgres
- MongoDB
- Redis
- InfluxDB
- SQLite (only in development environments)
How to deploy databases with Cloud 66
When creating a Cloud 66 application, you can add as many databases as you need in your service configuration during the application build.
After you have analyzed your code, ensure that your desired database type is displayed in the About your app section of the analysis results.
Adding databases after initial deployment
You can add databases to an existing application either by using Database Groups for physical databases, or by adding logical databases to your existing physical database(s)
Database authentication
When we deploy a database we automatically generate the required users and passwords to allow authentication. You can find these values via your Dashboard in the detail page of any database server. They will be available as environment variables and your application will be configured to use them.
MySQL and Postgres databases managed by Cloud 66 automatically have the following users created:
- a Database Application user
- a Database Admin user
- a Database Replication user (where replication is required)
The Application and Replication users always have the same password. The associated Linux users for these will differ depending on database type.
If you switch to managing your passwords manually, be sure to update all of these users whenever you change passwords. Remember that the Application and Replication users must use the same password.
Connecting your container to your DB
Databases in Cloud 66 run as separate components and aren't containerized. Even though they may be running on the same private network as your cluster servers, you will not be able to connect to them via localhost because of the nature of containers (which are, by definition, abstracted from operating the system).
Instead, we we automatically create a Kubernetes services for each DB that connects out from your cluster to the database server(s). To see these on your cluster, you can list the namespaces and then select your namespace and list the services associated with it with the following commands:
This will show you all the services running, some of which will be your databases.
Service names for database groups
If your application has two or more database groups, your Kubernetes database services will inherit those names. For example, if you have three MySQL database groups named main
, spare
and archive
then the Kubernetes services will be named:
- mysql-main
- mysql-spare
- mysql-archive
If one of these groups is set as your "primary" then it will use the default service name (mysql
) instead of its group-specific name.
Connection strings
A typical connection string might have:
- The protocol
- The username and password (where required)
- The name of the Kubernetes service, including database groups (e.g.
mongodb-spare
) - The name of the DB server (e.g.
mongo_production_1
)
So to connect to a MongoDB server named mongo_production_1
and running in your app namespace as mongodb-spare
you would use something like:
A similar setup for a Postgres server would look something like this:
Connecting your app to your DB in Cloud 66 Container Service V1
To connect to a database in Version 1 of Cloud 66 Container Management Service (CSv1), you should use its ElasticDNS address. Please read our full guide on ElasticDNS for more details.
Database deployment types
No database (external)
This option allows you to deploy your application without a database managed by Cloud 66, and is ideal for externally hosted databases.
You can also configure an external database via your Manifest file by specifying the server
node as external
.
Please note that if there is no connectivity to your external database, or your external database host is not configured correctly, the deployment will fail.
Local database
This option deploys your chosen database to the same server as your web server - this is intended primarily for development, as running your database locally in production is not advised. In this case, your application database configuration will be amended to target your local database server. If you scale up your web server, these settings will also be amend automatically to reflect your database configuration.
Dedicated database
This option will automatically create a new server for your database and configure your application accordingly.
Upgrading your database
Cloud 66 will not do in-place database upgrades, because this process may cause your application to stop working or may not be possible automatically.
You have two options for upgrading your database through Cloud 66:
- Using Database Groups
- Cloning your entire application
These options are described in full below.
Upgrading databases using Groups
To upgrade your database(s) using Groups:
- Add a new Database Group to your application - this will automatically create a Group with the latest version of your chosen engine
- Migrate your data from your existing database to your new Group - using database backups is usually the quickest and easiest way
- Test that your application can connect to and read your new database
- Switch your application configuration to use the new Group
- Remove the old Database Group
Cloning your application
You can make a new instance of your application by cloning it. We will provision new components for your application, which will use the latest versions by default. Be sure to check that you have not locked any component versions using your Manifest file.
Once the new application is created, you can migrate data from your old application to your new application.
How to run database schema migrations
If you’ve made structural changes to your databases, you will typically need to run migration commands during your build process, so that those changes are applied to your live database. The nature of these commands depend on your framework.
To do this in Cloud 66, you should add the commands to your service.yml
file using the following syntax:
So, for example, the service definition for a Django app with a migration enabled might look as follows:
Customize your database configuration
You can customize the database configuration on your servers using CustomConfig. CustomConfig is available for MySQL, Postgres, Redis and MongoDB.
Editing and committing your database CustomConfig will perform the following steps on every database server in your application, one by one, sequentially:
- Check your template for Liquid syntax errors
- Determine the correct server configuration and prepare general variables
- Prepare custom variables for your database type (e.g. server_state)
- Compile the database configuration based on the information from the server and database type
- Upload the configuration to the server
- Restart your database
A bad database configuration might stop your database from working. Take extra care to make sure the configuration is correct.
Database customization variables
There are a number of variables available for use in your database CustomConfig. Some are general for all database types, while others are database specific.
Global variables
The following variables are available to any database CustomConfig.
Variable Name | Type | Description |
---|---|---|
server | Hash | Hash containing information about your server |
cloud | string | Application cloud |
memory | integer | Server memory size (bytes) |
core | integer | Server core count |
MySQL variables
The following variables are only available in the MySQL CustomConfig.
Variable Name | Type | Description |
---|---|---|
server_state | string | Value can be stand_alone, mysql_master or mysql_slave based on your server status |
server_id | integer | An ID used by MySQL replication to identify your server* |
db_name | string | Database name |
*It is 0 for standalone servers, 1 for master servers and a number greater than 1 for slave servers
Postgres variables
The following variables are only available in the Postgres CustomConfig.
Variable Name | Type | Description |
---|---|---|
server_state | string | Value can be stand_alone, pg_master or pg_slave based on your server status |
Redis variables
The following variables are only available in the Redis CustomConfig.
Variable Name | Type | Description |
---|---|---|
server_state | string | Value can be stand_alone, redis_master or redis_slave based on your server status |
master_address | string | IP address of replication master (empty string if server is stand alone or master) |
master_port | integer | Will be 6379 when server is redis_slave , otherwise it is 0 |
Migrating to an external database
If you need to migrate a database managed by Cloud 66 to an external provider, you should bear in mind the following:
- Updating your Manifest file will not be sufficient to reconfigure your application - you will need to connect your application manually to your new database servers, including authentication credentials, ideally via your app’s environment variables.
- Your existing database servers will need to be manually removed from your application after you have migrated. They will not be automatically removed or deleted.
The exact migration process will differ widely depending on both the database used, and the host to which you are migrating your data, but all of them share the following steps:
- Switch off your application (maintenance mode is useful here)
- Migrate your data to the new host
- Set up authentication credentials and connection details
- Add a firewall rule to allow your app to reach the new data host (and vice versa)
- Turn your application back on
- Delete your defunct Cloud 66 database servers