Let the Engine Yard Cloud dashboard and SSH access help you »
Created at: 25.10.2011 21:06, source: Engine Yard Blog, tagged: cloud Technology Tips & Tricks
A common web application frustration almost everyone can understand is the headache associated with discovering your site is down. The discovery that your site is down can encompass a wide spectrum of situations ranging from 404 errors, to a 500 internal server error, to a no response timeout. What may be even more frustrating, is the fact that you do not always know exactly what the issue is, or how to tackle it, even if you later discover it is merely a trivial error. In this post I’ll walk through ways the Engine Yard Cloud dashboard and SSH access can help users gain better visibility into the issue or issues resulting in site downtime.
The Engine Yard Cloud dashboard
Before we begin, it’s important to keep in mind that the following steps assume there are no technical issues with the Engine Yard Cloud platform itself. For Engine Yard Cloud system level issues, we recommend following @eycloud on Twitter and subscribing to the Release Notes feed.
Start with visual inspections
From the Dashboard homepage, do you see a red status indicator? This designates that your EC2 instance is experiencing problems. A few things can cause this problem. So, how do you figure out why? Click on the environment that has a red status indicator. As you can see the environment below displays a red status indicator.
Now you can view a handful of logs to diagnose the problem. If a problem was caused by pressing the Upgrade button, the Base Log will display the reason for it. It may be necessary to check the Custom Log if you are using custom Chef recipes.
For example, this particular error was caused by a typo in the custom chef recipe. Here is the custom log displaying the error. The database name was spelled incorrectly in this case.
More often than not, the errors are descriptive enough to resolve once you have identified them. Once you have fixed the error, you will need to “Apply” the changes.
What else could be wrong?
Your next discovery may be found in the alerts tab. Alerts offer you useful information about heavy load, high memory usage, low disk space, etc. For example, if you discover you are running out of memory, you may decide to scale your environment or modify your application in order to resolve such issues.
I see a green status indicator and there are no alerts
If this is the case, there is a strong possibility that your application deployment failed. Let’s visit your application’s View Log. Usually you will find an explanation for the deployment failure somewhere along the bottom of the log. Common culprits may include git errors, RubyGem issues, a typo in your application’s custom Chef recipes, etc.
In this case the error is showing “Permission denied (publickey)”, which is often displayed as a result of failing to add your deploy key to your git repository.
My application is still down
Hopefully the suggestions above will help you diagnose the source of your downtime so that you can get your application back up. Of course situations may also occur where no information on the Engine Yard Cloud Dashboard indicates any potential problems. So, what do you do in this case?
Let’s get down and utilize SSH
Inspect application logs within your instance
Additional logs exist that are not viewable directly through your Dashboard. Since each Engine Yard Cloud instance corresponds to an actual Amazon EC2 instance, you can view files in your instance as you would on any other server.
The first place to check is your application’s logs under /data//current/log. The file production.log may point you in the right direction. Other log files in the same directories may lead you to a discovery as well.
What other processes can fail?
Another common problem can result from Nginx. Due to certain triggers, it is possible for Nginx to be terminated. To determine the Nginx status execute sudo /etc/init.d/nginx status. If the status indicates that Nginx has not started, you can run sudo /etc/init.d/nginix start to fix that. Then, recheck the status to verify you are good to go.
The same principle can be applied to MySQL. You can check the status with sudo /etc/init.d/mysql status and start MySQL with sudo /etc/init.d/mysql start. To check the status of Passenger, run passenger-status and you can restart passenger by restarting Nginix as passenger automatically restarts with passenger. You can also find other useful logs under /var/log, such daemon.log, syslog, etc.
Wrapping up
Downtime is frustrating. Luckily, there are many tools and resources to arm you with useful information to help diagnose and resolve downtime related issues. You can also check out the Site is down: diagnostic checklist on our documentation page for a more formal walk through.
more »
Rails 3.1 Has Landed »
Created at: 18.10.2011 23:43, source: Engine Yard Blog, tagged: cloud Product Technology
We are ecstatic to let all of you wonderful Engine Yard Cloud and Engine Yard Managed customers know that we are officially supporting Rails 3.1! Rails 3.1 brings a metric ton (we measured) of new features and functionality that will benefit you all. Instead of just listing them out, I asked a few folks including some of our staff what they were most looking forward to in Rails 3.1.
Asset Pipeline
A whole slew of excited Twitterers said they were most looking forward to the use of the asset pipeline! Our own Evan Machnic sums it up by saying, “The asset pipeline makes it easy to organize and serve your assets. Pairing the pipeline with a well-tuned web and application server means that web sites are rendered blazing fast.” I would have said the same thing. Word for word. I’m suspicious that he copied my work.
Prepared Statements
Thomas Enebo and Nick Sieger of the JRuby crew are wildly excited about the use of Prepared Statements. PostgreSQL customers will notice a huge performance boost. It was because of Rails 3.1’s improvements for PostgreSQL that we decided to offer PostgreSQL to our customers. PostgreSQL is currently released in Alpha. MySQL customers utilizing complex statements will also notice a boost.
HTTP Streaming
Danish Khan and several folks from Facebook also chimed in for HTTP streaming response. Browsers will load pages faster than ever before, especially when used with the asset pipeline! Please note that currently we only support streaming with Unicorn. We are working as quickly as possible to support other web servers.
jQuery
Shane Becker is excited by jQuery being the default JavaScript framework for Rails with 3.1. He says, “One of my favorite Rails 3.1 features is that jQuery is the default JavaScript library. It's such a small detail. But there's something in the details, right?”
:bulk => true
Josh Lane and Tyler Poland both echoed that the use of :bulk => true is what will make their dreams come true. Using :bulk => true option in change_table migrations ensures that all schema changes use a single ALTER statement.
Tyler explains that, “Before Rails 3.1, each statement within a migration is mapped to an individual 'ALTER TABLE' statement within MySQL. This is problematic since each of those 'ALTER' statements re-writes the entire table on disk and blocks writes while it is running. Generally, each 'ALTER' takes about the same amount of time to run as a single statement capturing all those changes written in the 'SQL' syntax. Baron Schwartz discusses the topic here. This feature enables Rails to merge the changes into a single statement automatically, thus increasing the speed of your migrations.”
This is just a sampling of the new features available to you with Rails 3.1. Now everyone who has been building Rails 3.1 applications can start deploying them on Engine Yard today. For all additional documentation, go here.
When you upgrade your Rails 3 application to Rails 3.1, all this goodness is available when you ey deploy!
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.
more »
Simple DNS for AppCloud »
Created at: 28.05.2011 01:58, source: Engine Yard Blog, tagged: cloud Technology Tips & Tricks
Pop quiz, which URL is prettier:
Exactly, the first one. To setup a custom domain name you need to buy a domain and then register DNS records to point to your AppCloud cluster. This is (to me) a convoluted process. It could be much simpler. Introducing theey-dns command line application to make DNS simple (see the readme). It supports 6 different DNS services, including DNSimple and AWS Route 53 (see below).
It’s really quite easy to use:
- Install the tool:
$ gem install engineyard-dns
- Change to your Rails/Ruby project that is deployed with AppCloud:
$ cd path/to/my/app
- Run
ey-dns:$ ey-dns apply myapp.com Assigning myapp.com —> 1.2.3.4 (drnic/myapp_production) Assigning www.myapp.com —> 1.2.3.4 (drnic/myapp_production)
--environment and --account options to be more specific:
$ ey-dns apply myapp.com --environment myapp_productionSubdomains are a little weird because of how DNS zones work. Put your bare domain first and then subdomain names after. The following sets staging.myapp.com to the myapp_staging environment.
$ ey-dns apply myapp.com staging --environment myapp_stagingIf you have multiple apps on one environment, you will still have to update the domain name of each app in the AppCloud dashboard so that nginx knows what vhost you mean to serve at that domain. Just click edit on each app in an environment to add vhost domains.
Preparing your DNS provider
To be complete you will also need to purchase/transfer a domain:- Register your application’s domain with a DNS provider (see supported list below), such as DNSimple.
- Transfer your domain to your DNS provider or change to use their name servers, such as
ns1.dnsimple.com(ns2, ns3, etc) for DNSimple.
Supported DNS providers
ey-dns will automatically determine which DNS provider is managing the domain/zone that you are wiring up to your AppCloud environment.
This new CLI uses fog to access DNS providers. The current list of available DNS providers for fog is: AWS, Bluebox, DNSimple, Linode, Slicehost, Zerigo. The next section shows how to setup fog credentials.
DNS credentials
To access your DNS provider, you need to add your account/API credentials into your~/.fog file.
In my example ~/.fog file below I have DNS access to DNSimple, Slicehost and AWS Route 53.
:default: :dnsimple_email: MYEMAIL :dnsimple_password: XXXXXXXXXXX :aws_access_key_id: 0NJRCXXXXXXXXXXXX :aws_secret_access_key: QGtnbXXXXXXXXXXXX/qQ4lXXXXXXXXXXXXXX :slicehost_password: f9a265f66XXXXXXXXXXXXXXXXXXXXXXXXXXX
DNSimple credentials
I currently use DNSimple for registering and serving all my new domains. Their API credentials are the same email/password you use to login to the service. Note the surreptitious referral used here, giving me a free month for each DNSimple sign-up, bwhahahaha. To avoid gifting me a free month, use http://dnsimple.com link. A free month isn’t as cool as free swag, but I don’t think DNSimple has free swag. Well, I don’t have any of it.AWS credentials
Recently AWS began offering an API-driven DNS server Route 53. The AWS credentials for access DNS are the same credentials you use in CarrierWave or PaperClip to access AWS S3. To find them, log into your AWS Account and navigate to “Security Credentials”, then “Access Credentials”, and click “Show” to see your secret access key.
Slicehost credentials
Until I switched to DNSimple and to fog, I used Slicehost for its API/CLI-driven DNS. I still have many domains managed by Slicehost. To enable API access to your Slicehost account infog (and hence ey-dns) go to https://manage.slicehost.com/api, enabled API access and copy your API token into the slicehost_password field of ~/.fog above.
Testing credentials
You can test your DNS credentials with theey-dns domains command:
$ ey-dns domains AWS: none DNSimple: drnicwilliams.com - 0 records emrubyconf.com - 2 records mocra.com - 27 records Slicehost: myconfplan.com. - 0 records
Summary
Hopefully this tool makes it much easier to setup or change DNS for your AppCloud environments. Let us know in the comments or in the project’s Issues if you love it, find bugs or have feature requests. The source and instructions for the project is available on GitHub.more »
JRuby on AppCloud Available Through Beta Program »
Created at: 25.05.2011 04:39, source: Engine Yard Blog, tagged: cloud Product Technology Engine Yard Beta Program jruby jruby on appcloud trinidad
We’re overjoyed to announce that customers can now sign up to use JRuby with Engine Yard AppCloud through our beta program. Engine Yard has been a strong supporter of the JRuby project and we’re thrilled that we can now begin offering JRuby support to our customers.
There are two camps of customers demanding JRuby:
- Applications that desire to incorporate Java libraries
- Developers wanting features that MRI cannot provide – real threads, a selection of modern garbage collectors, in-process caching, and full utilization of available memory, as starters.
- Add to your Gemfile:
platforms :jruby do gem 'activerecord-jdbc-adapter' gem 'jruby-openssl' gem 'jdbc-mysql', :require => false gem 'trinidad' end platforms :ruby do gem 'mysql2' end - Install and switch to JRuby:
$ rvm install jruby $ rvm jruby $ bundle
- Launch your Ruby application with Trinidad (it auto-detects what sort of Ruby web application you have):
$ trinidad
- Open http://localhost:3000 in your browser and wait for the Tomcat application server to boot up, then you are good to go.
- Commit the Gemfile & Gemfile.lock changes (possibly to a branch)
- Deploy to staging environment on AppCloud setup with JRuby. There are some additional instructions and limitations in the Trinidad/JRuby documentation.
Full House of Rubies
Personally, I’m more than overjoyed. With JRuby now available on AppCloud, Engine Yard is the first Ruby platform to make available all stable, production-ready Ruby implementations; most notably JRuby and Rubinius.OSS Grant for David Calavera
I would also like to announce that earlier this year Engine Yard offered David Calavera an Engine Yard OSS Grant towards the Trinidad project. This has allowed David to travel to Baltimore last week to speak at RailsConf. We’re excited to continue to help David spread the word about Trinidad – it is our favorite “JRuby in a Box” solution!more »
Tag cloud
Categories
Links
Blogs: 43
Posts: 2516