I am literally following the Setup and Deploy tutorials line for line. I have my local dummy rails app up and running and I am trying to run my first deploy to DigitalOcean. Here is the error I am seeing:
DEBUG[700595ea] Could not locate Gemfile cap aborted! SSHKit::Runner::ExecuteError: Exception while executing on host 18.104.22.168: bundle exit status: 10 bundle stdout: Nothing written bundle stderr: Nothing written
There is way more dumped out here but this is the line that triggers it. I already stumbled on the requirement to manually upload your database.yaml file so is this the case again here?
Ok - I think I sort of sorted this out. I had not committed / pushed my site to git.
I did that and now I am having endless issues just trying to get the empty default rails app to deploy.
I can't seem to get the deploy to work at all. Here is where I am stuck:
INFO[9a80e4f2] Running ~/.rbenv/bin/rbenv exec bundle exec rake assets:precompile on 22.214.171.124 DEBUG[9a80e4f2] Command: cd /home/deploy/oilfieldlocator/releases/20141210083340 && ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.1.3 RAILS_ENV=production ~/.rbenv/bin/rbenv exec bundle exec rake assets:precompile ) DEBUG[9a80e4f2] rake aborted! DEBUG[9a80e4f2] ActiveRecord::AdapterNotSpecified: '126.96.36.199' database is not configured. Available: ["default", "development", "test", "production"]
I am getting ready to give up on this. That IP is the one for my VPS but I changed that to localhost in my database.yml file. Why do I still see it on the deploy errors??
Yeah I was going to say, it seems like your
Gemfile is missing from the git repo.
Sounds like you're just about finished with it! That last error sounds like your database.yml file might be misconfigured. It looks like you've got the IP address on the line where the adapter should be. Can you paste your database.yml file so I can take a look?
default: &default adapter: postgresql encoding: unicode # For details on connection pooling, see rails configuration guide # http://guides.rubyonrails.org/configuring.html#database-pooling pool: 5 development: <<: *default database: locator_development test: <<: *default database: locator_test production: <<: *default url: 188.8.131.52 database: locator_production username: oilfieldlocator #password: <%= ENV['LOCATOR_DATABASE_PASSWORD'] %> password: *************
I have been too lazy to get around to setting the ENV variables
That's totally fine about environment variables. Been there too. ;)
I think you may want to try
host instead of
url. I've never used the url option before so that could be related. If the db is on the same server, you should use
127.0.0.1 instead of the public IP so that it doesn't have to connect to the outside world and it can run quickly internal to your server.
Changed that to host: 127.0.0.1, ran:
git add. git commit -m "update" git push cap production deploy
I don't think capistrano is getting the most recent git repository because I still get the same errors with the external IP reference:
INFO[b739d356] Running ~/.rbenv/bin/rbenv exec bundle exec rake assets:precompile on 184.108.40.206 DEBUG[b739d356] Command: cd /home/deploy/oilfieldlocator/releases/20141210201232 && ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.1.3 RAILS_ENV=production ~/.rbenv/bin/rbenv exec bundle exec rake assets:precompile ) DEBUG[b739d356] rake aborted! DEBUG[b739d356] ActiveRecord::AdapterNotSpecified: '220.127.116.11' database is not configured. Available: ["default", "development", "test", "production"]
database.yml created manually on the server or is it in your git repository?
Ok - some headway. I forgot to update the database.yml file on the server and I had some username / password issues. Now I seem to have a chicken and the egg issue. I get the process on the tutorial where after your first deploy you run rake to initialize the database on the server but my deploy seems to be trying to connect before the repository is even uploaded:
INFO[a0fcf2e4] Running ~/.rbenv/bin/rbenv exec bundle exec rake db:migrate on 18.104.22.168 DEBUG[a0fcf2e4] Command: cd /home/deploy/oilfieldlocator/releases/20141210203639 && ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.1.3 RAILS_ENV=production ~/.rbenv/bin/rbenv exec bundle exec rake db:migrate ) DEBUG[a0fcf2e4] rake aborted! DEBUG[a0fcf2e4] ActiveRecord::NoDatabaseError: FATAL: database "locator_production" does not exist DEBUG[a0fcf2e4] Run `$ bin/rake db:create db:migrate` to create your database
I would run rake but nothing has been uploaded to the 'current' directory to run it from.
That command they suggest there is incorrect if the database doesn't exist. You can ssh into your server and run the following command to create your db, then your deploy should be able to run the migrations.
RAILS_ENV=production bundle exec rake db:create
Ah yeah, you need to run that in one of the releases directories (as long as your Rails code is in there). If there aren't any, you can create the database manually with the postgres command prompt.
[email protected]:~/oilfieldlocator/releases/20141210203639$ RAILS_ENV=production bundle exec rake db:create PG::InsufficientPrivilege: ERROR: permission denied to create database : CREATE DATABASE "locator_production" ENCODING = 'unicode'
Now I know enough to add create privileges to my user but going forward what would be the 'least privileges' that this user should have from a security standpoint?
You may actually need to do this from the
postgres user because it may be the only one that has admin permissions to do that. They set up their security permissions by default pretty well.
Check out this document https://help.ubuntu.com/community/PostgreSQL#Create_database
sudo -u postgres createdb mydb
I can't remember what I used to create my pg database last time, but that looks about right.
Thanks Chris - that did the trick. Now I have an entire new issue that is beyond this thread. Passenger won't start:
cannot load such file -- bundler/setup (LoadError) /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require' /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require' /usr/lib/ruby/vendor_ruby/phusion_passenger/loader_shared_helpers.rb:263:in `block in run_load_path_setup_code' /usr/lib/ruby/vendor_ruby/phusion_passenger/loader_shared_helpers.rb:366:in `running_bundler' /usr/lib/ruby/vendor_ruby/phusion_passenger/loader_shared_helpers.rb:261:in `run_load_path_setup_code' /usr/share/passenger/helper-scripts/rack-preloader.rbin `preload_app' /usr/share/passenger/helper-scripts/rack-preloader.rb:158:in `<module:App>' /usr/share/passenger/helper-scripts/rack-preloader.rb:29:in `<module:PhusionPassenger>' /usr/share/passenger/helper-scripts/rack-preloader.rb:28:in `<main>'
I turned on the user friendly errors. I will do some Googling but have a suspicion that my ruby versions are different. I have 2.1.3 on my server but the error page shows 1.9.3.
Awesome, making progress! :)
I think you might want to check your
passenger_ruby line in
nginx.conf to make sure it points to the right version.
Yup - way ahead of you. It was:
# passenger_ruby /home/deploy/.rbenv/shims/ruby; # If you use rbenv
that I forgot to change. Now that I fixed that I am hitting:
Missing `secret_key_base` for 'production' environment, set this value in `config/secrets.yml`
This looks like a Rails 4.1 feature that I had not seen before. I copied and pasted the test key for now and created a dummy index.html file in the public folder and I am up and running finally! Next is to figure out how to set the determine and set key base (and others such as passwords etc.) env variable on the remote server. Thanks for your help.
Glad you got it working! The
config/secrets.yml works very similarly to your
config/database.yml and it's the file that you can store environment variables in with Rails 4.1+. You can create it on the server manually and have Capistrano symlink it just like database.yml or you can store a copy in your git repo which might be easier.
I forgot we had this thread going? I was using EV's on my server but after the last reboot they got wiped? How do I keep these persistent or do the symlink like you mention above?
I'd suggest doing the symlink and using those. Environment variables are harder to configure and
secrets.yml was designed specifically to help solve that problem.
Join 27,623+ developers who get early access to new screencasts, articles, guides, updates, and more.