Bonjour, j'ai appris des rails depuis une demi-année et j'ai quelques applications sur Heroku. Donc, pour moi, je pensais que le déploiement d'applications sur le World Wide Web était aussi simple que Heroku Push . Cependant, je viens de recevoir mon premier stage en train de faire des rails et qu'un de mes aînés parle d'Apache et de Nginx et je ne suis pas sûr de la manière dont ils s'intégrent dans la photo, car je pensais que les applications consistaient à des rails + plate-forme d'application Cloud. Je l'ai regardé mais je ne comprends toujours pas comment et où cela affecte mon cycle de vie de l'application. Quelqu'un peut-il expliquer quoi / où / quand utiliser des serveurs Web?
3 Réponses :
Heroku est un service nuageux, ce qui signifie qu'ils s'occupent du matériel et des logiciels vous permettant de vous publier de manière transparente de votre application sans vous soucier de ce qui se passe derrière la scène. Donc, la seule chose que vous devez faire est de repousser votre code à leur git et à votre voile.
D'autre part, les rails peuvent également être déployés sur un système construit par vous complètement à partir de zéro, et vous serez responsable non seulement pour le développement de l'application, mais également pour la maintenance et le choix du serveur du matériel et / ou du logiciel. . Vous pouvez ensuite choisir entre plusieurs serveurs d'applications capables de courir des rails tels que NGIX.
espère que cela aide.
Les pages Web ont besoin d'un serveur Web pour les rendre disponibles sur Internet.
Ainsi, un site qui est tout le contenu statique (toutes les pages Tout simplement .html) a besoin d'un serveur Web et de savoir où Apace, Nginx, etc. Entrez. Ce sont des serveurs Web.
Lorsque vous utilisez des cadres tels que des rails, un composant supplémentaire est ajouté, un serveur d'applications. Cela pré-traiter les pages à l'aide du framework Rails, puis (toujours) utilise le serveur Web mentionné ci-dessus pour rendre les pages finales (qui sont bien sûr bien sûr) disponibles pour les utilisateurs finaux via leur navigateur.
PASSAGER PHUSTION est un serveur d'applications qui, avec des rails aidera à gérer et à automatiser le déploiement du code.
Vous avez donc votre application de rails et, comme vous savez que vous avez des contrôleurs et des actions et de la visualisation et de ce qui n'est pas.
Lorsqu'un utilisateur de son navigateur passe à votre application sur Heroku, ils tapent l'URL qui pointe vers les serveurs Heroku.
Les serveurs Heroku sont des serveurs Web qui écoutent vos utilisateurs qui tapent l'URL et les connectent à votre application Rails. L'application Rails fait sa chose (obtient une liste de poteaux de blog ou autre) et le serveur envoie ces informations à votre navigateur de votre utilisateur.
Vous utilisez un serveur Web tout au long de votre temps, il a été abstraité de vous et rendu super simple grâce à Heroku.
Le cycle de vie est donc un peu comme celui-ci:
Alors que vous construisez vos applications sur votre machine de développement, vous avez probablement connu la commande Webrick écoute sur le port 3000 et répond aux demandes d'utilisateurs, telles que le «Hey Donnez-moi une liste de messages» Commande.
Lorsque vous appuyez sur votre code dans la production (dans votre expérience via Une configuration de production (que vos développeurs seniors parlent) est un peu plus complexe que votre serveur Rails local sur votre machine de développement.
Dans la production, vous avez votre serveur de rails (souvent des choses comme la licorne, le passager) qui prend la place de Webrick.
Dans de nombreuses configurations de production, un autre serveur, tel que Apache ou NGinx, est également utilisé, et est le serveur que l'utilisateur se connecte à quand ils vont à votre application.
Ce serveur existe souvent comme un peu de routeur pour déterminer la manière dont différents types de demandes doivent être traités. Par exemple, les demandes de fichiers statiques (CSS, images, JavaScript, etc.) clôturées sur le serveur peuvent simplement être traitées directement par Apache ou NGinx, car il effectue un travail fantastique (et rapide) d'envoi d'actifs statiques de retour au client.
Autres demandes, telles que "Get Me une liste de tous les postes de blogs", envoyez-vous sur le serveur Rails (Licorne, passager, etc.) qui font à son tour le travail requis et envoyez la réponse à Apache / Nginx, qui le renvoie au client.
HEROKU fait tout cela pour vous dans un joli paquet facile à utiliser, mais cela ressemble à l'endroit où votre travail gère cela, plutôt que d'utiliser Heroku. Ils ont configuré leur propre tas de serveurs Web et auront leur propre moyen de faire un équivalent de espère que cela aide! Rails Server . Ceci commence un programme appelé Webrick qui est un serveur Web et écoute sur Port 3000. Vous allez à votre application via http: // localhost: 3000 . .
héroku push ) Vous envoyez votre code un fournisseur qui prend soin de l'équivalent de production de Rails Server Pour vous.
Heroku Push qui enverra le code aux serveurs et assurez-vous qu'ils sont en train de suivre répondre aux demandes des utilisateurs.
Merci. Première fois que j'ai lu sur le passager / la Licorne faisant le "côté des rails du travail du serveur" et NGinx / Apache faisant l'envoi des fichiers. Jusqu'à présent, j'ai été confus que Nginx était identique à celui du passager, etc. et pourquoi vous avez besoin de deux composants de serveur différents en production.