Failed binding port to Ruby application on Heroku - ruby-on-rails

I want to host a Ruby on Rails app as a Docker container on Heroku. But it seems to have an issue with port binding when deployed.
I successfully hosted a simple Ruby app via Docker locally and on Heroku then I moved to the actual app. The app works fine on localhost but it gets the port binding issue:
Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2019-05-06T18:23:13.608790+00:00 app[web.1]: Digest::Digest is deprecated; use Digest
2019-05-06T18:23:15.826137+00:00 app[web.1]: Puma 2.7.1 starting...
2019-05-06T18:23:15.826185+00:00 app[web.1]: * Min threads: 0, max threads: 16
2019-05-06T18:23:15.826188+00:00 app[web.1]: * Environment: production
2019-05-06T18:23:15.826189+00:00 app[web.1]: * Listening on tcp://0.0.0.0:3000
2019-05-06T18:24:03.338792+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2019-05-06T18:24:03.338920+00:00 heroku[web.1]: Stopping process with SIGKILL
2019-05-06T18:24:03.468261+00:00 heroku[web.1]: State changed from starting to crashed
2019-05-06T18:24:03.451392+00:00 heroku[web.1]: Process exited with status 137
2019-05-06T18:24:05.407120+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=floating-spire-20546.herokuapp.com request_id=9362ea3c-bcb6-476a-a5d4-76c82cd443a3 fwd="5.151.93.202" dyno= connect= service= status=503 bytes= protocol=https
I tried configuring $PORT variable on Heroku to 3000. I also tried running the app with rails server -b 0.0.0.0. I tried without any port too.
I am thinking it may be due to the size of the app and multiple gems to be loaded which may exceed 60 seconds.
I expect the app to bind to the port to be accessed. However, it crashed.

I tried configuring $PORT variable on Heroku to 3000
That's not how the PORT environment variable works. You don't get to set it to the value you want to use; Heroku sets it and you must bind to the port it gives you.
For example, if you're using Puma you might include the -p option in your Procfile:
web: bundle exec puma -p ${PORT:-3000}
Here we use the value given by $PORT, falling back to 3000 in case it isn't set (e.g. on your development machine).

In my case, I had to use a different startup script.
I used CMD ["bundle", "exec", "puma" ,"-C" ,"config/puma.rb"]
instead of rails server -b 0.0.0.0

Related

Heroku with existing couchdb docker image won't work

I got the couchdb image from docker (https://hub.docker.com/_/couchdb) and then i run the follow commands:
docker run -p 5984:5984 -d --name my-couchdb2 couchdb:latest
docker commit 1d329ef7c516 registry.heroku.com/coucherte/web
docker tag my-couchdb2 registry.heroku.com/coucherte/web
docker push registry.heroku.com/coucherte/web
heroku container:release web --app coucherte
After this the dyno crashes, with "heroku logs --app coucherte" i get this log:
2019-02-28T17:55:15.064991+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=coucherte.herokuapp.com request_id=b875a9ce-6b45-4e37-b0fa-9a0ff243b5de fwd="177.251.168.219" dyno= connect= service= status=503 bytes= protocol=http
2019-02-28T17:55:15.542527+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/favicon.ico" host=coucherte.herokuapp.com request_id=291c7afd-0e7d-41f2-846e-6555dbdb4621 fwd="177.251.168.219" dyno= connect= service= status=503 bytes= protocol=http
2019-02-28T18:00:23.647796+00:00 heroku[web.1]: State changed from crashed to starting
2019-02-28T18:00:27.580280+00:00 heroku[web.1]: Starting process with command `/opt/couchdb/bin/couchdb`
2019-02-28T18:00:28.727119+00:00 heroku[web.1]: State changed from starting to crashed
2019-02-28T18:00:28.670713+00:00 app[web.1]: [WARN tini (4)] Tini is not running as PID 1 and isn't registered as a child subreaper.
2019-02-28T18:00:28.670738+00:00 app[web.1]: Zombie processes will not be re-parented to Tini, so zombie reaping won't work.
2019-02-28T18:00:28.670753+00:00 app[web.1]: To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.
2019-02-28T18:00:28.674975+00:00 app[web.1]: find: 'couchdb' is not the name of a known user
2019-02-28T18:00:28.727539+00:00 heroku[web.1]: Process exited with status 1
2019-02-28T18:02:42.410954+00:00 heroku[web.1]: State changed from crashed to starting
2019-02-28T18:02:51.032603+00:00 heroku[web.1]: Starting process with command `/opt/couchdb/bin/couchdb`
2019-02-28T18:02:53.540759+00:00 heroku[web.1]: State changed from starting to crashed
2019-02-28T18:02:53.517057+00:00 heroku[web.1]: Process exited with status 1
2019-02-28T18:02:53.453924+00:00 app[web.1]: [WARN tini (4)] Tini is not running as PID 1 and isn't registered as a child subreaper.
2019-02-28T18:02:53.453944+00:00 app[web.1]: Zombie processes will not be re-parented to Tini, so zombie reaping won't work.
2019-02-28T18:02:53.453960+00:00 app[web.1]: To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.
2019-02-28T18:02:53.454218+00:00 app[web.1]: find: 'couchdb' is not the name of a known user
What i am doing wrong? How i have to change the PORT for Heroku? Do i have to change couchdb settings to work with HTTPS when working with Heroku?
UPDATE
I now figured out that inside the image in the root directory there is a file called docker-entrypoint.sh. In this file there is this line:
find /opt/couchdb \! \( -user couchdb -group couchdb \) -exec chown -f couchdb:couchdb '{}' +
So on this line i think it crashes in heroku. So there is a problem with the user couchdb. Localy it works and i can find the user with:
cut -d: -f1 /etc/passwd
but on heroku the user does not exist or cannot be found. Why?
UPDATE 2
The answer is here: https://github.com/apache/couchdb-docker/issues/136

Deployment of Go App + Vue.js on Heroku using docker image

I am trying to deploy an app https://github.com/valasek/timesheet on Heroku using a docker image.
App has a go backend (negroni/gorilla) and Vue.js/Vuetify.js on the frontend and is using PostgreSQL persistence.
I am stuck on deployment. I do not know how to debug, how to show the command line output, what is failing ... and any help highly appreciated.
Relevant Dockerfile - https://github.com/valasek/timesheet/blob/master/Dockerfile
Here are the steps I am doing:
> docker build --rm -f "Dockerfile" -t timesheet:latest .
Successfully tagged timesheet:latest
...
> heroku container:push timesheet:latest --app timesheet-cloud
...
The push refers to repository [registry.heroku.com/timesheet-cloud/timesheet]
...
Your image has been successfully pushed. You can now release it with the 'container:release' command.
> heroku container:release timesheet --app timesheet-cloud
Releasing images timesheet to timesheet-cloud... done
> heroku ps -a timesheet-cloud
Free dyno hours quota remaining this month: 971h 8m (97%)
Free dyno usage for this app: 0h 0m (0%)
For more information on dyno sleeping and how to upgrade, see:
https://devcenter.heroku.com/articles/dyno-sleeping
No dynos on ⬢ timesheet-cloud
> heroku logs --app timesheet-cloud
2019-02-15T08:33:49.373221+00:00 app[api]: Deployed timesheet (709022e100f9) by user <email-reducted>#gmail.com
2019-02-15T08:33:49.373221+00:00 app[api]: Release v20 created by user <email-reducted>#gmail.com
2019-02-15T08:34:43.901070+00:00 heroku[router]: at=error code=H14 desc="No web processes running" method=GET path="/" host=timesheet-cloud.herokuapp.com request_id=4c21eb79-5344-4d40-b341-8977128c873f fwd="195.250.152.42" dyno= connect= service= status=503 bytes= protocol=https
2019-02-15T08:34:44.842322+00:00 heroku[router]: at=error code=H14 desc="No web processes running" method=GET path="/favicon.ico" host=timesheet-cloud.herokuapp.com request_id=b66caaee-880a-46a0-918b-e778a49334f4 fwd="195.250.152.42" dyno= connect= service= status=503 bytes= protocol=https
2019-02-15T08:34:54.865321+00:00 heroku[router]: at=error code=H14 desc="No web processes running" method=GET path="/" host=timesheet-cloud.herokuapp.com request_id=d5af6aa7-0279-4f0e-a4cc-0f9e8682ec2f fwd="195.250.152.42" dyno= connect= service= status=503 bytes= protocol=https
2019-02-15T08:34:55.158317+00:00 heroku[router]: at=error code=H14 desc="No web processes running" method=GET path="/favicon.ico" host=timesheet-cloud.herokuapp.com request_id=2d69f4b5-9015-48de-9314-c493703818d1 fwd="195.250.152.42" dyno= connect= service= status=503 bytes= protocol=https
This is likely to happen because Heroku does not detect any endpoint for your application (binded on port 3000 by default).
Heroku attributes your app a dynamic port, and put the port value on the env variable named $PORT.
Your app have to use the value specified by Heroku in this variable and listen for incoming connections on it, because that is where Heroku will forward connections.
The variable has to be read when the app starts:
https://help.heroku.com/PPBPA231/how-do-i-use-the-port-environment-variable-in-container-based-apps
You can check current env variables on your app using heroku run printenv
(I see you are using Viper, that should handle env variables. However they say in their documentation that when from env, it is case sensitive, maybe that could explain why it does not work for you: https://github.com/spf13/viper#working-with-environment-variables)
Thank you #Jonathan Muller. Solved!
GUI is running on https://timesheet-cloud.herokuapp.com.
On Heroku DB connection and PORT string should be read from the environment variables
DATABASE_URL
PORT
Updated was file timesheet.yaml.
BaseUrl in Axios is set to '' so Axios is using relative API URLs, which works. Fixed in file axiosSettings.js.
Before the command heroku run printenv returned:
panic: dial tcp 127.0.0.1:5432: connect: connection refused
Now I am getting:
Running printenv on ⬢ timesheet-cloud... up, run.1962 (Free)
Feb 15 16:22:34.186 [INFO] config file /timesheet.yaml
Feb 15 16:22:34.197 [INFO] connecting to DB postgres://user:hash#ec2-54-235-68-3.compute-1.amazonaws.com:5432/dbname
Feb 15 16:22:34.246 [INFO] connected to DB postgres://user:hash#ec2-54-235-68-3.compute-1.amazonaws.com:5432/dbname

Heroku Docker - Tomcat 7 is not serving the requests

Below is the Docker file:
FROM tomcat:7.0.90-jre7-alpine
ENV spring.profiles.active=dev
ENV CATALINA_OPTS=" -Dlogback.ContextSelector=JNDI"
#ADD builds/lib/ILCH-*.war $CATALINA_HOME/webapps/ilch.war
ADD heroku/catalina.sh /usr/local/tomcat/bin
RUN `chmod 777 /usr/local/tomcat/bin/catalina.sh`
Tomcat Server is started successfully per the below logs after container released:
heroku container:release web --app runningticker
The port assignment is good as I updated the server.xml inside the Catalina.sh before starting the server. (Last but one line in the docker file)
The requests to this application are not serving and I always see the logs code=H80 desc="Maintenance mode"
2018-09-22T19:38:08.446927+00:00 app[web.1]: INFO: Server startup in 5965 ms
2018-09-22T19:39:05.242821+00:00 heroku[router]: at=info code=H80 desc="Maintenance mode" method=GET path="/"
host=runningticker.herokuapp.com
request_id=e1cb4819-6bd9-4b04-8fc5-09c1bb2d7ad1 fwd="72.48.50.103"
dyno= connect= service= status=503 bytes= protocol=https
Expected to run the ROOT application of tomcat home page, but not.
What am I missing? Port binding while docker run? If so, how can I do this on Heroku?
If you wonder what's there in Catalina.sh this is the first line I added.
sed -i -e "s/8080/$PORT/" /usr/local/tomcat/conf/server.xml

Heroku: deploying minio server with Dockerfile CMD failure

I am trying to deploy my minio server to heroku. This is my Dockerfile:
FROM minio/minio
ENV MINIO_ACCESS_KEY="xxxxxx"
ENV MINIO_SECRET_KEY="xxxxxxxx"
CMD ["server", "/data"]
EXPOSE 9000
This works locally when I build and run it through docker (using these commands:)
docker build . -t testheroku
sudo docker run -p 8080:8080 testheroku
The Dockerfile is the only file in the directory.
Then, I try to push it to heroku. I followed the commands on the heroku docker instruction page to install the heroku container plugin, login, etc. Then, I pushed my app with: heroku container:push web --app APP_NAME
When I visit the app, I get an application error in browser. This is what the heroku logs display:
2017-09-21T02:24:47.589576+00:00 app[api]: Deployed web (26b84915ed48) by user []
2017-09-21T02:24:47.589576+00:00 app[api]: Release v28 created by user []
2017-09-21T02:24:48.241050+00:00 heroku[web.1]: State changed from crashed to starting
2017-09-21T02:24:49.480733+00:00 heroku[web.1]: Starting process with command `server /data`
2017-09-21T02:24:51.961825+00:00 app[web.1]: ‘server /data’ is not a minio sub-command. See ‘minio --help’.
2017-09-21T02:24:52.056706+00:00 heroku[web.1]: Process exited with status 1
2017-09-21T02:24:52.064400+00:00 heroku[web.1]: State changed from starting to crashed
2017-09-21T02:24:52.938136+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=APP_NAME.herokuapp.com request_id=80ddd6f8-c053-4ff6-b4c9-fdb0ce8a48a5 fwd="67.245.14.153" dyno= connect= service= status=503 bytes= protocol=https
2017-09-21T02:24:54.319660+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/favicon.ico" host=APP_NAME.herokuapp.com request_id=9988b6af-8a91-4e77-9bd4-c79c9e2ec24c fwd="67.245.14.153" dyno= connect= service= status=503 bytes= protocol=https
For those unfamiliar with minio, some explanation of ‘server /data’ is not a minio sub-command. See ‘minio --help’.: this shows when you run the minio command with an argument that isn't a minio command. For example,
./minio sadf
‘sadf’ is not a minio sub-command. See ‘minio --help’.
So what heroku is telling me is that it's interpreting the CMD line from my Dockerfile, not as it should (which is with server as the minio subcommand and /data as its argument) but instead, if you notice the quotation marks, heroku is smashing the two pieces together and attempting to use the whole string as a minio subcommand - hence the error message. It's trying to run the command minio 'server /data' instead of minio server /data
Has anyone seen this kind of behavior from heroku before with a Dockerfile? How can I make sure that the CMD line gets interpreted correctly, and not as one full string? I assume this is a heroku issue because it runs fine locally. Any advice would be welcome.
I had a similar issue that seemed to be caused by having other ENTRYPOINTS in the parent layers. To solve this, I added ENTRYPOINT [] above my CMD and everything worked fine.
Actually, I had the same issue.
This Dockerfile works fine.
FROM minio/minio:RELEASE.2022-01-08T03-11-54Z.fips
ENV MINIO_ROOT_USER=XXXXXX
ENV MINIO_ROOT_PASSWORD=XXXXXX
EXPOSE 9000
EXPOSE 9001
ENTRYPOINT ["minio"]
CMD ["server","/data","--console-address",":9001"]

web.1: crashed ERROR when scaling dyno on heroku

I just deployed my app on heroku. Then I ran:
heroku ps:scale web=1
Which ran ok, but when I wanted to check the dyno working with heroku ps I got the following:
=== web (1X): `bin/rails server -p $PORT -e $RAILS_ENV`
web.1: crashed 2015/01/19 11:18:38 (~ 3m ago)
heroku logs:
2015-01-19T15:14:06.131511+00:00 heroku[router]: at=error code=H10
desc="App crashed" method=GET path="/favicon.ico"
host=rock-paper-scissors-test.herokuapp.com
request_id=27ca44cb-ca4e-473e-9789-0245d393bd56
fwd="190.15.209.212" dyno= connect= service= status=503 bytes=
Any ideas?
UPDATE:
get the following line before exiting on heroku logs:
2015-01-19T15:28:57.189329+00:00 app[web.1]: => Notice: server is listening on all interfaces (0.0.0.0). Consider using 127.0.0.1 (--binding option)
2015-01-19T15:28:57.922629+00:00 heroku[web.1]: Process exited with status 1
Try the suggestion you're receiving in the logs:
Consider using 127.0.0.1 (--binding option)
Change your Procfile to:
bin/rails server -p $PORT -e $RAILS_ENV --binding 127.0.0.1
There was an error that wasn't being addressed in the logs. I had to run:
heroku run console
to get the details. Just like they advice here.

Resources