Knowledge Base/Engine Yard Cloud Documentation/Manage your Instances

About Instances on Engine Yard Cloud

Engine Yard
posted this on February 16, 2012 10:03 AM

Updated: October 30th, 2012

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

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

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.

 

Comments

User photo
TJ Singleton
salescrunch

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?

October 25, 2012 07:06 AM
User photo
J. Austin Hughey
Engine Yard Inc.

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.

October 26, 2012 04:03 PM
User photo
Paulo H. C. de Oliveira
cuscuz

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?

February 10, 2014 06:30 AM
User photo
Ralph Bankston
Engine Yard Inc.

The small option is offered if you choose "custom configuration" and then small with 1 instance and no seperate database server.

 

 

February 10, 2014 09:07 AM
User photo
Paulo H. C. de Oliveira
cuscuz
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.
February 10, 2014 09:34 AM
User photo
Paulo H. C. de Oliveira
cuscuz

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.

February 10, 2014 12:58 PM
User photo
Matt Dolian
Engine Yard Inc.

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.

 

February 10, 2014 01:00 PM
User photo
Paulo H. C. de Oliveira
cuscuz

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.

February 10, 2014 01:11 PM