Recently, I set up some deployment scripts for a Ruby app where I wanted the server to handle SSL termination.
In the "old" days, I would set up Caddy with reverse proxy the app with something like this:
# Caddyfile yourdomain.com { reverse_proxy localhost:3000 tls }
On top of this, I would usually run Caddy as one of the dependencies in a docker-compose.yml file to make it easier to install and reinstall everything.
Recently, Basecamp released a simple reverse proxy server that handles everything I would need for serving Ruby apps in a gem called Thruster.
As per the GitHub repo, here is what this server brings:
For 99% of the use cases out there, this fits the requirements perfectly. And best of all, I could run this in the same container as my Ruby app. This means I don't need a separate container to run Caddy.
The gem is stated as a "no configuration" software, and this is almost true.
In reality, you still need to (at the very least) specify to Thruster which domains you want it to request SSL certificates for.
This is done via the environment variable TLS_DOMAIN.
The good thing about this is that it is possible to specify multiple domains, so Thruster can automatically request the correct Let's Encrypt certs for each of them.
For instance, if my app is serving from domain1.com and domain2.com, I could just specify it as TLD_DOMAIN=domain1.com,domain2.com and Thruster would pick this up just fine.
To run Thruster, all you need to do is prefix it with the command you usually use to run your Ruby app.
For example, if you're on Rails, you'd normally type bin/rails server.
The modification for thruster would be thrust bin/rails server.
I feel this is why I like Thruster so much. With Caddy, I needed to set up a reverse proxy (oftentimes with trial and error with that darn Caddyfile). Using Thruster, I was able to get things set up in less than 3-5 minutes.
There are many options for serving web requests from Ruby (and Rails) apps these days in production environment.
I think in most cases, options (1) and (2) makes the most sense if it's on servers you control.
For (3), there is a special use case: self hosted applications. In other words, Ruby apps that your customers run on their own infrastructure and where they're the ones installing the app.
The difference between the three described options is that in cases (1) and (2), it is easy for the devops person to go in and reconfigure things easily.
When providing a Docker image (likely the most often scenario) to a customer to self-host, there are a lot of things that can go wrong.
The customer may not be familiar with managing their own server, for example. Or perhaps the customer does not want to fiddle around with reverse proxies to make things work.
In these cases, it's easier to just hand over a Docker container where things "just work".
I ran into this problem while developing my self-hosted email marketing software, and luckily Thruster was available.
As I packaged everything into containers anyway and provide a docker-compose.yml file, this also dropped my container dependencies from 4 to 3, eliminating the need to run nginx or Caddy.
Thruster is a pretty good alternative for handling reverse proxies to your Ruby app.
Its simple "no-configuration" option makes it work very well in many scenarios.
For myself, when packaging Ruby apps that need to be run in environments I don't control (ie. self hosted apps on customers' machines), this is the way to go.
The above is the detailed content of Using Thruster web server for Ruby apps. For more information, please follow other related articles on the PHP Chinese website!