Permalink
Browse files

Update USAGE.md

Some notes from QAing.
  • Loading branch information...
daemianmack committed Sep 28, 2012
1 parent f1890f8 commit 7a717be3c4a766ea3db93b4502b3eecd78d30a6e
Showing with 12 additions and 10 deletions.
  1. +12 −10 USAGE.md
View
@@ -7,6 +7,9 @@ This example assumes that you have a working Rails application that is
compatible with the default [Rails DNA](/relevance/elzar/tree/master/lib/elzar/templates/dna/rails.json)
included in Elzar.
All commands assume your RAILS_ROOT is your current working directory.
It's worth noting that a new EC2 instance is provisioned each time this script is executed; you'll probably want to clean those up if you need to re-start for any reason.
### Step 0: Install Elzar
@@ -73,6 +76,8 @@ The `rails_app[name]` in `dna.json` has several implicit effects:
* It determines the path of your nginx configuration file (e.g.,
`/etc/nginx/sites-enabled/elzar_rails_example`)
You'll want to consider how your choice of rails_app name will operate in these contexts; for example, whether your database engine allows dashes in its database names.
### Step 3: Configure AWS Settings
@@ -128,7 +133,7 @@ of "ElzarRailsExample Staging". This is the name that you will see when browsing
instances in the AWS console. Name your instance accordingly.
If this step completes successfully, it will display the ID of the
instance as well as its public IP address. For example:
instance, which you'll use in the next step, as well as its public IP address. For example:
```
Finished Provisioning Server
@@ -146,12 +151,9 @@ combined payload will be uploaded to the server and placed in
```sh
elzar cook i-abcdef01
elzar cook [YOUR-INSTANCE-ID]
```
When running this command be sure to use the instance ID returned to you
from the `preheat` command.
### Step 6: Configure Capistrano
@@ -182,7 +184,7 @@ role :db, "your primary db-server here", :primary => true # This is where Rails
role :db, "your slave db-server here"
```
Using the IP address that we got from running `elzar preheat` earlier,
Using the IP address that we got from previous elzar commands,
our config would look like this:
```ruby
@@ -215,20 +217,20 @@ vim /var/www/apps/elzar_rails_example/shared/config/database.yml
```
Your `database.yml` file should look similar to this one, obviously
edited to meet your application's needs. Be sure you configure the value
of `database` to match the one created by Chef (i.e.
`#{rails_app[name]}_production`).
edited to meet your application's needs.
```yaml
production:
adapter: postgresql
encoding: unicode
database: elzar_rails_example_production
database: [YOUR-APP-NAME]_production
pool: 5
username: deploy
password: d3pl0y-p0stgr3s
```
If you chose to SSH into the instance to set up database.yml, be sure continue from the RAILS_ROOT on the local machine.

This comment has been minimized.

Show comment
Hide comment
@sumbach

sumbach Oct 1, 2012

Contributor

Not sure what this means, Daemian. Please clarify.

@sumbach

sumbach Oct 1, 2012

Contributor

Not sure what this means, Daemian. Please clarify.

### Step 8: Serve It Up
Here comes the exciting part. It's time to deploy our Rails app to the

1 comment on commit 7a717be

@daemianmack

This comment has been minimized.

Show comment
Hide comment
@daemianmack

daemianmack Oct 1, 2012

Member

Probably not the best phrasing. If you're following along with the doc in lockstep, you're now on the remote machine (having just run mkdir and vim there), but the next commands assume you're on the local one in order to cap deploy. If the reader has gone that route, I think we should make that assumption explicit.

Maybe the clearest way to do this would be to instead append the following to the mkdir/vim code sequence...

exit # Be sure to log out of the remote machine when finished editing database.yml.

Member

daemianmack commented on 7a717be Oct 1, 2012

Probably not the best phrasing. If you're following along with the doc in lockstep, you're now on the remote machine (having just run mkdir and vim there), but the next commands assume you're on the local one in order to cap deploy. If the reader has gone that route, I think we should make that assumption explicit.

Maybe the clearest way to do this would be to instead append the following to the mkdir/vim code sequence...

exit # Be sure to log out of the remote machine when finished editing database.yml.

Please sign in to comment.