diff options
Diffstat (limited to 'v1.3/deploying.html')
| -rw-r--r-- | v1.3/deploying.html | 212 |
1 files changed, 0 insertions, 212 deletions
diff --git a/v1.3/deploying.html b/v1.3/deploying.html deleted file mode 100644 index 1d1dccff03..0000000000 --- a/v1.3/deploying.html +++ /dev/null @@ -1,212 +0,0 @@ -<!DOCTYPE html> -<html> - <head> - <title>Bundler: The best way to manage a Ruby application's gems</title> - <meta content='text/html; charset=UTF-8' http-equiv='Content-Type'> - <meta content='276VSYOko8B8vIu1i8i5qbj7_ql5PXo0dU69XQy-SL' name='globalsign-domain-verification'> - <link href='/images/favicon.png' rel='shortcut icon' type='image/png'> - <link href="/stylesheets/application.css" media="screen" rel="stylesheet" type="text/css" /> - </head> - <body> - <div id='body'> - <div id='header'> - <a class="image" href="/"><img width="725" alt="The best way to manage your application's dependencies" src="/images/gembundler.png" /></a> - </div> - <div id='container'> - <div id='contents'> - <h2>Deploying bundled applications</h2> - <div class='contents'> - <div class='bullet'> - <div class='description'> - Before deploying an app that uses Bundler, Add your <code>Gemfile</code> - and <code>Gemfile.lock</code> to source control, but ignore the - <code>.bundle</code> folder, which is specific to each machine. - </div> - <pre class="highlight plaintext">$ echo ".bundle\n" >> .gitignore
$ git add Gemfile Gemfile.lock .gitignore
$ git commit -m "Add Bundler support"</pre> - <div class='notes'> - Once you have done that, there are two ways to deploy using Bundler: - manually or automatically. - </div> - </div> - <div class='bullet'> - <div class='description'> - <h3>Manual deployment</h3> - In your deploy script, after updating to the latest - code, install your bundle to the <code>vendor/bundle</code> - directory, ensuring all your dependencies are met. - </div> - <pre class="highlight plaintext">$ bundle install --deployment</pre> - <div class='notes'> - <p> - Start your application servers as usual, and your - application will use your bundled environment - with the exact same gems you use in development. - </p> - <p> - If you have run <code>bundle package</code>, the cached - gems will be used automatically. - </p> - <a href="/v1.3/bundle_package.html">Learn More: Packing</a> - </div> - </div> - <div class='bullet'> - <h3>Automatic deployment with Capistrano</h3> - <div class='description'> - To pull in the Bundler Cap task, just add this to your - <code>deploy.rb</code> file: - </div> - <pre class="highlight ruby"><span class="nb">require</span> <span class="s1">'bundler/capistrano'</span></pre> - <div class='notes'> - That's it! Running <code>cap deploy</code> will now automatically run - <code>bundle install</code> on the remote server with deployment-friendly - options. A list of options that can be changed is available in the help - for the cap task. To see it, run <code>cap -e bundle:install</code>. - </div> - </div> - <div class='bullet'> - <div class='description'> - <h3>Automatic deployment with Vlad</h3> - There is a default Vlad task available. To make it available, add this line - to the Vlad <code>deploy.rb</code>. - </div> - <pre class="highlight ruby"><span class="nb">require</span> <span class="s1">'bundler/vlad'</span></pre> - <div class='notes'> - Once you have done that, the <code>vlad:bundle:install</code> task will be - available for use. Make sure it is run as part of your deploy. For example: - </div> - <pre class="highlight ruby"><span class="n">task</span> <span class="s2">"vlad:deploy"</span> <span class="o">=></span> <span class="sx">%w[
 vlad:update vlad:bundle:install vlad:start_app vlad:cleanup
]</span>
</pre> - </div> - <div class='bullet'> - <div class='description'> - <h3>After deploying</h3> - Make sure to use <code>bundle exec</code> to run any executables - from gems in the bundle - </div> - <pre class="highlight plaintext">$ bundle exec rake db:setup</pre> - <div class='notes'> - Alternatively, you can use the <code>--binstubs</code> option on the - install command to generate executable binaries that can be used instead of - <code>bundle exec</code>. - </div> - <a href="./man/bundle-exec.1.html">Learn More: Executables</a> - </div> - <div class='bullet'> - <div class='description'> - <h3>Heroku</h3> - When you deploy to Heroku, Bundler will be run automatically as long as a Gemfile is present. If you check in your Gemfile.lock, Heroku will run <code>`bundle install --deployment`</code>. If you want to exclude certain groups using the <code>--without</code> option, you need to use <code>`heroku config`</code>. - </div> - <pre class="highlight plaintext">$ heroku config:add BUNDLE_WITHOUT="test development" --app app_name</pre> - <a href="http://docs.heroku.com/bundler">Heroku Bundler Documentation</a> - </div> - <h2 id='deploying-your-application'> - Deploying Your Application - </h2> - <p> - When you run <code>bundle install</code>, bundler will (by default), install your gems - to your system repository of gems. This means that they will show up in <code>gem - list</code>. Additionally, if you are developing a number of applications, you will not - need to download and install gems in common for each application. This is nice for - development, but somewhat problematic for deployment. - </p> - <p> - In a deployment scenario, the Unix user you deploy with may not have access to install - gems to a system location. Even if the user does (or you use <code>sudo</code>), the - user that boots the application may not have access to them. For instance, Passenger - runs its Ruby subprocesses with the user <code>nobody</code>, a somewhat restricted - user. The tradeoffs in a deployment environment lean more heavily in favor of isolation - (even at the cost of a somewhat slower deploy-time <code>bundle install</code> when some - third-party dependencies have changed). - </p> - <p> - As a result, bundler comes with a <code>--deployment</code> flag that encapsulates the - best practices for using bundler in a deployment environment. These practices are based - on significant feedback we have received during the development of bundler, as well as a - number of bug reports that mostly reflected a misunderstanding of how to best configure - bundler for deployment. The <code>--deployment</code> flags adds the following defaults: - </p> - <ul> - <li> - Instead of installing gems to the system location, bundler will install gems to - <code>vendor/bundle</code> inside your application. Bundler will transparently remember - this location when you invoke it inside your application (with - <code>Bundler.setup</code> and <code>Bundler.require</code>). - </li> - <li> - Bundler will not use gems already installed to your system, even if they exist. - </li> - <li> - If you have run <code>bundle pack</code>, checked in the <code>vendor/cache</code> - directory, and do not have any git gems, Bundler will not contact the internet while - installing your bundle. - </li> - <li> - Bundler will require a <code>Gemfile.lock</code> snapshot, and fail if you did not - provide one. - </li> - <li> - Bundler will not transparently update your <code>Gemfile.lock</code> if it is out of - date with your <code>Gemfile</code> - </li> - </ul> - <p> - If you use Capistrano, you should symlink <code>vendor/bundle</code> to - <code>shared/vendor_bundle</code> so that bundler will share your installed gems between - deployments (making things zippy if you didn't make any changes), but still give you the - benefits of isolation from other applications. - </p> - <p> - By defaulting the bundle directory to <code>vendor/bundle</code>, and installing your - bundle as part of your deployment process, you can be sure that the same Unix user that - checked out your application also installed the third-party code your application needs. - This means that if Passenger (or Unicorn) can see your application, it can also see its - dependencies. - </p> - <p> - The <code>--deployment</code> flag requires an up-to-date <code>Gemfile.lock</code> to - ensure that the testing you have done (in development and staging) actually reflects the - code you put into production. You can run <code>bundle check</code> before deploying - your application to make sure that your <code>Gemfile.lock</code> is up-to-date. Note - that it will always be up-to-date if you have run <code>bundle install</code>, - successfully booted your application (or run your tests) since the last time you changed - your <code>Gemfile</code>. - </p> - </div> - </div> - </div> - </div> - <div id='footer'> - <img src="/images/emocow.png" /> - <img src="/images/panda.jpg" /> - <div class='spacer'></div> - <div id='credits'> - <p> - Many thanks to Bundler's <a href="/contributors.html">contributors</a> - and <a href="/sponsors.html">sponsors</a> - </p> - </div> - <div class='spacer'></div> - <img src="/images/bundler-small.png" /> - </div> - <a href='http://github.com/bundler/bundler/' id='github'> - <img alt='Fork me on GitHub' src='http://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png'> - </a> - <div id='prod-versions'> - Docs: - <a href="/v0.9/">v0.9</a> - <a href="/v1.0/">v1.0</a> - <a href="/v1.1/">v1.1</a> - <a href="/v1.2/">v1.2</a> - <a class="current" href="/v1.3/">v1.3</a> - <a href="/v1.5/index.html">v1.5</a> - <a href="/">v1.6</a> - </div> - <script> - (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ - (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), - m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) - })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); - ga('create', 'UA-39559982-1', 'bundler.io'); - ga('send', 'pageview'); - </script> - </body> -</html> |