Capistrano deployment questions == Best practice type ones

Rails
#1

Hi everyone,

I’ve been sold on the whole idea of using Capistrano for deployment
of my sites and have successfully deployed three apps in three
different environments all with success.

As I’m trying to configure my sites I’ve encountered a number of
issues/questions hence this post.

  1. Database.yml

Twice I’ve been stumped by apps refusing to work on the host because
I did not include the database.yml file in my SVN repos. How does
everyone else handle this point ?

In my mind, I would like to store it in the /shared directory so that
it remains in location for each release. Is there a reason why this
is NOT the default function today ? It seems to me that Capistrano
does so much else, why not this little bit too?

I’m thinking of creating a ‘deploy_db’ task that takes the local
database.yml and uploads it into this location that is run at some
point in the process. When is the key question in my mind ?

  1. /tmp/cache, /tmp/sessions etc

This is also in the release version directory. Is there a valid
reason for this as well, or can I move the whole /tmp directory into /
shared/tmp ? Why is this not the default already ?

  1. Local Rails & Plugins

On a shared host - like Dreamhost - it’s advised to freeze rails with
your app. Freeze normally stores rails inside /vendor/rails which
is also on per versions basis. I’ve tested on a local staging server
and it seems possible to run an app with a symlinked /vendor/rails.
Would this introduce any issues I can’t think of right now ?

The same with Plugins.

I’d really appreciate some feedback or comments on the above before I
proceed.

Kind regards,

Mats

“TextMate, coding with an incredible sense of joy and ease”

“RubyOnRails, joyful web development! Nothing more nothing less.”

#2

Mats P. wrote:

  1. Database.yml

[…]

I’m thinking of creating a ‘deploy_db’ task that takes the local
database.yml and uploads it into this location that is run at some
point in the process. When is the key question in my mind ?

I seems to me that this should work. Remember to soft link it (ln -nfs)
to #{release_path}/config/database.yml. I do similar things with other
files in :after_update_code.

[no opinion on tmp/*…]

  1. Local Rails & Plugins

On a shared host - like Dreamhost - it’s advised to freeze rails with
your app. Freeze normally stores rails inside /vendor/rails which
is also on per versions basis. I’ve tested on a local staging server
and it seems possible to run an app with a symlinked /vendor/rails.
Would this introduce any issues I can’t think of right now ?

On Dreamhost, I built my own binaries for ruby et al. in
/home//local/bin. I liked this solution better than exposing myself
to random acts of updating or freezing Rails in each app. It works fine,
though I have to remember to edit the paths in public/dispatch*. I do
this via a :before_restart Capistrano task.

The same with Plugins.

Wouldn’t all your applications load all your plugins in this case?

–Al Evans

#3

Apologies for opening my mouth and removing all doubts…

On 6 Jul 2006, at 20:41, Al Evans wrote:

Mats P. wrote:

  1. Database.yml
    I’m thinking of creating a ‘deploy_db’ task that takes the local
    database.yml and uploads it into this location that is run at some
    point in the process. When is the key question in my mind ?

I seems to me that this should work. Remember to soft link it (ln -
nfs) to #{release_path}/config/database.yml. I do similar things
with other files in :after_update_code.

Why soft link ? What does that do ? Never encountered that one
before, so don’t get it right now.

local/bin. I liked this solution better than exposing myself to
random acts of updating or freezing Rails in each app. It works
fine, though I have to remember to edit the paths in public/
dispatch*. I do this via a :before_restart Capistrano task.

WOW, do I understand you correctly (??) but do you mean you compiled
your own Ruby 1.8.4 and etc on a normal DH a/c ? IF so, how did you
manage to do so? Any pointers or are welcome. Does that speed up the
site, or just insulates you against DH’s activities ? I’m on poprock
and alondra at DH in case it matters. God, I’d really like to have my
own server, but it’ll have to wait awhile.

The same with Plugins.
Wouldn’t all your applications load all your plugins in this case?

Yes, that’s kind of the idea. It’s all about DRY over here :wink:
Honestly though there are three apps all running with basically the
same plugins so it’s better to keep just one in there, as long as
that does not cause any conflicts. I should probably just use
svn:externals more than I am though :wink:

Kind regards,

Mats

“TextMate, coding with an incredible sense of joy and ease”

#4

On 7/6/06, Mats P. [email protected] wrote:

WOW, do I understand you correctly (??) but do you mean you compiled
your own Ruby 1.8.4 and etc on a normal DH a/c ? IF so, how did you

Hi Mats,
you can visit this page http://wiki.dreamhost.com/index.php/Collaboa
to have a feeling of what you need to do if you want your own
binaries.
http://wiki.dreamhost.com/index.php/Ruby_on_Rails also has some good
insghtings about using local gems.
Cheers.

#5

On Jul 6, 2006, at 1:17 PM, Mats P. wrote:

database.yml and uploads it into this location that is run at some
point in the process. When is the key question in my mind ?

I’ll just address this part, but the technique is useful other places.

My database.yml is placed into svn and works standalone. The
defaults are the login and connection used by production in this
example, but you could “hard-code” the production values, too. To
override the settings, simply place a file in config/mydatabase.yml
containing the lines indicated by the comments and adjust as needed.

For example, the login defaults are fine, but I want to change the
connection method on my local machine:

config/mydatabase.yml

connection: &connection
host: localhost
socket: /tmp/mysql.sock
###EOF

config/database.yml

MySQL (default setup). Versions 4.1 and 5.0 are recommended.

Get the fast C bindings:

gem install mysql

(on OS X: gem install mysql – --include=/usr/local/lib)

And be sure to use new-style password hashing:

http://dev.mysql.com/doc/refman/5.0/en/old-client.html

vvv Copy the following two YAML maps to a file called config/

mydatabase.yml

login: &login
username: demo
password: demo

connection: &connection
host: 127.0.0.1
port: 3306

^^^ Copy the previous two YAML maps to a file called config/

mydatabase.yml

<%= file = File.join(RAILS_ROOT, “config”, “mydatabase.yml”)
IO.read(file) if File.exist?(file) %>

development:
adapter: mysql
database: demo_development
<<: *login
<<: *connection

Warning: The database defined as ‘test’ will be erased and

re-generated from your development database when you run ‘rake’.

Do not set this db to the same as development or production.

test:
adapter: mysql
database: demo_test
<<: *login
<<: *connection

production:
adapter: mysql
database: demo_production
<<: *login
<<: *connection

###EOF

Since the database.yml is passed through ERB, you can do a lot
between ruby and YAML.

I don’t put the config/mydatabase.yml files into svn and keep other
config/*database.yml files on my development machine. You could have
conditional settings based on environment variables or anything else
that Ruby can gets its hands on.

-Rob

Rob B. http://agileconsultingllc.com
[email protected]

#6

Mats P. wrote:

I seems to me that this should work. Remember to soft link it (ln -
nfs) to #{release_path}/config/database.yml. I do similar things
with other files in :after_update_code.

Why soft link ? What does that do ? Never encountered that one
before, so don’t get it right now.

A soft link is the same as a symbolic link. That means it points to
whatever file is named database.yml, as opposed to a hard link, which
links a second name to a specific file, regardless how you rename it.

WOW, do I understand you correctly (??) but do you mean you compiled
your own Ruby 1.8.4 and etc on a normal DH a/c ? IF so, how did you
manage to do so? Any pointers or are welcome. Does that speed up the
site, or just insulates you against DH’s activities ? I’m on poprock
and alondra at DH in case it matters. God, I’d really like to have my
own server, but it’ll have to wait awhile.

It’s not like having your own server, but it does insulate me against
DH’s activities, at least with regard to Ruby, Rails, what Gems I have
installed, and a few other things (ImageMagick, for one). I didn’t
“manage to do so”, I just sort of did it, like I’d install software in
any other UNIX system. The link given in the message from Francesco
Levorato gives you the basic steps.

The same with Plugins.
Wouldn’t all your applications load all your plugins in this case?

Yes, that’s kind of the idea. It’s all about DRY over here :wink:
Honestly though there are three apps all running with basically the
same plugins so it’s better to keep just one in there, as long as
that does not cause any conflicts. I should probably just use
svn:externals more than I am though :wink:

I guess if you’re using the same plugins in all your apps, it makes
sense to have just one copy. You could try moving the vendor/plugins
directory from one of your apps somewhere else, removing it from the
app/vendor directory, and ln -s /path/to/plugins
/path/to/app/vendor/plugins, then restart your app and see if it works.
If so, you’re golden, and you can remove the plugins directory from your
other apps, make a link to the global plugins directory, and restart
them. If not, just move the plugins directory back where you found it.

Personally, I keep everything under Subversion, and use svn:externals
for all my plugins.

–Al Evans

#7

Al Evans wrote:

Mats P. wrote:

I seems to me that this should work. Remember to soft link it (ln -
nfs) to #{release_path}/config/database.yml. I do similar things
with other files in :after_update_code.

Why soft link ? What does that do ? Never encountered that one
before, so don’t get it right now.

A soft link is the same as a symbolic link. That means it points to
whatever file is named database.yml, as opposed to a hard link, which
links a second name to a specific file, regardless how you rename it.

WOW, do I understand you correctly (??) but do you mean you compiled
your own Ruby 1.8.4 and etc on a normal DH a/c ? IF so, how did you
manage to do so? Any pointers or are welcome. Does that speed up the
site, or just insulates you against DH’s activities ? I’m on poprock
and alondra at DH in case it matters. God, I’d really like to have my
own server, but it’ll have to wait awhile.

It’s not like having your own server, but it does insulate me against
DH’s activities, at least with regard to Ruby, Rails, what Gems I have
installed, and a few other things (ImageMagick, for one). I didn’t
“manage to do so”, I just sort of did it, like I’d install software in
any other UNIX system. The link given in the message from Francesco
Levorato gives you the basic steps.

The same with Plugins.
Wouldn’t all your applications load all your plugins in this case?

Yes, that’s kind of the idea. It’s all about DRY over here :wink:
Honestly though there are three apps all running with basically the
same plugins so it’s better to keep just one in there, as long as
that does not cause any conflicts. I should probably just use
svn:externals more than I am though :wink:

I guess if you’re using the same plugins in all your apps, it makes
sense to have just one copy. You could try moving the vendor/plugins
directory from one of your apps somewhere else, removing it from the
app/vendor directory, and ln -s /path/to/plugins
/path/to/app/vendor/plugins, then restart your app and see if it works.
If so, you’re golden, and you can remove the plugins directory from your
other apps, make a link to the global plugins directory, and restart
them. If not, just move the plugins directory back where yndorou found it.

Personally, I keep everything under Subversion, and use svn:externals
for all my plugins.

–Al Evans

Be careful sharing the plugin as plugins evolve over time with your
application and the dependency is broken if individual component are
also not tightly released. I would rather have it in my vendor folder
and take on extra overhead for the sake of versioning.

But again this raises the question: Do u need to go back to a previous
version. I am thinking more or less practically. If it is just a
version or two then sharing is ok. But if u go back 3 or 4 then plugin
dependency could cause trouble.

Just a thought.

aj

aj