Instances on Engine Yard Cloud comprise of the compute resources that are dedicated to running your Ruby application in the cloud. Instances can be configured to serve your application tier, database tier, cache tier, background processing and utilities, and more. Instances are available in various configurations to meet your CPU, memory, and disk space needs.
Engine Yard Cloud is built on top of Amazon’s AWS services. When you create an instance with Engine Yard, you are booting up an EC2 instance. We boot this instance for you and automatically configure it with the appropriate Engine Yard stack components for your environment.
- Persistent Storage
- Instance Types and Roles
- Application Instances
- Database Instances
- Utility Instances
- Single Instance Environment
Your application code and database are written out to persistent storage volumes. We automatically mount these volumes and take backups for you.
/data mount on the application master instance and the
/db mount on the database master instance(s) are persistent. We take advantage of Amazon’s EBS storage allowing us to take regular disk snapshots of both of these volumes.
If you ever have to rebuild your instances from scratch you will have the ability to restore both of these volumes from previous snapshots.
Instance Types and Roles
There are various roles that an instance can play in your application’s environment. These roles include the following:
Application instancesInstances configured to run your application tier.
Instances configured to run your database tier.
Instances configured for utility and background work.
Single instance environment
A single instance configured to combine multiple roles into one environment.
These instances are configured to run your Ruby-based application. They are configured with the Engine Yard stack. Your application is automatically deployed onto the
/data mount which is persistent storage.
We back up the
/data volume only on the application master instance.
You can run crons on your Application instances and you can setup crons to run on the application master instance via the web UI’s Crontab page. If your crons are CPU or memory intensive, consider off-loading the work to a utility instance.
This instance is configured to run your database. Running your database on a separate server prevents your database and application from contending for the same resources.
Your database resides on the
/db mount. This mount point is persistent and can be used to restore your database later. We take regular snapshots and backups of your database by default.
Note: If your application does not use a database, or you want to use an add-on database instead of PostgreSQL or MySQL, choose the "No Database" Database Stack option.
For more information about databases, see Manage your database.
Utility instances are great for off loading any heavy work from your application instances. It’s common to run background jobs, job queues, and crons on utility instances. They are also useful for running large memcached instances.
We automatically push your code to the utility instances with each deploy for you. This allows your crons and background jobs to access any application code that they need.
Single Instance Environment
Single instance environments, commonly called a solo instance, are great for staging and development environments because they’ll save you money. You can boot up a single instance, and we’ll deploy both your application and your database to this instance. These types of environments are not, however, ideal for production because your database and application contend for the same system resources.
If you boot up a single instance environment to start with, you can upgrade it to a multiple-instance environment later.
|For more information about...||See...|
|Adding instances to a cluster||Add Instances to a Cluster|
|No database option||Create an Environment|
|Application master instances||application master glossary definition|