J’ai mis en place un environnement de production de rails avec:
* Les applications rails sous un utilisateur appelé déployer.
* L’utilisateur deploy n’est qu’un utilisateur normal n’ayant PAS d’permissions sudo.
* L’utilisateur deploy utilise son propre gestionnaire de ressources en boîte de sable (pas à l’échelle du système), de sorte que tout ce qui concerne ruby n’est accessible qu’à l’utilisateur du déploiement.
* L’utilisateur qui exécute Apache n’a pas access à l’environnement Ruby et il n’a pas besoin d’y avoir access, car Apache n’a pas besoin de Ruby.
* L’utilisateur de déploiement exécute un cluster Licorne.
Cette configuration non système à l’échelle du système fonctionne parfaitement pour moi. Les avantages que je vois sont:
* Je n’ai pas besoin d’utiliser sudo chaque fois que j’installe un bijou.
* Ruby est en boîte de sable et est uniquement disponible pour l’utilisateur du déploiement, améliorant ainsi la sécurité du système par la minimisation. Apache ne se soucie pas de Ruby, donc il n’y a pas access!
Le seul inconvénient est que nous ne pouvons pas utiliser les modules passagers-apache-module ni les passagers-nginx-modules, mais le passager autonome vient à la rescousse!
Ma question: Pourquoi tout le monde sur Internet est-il enclin à utiliser l’installation à l’échelle du système RVM? Je n’ai pas pu trouver un seul article sur l’utilisation de RVM en mode non sudo en production. Est-ce que je manque l’article le plus critique ici? Je veux savoir ce qui ne va pas avec l’installation de non-sudo en production.
Merci!
Je fais toujours une sorte d’hybride pour les déploiements:
De cette façon, vous pouvez:
Si vous installez RVM sous un utilisateur spécifique, vous ne pouvez pas utiliser ruby en dehors de cet utilisateur.
J’utilise également le rvm en tant qu’utilisateur local, mais j’ai pu intégrer le passager (version 2.x). Est-ce que cette page aide? https://rvm.beginrescueend.com/integration/passenger/
Je peux creuser dans mes fichiers de configuration (au cours du week-end) et vous aider si vous êtes bloqué. Faites le moi savoir.
réponse au commentaire
Je l’ai fait non-system-wide-install parce que:
Je n’ai pas rencontré de problème, mais j’imagine que le RVM à l’échelle du système et le RVM hors système peuvent fonctionner sans problème en production.
J’utilise Apache, pas Nginx. De plus, je n’utilise pas Unicorn. Ces deux différences pourraient vous poser un problème qui pourrait ne pas m’affecter.
N’oubliez pas que RVM ne concerne pas uniquement les rails ou certaines applications en rack qui, pour le déploiement, sont essentiellement transparentes, grâce à différents outils (serveurs Web, etc.) mais pour un environnement Ruby.
Déterminez, par exemple, un serveur threadé écrit en ruby en train de regarder le port série, qui doit fonctionner en tant que démon, si vous voulez le lancer avec un script init de init.d ou simplement de boot.local, croyez-moi avec su - rvm_user -c"whatever
et généralement impossible. Dans ces moments, vous repensez à l’installation de RVM, au moins pour l’environnement de production.