Currently I have been doing the usual cap deployments for a project to a test environment as my app develops. Nothing exciting, but I have now got to deploy it on a reasonable scale to a DMZ that has no access to the git repo/ or any other nice things. Anyone got ''best practice'' for this situation, I can push to the DMZ using ssh/scp etc, even rsync ... but rather than a cobbled together approach, I would prefer good practice. Thanks -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 29 February 2012 10:42, Bert Gloan <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Currently I have been doing the usual cap deployments for a project to a > test environment as my app develops. Nothing exciting, but I have now > got to deploy it on a reasonable scale to a DMZ that has no access to > the git repo/ or any other nice things. > > Anyone got ''best practice'' for this situation, I can push to the DMZ > using ssh/scp etc, even rsync ... but rather than a cobbled together > approach, I would prefer good practice.I use a script that touches the local tmp/restart.txt (which, for me anyway, causes the server to restart) then uses rsync to update the server then using ssh run the remote command to precompile the assets. For the actual file transfer rsync is amazingly fast (particularly if the server is remote) as the connection is only made once. If any gems have changed you will need to bundle install on the server also, but I do this manually if required. Also if migrations have been added then you will need to run the migrations. For the rsync I have an ignore file containing: .git .gitignore .rvmrc .bundle doc log db/schema.rb tmp/cache tmp/pids tmp/sesssions tmp/sockets tmp/markup test spec public/javascripts/all.js public/assets vendor/bundle .bundle/config I too will be interested to hear of other suggestions. Colin -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Wed, Feb 29, 2012 at 12:06 PM, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> On 29 February 2012 10:42, Bert Gloan <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: > > Currently I have been doing the usual cap deployments for a project to a > > test environment as my app develops. Nothing exciting, but I have now > > got to deploy it on a reasonable scale to a DMZ that has no access to > > the git repo/ or any other nice things. > > > > Anyone got ''best practice'' for this situation, I can push to the DMZ > > using ssh/scp etc, even rsync ... but rather than a cobbled together > > approach, I would prefer good practice. > > I use a script that touches the local tmp/restart.txt (which, for me > anyway, causes the server to restart) then uses rsync to update the > server then using ssh run the remote command to precompile the assets. > For the actual file transfer rsync is amazingly fast (particularly if > the server is remote) as the connection is only made once. > > If any gems have changed you will need to bundle install on the server > also, but I do this manually if required. Also if migrations have > been added then you will need to run the migrations. > > For the rsync I have an ignore file containing: > .git > .gitignore > .rvmrc > .bundle > doc > log > db/schema.rb > tmp/cache > tmp/pids > tmp/sesssions > tmp/sockets > tmp/markup > test > spec > public/javascripts/all.js > public/assets > vendor/bundle > .bundle/config > > I too will be interested to hear of other suggestions. >If I understand correctly, the root problem of the OP is not being able to use standard capistrano recipes since the production server (in the DMZ) cannot reach the git repo that is inside the company firewall? What I have done in such a scenario (where my production server is at a hosting company) is to use standard capistrano practice, but have a "production" branch of the git repo on the production server. So the `git checkout` on the production server is pulling from a "local" repo. The top of my deploy.rb then becomes something like: set :user, ''vandenabeele'' # username on the production server set :application, ''flamjobs'' # app name set :repository, ''vandenabeele-JY/383W3OFDKtWrImGP1oA@public.gmane.org:git/flamjobs.git'' set :branch, ''production'' For that, I has set-up a "bare" repository in the directory /home/vandenabeele/git/flamjobs.git and I push into that from my dev machine before running cap deploy (I could probably automate that too ...). HTH, Peter -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
yes - I have thought of similar things, but just to clarify: I cannot do a git pull from the DMZ inside the firewall as a deployment method, I cannot compile locally on the DMZ machine, my test target is the same OS as the test/dev envs, so compiled assets will work when transferred directly. The ''production branched'' local repo may be my best approach though ... I just think that others must have encountered this problem. Was always surprised that cap didnt have some kind of push approach. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 29 Feb 2012, at 17:33, Bert Gloan wrote:> yes - I have thought of similar things, but just to clarify: > I cannot do a git pull from the DMZ inside the firewall as a > deployment > method, I cannot compile locally on the DMZ machine, my test target is > the same OS as the test/dev envs, so compiled assets will work when > transferred directly. > > The ''production branched'' local repo may be my best approach > though ... > I just think that others must have encountered this problem. Was > always > surprised that cap didnt have some kind of push approach.It actually does or at least did: https://groups.google.com/group/capistrano/browse_thread/thread/d00a703c99353567/642026e315d64461?hl=en Best regards Peter De Berdt -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Peter De Berdt wrote in post #1049490:> It actually does or at least did: >https://groups.google.com/group/capistrano/browse_thread/thread/d00a703c99353567/642026e315d64461?hl=en> > > Best regards > > Peter De BerdtYes - thats what I was looking for. Thanks, it works as described. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.