When using Rails inside a Docker container
several posts, (including one on docker.com) use the following pattern:
In Dockerfile do ADD Gemfile and ADD Gemfile.lock, then RUN bundle install.
Create a new Rails app with docker-compose run web rails new.
Since we RUN bundle install to build the image, it seems appropriate to docker-compose build web after updating the Gemfile.
This works insomuch as the gemset will be updated inside the image, but:
The Gemfile.lock on the Docker host will not be updated to reflect the changes to the Gemfile. This is a problem because:
Gemfile.lock should be in your repository, and:
It should be consistent with your current Gemfile.
So:
How can one update the Gemfile.lock on the host, so it may be checked in to version control?
Executing the bundle inside run does update the Gemfile.lock on the host:
docker-compose run web bundle
However: You must still also build the image again.
Just to be clear, the commands to run are:
docker-compose run web bundle
docker-compose up --build
where web is the name of your Dockerized Rails app.
TL;DR - make the changes on the container, run bundle on the container and restart for good measure. Locally these changes will be reflected in your app and are ready to test/push out to git, and your production server will use it to rebuild.
Long; Read:
docker exec -it name_of_app_1 bash
vim Gemfile and put something like gem 'sorcery', '0.9.0' I feel this ensures you get the version you're looking for
bundle to get just this version in the current container's Gemfile and Gemfile.lock
This has been semi normal "Rails" type stuff here, just you are doing it on the container that is running. Now you don't have to worry about git and getting these changes onto. your git repo because these changes are all happening on your local copy. So like, open a terminal tab and go into your app and less Gemfile and you should see the changes.
Now you can restart your running container. Your Dockerfile will get rebuilt (in my case by docker-compose up locally, tests should pass. Browser test at will.
Commit your changes to git and use your deploy process to check it out on staging.
Notes:
Check that Dockerfile like the OP's links say. I'm assuming that you have some kind of bundle or bundle install line in your Dockerfile
Run bundle update inside the container, then rebuild.
$ docker-compose run web bundle update
$ docker-compose build
So I am trying to deploy a Rails app on my web hosting service. I have developed an app locally, but this is the first time I have tried to get it to work on another server. My service provider is Blue Host and I am on their most basic shared hosting plan. Just as a test, I created a fresh application on the server, and everything ran fine. However, whenever I add any gem to the Gemfile and run 'bundle install', I get this error:
sudo: unable to stat /etc/sudoers: No such file or directory
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
Gem::Exception: Cannot load gem at [/usr/lib64/ruby/gems/1.9.3/cache/rake-10.4.2.gem] in /home/user/application
An error occurred while installing rake (10.4.2), and Bundler cannot continue.
Make sure that `gem install rake -v '10.4.2'` succeeds before bundling.
Whenever I run gem install rake -v '10.4.2' the gem installs fine.
I get similar errors that mention 'sudo' when i try to run other commands as well.
I am not quite sure what this error means. Do I not have the required permissions on my server?
Always use a continuous deployment/integration.
Capistrano does part of the job. It is very simple, you develop you application offline, push to a remote repository, like BitBucket or Github, and then Capistrano takes care of cloning the remote repository to your server (you can also have many), restarting services etc.
If you want to go a step forward you can use continuous integration, so when you push to remote tests will automatically be performed and if they pass your application will be deployed.
This is a basic introduction on how deployment works, you can check online, there are plenty of resources about how to deploy rails.
Go with root user
su root
root$ /etc/
I have a forked Github repo which is used by my app deployed on heroku. I included it in my Gemfile like this :
gem 'service-client', :git => 'https://github.com/blabla/client-stuff'
Now I changed some parts of the forked repo, which requires no changes in my heroku app.
So how can I make my heroku app, rebundle or do the bundle install or whatever to pick up the latest changes from https://github.com/blabla/client-stuff master branch?
You should update gem localy and write changes to Gemfile.lock by bundle update service-client then commit changes and push to origin. Heroku update you gemset when look in to the changes in Gemfile.lock.
Unfortunately it does require changes in your heroku app.
It requires the newest gem version. You will have to push up to heroku again so that it can re bundle your Gemfile.
there is not way to run a bundle update on heroku itself because this could cause git fast-forward issues along with other unexpected consequences where a newer gem does not work appropriately.
Heroku is a production environment and all changes should be tested locally before deploying
See this SO Question
When deploying my Rails App to Linode via Capistrano/Unicorn, when running this command "bundle exec cap deploy:cold" it's giving the error :
The --deployment flag requires a Gemfile.lock. Please make sure you have checked your Gemfile.lock into version control before deploying.
command finished in 495ms
*** [deploy:update_code] rolling back
I've searched around and can't seem to find a solution. Any one know any solutions? How do you check your gemfile.lock into version control
https://github.com/Ruekompa/itcinema.git
After a little while of running running countless commands and attempts, I now notice there is a folder called cached-copy residing in /home/USERNAME/apps/APPNAME, and it contains my app.
UPDATE:
I have fixed everything. I simply rebuilt ubuntu server on linode and started over. This time my deployment worked. Thanks everyone
I have fixed everything. I simply rebuilt ubuntu server on linode and started over. This time my deployment worked. I changed Ubuntu 12.04 to 10.04. Perhaps it was something in my capistrano recipes, for I was piggy backing off of someone else's code that was using 10.04.
Did you add the Gemfile.lock to your repository?
you can add it by
# in your app root dir
git add Gemfile.lock
git commit -m "Added Gemfile.lock to repository"
EDIT
Did you run the following command?
bundle install --deployment
I'm pretty new to bundler and capistrano, and I'm trying to use them together. When I try to deploy, I get the message:
You are trying to install in deployment mode after changing your Gemfile. Run `bundle install' elsewhere and add the updated Gemfile.lock to version control.
I don't know how to satisfy the system that's complaining, and I don't understand why the complaint is coming up because I read in the doc:
If a Gemfile.lock does exist, and you have updated your Gemfile(5),
bundler will use the dependencies in the Gemfile.lock for all gems
that you did not update, but will re-resolve the dependencies of gems
that you did update. You can find more information about this update
process below under CONSERVATIVE UPDATING.
I interpret that to mean that the Bundler can handle the fact that my Gemfile is not whatever it expected. Any help?
Specs: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, deploying to a Posix machine.
Edit: My Gemfile includes logic blocks like the following:
unless RbConfig::CONFIG['host_os'] === 'mingw32'
# gem 'a' ...
end
The error message you're getting regarding Gemfile.lock may be because your Gemfile and Gemfile.lock don't agree with each other. It sounds like you've changed something in your Gemfile since you last ran bundle install (or update). When you bundle install, it updates your Gemfile.lock with any changes you've made to Gemfile.
Make sure you run bundle install locally, and check-in to source control your newly updated Gemfile.lock after that. Then try deploying.
Edit: As recognised in the comments, a conditional in the Gemfile resulted in a valid Gemfile.lock on one platform, invalid on another. Providing a :platform flag for these platform-dependent gems in the Gemfile should solve the asymmetry.
vi .bundle/config
change the BUNDLE_FROZEN option from '1' to '0'
do "bundle install"
OR
run "bundle config"
see if the "frozen" value is true set it to false
bundle config frozen false
Watch out for global Bundler config.
I had a global config on my dev environment in ~/.bundle/config that I did not have in my CI / Production environment that caused the Gemfile.lock that was generated in my dev environment to be different than the one in my CI / Production environment.
In my case I was setting github.https to true in my dev environment but had no such config in my CI / Production environment. This caused the two Gemfile.lock files to be different.
When you see the following...
$ bundle install
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
If this is a development machine, remove the Gemfile freeze
by running `bundle install --no-deployment`.
You have added to the Gemfile:
* source: rubygems repository https://rubygems.org/
* rails (~> 3.2)
. . .
... Then, the problem is most likely that you have outdated .gem files in your vendor/cache directory.
Perhaps, you previously ran $bundle install --deployment which put some "outdated" .gem files in the cache?
In any case, you can get past this error by running: bundle install --no-deployment
That's one of the many great things about Rails... the error messages often tell you exactly what to do to fix the problem.
My specific problem was related to what reported by #JoshPinter, i.e. dev-vs-deploy host discrepancies in the protocol used by bundler to retrieve gems from github.
To make a long story short, all I had to was modify the following Gemfile entry...
gem 'activeadmin', github: 'activeadmin'
...to this secure syntax (see reference):
gem 'activeadmin', git: 'https://github.com/activeadmin/activeadmin.git'
And my deployments are back to normal.
I don't care. This is what I did. It fixed it.
rm -rf .bundle
rm -rf Gemfile.lock
bundle install
The solution for me was slightly different than the others listed here. I was trying to upgrade from sidekiq to sidekiq-pro (which requires bundler 1.7.12+), but I kept getting the "You are trying to install in deployment mode after changing your Gemfile" message from travis-ci
Inspecting the console output of travis-ci revealed that an older version of bundler was being used.
In my case, I had to edit the travis.yml file to add:
before_install:
- gem update bundler
This forced travis-ci to use the latest version of bundler, and made the error message go away.
rm -fr .bundle
Fixed the problem for me.
Another cause of the error:
This is a bit foolish, but i'm sure someone else will make the same mistake.
For Rails 4 Heroku added the gem rails_12factor. If you were using it before they added it, then you'll have these two gems:
gem 'rails_log_stdout', github: 'heroku/rails_log_stdout'
gem 'rails3_serve_static_assets', github: 'heroku/rails3_serve_static_assets'
You have to remove them when you add the new one. (they're included). I think you can get away with it until you touch them lines in your gem file, then Heroku notices the duplication and cries out with the above error.
good luck with Rails 4.
After this command, you can do your normal bundle install again:
bundle install --no-deployment
I ran into something similar before. One way to fix it, I think, but may take more space on your server than you want, is to run
bundle install --deployment
and then try to deploy. This does something like install all of your gems into the vendor folder, which I believe is generally good to avoid... but will still probably work. My app used to behave like this, my solution was removing exact versions to download from in my Gemfile, and then rebundling and deploying.
gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git', :branch => 'master'
to
gem 'rails_admin'
Or you can do what it suggests, and Git your project off the production server onto a local machine, bundle it, and then repush onto your server. This solution might not be 100% correct but some of it worked for me... just thought I'd share. Goodluck
In our case we were using a feature that wasn't available in an old version of bundler which ran on our production machine. Therefore it was enough to upgrade bundler, i.e. do a gem update bundler.
This might be a dangerous idea, but if absolutely must test something in a production deploy environment, you can edit the .bundle/config file
# This value is normally '1'
# Set it to '0'
BUNDLE_FROZEN: '0'
Now invoke bundle, in my case I needed to update a specific gem, so this my command
RAILS_ENV=production bundle update <whatever gem>
You should probably change it back after the update, so things work like you expect, afterwards. Again, this is probably unsupported, and YMMV
This issue can be related to submodules pointing to old versions of code. For me, I resolved this issue by updating my submodules
If you have submodules, try running:
git submodule update --init
bundle install
The error message for the command bundle install in windows 10 (rails v-7) was like
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
If this is a development machine, remove the C:/Users/friends/Gemfile freeze
by running `bundle config unset deployment`.
The dependencies in your gemfile changed
You have added to the Gemfile:
* pg
You have deleted from the Gemfile:
* sqlite3 (~> 1.4)
So I did exactly the error message asked me to do. Ran the following command
bundle config unset deployment
And then I again ran `bundle install and then it worked
I ran into this deploying a Nesta app after some gem updates. What worked for me was to delete the Gemfile.lock, run bundle install to re-generate it, and deploy again.
I ran into a similar issue however I did both bundle install and bundle update and Heroku still rejected my push.
I fixed the issue by just deleting Gemfile.lock and then running bundle install again. I then added, committed, and pushed that to my git repo. After that I had no problem pushing to Heroku.
for heroku, you don't have to change the syntax in the Gemfile. you can just add BUNDLE_GITHUB__HTTPS (note the double underscore) as an environment variable and set it to true (in your heroku app's dashboard under the Settings tab in the Config Vars section). this will switch the protocol from git:// to https:// for all such requests.
I had the error message when attempting push to Heroku. I found the following solution fixed.
Git pull origin master
Git status
Git commit
Git push origin master
Git push heroku master
I read a dozen solutions on different resources but didn't find exactly what could help me in this situation
So I did find a solution. Exactly saying i read the error message attentively and there was a sollution: Run bundle install elsewhere. "Elsewhere" was my Cloud9 where i developed my app. So my steps
copy Gemfile and Gemfile.lock from server to local machine with rsync command
insert these two files into my RoR project (i used Cloud9)
open Gemfile and make changes that i want. In my case i added gem 'thin'
in terminal cd to my app on Cloud9 and run bundle install. in this case you will have a changed version of Gemfile.lock
copy new Gemfile and Gemfile.lock on server using rsync
cd to my app folder and again run bundle install --deployment --without development test
DONE! Wish GOOD luck for all!
As of the time of this writing Bundler support for capistrano defaults to "deployment: true", per
https://github.com/capistrano/bundler
So as opposed to trying to modify the bundle by hand after bundler [via capistrano] has laid it down, you may be able to solve the problem permanently by adding this to your deploy.rb or other Capistrano config file [you can do it just for one stage file as well if necessary]:
set :bundle_config, { deployment: false }
and then deploying again.
You will then notice in the "cap" output the following line [note I am using rvm here but you may not be]
.../rvm ruby-2.7.6#... do bundle config --local deployment false
Why did this stop working all of a sudden?
This is the $1M question, I never had to mess with this, but once I got to an Ubuntu 20.04.05 machine, suddenly, yes. Same cap files, same ruby version, same rails version, same OS version except the minor number.
Did it work?
Did this work for you? Leave me a comment and let me know.