bgror

Understanding Engine Yard Cloud Takeover »

Created at: 04.10.2011 22:20, source: Engine Yard Blog, tagged: Product Tips & Tricks appcloud Engine Yard Cloud takeover

Two basic tenets of cloud computing are that 1) servers are dispensable; and 2) any two servers in the same role are interchangeable. When an instance fails or detects an impending failure, it must be replaced with another. When performed on one of your app servers, Engine Yard Cloud refers to this process as a “takeover.” A takeover is specifically the process by which an app master is replaced by an app slave.

In Engine Yard Cloud, your environment’s Elastic IP is attached to the ‘app master’ instance. During a takeover, an ‘app slave’ is promoted to ‘app master’ and takes control of the IP address. The practicalities of running Ruby applications require the app master to be special in a few other ways, such as running cron tasks and migrations. If an ‘app slave’ fails, no takeover is necessary, because you can simply boot a replacement slave.

During takeover, a new app slave instance will be booted up to replace the one promoted to master. With the recent introduction of Stack Change Management, the new instance will be on the same Engine Yard stack version as the rest of the environment.

On the newly-promoted app master, a few things will happen. These include reconfiguring HAProxy and spinning up a new application server with the snapshot of the failed app master's /data file system.

There are a couple key implications of this takeover process:

1. In your environment, there should be at least one "spare" application server. This is in addition to the application servers that provide the capacity while a new application server is spinning up. For example, if you need a minimum of three application servers to serve the everyday traffic, there should be four application servers during normal operation. Without a spare instance, your site could fail or slow down under load during the takeover.
2. If, after an app slave is promoted to master, you find yourself missing the data you had written to the /data mount, you should strongly consider storing such data in a ‘cloud-friendly’ store, such as S3 or your own service running on ‘utility’ instances.

By understanding the takeover process and implementing your system according to best practices, you can take better advantage of the Engine Yard Cloud platform and minimize potential downtime or data loss.

more »

Ruby and Passenger News »

Created at: 05.08.2011 03:09, source: Engine Yard Blog, tagged: Product appcloud jruby on appcloud passenger 3 ruby 1.9.2

more »

PostgreSQL 9 Support in Alpha »

Created at: 12.07.2011 01:16, source: Engine Yard Blog, tagged: cloud Product Technology appcloud Engine Yard Beta Program PostgreSQL

We are happy to announce that we have made PostgreSQL 9 available in Alpha to AppCloud customers who want to give it a try. Customers looking for additional database choices who are interested in the features offered by PostgreSQL 9 (current version is 9.0.4) should enroll in the alpha program. Also, we are currently working towards our Beta release, which will be available to all customers, and we want to include as much of your feedback as possible to make this a great feature! In addition to taking advantage of the stability, robustness, and feature set offered by PostgreSQL 9, customers using Rails 3.1 can take advantage of significant speed gains with PostgreSQL over MySQL. At RailsConf 2011, Aaron Patterson talked about the use of cached prepared statements in Rails 3.1, which provide a significant boost for PostgreSQL. If you would like to try PostgreSQL in Alpha:

• Review the documentation, noting the current limitations for this Alpha release. These are important to be aware of before you request Alpha access.
• Request access.

Once you’ve been granted Alpha access, refer back to the documentation for instructions on how to set up PostgreSQL 9 on your environment. Have some fun with it and let us know what you think! You can provide feedback by creating a discussion on the ey-beta-talk mailing list.

more »

AppCloud Dashboard Design Updates »

Created at: 29.06.2011 21:10, source: Engine Yard Blog, tagged: Product appcloud dashboard ui ux

Last week we rolled out a major application-centric UI redesign for our Dashboard, which lays the foundation for many awesome features coming down the path. We’re very excited about where the user experience is headed, and we look forward to all the improvements we have planned which will allow people to manage their clusters and applications more easily. However, we realize that not everyone is as happy about this initial step as we were. Our excitement to show off our changes led us to ship something that isn’t up to our usual standards of excellence, and for that we very sincerely apologize. We are definitely listening to the feedback we’ve received through emails, Twitter, support requests, and comments here on the blog. We are prioritizing the most painful issues and plan to address them as soon as possible. The list of immediate improvements include:

• Adding an instance summary for each environment on the dashboard so you can see what is running.
• Ensuring that the status indicator for environments and instances reflects the appropriate state.
• Showing stack updates on the dashboard index so you can see environments that need updates.
• Making active alerts for your environments more visible.
• Simplifying the process to add an application to a new environment.
• Clarifying when you are viewing a production environment.
• Placing the deploy button front and center on the new dashboard.
• Giving prominence to all applications running on an environment.

Based on the feedback we’ve received, we believe that these are the most important issues to address. However, we would love to hear from you if you have any additional feedback or suggestions for the new interface. Again, we want to apologize for the frustration we’ve caused. We have many features planned which are built on top of this redesign and we hope they will more than make up for it!

more »

Bundler and Rails 3.1 on AppCloud »

Created at: 24.06.2011 02:04, source: Engine Yard Blog, tagged: Technology Tips & Tricks appcloud bundler rails 3.1

Specifying the correct gem dependency in your Ruby on Rails application has always been very important. Luckily, Bundler has made our lives much easier by taking care of many of the headaches for us. There have been many changes to the codebase with Rails 3.1. With Rails 3.1 on the horizon, it is increasingly important to know which versions of gems are needed for an application depending on the Rails version. Here are some things to think about when preparing for deployment.

Common Errors with Gem Versions

Below are some common errors that we have received lately on the Engine Yard AppCloud platform.

Gem::SilentUI (NameError)

Lately, we have received an elevated amount of tickets when people try to deploy with the error: "uninitialized constant Gem::SilentUI (NameError)". The problem is that this error does not really tell people what is wrong.

Different Bundler Versions

Most of the time, this issue can be resolved by checking the system Bundler version on your instance against the Bundler version on your development machine. If the system version is 1.0.0 or below and your machine version is 1.0.15, then the easiest thing to do is add gem 'bundler', '1.0.15' to your Gemfile. Then just run bundle update bundler from the command line and re-deploy your application.

no such file to load -- active_record/connection_adapters/mysql2_adapter

This is another error that does not really explain what the problem is. In Rails 3.1, the ActiveRecord MySQL2 Adapter is included by default and therefore is not provided in the mysql2 gem in versions greater than 0.3.

Rails 3.1 and Higher

For versions of Rails 3.1 and up, you just want to add gem 'mysql2', '~> 0.3' to your Gemfile.

Below Rails 3.1

If you are using a version of Rails lower than 3.1, you need to tell bundler the version of mysql2 to use and it needs to be lower that 0.3. Adding gem 'mysql2', '~> 0.2.7' to your Gemfile should take care of this.

What does this mean for my application?

It is increasingly important to require the correct version of your gems in your Gemfile. You should also use bundle exec <command> from your application so you only use the gem versions specified for your environment. A better option is to use binstubs which are automatically installed on AppCloud instances. Just run bin/rspec or bin/<executable> instead of just rspec or <executable> and your commands will be run against the application environment.

More Information

• Installing Rails 3.1
• Bundler Homepage
• Bundler Documentation
• Bundler Pro Tips

more »