번들러를 사용하는 애플리케이션 배포
Gemfile과
Gemfile.lock을 버전 관리하세요. 하지만 .bundle은
각 기기에 따라 지정되므로 제외하셔야 합니다.
$ echo ".bundle" >> .gitignore $ git add Gemfile Gemfile.lock .gitignore $ git commit -m "Add Bundler support"
수동 배포
최신 코드로 갱신한 후 배포 스크립트에서 번들을vendor/bundle 디렉터리에 설치하고
모든 의존성을 만족하는지 확인합니다.
$ bundle install --deployment
평상시처럼 애플리케이션 서버를 기동하면 개발 환경과 완전히 동일한 번들러 환경을 사용합니다.
bundle package를 실행했다면 자동으로
캐시된 gem이 사용됩니다.
카피스트라노로 하는 자동 배포
deploy.rb에 추가하시기만 하면 됩니다.
require 'bundler/capistrano'
cap deploy를 실행하시면 자동으로 원격 서버에서
배포용 옵션과 함께 bundle install을 실행하게 됩니다.
카피스트라노 작업에서 변경할 수 있는 옵션의 목록은 cap -e bundle:install로
보실 수 있습니다.
Vlad로 하는 자동 배포
기본 Vlad 작업으로 할 수 있습니다. 이 기능을 활성화하려면 Vlad의deploy.rb에
다음 줄을 추가하세요.
require 'bundler/vlad'
vlad:bundle:install 작업이 사용가능하게 됩니다.
배포의 일부분으로 동작하는지 확인하세요. 예를 들면 이런 식입니다.
task "vlad:deploy" => %w[ vlad:update vlad:bundle:install vlad:start_app vlad:cleanup ]
배포 이후
번들 안의 gem의 실행 파일을 실행할 때bundle exec을
사용하는지 확인하세요.
$ bundle exec rake db:setup
--binstubs 옵션을 사용해 설치 명령이 bundle exec
대신 사용 가능한 실행 파일 바이너리를 생성하도록 하세요.
Heroku
Heroku에 배포할 때 Gemfile만 있다면 번들러는 자동으로 실행됩니다. Gemfile.lock 파일을 체크인했다면 Heroku는`bundle install --deployment`를 실행 합니다.
--without 옵션을 사용해 특정 그룹을 제외하고 싶다면 `heroku config`을
사용하셔야 합니다.
$ heroku config:add BUNDLE_WITHOUT="test development" --app app_nameHeroku Bundler Documentation
애플리케이션 배포하기
bundle install을 실행할 때 번들러는 (기본 값으로) gem을 시스템 gem 저장소에
설치합니다. 이 말은 gem list에서 볼 수 있다는 의미입니다. 추가적으로
여러 애플리케이션을 개발 중이라면 각각의 애플리케이션에서 다운로드해 설치할 필요가
없습니다. 이렇게 하면 개발할 때는 편하지만 배포할 때는 다소 문제가 될 수 있습니다.
배포 시나리오에서 유닉스 사용자는 시스템 영역에 gem을 설치할 권한이 없을 것입니다.
배포하는 사용자에게 권한이 있(거나 sudo를 사용한)다 하더라도 애플리케이션을
실행하는 사용자에게는 권한이 없을 수도 있습니다. 예를 들어 패신저는 루비 서브 프로세스를
제한된 사용자인 nobody로 실행합니다.
배포 환경에서는 환경을 격리하는 데 보다 힘을 씁니다.(어떤 서드파티 의존성이 바뀌었을 때
배포 중에 bundle install이 느려진다고 해도 말이죠.)
결과적으로 번들러를 --deployment 플래그와 함께 사용하면 배포환경에서 번들러를
사용하는 최선의 사례을 캡슐화합니다. 이 사례들은 번들러의 개발 기간 동안 받은 중요한
피드백뿐만 아니라, 버그 리포트를 기반으로 합니다. 버그 리포트의 대부분은 가장 적합한
배포를 위한 번들러를 구성하는 방법에 대한 오해를 반영하고 있습니다.
--deployment 플래그는 기본적으로 다음을 추가합니다.
-
시스템에 gem을 설치하는 대신 번들러는 애플리케이션 안의
vendor/bundle에 설치할 것입니다. 애플리케이션 안에서 (Bundler.setup과Bundler.require를 사용해) 번들러를 실행하면 번들러는 이 위치를 투명하게 기억할 것입니다. - 번들러는 시스템에 설치된 gem이 이미 있다고 해도 사용하지 않을 것입니다.
-
bundle pack을 실행한 적이 있고vendor/cache디렉터리가 체크인 되어있고 git gem을 가지고 있지 않다면, 번들러는 번들을 설치할 때 인터넷에 접속하지 않을 것입니다. -
번들러는
Gemfile.lock스냅숏을 요청하고 없다면 실패합니다. -
번들러는
Gemfile이 오래된 버전이라 하더라도Gemfile.lock을 갱신하지 않습니다.
카피스트라노를 사용하시고 계신다면 vendor/bundle을
shared/vendor_bundle의 심볼릭 링크로 만드실 수 있습니다. 이렇게 하면 번들러는
배포판 사이에 설치된 gem을 공유해 (변경되지 않았다면 배포 과정을 단축하면서) 다른
애플리케이션과 격리되는 장점은 유지 할 수 있습니다.
기본적으로 번들 디렉터리는 vendor/bundle입니다. 그리고 배포 프로세스의 일부로
번들을 설치하면 애플리케이션을 체크아웃한 같은 유닉스 사용자들도 애플리케이션에서 필요한
서드파티 코드들이 설치되어 있는 것을 확인 할 수 있습니다. 이 말은 페신저(또는 유니콘)가
애플리케이션을 볼 수 있다면, 의존성도 볼 수 있다는 이야기입니다.
--deployment 플래그는 실제로 프로덕션에 코드를 반영하기 전에 (개발과 스테이징
환경에서) 테스트가 끝난 최신의 Gemfile.lock을 필요로 합니다. 배포하기 전에
bundle check를 실행해 Gemfile.lock이 최신 상태인지 확인할 수
있습니다. 마지막으로 Gemfile을 변경한 이후 bundle install을 실행하고
성공적으로 애플리케이션을 부트(하거나, 테스트를 실행)했다면 항상 최신 상태임을 주의하세요.
