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.
Related
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 would like to run one and the same project twice on the same server. So I defined two environments alpha and beta for this purpose.
alpha should run on port 3000
beta should run on port 4000
Then I try to start the server twice:
$ ruby bin/rails server -b 0.0.0.0 -p 3000 -e alpha --pid tmp/pids/server-alpha.pid
$ ruby bin/rails server -b 0.0.0.0 -p 4000 -e beta --pid tmp/pids/server-beta.pid
Unfortunately one of those servers (the second to start) stops when it recognizes, that there is another instance.
Environment alpha starts:
=> Booting Puma
=> Rails 5.0.0.1 application starting in alpha on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.6.0 (ruby 2.3.1-p112), codename: Sleepy Sunday Serenity
* Min threads: 5, max threads: 5
* Environment: alpha
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
Environment beta starts:
=> Booting Puma
=> Rails 5.0.0.1 application starting in beta on http://0.0.0.0:4000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.6.0 (ruby 2.3.1-p112), codename: Sleepy Sunday Serenity
* Min threads: 5, max threads: 5
* Environment: beta
* Listening on tcp://0.0.0.0:4000
Use Ctrl-C to stop
Environment alpha restarts (don't know why!):
* Restarting...
=> Booting Puma
=> Rails 5.0.0.1 application starting in alpha on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
A server is already running. Check tmp/pids/server-alpha.pid.
Exiting
Obviously the pid file still exists. But how can I avoid a restart of the server when I start another one? How can I tell rails to delete the pidfile on restart? Or how else could I handle this problem?
You probable have plugin :tmp_restart in your config/puma.rb. Everytime tmp/restart.txt is touched (which is everytime a server starts), the other server restarts.
Just comment the line and it works (you won't be able to restart your rails server by touching tmp/restart.txt anymore).
I'm not sure this will work but try using = after --pid like this
$ ruby bin/rails server -b 0.0.0.0 -p 3000 -e alpha --pid=tmp/pids/server-alpha.pid
$ ruby bin/rails server -b 0.0.0.0 -p 4000 -e beta --pid=tmp/pids/server-beta.pid
My Heroku app is not starting any workers. I scale the worker first:
heroku ps:scale resque=1 -a test-eagle
Scaling dynos... done, now running resque at 1:Free
Then when I check the workers, I see:
heroku ps:workers -a test-eagle
<app> is running 0 workers
What could be worng here? This is how my Procfile looks:
web: bundle exec puma -C config/puma.rb
resque: env TERM_CHILD=1 bundle exec rake resque:work QUEUE=* COUNT=1
Or is it because it is a free app which can only handle 1 web worker and no other dynos?
Edit:
When I check with heroku ps -a <appname> I see that just after starting the worker is crashed: worker.1: crashed. This is without doing anything in the application itself.
UPDATE: Well, I have a "free" app running that happens to run Puma, too. So, I updated Procfile as follows:
web: bundle exec puma -C config/puma.rb
resque: env TERM_CHILD=1 bundle exec rake resque:work QUEUE=* COUNT=1
After that, I pushed the app to Heroku and ran heroku ps:scale, as you specified. It worked as follows:
D:\Bitnami\rubystack-2.2.5-3\projects\kctapp>heroku ps -a kctapp
=== web (Free): bundle exec puma -C config/puma.rb (1)
web.1: up 2016/06/06 19:38:24 -0400 (~ 1s ago)
D:\Bitnami\rubystack-2.2.5-3\projects\kctapp>heroku ps:scale resque=1 -a kctapp
Scaling dynos... done, now running resque at 1:Free
D:\Bitnami\rubystack-2.2.5-3\projects\kctapp>heroku ps -a kctapp
=== web (Free): bundle exec puma -C config/puma.rb (1)
web.1: up 2016/06/06 19:38:24 -0400 (~ 51s ago)
=== resque (Free): env TERM_CHILD=1 bundle exec rake resque:work QUEUE=* COUNT=1 (1)
resque.1: crashed 2016/06/06 19:39:18 -0400 (~ -3s ago)
Note that it did crash. But, I don't have any code running there, so that could be why? Also, note that I use the "heroku ps" command as "heroku ps:workers" for me throws an error saying it is deprecated.
This is my config/puma.rb, if that helps:
workers Integer(ENV['WEB_CONCURRENCY'] || 4)
threads_count = Integer(ENV['MAX_THREADS'] || 8)
threads threads_count, threads_count
preload_app!
rackup DefaultRackup
port ENV['PORT'] || 5000
environment ENV['RACK_ENV'] || 'development'
With edit: I missed the scale command...
See scaling in Heroku here. The options that I see are web, worker, rake or console, not resque. I tried your command and it didn't recognize "that formation". I'm curious about it.
Checking a free app, it does not give you the option to add a worker dyno. Checking a hobby app, you can add workers to it. With professional apps, you can mix and match the dyno type between web and worker using 1X, 2X, and Performance dynos.
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).