Search code examples
bundlercloud-foundryruby-on-rails-6

I can't deploy a working rails 6 app on cloud foundry due to bundle version

I am experiencing this issue even having a higher version of bundler in my gemfile. What could be the issue causing this?

APP/PROC/WEB    0   from /home/vcap/app/bin/bundle:3:in `<main>'    
Feb 18, 2021, 08:40:32 PM
APP/PROC/WEB    0   from /usr/lib/ruby/2.5.0/rubygems.rb:263:in `bin_path'  
Feb 18, 2021, 08:40:32 PM
APP/PROC/WEB    0   To install the missing version, run `gem install bundler:2.1.4` 
Feb 18, 2021, 08:40:32 PM
APP/PROC/WEB    0   To update to the lastest version installed on your system, run `bundle update --bundler`.   
Feb 18, 2021, 08:40:32 PM
APP/PROC/WEB    0   /usr/lib/ruby/2.5.0/rubygems.rb:289:in `find_spec_for_exe': Could not find 'bundler' (2.1.4) required by your /home/vcap/app/Gemfile.lock. (Gem::GemNotFoundException)  
Feb 18, 2021, 08:40:32 PM
APP/PROC/WEB    0   /usr/lib/ruby/2.5.0/rubygems.rb:289:in `find_spec_for_exe': Could not find 'bundler' (2.1.4) required by your /home/vcap/app/Gemfile.lock. (Gem::GemNotFoundException)  
Feb 18, 2021, 08:57:02 PM
APP/PROC/WEB    0   To update to the lastest version installed on your system, run `bundle update --bundler`.
Solution

  • The Ruby buildpack cannot carry every single version of Ruby & bundler, it would make for an extremely large buildpack. Due to this, all buildpacks will only retain a select set of versions of the software they include in each version of the buildpack. Buildpacks are meant to encourage you to keep up with the latest versions of your software, so buildpacks will drop older versions of software as the buildpacks are updated & new releases are cut.

    This means you have three choices:

    1. You can look at the release notes for your buildpack or the build pack dependency viewer to see buildpack versions contain the specific versions of software you require.

      For example, if you must have bundler 2.1.4, then you'd need to look and find the latest buildpack version which contains it. Hint, it's v1.8.27. You can confirm the same info using the buildpack release notes also.

      Once you find the specific buildpack version, then you need to tell Cloud Foundry that you want that version of the buildpack, which contains the version of the software you require. For example: cf push -b https://github.com/cloudfoundry/ruby-buildpack#v1.8.27.

      This has some drawbacks though, a.) Cloud Foundry must be able to talk to the Internet and download that buildpack and b.) you're stuck with the versions of software in that buildpack, so your app may be vulnerable to security issues that have already been resolved in newer versions of software installed by the buildpack.

    2. Most of the time you don't care about the exact specific version of Ruby, Bundler, or other libraries, and what you want is to declare a more flexible version in your project, like "I want Bundler 2". At which point, you'll just get the latest Bundler 2.x.y version supported, so long as the buildpack you're using still includes some version of Bundler 2 (even major versions will roll-off over time).

    3. If you feel like you do need to continue specifying an exact version of Bundler (or other software), you will need to periodically update your application and the versions of software it uses to work with the more recent versions installed by the buildpack.

      For example, the latest Ruby buildpack as I write this, 1.8.32, includes Bundler 2.2.11. That would mean you'd need to update your app to expect and work with this version.

    In general, the most friction-free & safe option is #2. You'll continue to get updates to your software and it should continue to deploy without issue. The downside is that you may over time get an update that's incompatible with your app. You'd then have to fix that before you can continue deploying your app.

    Option #3 is also OK, but it requires a lot of micromanagement. If you don't really need that level of control, I would suggest going with option #2. You'll get similar results and it'll be less effort.

    Option #1 should be a last resort and only used if your app absolutely has no other option, or perhaps you need to buy some time as you upgrade the app to be compatible with newer versions. This version, over time, will leave your app susceptible to security vulnerabilities.

    You might be thinking that this all sounds like a tremendous pain, but it's not. It's the buildpack forcing you to think about your software dependencies and forcing good upgrade hygiene. That is a very good thing, as it will keep your software up-to-date and keep your application protected from vulnerabilities in the software it consumes.