Using a vanilla rails install using git (in fact following the heroku guide here https://devcenter.heroku.com/articles/rails3)
However it mentions the creation of a Procfile
web: bundle exec rails server thin -p $PORT -e $RACK_ENV
Yet if you run this is needs using foreman start, you receive an error because you haven't defined the RACK_ENV
20:45:26 web.1 | started with pid 26364 20:45:27 web.1 |
/SomeLocalPath/.rvm/gems/ruby-1.9.2-p318/gems/railties-3.2.2/lib/rails/commands/server.rb:33:in
`parse!': missing argument: -e (OptionParser::MissingArgument)
Where should this -e argument be stored for this all to work?
I guess you mean that you are getting this error on your local development machine.
You can set the RACK_ENV when starting foreman like this, for example:
RACK_ENV=development foreman start
Or you could use a different procfile for development (e.g. "Procfile-dev") which has the value for the option -e inline, like this:
web: bundle exec rails server thin -p 3000 -e development
and call it with:
foreman start -f Procfile-dev
(On Heroku, it should just work, because when you run "heroku config -s" while you are in your app-folder, you should see "RACK_ENV=production", so the needed environment variable is set correctly here).
Related
I'm new to Heroku and despite all the documentation, I'm a little unsure what the profile is for. I can set a port and the environment as follows, but Heroku always starts in production mode (which makes sense) and not with the specified port.
I suppose that the port cannot be set because it is determined by Heroku?
Is the Procfile only for the command "heroku local" to test?
Because when I run "heroku ps" I get info about the procfile, but the API runs without the procfile port in production mode.
Thank you for any explanation!
Procfile:
web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}
Output of heroku ps after deploying:
=== web (Hobby): bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development} (1)
web.1: up 2020/07/27 13:50:23 +0200 (~ 1m ago)
Output of heroku logs at the same time:
Version 3.12.6 (ruby 2.5.8-p224), codename: Llamas in Pajamas
2020-07-27T11:49:32.219309+00:00 app[web.1]: * Min threads: 5, max threads: 5
2020-07-27T11:49:32.219309+00:00 app[web.1]: * Environment: production
2020-07-27T11:49:33.740321+00:00 app[web.1]: * Listening on tcp://0.0.0.0:10269
Heroku will set both $PORT and $RACK_ENV for Rails apps when they're deployed. You can confirm this by running heroku config --app <yourapp>. The construct ${PORT:-3000} means "use the PORT variable if it's present, otherwise use the value 3000.
In any case, you can't run a Heroku app on a port other than the one defined in $PORT, which is randomized for each dyno. Whatever that's set to will be forwarded to from ports 80 and 443 for HTTP/S.
If you want to override the RACK_ENV, you can run heroku config:set RACK_ENV=development.
When I run rails s -e production -p 9292 (normal case), I get:
=> Booting Puma
=> Rails 5.1.1 application starting in production on http://0.0.0.0:9292
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.8.2 (ruby 2.3.0-p0), codename: Sassy Salamander
* Min threads: 5, max threads: 5
* Environment: production
* Listening on tcp://0.0.0.0:9292
Use Ctrl-C to stop
When I run rails s -d -e production -p 9292 (as daemon), I get:
=> Booting Puma
=> Rails 5.1.1 application starting in production on http://0.0.0.0:9292
=> Run `rails server -h` for more startup options
That's it. I would need to run bundle exec puma -e production -p 9292 --pidfile tmp/pids/puma.pid -d to get the 2nd part:
Puma starting in single mode...
...
Also where are my Puma logs? I see a blank production.log in my log folder and no other log files.
Background context: When I run curl 0.0.0.0:9292 after running both rails and puma as daemons, I get the error An unhandled lowlevel error occurred. The application logs may have details.
rails s -e production -p 9292 -d
Ah, seems Puma only cares about RAILS_ENV when used with capistrano. Can you use RACK_ENV or use -e instead? That should work:
RACK_ENV=production bundle exec puma -p 3000
or
bundle exec puma -p 3000 -e production
See here
Hope to help
to kill the server
kill cat tmp/pids/server.pid
rails s -e production -p 9292 -d
For Puma Versions Below 5, we can use -d option to start in background.
puma -e production -p 4132 -C config/puma.rb -d
But Puma gem does n't support -d option in versions above 5.
In version 5.0 the authors of the popular Ruby web server Puma chose
to remove the daemonization support from Puma, because the code wasn't
wall maintained, and because other and perhaps better options exist
(such as systemd, etc), not to mention many people have switched to
Kubernetes and Docker, where you want to start all servers on the
foreground
You can use this gem for starting in background.
https://github.com/kigster/puma-daemon
https://rubygems.org/gems/puma-daemon/versions/0.1.2
Heroku suggests this Procfile command to start Puma on Rails 5 setup:
web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}
At first I thought 3000 was a default value, but in fact foreman uses port 5000 if PORT is missing in development.
Question: What does the notation ${VARIABLE:-3000} mean?
--
Update: It seems like puma is the culprit: Foreman/Puma isn't using the specified port in dev env
That is the default value of the VARIABLE.
Use Default Values. If parameter is unset or null, the expansion of
word is substituted. Otherwise, the value of parameter is
substituted.
From: https://www.gnu.org/software/bash/manual/bash.html#Shell-Parameter-Expansion
In this case if the PORT variable is not set then its value will be 3000 and similarly if RACK_ENV is not set then it will be development.
I'm using rails 4.0.0 and ruby 2.0.0
When I start the server with foreman some of the environment variables fail to load. It really bugs me that some of the variables are loaded.
foreman start -e development.env
Procfile
web: bundle exec passenger start -p $PORT -e $RAILS_ENV
worker: bundle exec rake jobs:work RAILS_ENV=$RAILS_ENV
development.env file
S3_BUCKET=bucketname
AWS_ACCESS_KEY_ID=accesskey
AWS_SECRET_ACCESS_KEY=secretaccesskey
RAILS_ENV=development
PORT=3000
In my application.rb file i've added some logging to help debug this problem
puts "PORT is #{ENV["PORT"].inspect}"
puts "RAILS_ENV is #{ENV["RAILS_ENV"].inspect}"
puts "S3_BUCKET is #{ENV["S3_BUCKET"].inspect}"
puts "AWS_ACCESS_KEY_ID is #{ENV["AWS_ACCESS_KEY_ID"].inspect}"
puts "AWS_SECRET_ACCESS_KEY is #{ENV["AWS_SECRET_ACCESS_KEY"].inspect}"
Once I start the server this is the output for the logging code
23:34:52 worker.1 | PORT is nil
23:34:52 worker.1 | RAILS_ENV is "development"
23:34:52 worker.1 | S3_BUCKET is nil
23:34:52 worker.1 | AWS_ACCESS_KEY_ID is nil
23:34:52 worker.1 | AWS_SECRET_ACCESS_KEY is nil
Why oh Why ? :-(
When I load the rails console with foreman it successfully loads the variables
foreman run -e development.env rails c
Try modify your development.env like
export S3_BUCKET=bucketname
export AWS_ACCESS_KEY_ID=accesskey
export AWS_SECRET_ACCESS_KEY=secretaccesskey
export RAILS_ENV=development
export PORT=3000
Then in the terminal
$ source /path/to/development.env
$ foreman start
Advanced
You can use dotenv to manage some of your environment variables without polluting your system environment. Though it can't manage those environment variables required for server booting like PORT.
I have a .foreman file with the following line:
port: 3000
Then in my Procfile.dev I have the following:
web: bundle exec rails server -p $PORT
However, when running the server by doing:
foreman -f Procfile.dev, Ig get the following:
Rails 4.0.0 application starting in development on http://0.0.0.0:3100
Why is that happening? Why is not starting at 3000, but at the 3100?
After digging a little bit further, I realized that in my Procfile, I have the first line as:
redis: redis-server
When moving that to the second line, and placing the:
web: bundle exec rails server -p $PORT
As my first line, it works fine. Why would that order matter at all?