No, this is not a real Sinatra error :).
This is the personal homepage of Elad Meidar, a web developer and an entrepreneur specializing in Ruby on Rails. I hang around in Israel, and i am currently having the best time of my life over at Fiverr.com
I am a proud member of RailsBridge, Helping new Rails developers get into our world and also contributed a few Patches to the Ruby on Rails core.
A while ago i wrote a post tutoring a deployment of a simple rails application on ec2 using the EC2onRails gem,
in this post i will explain how to use another plugin, called rubber that simplifies the deployment of more complex applications, those with multiple instances for example.
Follow this section on my previous Rails on EC2 post to get your EC2 account SSH keypair first,
Then, install he
$ sudo gem install amazon-ec2
$ sudo gem install aws-s3
$ sudo gem install capistrano
$ sudo gem install nettica
netticagem if you need to automatically map specific instances to A Records.
in your application root, install the
$ script/plugin install git://github.com/wr0ngway/rubber.git
and than the crazy part, you’ll have to generate a
rubber deployment setup that matches your application needs. To do that you’ll have to choose on your own.
Each one of these “configurations” contains one or more service that is needed for your application, such as Apache, Mysql, Sphinx and more, and some act as bundles that basically install a group
of other services:
The one that we will use is the one that was the most suitable for my application, the
complete_passenger_mysql, so in your project root type:
$ script/generate vulcanize complete_passenger_mysql
now edit your
config/rubber/rubber.yml and add your
access_key, secret_access_key, aws_account, ec2_key_name and
ec2_key_file (you can get all of those by following my previous post).
each service/bundle installs with a set configuration files, a
rubber-module.yml file for configuring each module will be found in your
config/rubber folder, a long side a
deploy-module.rb file for deployment specific behavior.
As you can see, the configuration files are basically ERB templates.
Some special variables are defined to handle and control the module:
|@*path*||The output path to write the transformed config file to|
|@*read_cmd*||The command to use for reading the original config file from, e.g. “crontab -l”|
|@*write_cmd*||The command to use for piping the transformed config file to, e.g. “crontab -”|
|@post The||command to run after generating the config file ONLY if it has changed|
|@owner||The owner the output file should have, e.g. “root”|
|@group||The group the output file should have, e.g. “system”|
|@perms||The permissions the output file should have, e.g. 0644|
|@additive||Sets transformation to be additive, only replaces between given delimiters, e.g. @additive = [“## start”, “## end”]|
The variables set in bold are those you must supply.
In addition, within the configuration files you can access to the rubber configuration objects
rubber_env (rubber*.yml) and
to test your configuration run:
$ rake rubber:config
developmentenvironment, so you can check that everything is up and running.
and will override based on that order in favor of the most specific configuration and alphabet order of configuration files.
first, you’ll need to create your environment bootstrap, in this case, it’s production
$ ALIAS=production ROLES=web,haproxy,app,mysql_master,passenger cap rubber:create
$ ALIAS=web01 ROLES=web,haproxy, passenger cap rubber:create
$ ALIAS=app01 ROLES=app cap rubber:create
$ ALIAS=app02 ROLES=app cap rubber:create
$ ALIAS=db01 ROLES=mysql_master cap rubber:create
$ ALIAS=db02 ROLES=mysql_slave cap rubber:create
$ cap rubber:bootstrap
$ cap deploy:check
$ cap deploy:setup
$ cap deploy:cold
and that’s about it.
The process of configuring an instance, bootstarping, and delpoying will run on all the instances your have specified, old and new!, so you shoudl always check your configuration on a local/staging environment.
You're seeing this error because I think it is funny.