Building your manifest file
Overview
A manifest file allows you to be more explicit about your application composition and control settings that are not usually available through the user interface or Cloud 66 toolbelt.
The file describes the setup of the components that run your application. See Getting started with manifest files for an introduction.
For Rails/Rack applications, place a file called manifest.yml
in a folder named .cloud66
, that is in turn located in the root of your source code and checked into your repository.
Once you’re ready, start by going through each section below to build your manifest file.
Problems upgrading?
If you explicitly set the version of any component in your manifest file, we will respect that setting even if it conflicts with other system changes or upgrades (for example upgrading Ubuntu). If you are having trouble upgrading any component of your application, remember to check your manifest file to ensure you have not previously locked the version of that component or one of its dependents.
Which environment?
The first level of your manifest file is the environment - this allows you to use the same manifest.yml
for multiple applications with different environments. Some examples are:
- production
- staging
- development
You can also use your own custom environment names in your manifest file.
Applying settings across all environments
If you would like you a manifest setting to apply to all environments, you can simple drop the root level environment node from your YAML. This will ensure a component is always provisioned, regardless of environment.
Which component?
Next, select which component you would like to specify settings for. You can choose from the following:
- ElasticSearch
- Gateway
- GlusterFS
- Load balancers
- Memcached
- MongoDB
- MySQL
- Nginx
- Node version
- PostGIS
- PostgreSQL
- Redis
- Sinatra
- Rails
- Rails health checks
ElasticSearch
- Groups: (Optional) Used to define multiple separate database groups (of the same type), each with their own configuration. The name of each group in your Manifest must match the names in your Dashboard.
- version: Specify the version of ElasticSearch you want to install.
- operating_system (Optional):
ubuntu1604
orubuntu1804
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers used by application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is ssd.
- iam_instance_profile_name (optional, AWS only): The name of the IAM instance profile that should be used when provisioning this server. (More info here)
production:
elasticsearch:
groups:
my_main:
configuration:
iam_instance_profile_name: elastic-perms
version: 0.90.7
root_disk_size: 100
root_disk_type: ssd
my_spare:
configuration:
version: 0.90.7
Gateway
- name: Specify the name of gateway you want to use for your application.
- username (Optional) Specify the username which should be used to connect to bastion server.
Note
The gateway should be defined and open before you can use it in manifest.
production:
gateway:
name: aws_bastion
username: ec2-user
GlusterFS
The version of GlusterFS currently offered via the Cloud 66 Add-in is not supported by Ubuntu 18.04. To use this add-in please ensure that all of your application components are installed on servers running Ubuntu 16.04.
- version: Specify the version of GlusterFS you want to install.
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers used by application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is
ssd
. - replica_count : Number of nodes in GlusterFS cluster which a data will be replicated on it(i.e replica count 2 means your data exist on two nodes). Default value is 1.
- mount_targets : List of Servers and Server Groups you need GlusterFS mounted on them. You can specify the name of the server or server group (i.e rails,docker,mysql,…). You can also use
app
anddb
keywords,app
is your main app server group (i.e docker, rails, …) anddb
is your db server groups (i.e mysql,redis,postgresql,… ). Default value isapp
. - iam_instance_profile_name (optional, AWS only): The name of the IAM instance profile that should be used when provisioning this server. (More info here)
- volumes: List of volumes you want in your GlusterFS Cluster. By default we are creating a volume called
cloud66-vol
and mounted to/mnt/data-store
.
Available settings for a volume are:
- name: Specify the name of volume.
- mount: Specify the mount point of the volume on clients.
After you change the volume list, you need to redeploy your application for new configuration be applied to your application.
Notes
- You can not change replica_count after GlusterFS added to your application.
- You can not use glusterfs group or any of its servers in mount_targets.
Warning
Renaming a volume will actually delete that volume and create a new one.
production:
glusterfs:
configuration:
version: 3.7
replica_count: 2
mount_targets: ['app','redis']
volumes:
- volume:
name: images-data
mount: "/mnt/images"
access_control:
read: ['web', 'api']
write: ['web']
- volume:
name: videos
mount: /mnt-data/videos
access_control:
read: ['web']
write: ['web']
Memcached
- memory: Specify maximum memory (in MB) that can be used (default value is 64).
- port: Specify connection port (default value is 11211).
- listen_ip: Specify which IP address to listen on (default value is 0.0.0.0).
production:
memcached:
configuration:
memory: 1024
port: 11211
listen_ip: 127.0.0.1
MongoDB
- Groups: (Optional) Used to define multiple separate database groups (of the same type), each with their own configuration. The name of each group in your Manifest must match the names in your Dashboard.
- version: Specify the version of MongoDB you want to install (can only be set during application build).
- operating_system (Optional):
ubuntu1604
orubuntu1804
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers in application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is ssd.
- tamper_with_yml (Optional): Determines whether Cloud 66 can automatically update your database configuration (username, password and server address). Default is yes.
- iam_instance_profile_name (optional, AWS only): The name of the IAM instance profile that should be used when provisioning this server. (More info here)
production:
mongodb:
groups:
my_mongo:
configuration:
version: 2.4.8
root_disk_size: 100
root_disk_type: ssd
spare_mongo:
configuration:
version: 2.4.8
MySQL
- Groups: (Optional) Used to define multiple separate database groups (of the same type), each with their own configuration. The name of each group in your Manifest must match the names in your Dashboard.
- version: Specify the version of MySQL you want to install. Valid values are 5.7 or 8.0 (can only be set during application build).
- operating_system (Optional):
ubuntu1604
orubuntu1804
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers used by application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is ssd.
- engine: Specify the MySQL engine you want to install. Valid values are ‘mysql’ and ‘percona’ (can only be set during application build).
- tamper_with_yml (Optional): Determines whether Cloud 66 can automatically update your database configuration (username, password and server address). Default is yes.
- iam_instance_profile_name (optional, AWS only): The name of the IAM instance profile that should be used when provisioning this server. (More info here)
production:
mysql:
live-db:
configuration:
version: 5.7
root_disk_size: 100
root_disk_type: ssd
engine: percona
iam_instance_profile_name: mysql-perms
upgrade:
configuration:
version: 8.0
root_disk_size: 100
root_disk_type: ssd
engine: percona
iam_instance_profile_name: mysql-perms
Nginx
- cors: Enable Cross Origin Resource Sharing - this will be taken into account when your Nginx configuration is reloaded.
- extra_build_arguments: (applies to Rack/Passenger applications only). Extra build argument string to be added the nginx build command. Note: if you require additional modules that themselves require specific source to be present, you should use a
BEFORE_NGINX
deploy hook to ensure that source is present. You can use thecloud66/download
snippet to achieve this easily. The following build arguments are currently always added:--with-http_realip_module --with-ipv6 --with-http_v2_module
regardless of this value. - perfect_forward_secrecy (deprecated): Enable Perfect Forward Secrecy - this will be taken into account when your Nginx configuration is reloaded.
production:
rails:
configuration:
nginx:
cors: true
extra_build_arguments: "--add-module=/path/to/module"
perfect_forward_secrecy: true # deprecated
CORS configuration
If required, you can also specify the allowed origin (as ‘*’ or a single origin) and methods. For applications created after September 2016, or if you have updated your application to use the latest NGINX configuration, you can also specify a comma-separated list of origins, headers, and whether to allow credentials for CORS.
production:
rails:
configuration:
nginx:
cors:
origin: '*'
methods: 'GET, OPTIONS'
headers: 'Custom-Header, Another-Header'
credentials: true
Node version (for Rails applications)
We automatically install the latest release of Node version 6.x.x when we set up your Rack/Rails application servers. You can control which version is installed by editing the manifest file for any Rails application as follows:
rails:
configuration:
node_version: "12" # will install latest release of v12.x.x
rails:
configuration:
node_version: "12.18.3" # will install specific v12.18.3
If you need a newer version of Node, you can install one using the same method above. We support any version of Node that is supported by our version manager (which itself supports the Node distribution list).
Applying changes
To apply changes to the Node version you need to update your manifest file, then deploy-with-options and select the Apply Ruby/Node upgrades option.
PostgreSQL
- Groups: (Optional) Used to define multiple separate database groups (of the same type), each with their own configuration. The name of each group in your Manifest must match the names in your Dashboard.
- version: Specify the version of PostgreSQL you want to install (can only be set during application build).
- operating_system (Optional):
ubuntu1604
orubuntu1804
- postgis: Specify whether to include PostGIS (can be added after initial application build).
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers used by application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is ssd.
- tamper_with_yml (Optional): Determines whether Cloud 66 can automatically update your database configuration (username, password and server address). Default is yes.
- iam_instance_profile_name (optional, AWS only): The name of the IAM instance profile that should be used when provisioning this server. (More info here)
production:
postgresql:
groups:
live-data:
configuration:
iam_instance_profile_name: psql-perms
version: 9.3.4
postgis: true
root_disk_size: 100
root_disk_type: ssd
spare-data:
configuration:
version: 9.3.4
PostGIS
- version: Specify the version of PostGIS you want to install.
production: postgresql: configuration: postgis: version: 2.1.1
Rails
A Rails application type in the manifest file gives you fine control over things like the Ruby version or the server the rails application is deployed on.
- ruby_version: Specify the version of Ruby to use. Also applies when you want to upgrade your Ruby version. We recommend that you use this and remove the Ruby version declaration from your Gemfile to avoid situations where your application will not run on every server during an upgrade.
- operating_system (Optional):
ubuntu1604
orubuntu1804
- asset_pipeline_precompile: Specify whether to use asset pipeline compilation - this will be taken into account during redeployment.
- do_initial_db_schema_load: Specify whether to perform
rake db:schema:load
on a new application build. - reserved_server_memory: A value in MB that Cloud 66 will assume should be left available. This will affect any automatically calculated values, and will be taken into account during redeployment.
- passenger_process_memory: A value (in MB) that Cloud 66 will use for each Passenger process. This is also used to calculate the value of the
passenger_pool_max
variable in your Nginx configuration which in turn setspassenger_max_pool_size
. - locked_passenger_version: Force the version of passenger to use. Note: this only applies during server build and is not supported on Passenger Enterprise applications.
- vpc_id (Optional, AWS EC2 only): ID of the AWS VPC in which you would like to create your servers. Note that you must provide subnet_id for all servers in your application.
- vn_name (Optional, AZURE only): Name of the Virtual Network in which you would like to create your servers.
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers used by application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is ssd.
- iam_instance_profile_name (optional, AWS only): The name of the IAM instance profile that should be used when provisioning this server. (More info here)
- nameservers (_Optional, defaults [ 8.8.8.8, 8.8.4.4 ]): Set DNS servers for your application. Note that if you specify empty array i.e [ ], it won’t add any nameserver to your servers
- include_submodules (Optional, default is true): Set this to false to exclude any Git submodules from being pulled during a build.
- keep_releases (Optional, Defaults to 5) Specify the number of releases to keep on your server(s).
- memory_allocator (Optional): The memory allocation library that will be used for your Ruby installation. Options are
malloc
orjemalloc
. Defaults tomalloc
. - activeprotect:
- whitelist: Specify a comma-separated whitelist of IPs that should be ignored by your ActiveProtect configuration.
- http_ban_rate: Set the threshold of requests per minute from a single IP address. The default is 2000.
Important
In order to use a vpc_id, you must provide subnet_id for all servers used by your application.
production:
rails:
configuration:
ruby_version: 2.2.0
asset_pipeline_precompile: true
do_initial_db_schema_load: false
reserved_server_memory: 0 #default value
passenger_process_memory: 200 #default value
memory_allocator: jemalloc # malloc is default
locked_passenger_version: 4.0.59
activeprotect:
whitelist: 123.123.123.123,234.234.234.234
http_ban_rate: 2000 # Default
vpc_id: vpc-64872001
root_disk_size: 100
root_disk_type: ssd
nameservers: ['8.8.8.8', '8.8.4.4']
iam_instance_profile_name: rails-perms
Rack
The manifest file gives you fine control over things like the Ruby version or which server the application is deployed on.
- ruby_version: Specify the version of Ruby to use. Also applies when you want to upgrade your Ruby version. We recommend that you use this and remove the Ruby version declaration from your Gemfile to avoid situations where your application will not run on every server during an upgrade.
- operating_system (Optional):
ubuntu1604
orubuntu1804
- do_initial_db_schema_load: Specify whether to perform
rake db:schema:load
on new application build. - reserved_server_memory: A value in MB that Cloud 66 will assume should be left available. This will affect any automatically calculated values, and will be taken into account during redeployment.
- passenger_process_memory: A value (in MB) that Cloud 66 will use for each Passenger process. This is also used to calculate the value of the
passenger_pool_max
variable in your Nginx configuration which in turn setspassenger_max_pool_size
. - locked_passenger_version: Force the version of passenger to use. Note: this only applies during server build and is not supported on Passenger Enterprise applications.
- vpc_id (Optional, AWS EC2 only): ID of the AWS VPC in which you would like to create your servers.
- vn_name (Optional, AZURE only): Name of the Virtual Network in which you would like to create your servers.
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers used by application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is ssd.
- iam_instance_profile_name (optional, AWS only): The name of the IAM instance profile that should be used when provisioning this server. (More info here)
- nameservers (_Optional, defaults [ 8.8.8.8, 8.8.4.4 ]): Set DNS servers for your application. Note that if you specify empty array i.e [ ], it won’t add any nameserver to your servers
- include_submodules (Optional, default is true): Set this to false to exclude any Git submodules from being pulled during a build.
- keep_releases (Optional, Defaults to 5) Specify the number of releases to keep on your server(s).
- memory_allocator (Optional): The memory allocation library that will be used for your Ruby installation. Options are
malloc
orjemalloc
. Defaults tomalloc
. - activeprotect:
- whitelist: Specify a comma-separated whitelist of IPs that should be ignored by your ActiveProtect configuration.
- http_ban_rate: Set the threshold of requests per minute from a single IP address. The default is 2000.
Important
In order to use a vpc_id, you must provide subnet_id for all servers used by your application.
production:
rack:
configuration:
ruby_version: 1.9.3
do_initial_db_schema_load: false
reserved_server_memory: 0 #default value
passenger_process_memory: 200 #default value
memory_allocator: jemalloc # malloc is default
locked_passenger_version: 4.0.59
activeprotect:
whitelist: 123.123.123.123,234.234.234.234
vpc_id: vpc-64872001
root_disk_size: 100
root_disk_type: ssd
nameservers: ['8.8.8.8', '8.8.4.4']
iam_instance_profile_name: rack-perms
Rails (Rack) deployment health checks
These checks define tests to confirm whether your application has been successfully deployed, and to mark a deployment as “failed” if any do not pass. They have the following options:
- protocol: which protocol(s) to use when running the check. Acceptable values are
http
orhttps
- host: The hostname or IP address that will we called during the check
- port: The port number that must be used when submitting the request. The default is
80
if you sethttp
as your protocol and443
if you set it tohttps
- endpoint: The URL, path or endpoint that should be checked. This can be any URL in the application.
- accept: A comma separated list of the HTTP response codes that should be considered as a “pass” of this check. All values must be enclosed in quotes. Ranges can be defined with dashes and both the first and last port numbers are included.
- timeout: The wait, in seconds, before the check will time out. The max is 120.
All of these are optional. For more details on health checks please read our how-to guide.
Example:
rails:
configuration:
health:
protocol: 'https'
host: '127.0.0.1'
port: 4430
endpoint: '/'
accept: ["200", "300-399"]
timeout: 30
Redis
- Groups: (Optional) Used to define multiple separate database groups (of the same type), each with their own configuration. The name of each group in your Manifest must match the names in your Dashboard.
- version: Specify the version of Redis you want to install (defaults to 5.0).
- operating_system (Optional):
ubuntu1604
orubuntu1804
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers used by application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is ssd.
- iam_instance_profile_name (optional, AWS only): The name of the IAM instance profile that should be used when provisioning this server. (More info here)
production:
redis:
configuration:
version: 5.0.5
root_disk_size: 100
root_disk_type: ssd
iam_instance_profile_name: redis-perms
Sinatra
For Sinatra use Rack
Load balancers
AWS load balancer
You can use your Manifest file to customize the AWS load balancer deployed by Cloud 66.
Available settings:
- httpchk: The URL visited to check your server health (applies to newly created load balancers only).
- wait_after_adding_servers: The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
- wait_after_removing_servers: The time (in seconds) we will wait after removing a server from the load balancer before we begin deploying to it. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
- alb_ssl_policy: The SSL policy to associate with your ALB when performing SSL termination. See the official AWS docs for available ALB SSL policies.
- elb_ssl_policy: The SSL policy to associate with your ELB when performing SSL termination. See the official AWS docs for available ELB SSL policies.
production:
load_balancer:
configuration:
httpchk: /
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
alb_ssl_policy: ELBSecurityPolicy-FS-1-2-2019-08 # default
elb_ssl_policy: ELBSecurityPolicy-TLS-1-2-2017-01 # default
GCE load balancer
You can use your Manifest file to customize the GCE load balancer deployed by Cloud 66.
Available settings (refer to the GCE documentation for more information):
- httpchk: The URL visited to check your server health (applies to newly created load balancers only).
- balance: The load balancing strategy. Valid values:
NONE
,CLIENT_IP
orCLIENT_IP_PROTO
(applies to newly created load balancers only). - wait_after_adding_servers: The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
- wait_after_removing_servers: The time (in seconds) we will wait after removing a server from the load balancer before we begin deploying to it. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
production:
load_balancer:
configuration:
httpchk: /
balance: CLIENT_IP_PROTO
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
HAProxy
Use a manifest file to configure and define your HAProxy load balancer deployed by Cloud 66. These changes will be either be applied when you redeploy an application with more than one server, rebuild HAProxy or edit HAProxy CustomConfig.
Available settings (refer to the HAProxy documentation for more information):
Server definitions
- unique_name: Name of the instance
- size: The size of the instance (mandatory)
- region: Digital Ocean’s region (mandatory)
- vendor: digitalocean (mandatory)
- key_name: Default (mandatory)
Configuration
- httpchk: The health-check configuration.
- balance: The load balancing strategy. Options include
roundrobin
,leastconn
andsource
- errorfile_*: Location of your own custom error page content to serve in the case of receiving a HTTP error code on the load balancer.
- wait_after_adding_servers: The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
- wait_after_removing_servers: The time (in seconds) we will wait after removing a server from the load balancer before we begin deploying to it. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
production:
load_balancer:
servers:
- server:
unique_name: bananana
size: 1gb
region: ams2
vendor: digitalocean
key_name: Default
configuration:
httpchk: HEAD / HTTP/1.1\\r\\nHost:haproxy #default value
balance: roundrobin #default value
errorfile_400: /etc/haproxy/errors/400.http
errorfile_403: /etc/haproxy/errors/403.http
errorfile_408: /etc/haproxy/errors/408.http
errorfile_500: /etc/haproxy/errors/500.http
errorfile_502: /etc/haproxy/errors/502.http
errorfile_503: /etc/haproxy/errors/503.http
errorfile_504: /etc/haproxy/errors/504.https
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
Linode Nodebalancer
Use a manifest file to the Linode Nodebalancer deployed by Cloud 66.
Available settings (refer to the Linode documentation for more information):
- httpchk: The health-check configuration (applies to newly created load balancers only).
- balance: The load balancing strategy. Valid values :
roundrobin
,leastconn
orsource
(applies to newly created load balancers only). - wait_after_adding_servers: The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
- wait_after_removing_servers: The time (in seconds) we will wait after removing a server from the load balancer before we begin deploying to it. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
production:
load_balancer:
configuration:
httpchk: /
balance: leastconn
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
Rackspace load balancer
Use a manifest file to customize the Rackspace load balancer deployed by Cloud 66.
Available settings (refer to the Rackspace documentation for more information):
- balance: The load balancing strategy. Valid values :
ROUND_ROBIN
,RANDOM
orLEAST_CONNECTIONS
(applies to newly created load balancers only). - wait_after_adding_servers: The time (in seconds) we will wait after adding a server back to the load balancer before we begin routing traffic to that server. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
- wait_after_removing_servers: The time (in seconds) we will wait after removing a server from the load balancer before we begin deploying to it. Read our separate guide on configuration lag for more details. (Redeployment required to change setting)
production:
load_balancer:
configuration:
balance: LEAST_CONNECTIONS
wait_after_adding_servers: 30 # default is 0
wait_after_removing_servers: 10 # default is 0
Which server?
Every component defined in the manifest file must be bound to a server. However, if you’d like configurations to apply to all your servers, you don’t need to specify a server type.
Servers can be deployed specifically to host a single component, be shared between multiple components (e.g. Rails and MySQL on the same server) or be an external server (e.g. using an external database).
Here is an example of a server definition:
production:
rails:
servers:
- server:
unique_name: app
These are the parameters that the server section can take:
- unique_name (Required if you are specifying a server type): A unique name for this server.
- root_disk_size (Optional, AWS EC2, Azure and GCE only): Default size of root disk (in GB) for servers used by application. Default value is 50.
- root_disk_type (Optional, AWS EC2 and GCE only): Disk type, accepted values being ssd and magnetic. Default value is ssd.
- subnet_id (Optional, AWS EC2 only): ID of the AWS subnet in which you would like to create your servers.
- vendor (Optional): Cloud vendor where the server will be built. Valid values: aws, azure (use azure_rm for new Azure accounts), digitalocean, googlecloud, linode, rackspace, and clouda
- key_name (Optional): Key name of cloud vendor where the server will be built. This is used when an account has multiple keys for a given cloud vendor. The default value is
Default
. - region (Optional): Data center regionwhere the server will be built.
- size (Optional): Size of the server instance created.
- availability_zone (Optional, AWS EC2 only): Availability zone of the server instance in AWS EC2 region.
Important
Only a single cloud vendor and region is supported for servers used by an application.
production:
rails:
servers:
server:
unique_name: app
vendor: aws
key_name: Default
region: us-east-1
size: m3.medium
root_disk_size: 100
root_disk_type: ssd
subnet_id: subnet-40000000
availability_zone: us-east-1c
Deploy to your own server
- address (Optional, Registered Server only): Address of the server, only applicable to Registered Servers. For Registered Servers, unique_name and address should be defined.
production:
rails:
server:
unique_name: frontend
address: 123.123.123.123
Shared Servers
You can share a server between two components. This could be in cases like using the same server for both your Rails app and the MySQL server behind it.
Each shared server definition specifies the name of another server definition in the manifest file for which the components will then share the physical server:
production:
rails:
server:
same_as: *another_existing_servers_unique_name*
External Servers
If you would like to use an external server for a component (like using your own MySQL or AWS RDS instance, for example), you can define that server as external.
External server definitions specify that the component is hosted on a server external to Cloud 66. This is not a valid target for your main application (e.g. rails) but may be appropriate for another component (e.g. MongoDB):
production:
mysql:
server: external
Important
Specify environment variables
You can add your environment variables to your manifest files.
Here is an example:
production:
environment_variables:
SOME_VARIABLE: value
ANOTHER_ONE: another_value
THIRD_ONE: AUTO_GENERATE
LONG_ONE: AUTO_GENERATE_15
If you need to auto generate a value, you can use the AUTO_GENERATE
keyword. It generates a 10 character long random string unless you specify the length after it: AUTO_GENERATE_15
which generates a 15 character random string.
Environment variables set in your manifest file will only apply during the initial build of your application. Please refer to our documentation on environment variables if you’d like to set them beyond this point.
Any environment variable that is generated by the result of the code analysis (like database addresses) will override any value specified in the manifest file. In other words, you cannot specify a value like MYSQL_ADDRESS
in your manifest file as it will be ignored.
Processes
Background processes can be deployed and managed by Cloud 66. Any process in a Procfile
will be picked up, deployed and monitored by the system.
If you would like more flexibility over the signals used to control the processes, you can use the procfile_metadata
section. Here is an example:
production:
procfile_metadata:
worker:
stop_sequence: ttin, 120, term, 5, kill
web:
restart_signal: usr1
stop_sequence: usr1, 30, kill
nsq:
restart_on_deploy: false
In this example, a process called worker
is stopped using a TTIN
signal first. After waiting for 120 seconds, if the process is still running, a TERM
signal will be sent. If it is still running after 5 seconds, it will be killed.
As for web
or custom_web
processes, you can specify a restart_signal
which will be sent to the process serving web. This is useful for web servers that can do “phased” or zero-downtime restarts.
All processes restart during each redeployment of the application. If you want to avoid this, you can set restart_on_deploy
to false
.
The default values for process signals depend on which web server and/or process manager you are using.
For the default signals for web servers, click the links below:
For non-web processes:
Specify additional LiveLog files
Each component supports the additional partial configuration to add custom live log files for that component. For example:
production:
rails:
configuration:
custom_log_files: ["/tmp/mylog/*/*.log"]
…or
production:
docker:
configuration:
custom_log_files: ["/tmp/mylog/*/*.log"]
For more information about LiveLogs and additional examples, please see the LiveLogs help page.