Utilisation du serveur Web Thruster pour les applications Ruby

Récemment, j'ai mis en place des scripts de déploiement pour une application Ruby où je voulais que le serveur gère la terminaison SSL.

Auparavant, je configurais Caddy avec un proxy inverse pour l'application avec quelque chose comme ceci :

# Caddyfile
yourdomain.com {
    reverse_proxy localhost:3000
    tls
}

En plus de cela, j'exécuterais généralement Caddy comme l'une des dépendances dans un fichier docker-compose.yml pour faciliter l'installation et la réinstallation de tout.

Récemment, Basecamp a publié un simple serveur proxy inverse qui gère tout ce dont j'aurais besoin pour servir des applications Ruby dans une gemme appelée Thruster.

Selon le dépôt GitHub, voici ce que ce serveur apporte :

• Prise en charge HTTP/2
• Gestion automatique des certificats TLS avec Let's Encrypt
• Mise en cache HTTP de base des actifs publics
• Prise en charge et compression de X-Sendfile, pour servir efficacement les fichiers statiques

Pour 99 % des cas d'utilisation, cela répond parfaitement aux exigences. Et le meilleur de tout, je pourrais l'exécuter dans le même conteneur que mon application Ruby. Cela signifie que je n'ai pas besoin d'un conteneur séparé pour exécuter Caddy.

Configuration

Le joyau est déclaré comme un logiciel "sans configuration", et c'est presque vrai.

En réalité, vous devez quand même (au minimum) préciser à Thruster pour quels domaines vous souhaitez qu'il demande des certificats SSL.

Cela se fait via la variable d'environnement TLS_DOMAIN.

La bonne chose à ce sujet est qu'il est possible de spécifier plusieurs domaines, afin que Thruster puisse demander automatiquement les certificats Let's Encrypt corrects pour chacun d'eux.

Par exemple, si mon application est diffusée à partir de domain1.com et domain2.com, je pourrais simplement la spécifier comme TLD_DOMAIN=domain1.com,domain2.com et Thruster le comprendrait très bien.

Propulseur en marche

Pour exécuter Thruster, tout ce que vous avez à faire est de le préfixer avec la commande que vous utilisez habituellement pour exécuter votre application Ruby.

Par exemple, si vous êtes sur Rails, vous tapez normalement bin/rails server.

La modification pour le propulseur serait un serveur de poussée/rails.

Je pense que c'est pourquoi j'aime tellement Thruster. Avec Caddy, j'avais besoin de configurer un proxy inverse (souvent avec des essais et des erreurs avec ce foutu Caddyfile). Grâce à Thruster, j'ai pu configurer les choses en moins de 3 à 5 minutes.

Cas d'utilisation

Il existe de nos jours de nombreuses options pour répondre aux requêtes Web des applications Ruby (et Rails) dans un environnement de production.

1. Vous pouvez faire un proxy inverse, comme avec nginx ou Caddy.
2. Vous pouvez utiliser Kamal (qui, en v2, utilise Thruster).
3. Ou vous pouvez simplement utiliser Thruster et demander à Docker de surveiller le service lui-même.

Je pense que dans la plupart des cas, les options (1) et (2) ont le plus de sens si c'est sur des serveurs que vous contrôlez.

Pour (3), il existe un cas d'utilisation particulier : les applications auto-hébergées. En d'autres termes, les applications Ruby que vos clients exécutent sur leur propre infrastructure et où ce sont eux qui installent l'application.

La différence entre les trois options décrites est que dans les cas (1) et (2), il est facile pour le développeur d'entrer et de reconfigurer les choses facilement.

Lorsque vous fournissez une image Docker (probablement le scénario le plus courant) à un client pour qu'il s'auto-héberge, de nombreuses choses peuvent mal se passer.

Le client n'est peut-être pas familier avec la gestion de son propre serveur, par exemple. Ou peut-être que le client ne veut pas jouer avec les proxys inverses pour que les choses fonctionnent.

Dans ces cas-là, il est plus facile de simplement remettre un conteneur Docker où les choses « fonctionnent ».

J'ai rencontré ce problème lors du développement de mon logiciel de marketing par e-mail auto-hébergé, et heureusement, Thruster était disponible.

Comme j'ai quand même tout emballé dans des conteneurs et fourni un fichier docker-compose.yml, cela a également fait passer mes dépendances de conteneurs de 4 à 3, éliminant ainsi le besoin d'exécuter nginx ou Caddy.

Conclusion

Thruster est une très bonne alternative pour gérer les proxys inverses vers votre application Ruby.

Sa simple option « sans configuration » le fait fonctionner très bien dans de nombreux scénarios.

Pour moi, lors du packaging d'applications Ruby qui doivent être exécutées dans des environnements que je ne contrôle pas (c'est-à-dire des applications auto-hébergées sur les machines des clients), c'est la voie à suivre.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!