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@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Search Discussions

  • Colin Law at Feb 29, 2012 at 11:07 am

    On 29 February 2012 10:42, Bert Gloan 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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Peter Vandenabeele at Feb 29, 2012 at 12:09 pm

    On Wed, Feb 29, 2012 at 12:06 PM, Colin Law wrote:
    On 29 February 2012 10:42, Bert Gloan 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@xxx.yyy.zz: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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Bert Gloan at Feb 29, 2012 at 4:33 pm
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Peter De Berdt at Feb 29, 2012 at 4:46 pm

    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Bert Gloan at Mar 1, 2012 at 10:29 am

    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 Berdt
    Yes - 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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedFeb 29, '12 at 10:42a
activeMar 1, '12 at 10:29a
posts6
users4
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2022 Grokbase