How to use on Digital Ocean

[indigotechtutorials]

Hey I need some help with the thruster gem if anyones familiar with this I was expecting it to work out of the box on a digital ocean vm I am using thrust bin/rails s but I can't view the app when I go to the servers IP address and i tried setting TLS and accessing from the domain but still nothing shows up and no logs in the rails app

[3v0k4]

Does your setup work if you do not use thruster by running bin/rails server alone?

You might want to double check the network/port configuration. Is traffic reaching Rails app/Thruster through the right port?

[indigotechtutorials]

@3v0k4 thanks for your reply
no rails s does not work for digital ocean you have to set NGINX up to process the requests to the ip addres over to the right port for my web app. I've done this before and adding server blocks but I was under the impression Thruster would take care of that for me and make everything work out of the box

[3v0k4]

It should pretty much work out of the box, you are right.

Thruster binds to HTTP_PORT (80 by default) and HTTPS_PORT (443 by default), so you shouldn't need additional setup. Could you confirm that Thruster is running and waiting for traffic?

The fact that you don't see anything at all in the logs suggests that traffic doesn't even reach Thruster. That's where I'd start from.

Does curl -v return anything meaningful to investigate further?

[airblade]

I'm not the original poster but I have what seems like the same problem.

I can run Puma without Thruster (bin/rails server) and then, once I have opened port 3000 in ufw (the firewall), see the site in a browser at http://fooapp.com:3000.

However when I try with thruster everything appears to start correctly but I can't connect with a browser to https://fooapp.com.

Start up

$ TLS_DOMAIN=fooapp.com DEBUG=1 bin/thrust bin/rails server
{"time":"2024-06-20T11:19:58.760575788Z","level":"DEBUG","msg":"No custom 502 page found","path":"./public/502.html"}
{"time":"2024-06-20T11:19:58.760762522Z","level":"DEBUG","msg":"TLS: initializing","directory":"https://acme-v02.api.letsencrypt.org/directory","using_eab":false}
{"time":"2024-06-20T11:19:58.760827571Z","level":"INFO","msg":"Server started","http":":80","https":":443","tls_domain":"fooapp.com"}
=> Booting Puma
=> Rails 7.1.3.4 application starting in production
=> Run `bin/rails server --help` for more startup options
[69660] Puma starting in cluster mode...
[69660] * Puma version: 6.4.2 (ruby 3.3.3-p89) ("The Eagle of Durango")
[69660] *  Min threads: 3
[69660] *  Max threads: 3
[69660] *  Environment: production
[69660] *   Master PID: 69660
[69660] *      Workers: 2
[69660] *     Restarts: (✔) hot (✖) phased
[69660] * Preloading application
[69660] * Listening on http://0.0.0.0:3000
[69660] Use Ctrl-C to stop
[69660] - Worker 0 (PID: 69678) booted in 0.03s, phase: 0
[69660] - Worker 1 (PID: 69681) booted in 0.02s, phase: 0

curl output

curl -v https://fooapp.com
* Host fooapp.com:443 was resolved.
* IPv6: (none)
* IPv4: 188.245.38.45
*   Trying 188.245.38.45:443...
* connect to 188.245.38.45 port 443 from 192.168.1.220 port 60119 failed: Connection refused
* Failed to connect to fooapp.com port 443 after 27 ms: Couldn't connect to server
* Closing connection
curl: (7) Failed to connect to fooapp.com port 443 after 27 ms: Couldn't connect to server

Nothing is logged by Thruster / Puma when I visit the site in a browser or via curl.

This is using Thruster 0.1.4.

[airblade]

According to lsof -i and netstat -peanut, nothing is listening to port 443 (or 80) even though Thruster says it is.

[airblade]

I was trying to think why Thruster wouldn't bind to 443 (or 80) when nothing else is, and I wondered if it had to do with needing stronger permissions to bind to a privileged port.

I tried this, which didn't work:

TLS_DOMAIN=fooapp.com DEBUG=1 sudo bin/thrust bin/rails server

And then this, which did:

sudo TLS_DOMAIN=fooapp.com DEBUG=1 bin/thrust bin/rails server

Evidently sudo discards its environment when it executes, which makes sense.

So this is solved for me.

[reesericci]

I wouldn't recommend running your web server as root for security, you might want to give CAP_NET_BIND privileges to a separate user that runs thruster to allow it to bind to 443 & keep the rest of the benefits of non-root access.

[airblade]

@reesericci Thanks. The sudo was just my trying to get Thruster to run at all from the command line. I actually do use a non-root user with CAP_NET_BIND privileges.