I’m having similar issues and may have a work around but am unsure if it effectively does nothing. Let me explain:
I am running a Rails app which runs the Puma app server on port 3000. I imagine my application’s exposed port was either 8000 as that’s what I got in the error or 3000. My health check is configured for TCP on the same port. Everything was working fine.
Then I wanted to add the Thruster proxy. This requires a few small changes but the material one was changing EXPOSE 3000 to EXPOSE 80 in my Dockerfile.
My understanding of Thruster is that it listens on 80 and forwards application requests to 3000 (i.e. not files or public asset requests). This change caused my health checks to start failing.
I tried setting the port to 80 and the health check to HTTP on /up (provided by Rails) but this also failed. Changing the port to 3000 and using either HTTP or TCP solves the problem and my app runs again.
However, it is unclear if requests are going directly to 3000 and not going through Thruster at all. I’m also unsure how it can communicate on 3000 if EXPOSE 80 is in the Dockerfile.
Is there a way to confirm these assumptions or diagnose further?
I created a new topic as this is not only related to health-checks but also to port + Dockerfile setup.
Can you share your Dockerfile if there is nothing sensitive? I don’t think we use the EXPOSE instruction of the Dockerfile, we expose ports that you setup in the configuration of your service.
Right now, according to your screenshot, traffic is going to the process listening on the port 3000 of your container.
You should be able to use the Instance shell Access and simply use netstat to see which unix process is listening on a port (assuming it’s installed on your image).
Thanks @yann for the new topic. I’ve continued exploring and have Thruster working!
tl;dr on standard Rails set HTTP_PORT to { PORT } in your app’s environment variables. This runs Thruster on the exposed port and Thruster will handle running Puma on another port. This is 3000 by default and can be set through TARGET_PORT (see config).
I can also confirm I had port 8000 exposed previously. Everything was working as Puma sets its port via port ENV.fetch("PORT", 3000) and was running my Rails server on 8000. You don’t even need to change Puma settings as Thruster overrides PORT with TARGET_PORT for the process it runs! This also explains why the health check suddenly failed. Puma had been listening on 8000 and now it was on 3000.
As far as I can tell it does not matter what port is EXPOSEd in the Dockerfile as this is overwritten at runtime. netstat and the linked article were useful to confirm this information for myself as well. I did need to install net-tools in my image to use it.
