I solved many problems already, but struggling with this one.
Deploy environment:
ubuntu 12.10
rvm 1.18.21 (stable)
ruby 1.9.3p392
Getting this error with
cap deploy:cold
Error:
* 2013-03-23 18:01:27 executing `deploy:start'
triggering before callbacks for `deploy:start'
* 2013-03-23 18:01:27 executing `foreman:export'
* executing "cd /home/gwuix2/picurwebaruhaz/current && bundle exec foreman export bluepill /data/picurwebaruhaz/shared/config"
servers: ["198.211.117.84"]
[198.211.117.84] executing command
** [out :: 198.211.117.84] ERROR: Procfile does not exist.
** [out :: 198.211.117.84]
command finished in 1430ms
My deploy.rb:
https://gist.github.com/gwuix2/5228473
Gemfile: https://gist.github.com/gwuix2/5228488
According to Spree's docs, it looks like you need to generate a Procfile (which is used by Foreman) in your app before deploying it.
Spree guide to Application Processes
That guide shows a default Procfile's contents, which you may be able to get by with. Spree also has a deployment service which can take care of generating several things for you, including the Procfile:
Every server will get some basic configuration, such as Rails Environment environment variable, placeholder directories for your Spree application, automatically generated database.yml and Procfile files, and more.
So that may be worth looking into, because even if you are able to generate the Procfile manually, you may run into more issues from missing config files, and their deployment service may take care of all of that for you automatically.
Related
I'm trying to deploy an API-only Rails 5 application to AppEngine Flex w/ the standard Ruby runtime, and I'm getting the following error at the very end:
Updating service [default] (this may take several minutes)...failed.
ERROR: (gcloud.app.deploy) Error Response: [9]
Application startup error:
/usr/bin/env: 'ruby2.5': No such file or directory
I'm specifying ruby '2.5.1' in my Gemfile and I've added an explicit .ruby-version file to the root of my project set to 2.5.1 as well.
I have no other debugging information available to me in the logs, no other fancieness. My entrypoint command is:
bundle exec rails server Puma -p $PORT
I can provide more details if needed, not sure what else might be relevant. Any pointers? As far as I can tell, nothing on my side is asking for a version of ruby that specifically at execution time.
Thanks!
EDIT: Here's my app.yaml file
entrypoint: bundle exec rails server Puma -p $PORT
env: flex
runtime: ruby
UPDATE:
I can verify that I'm having similar problems when trying to exec rake tasks like db:migrate:
--------- EXECUTE COMMAND ----------
bundle exec rake db:migrate
/usr/bin/env: 'ruby2.5': No such file or directory
ERROR
ERROR: build step 0 "gcr.io/google-appengine/exec-wrapper:latest" failed: exit status 127
--------------------------------------------------------------------------------------------------------------------------------------------------------
OK I now see what has happened after debugging the docker image locally. Because I was on ubuntu and had used system ruby to install gems it had embedded /usr/bin/env ruby2.5 into every executable script that was bundled into my app. I deleted all gems and switched to rbenv for managing Ruby version which mitigated this odd behavior between unbuntu's ruby and my app.
Having followed the rails-cast (http://railscasts.com/episodes/271-resque?view=comments), I was able to setup my rails application similarly with worker and rake tasks.
However, as specified in the rails-cast, once I start my rails server, I have to issue the following command in a separate terminal window:
TERM_CHILD=1 QUEUES=* rake resque:work
This gets me up-and-running and I have no issues. However, instead of firing off a rake command on terminal (or writing a startup shell script), I would like to issue this terminal command (TERM_CHILD=1 QUEUES=* rake resque:work) from Rails itself when the application starts up so its available during the duration of the application's uptime on the server.
I am in the process of learning Rails framework so I would greatly appreciate if you can give me some help and let me know how/where to place any code snippet you may provide me with.
Thank you very much in advance.
Here are my environment specs:
I am using jruby (jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_72-b14 +jit [linux-amd64])
Rails version 4.1.8
I am developing on LINUX ubuntu 14.04
I will be deploying this application to Windows 2008 server on a Tomcat server as a WAR package
I am using PostgreSQL as my database.
That approach would make it difficult to turn off your resque workers. I recommend using a common gem called foreman to handle this. I'll let you look a the documentation, but your Procfile would look something like:
web: rails s -p $PORT
resque: TERM_CHILD=1 QUEUES=* rake resque:work
And you would be able to start both rails and resque by just running the foreman command in console. That will also allow you to exit out of both easily.
Updated per OP's message:
require 'resque/tasks'
ENV['TERM_CHILD'] = 1
ENV['QUEUES'] = '*'
Thread.new { Rake::Task["resque:work"] }
The Thread.new is there because it would otherwise cause the rest of the app to never load.
I am unable to run rake tasks with cron. The error it throws up is:-
/Library/Ruby/Gems/1.8/gems/bundler-1.2.0/lib/bundler/runtime.rb:199: warning: Insecure world writable dir /Library/Ruby/Gems/1.8 in PATH, mode 040777
/Library/Ruby/Gems/1.8/gems/bundler-1.2.0/lib/bundler/spec_set.rb:90:in `materialize': Could not find unf_ext-0.0.5 in any of the sources (Bundler::GemNotFound)
However, when I run the same rake task directly from the terminal, it works fine. In case of the cron job, as well as while running the rake task directly from the terminal, i cd into the (exact) same directory. Starting the rails server works as well.
What is the problem and how should I resolve this?
It could be an issue with your daemon user and your user when you're running it directly. Or it could be a problem with Ruby and/or your cron file commands.
Firstly, use this gem for making cron jobs with rake tasks:
https://github.com/javan/whenever
Then install RVM since you're using the standard ruby library provided by OSX and that can lead to some problems when you're developing various projects. This should fix the permissions error that you have displayed.
EDIT:
The issue here was that I used RVM on my local machine and rbenv on the server. This is highly not recommended, if you're managing several ruby installation (or upgrading your ruby version but do not want to change the system's) use either RVM or rbenv on all environments!
/EDIT
So I'll start with a bit history:
I'm in the process of upgrading our rails2 website to rails3. Most of the things are working properly by now, except Capistrano's deploy script.
The current setup I have is:
RVM (1.14.1) installed locally
ruby-1.9.3-p194 (set to the project's folder)
Capistrano v2.12.0 (upgraded from 2.6.0, but it doesn't work on 2.6.0 as well) installed as an RVM gem
rvm-capistrano (1.2.2), added to the Gemfile (after doing some reading online and on SO)
rbenv (with ruby 1.9.3p194 used globally) installed on the server
(by now if you see anything that doesn't make sense, please let me know)
Nothing changed in the deploy script, yet when I try to deploy to my testing server (let's call it beta) I get this error:
* executing `deploy:restart'
* executing "cd /home/foo/bar/current && rake RAILS_ENV=beta queue:restart_workers"
servers: ["208.0..."]
[208.0...] executing command
*** [err :: 208.0...] rake aborted!
*** [err :: 208.0...] no such file to load -- bundler/setup
*** [err :: 208.0...] /home/foo/bar/releases/20120630161947/Rakefile:5
*** [err :: 208.0...] (See full trace by running task with --trace)
** [out :: 208.0...] (in /home/foo/bar/releases/20120630161947)
command finished in 1183ms
failed: "sh -c 'cd /home/foo/bar/current && rake RAILS_ENV=beta queue:restart_workers'" on 208.0...
The relevant part on deploy.rb looks like this:
task :restart do
run "cd /home/foo/bar/current && rake RAILS_ENV=#{CAP_ENV} queue:restart_workers"
run "cd /home/foo/bar/current && rake RAILS_ENV=#{CAP_ENV} db:migrate"
run "touch #{deploy_to}/current/tmp/restart.txt"
end
Needless to say, rake RAILS_ENV=beta queue:restart_workers' works perfectly when run manually on the server. Also, the application gets deployed (the code was copied from git, it's just the last part of the deploy fails).
Lastly, the error didn't change since before I installed rvm-capistrano and added to the Gemfile, so I'm not even sure it's related to rvm, I'm just guessing from looking online.
Thanks
In order to work correctly, rbenv must override all the ruby and gem-related executables with the shims it provides.
Usually this is done with a startup script (this is why it works when you login to your server) but Capistrano logs in without shell and thus does not run those scripts.
You must add the following to your deploy.rb :
set :default_environment, {
'PATH' => "$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH"
}
and do not use anything rvm related on your server, rbenv and rvm really do not like each other
PS : a little more explanation on this topic : http://henriksjokvist.net/archive/2012/2/deploying-with-rbenv-and-capistrano/
In Rails 2 you're able to run
script/console --sandbox
so you can play with production data and not accidentally break anything.
I can't seem to find the equivalent command for Rails 3. Does anyone know what it is?
Easy, type in:
bundle exec rails c -s
and that is it.
$ bundle exec rails c --help
Usage: console [environment] [options]
-s, --sandbox Rollback database modifications on exit.
--debugger Enable ruby-debugging for the console.
--irb DEPRECATED: Invoke `/your/choice/of/ruby script/rails console` instead
It is simple, but, sometimes, if you are not running rails executable using bundle exec, it may, or may not, result in an error. In order to avoid this, ALWAYS use bundle exec.
To quote bundler page (if not documentation):
In some cases, running executables without bundle exec may work, if
the executable happens to be installed in your system and does not
pull in any gems that conflict with your bundle.
However, this is unreliable and is the source of considerable pain.
Even if it looks like it works, it may not work in the future or on
another machine.