So someone requested me to deploy rails on 30+ machines, he has a fully developped rails app on his local machine - only trouble is: he installed everything using gem. Now, since I have to care for more than 70 servers and workstations there are a number of organizational policy rules regarding system administration: Nothing EVER gets installed that bypasses the package management system (be it rpm or deb). Needless to say this clashes with gem. Unfortunately installing "gemless" rails works for newly created rails applications, but not for his fully developed (complains about missing rails gem). Now the question is: How can I help him to make his application runnable is this environment and avoid the same pitfall in the future? (and what did he do wrong to begin with?) Of course I can always tell him he has to locally compile and deploy all gems himself as non-root in his own directories, but he won''t be happy and neither do I like this. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Couldn''t you just do a rake:rails:freeze task to store the rails gem
locally in the project? And then for all dependent gems use "gem unpack
xxxx" in #{RAILS_ROOT}/vendor/gems to store the gem''s code locally
as
well within application? If you simply store the gems locally and rails
is frozen locally, it shouldn''t be a problem as far as I know...
caleridas wrote:> So someone requested me to deploy rails on 30+ machines, he has a
> fully developped rails app on his local machine - only trouble is: he
> installed everything using gem.
>
> Now, since I have to care for more than 70 servers and workstations
> there are a number of organizational policy rules regarding system
> administration: Nothing EVER gets installed that bypasses the package
> management system (be it rpm or deb). Needless to say this clashes
> with gem.
>
> Unfortunately installing "gemless" rails works for newly created
rails
> applications, but not for his fully developed (complains about missing
> rails gem). Now the question is: How can I help him to make his
> application runnable is this environment and avoid the same pitfall in
> the future? (and what did he do wrong to begin with?)
>
> Of course I can always tell him he has to locally compile and deploy
> all gems himself as non-root in his own directories, but he won''t
be
> happy and neither do I like this.
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
On Dec 11, 9:27 pm, Nathan Esquenazi <rails-mailing-l...@andreas- s.net> wrote:> Couldn''t you just do a rake:rails:freeze task to store the rails gem > locally in the project? And then for all dependent gems use "gem unpack > xxxx" in #{RAILS_ROOT}/vendor/gems to store the gem''s code locally as > well within application? If you simply store the gems locally and rails > is frozen locally, it shouldn''t be a problem as far as I know...well this just pushes the administrative burden off my desk, so it is fine with me :) however this still means no centralized management of >30 installations... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Have you looked at capistrano and vlad the deployer? On Dec 12, 2007 8:47 AM, caleridas <hcb-eUEd6hF3u00UwC0lI++cfQ@public.gmane.org> wrote:> > On Dec 11, 9:27 pm, Nathan Esquenazi <rails-mailing-l...@andreas- > s.net> wrote: > > Couldn''t you just do a rake:rails:freeze task to store the rails gem > > locally in the project? And then for all dependent gems use "gem unpack > > xxxx" in #{RAILS_ROOT}/vendor/gems to store the gem''s code locally as > > well within application? If you simply store the gems locally and rails > > is frozen locally, it shouldn''t be a problem as far as I know... > > well this just pushes the administrative burden off my desk, so it is > fine with me :) > however this still means no centralized management of >30 > installations... > > >-- Ryan Bigg http://www.frozenplague.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Heh. Well if you upload the code to an SVN repository and use the tips I suggested (rails freeze and gem unpacks), you can effectively create an isolated working rails application. (Obviously Ruby and MySQL would be the two pre-requisites). Using Capistrano or Vlad as the previous poster mentioned, people could simply check out copies from the SVN server (which could be updated as needed) and then pushed to the production servers using Capistrano. Seems like it would fit the bill and would have centralized management in the sense that you make a change, upload it to the repository and than it is simply a click a way for everyone else to have the updated version. caleridas wrote:> On Dec 11, 9:27 pm, Nathan Esquenazi <rails-mailing-l...@andreas- > s.net> wrote: >> Couldn''t you just do a rake:rails:freeze task to store the rails gem >> locally in the project? And then for all dependent gems use "gem unpack >> xxxx" in #{RAILS_ROOT}/vendor/gems to store the gem''s code locally as >> well within application? If you simply store the gems locally and rails >> is frozen locally, it shouldn''t be a problem as far as I know... > > well this just pushes the administrative burden off my desk, so it is > fine with me :) > however this still means no centralized management of >30 > installations...-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12 Dez., 12:37, Nathan Esquenazi <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Heh. Well if you upload the code to an SVN repository and use the tips I > suggested (railsfreeze andgemunpacks), you can effectively create an > isolated workingrailsapplication. (Obviously Ruby and MySQL would be > the two pre-requisites).sounds reasonable and we are probably going to do that for the moment... but one problem we will be hitting sooner or later with this approach: gems containing native code are linked to the specific library versions on the development machine, transferring those to other machines with different versions may or may not break, and sooner or later we will hit architecture issues (switch from 32 to 64 bit) so the question is whether this approach just creates a "better hidden" mess that still needs to be sorted out later is there a good tutorial for creating and using "private" gem repositories? or, alternatively, packaging the things up in .debs and .rpms so they can be fed through our install repositories and managed sanely> Using Capistrano or Vlad as the previous poster mentioned, people could > simply check out copies from the SVN server (which could be updated as > needed) and then pushed to the production servers using Capistrano.i will pass on this recommendation, but ulitmately i don''t know how the rails apps are going to be maintained, i just have to provide the infrastructure --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---