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.
Topics:
- Persistent Storage
- Instance Types and Roles
- Application Instances
- Database Instances
- Utility Instances
- Single Instance Environment
Persistent storage
Your application code and database are written out to persistent storage volumes. We automatically mount these volumes and take backups for you.
Both the /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 instances
Instances configured to run your application tier.
-
Database instances
Instances configured to run your database tier.
-
Utility instances
Instances configured for utility and background work.
-
Single instance environment
A single instance configured to combine multiple roles into one environment.
Application Instances
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.
Database Instances
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
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.
More information
| 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 |
If you have feedback or questions about this page, add a comment below. If you need help, submit a ticket with Engine Yard Support.
If an application master dies and an application is promoted. Does it receive the old master's /data mount or does it's own supersede it?
In the event of a takeover, the application master's volumes are snapshotted, an existing application slave is promoted to master (its volumes do not change, they stay exactly as they are), and a new application slave is spun up to replace the non-responsive master. That slave then attaches volumes based on the snapshots taken from the previously decommissioned master.
So basically, yes - the app slave's previous /data mount stays in-tact. The application master's volumes are not attached to the slave to be promoted.
I am trying to create an environment for staging, but the single instance option is oferring me 5 ECU's and 350 GB of storage. I have tried with the stacks 2 and 4, Ruby versions 1.9.3 and 2.0.0, and with PostgreSQL 9.2.x and 9.3.x. Nothing works. Is the cheapest server (small, 40 $/month) not offered anymore?
The small option is offered if you choose "custom configuration" and then small with 1 instance and no separate database server.
Nope. I tried your suggestion, both with the stacks 2 and 4, using passenger, and the only option for application instance is Medium (32 bits) - for stack 2 - and Medium (64 bits) - for stack 4. The same can be said about the database. Maybe I should not declare a database on the environment.
To be sure, I tried everything: Ruby 1.9.3, 2.0.0, stacks 2 and 4; with and without a database; boot from a snapshot and new volume; I even disabled the early access features that I would like to use: PostgreSQL 9.3 and Puma. Nothing worked. Even without a database, when the only options available is custom instance, the only option for me medium, 32 and 64 bits, for stack 2 and 4. Also, I never used my 500 free hours, and it is gone, twice.
It looks like your account is a trial which means only medium instances will be available. When you convert to a paid account, the small instance sizes will be available as well as all of our other available instance types.
Well, that explains a lot. Although I don't remember reading about that anywhere. But I admit that I may have missed it. Thank you.