Rails - Jul 2006 - Capistrano deployment questions == Best practice type ones

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 ?


2.	/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 ?


3.	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"
- www.macromates.com -

"RubyOnRails, joyful web development! Nothing more nothing less."
- www.rubyonrails.com -



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060706/5cee25fa/attachment-0001.html

On Jul 6, 2006, at 1:17 PM, Mats Persson wrote:
> 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 ?
>
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 Biedenharn		http://agileconsultingllc.com
Rob@AgileConsultingLLC.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060706/6096f9bb/attachment.html

Mats Persson 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/*...]
> 3.	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/<me>/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

-- 
Posted via http://www.ruby-forum.com/.

Apologies for opening my mouth and removing all doubts...

On 6 Jul 2006, at 20:41, Al Evans wrote:
> Mats Persson 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.

>> 3.	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/<me>/ 
> 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 ;-)
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 ;-)



Kind regards,

Mats

----
"TextMate, coding with an incredible sense of joy and ease"
- www.macromates.com -

On 7/6/06, Mats Persson <mats@imediatec.co.uk> 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.
-- 
francesco levorato aka flevour
http://www.flevour.net/

Mats Persson 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 ;-)
> 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 ;-)
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


-- 
Posted via http://www.ruby-forum.com/.

Al Evans wrote:
> Mats Persson 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 ;-)
>> 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 ;-)
> 
> 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

-- 
Posted via http://www.ruby-forum.com/.