We'll respond shortly.
Want to deploy a Rails app to ‘the cloud?’ Here are 5 steps to get your app on Cloud Foundry. Although here I’ll deploy a JRuby on Rails app, deploying a Ruby on Rails app works just the same.
In this example, I’ll use postgres but Cloud Foundry supports MySQL and other popular databases too.
$ jruby -S rails new myApp -d postgresql
Login to your Cloud Foundry account. If this is your first time logging in, it asks you to create a new Org. Orgs and Spaces are Cloud Foundry jargon which seem confusing and superfluous initially. However, they are a neat way of managing environments. Having deployed to Cloud Foundry on a couple of projects now, here is what Orgs and Spaces mean to me:
$ cf login
When prompted for an API endpoint enter api.run.pivotal.io. If all goes well, you should see a success message like:
API endpoint: https://api.run.pivotal.io (API version: 2.0.0) User: <your_cloud_foundry_username> Org: all-apps Space: staging
Cloud Foundry is not tightly coupled with your version control system. While this can be a little extra work and doesn’t give you the benefit of automatically deploying every time you push to git, I’ve generally found it to be quite useful:
tmp/ log/ test/ .DS_Store
$ cf create-service elephantsql turtle elephantsql-myApp-staging
This creates an instance of the ElephantSQL service that may be used by any app in the staging space. If you are unsure of what services you want to use
cf marketplace lists all available services and plans. To bind to the service instance(s) that you have created, use the manifest.yml. An app manifest is a way to specify details about your application. While its not required to deploy, its an easy way to configure your app. A simple manifest.yml looks like:
applications: - name: myApp-staging memory: 1024M instances: 1 host: myApp-staging domain: cfapps.io path: ./tmp/deploy timeout: 120 command: bundle exec rake db:migrate && bundle exec rails s -p $PORT services: - elephantsql-myApp-staging
While most of it is standard, a few interesting things are the path, command and timeout. path represents the path from which the manifest deploys. Copying the contents of your working directory over to a ./tmp/deploy and pointing your manifest to deploy from there allows you to continue working while the app deploys. command is what cloud foundry runs to start your app. timeout is a way to tell cloud foundry about your app’s startup time. If you don’t specify a timeout, Cloud Foundry assumes a default of 1 minute. This is reasonable for most RoR apps, but JRuby needs a longer startup time.
The last thing you need to do is to allow your Rails app to serve static assets in production. In production.rb make sure you have an entry
config.serve_static_assets = true
myApp is now ready for deploying!
$ cf push myApp-staging
Cloud Foundry uses Heroku’s Ruby buildpack, which precompiles assets for your Rails apps and if you have a single app it is faster to precompile assets on Cloud Foundry rather than uploading precompiled assets. However, if you are pushing multiple apps, it is faster for you to precompile assets locally once and upload them.
To do so,
$ RAILS_ENV=production rake assets:precompile before pushing your app.
Do you see your robots.txt when you go to myapp-staging.cfapps.io? Success! :)
PS: At any point if you get unexpected results, some useful debugging commands are:
cf logs myApp,
cf apps or
cf to list all cf commands.