Port handling is confusing when web is not first in Procfile

[rbclark]

In my Procfile I had the following:

release: rake db:migrate
web: bundle exec rails s -p $PORT

I then ran

$ myapp config:get PORT
6000

I found that when my app was scaled to 1, every time I ran systemctl status myapp-web-1 I would get

* Listening on tcp://0.0.0.0:6100

I then changed my Procfile to

web: bundle exec rails s -p $PORT
release: rake db:migrate

And got

* Listening on tcp://0.0.0.0:6000

My question here is how do I go about figuring out what port my app is up and running on so I can point a reverse proxy at it? It seems like changing the order of the Procfile should not cause the port number to jump around like it does.

[crohr]

This is the expected behaviour. PORT offsets are indexed according to the position in the Procfile, incrémenter by 100 for each process. First entry gets offset 6000, second entry gets 6100, etc. If you scale a process to more than 1, then it will increment the offset, for instance if you have the web process as the second entry in your Procfile and you scale to 2, you will get 6100 for the first web instance and 6101 for the second one. It might be confusing if you change the order in your Procfile, so let me know if you think of a better solution? Or maybe we just need to explain this in the README? Cyril

…

On 24 Jul 2018, at 17:01, Robert Clark ***@***.***> wrote: In my Procfile I had the following: release: rake db:migrate web: bundle exec rails s -p $PORT I then ran $ myapp config:get PORT 6000 I found that when my app was scaled to 1, every time I ran systemctl status myapp-web-1 I would get * Listening on tcp://0.0.0.0:6100 I then changed my Procfile to web: bundle exec rails s -p $PORT release: rake db:migrate And got * Listening on tcp://0.0.0.0:6000 My question here is how do I go about figuring out what port my app is up and running on so I can point a reverse proxy at it? It seems like changing the order of the Procfile should not cause the port number to jump around like it does. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[rbclark]

The best thing I can think of is at least having an interface to find out what port a service is running on. The only reason I was able to realize what was happening was due to the fact that I checked systemctl status myservice-web-1 and saw it was coming up on not the port I expected. If I could've said myservice config to view current port bindings for specific services, I believe that would've been pretty helpful.