Managing databases with Cloud 66

About deploying databases

We currently support the following databases, with no need for additional configuration after deployment.

For Rack-based stacks, Cloud 66 automatically detects whether your application relies on a database or not during your code analysis. This is based on a combination of your Gemfile and your database.yml or mongoid.yml files.

After you have analyzed your code, ensure that your desired database type is displayed in the About your app section of the analysis results.

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.

If you’d prefer to manage your users and password manually (i.e. your config files), you can prevent your configs from being modified.

Note

If your database.yml file has a url defined, we will assume that you are using an external (self-managed) database, and will follow that URL accordingly. This also means we won't set any of the database variables (such as username and password) the way we would normally do.

Managing YAML configs

A Rails app must have either a config/database.yml file or config/mongoid.yml in order to work on Cloud 66. We will create these files automatically if they don’t exist. We will update any existing files with new values (for example passwords) as required. (See above for how to prevent this)

If you want to specify a different DB config per environment, you can name the files config/database.yml.environment-name (e.g. config/database.yml.dev)

If you don’t want to use the standard config setup, you can also add a config/database.yml.cloud66 or config/mongoid.yml.cloud66 file instead.

We will prioritise these configs as follows:

  1. Files ending .cloud66
  2. Files ending with a .environment-name
  3. The standard YAML config file

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.

For Rails apps, if you have a url set in your database.yml then we will assume that you are using an external DB.

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. To upgrade your database through Cloud 66, we recommend that you create a new application (at which point Cloud 66 will deploy the newer database version).

Once the new application is created, you can migrate data from your old application to your new application.

Control your Rails database migrations

Cloud 66 chooses a server to perform the migrations - all other servers will wait until the migrations are finished before continuing with deployment. You can see which server performs the migrations in the Application Overview, and change it using the c66.migrations.run reserved tag.

You can control your Rails database migrations by setting the run.deploy.command option through application settings via Toolbelt which gives you the option of running migrations or not.

$ cx settings set -s my_stack run.deploy.command true

When you have disabled run.deploy.command in Application settings, you still have the option to run migrations on a one-off deployment by clicking Deploy -> Deploy with options and selecting Run database migrations.

Customize your database configuration

You can customize the database configuration on your servers using CustomConfig. CustomConfig is available for MySQL, PostgreSQL, 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:

Warning

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

PostgreSQL variables

The following variables are only available in the PostgreSQL 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