11
votes

Rails 3 Déploiement automatique des actifs à Amazon Cloudfront?

y a-t-il un joyau ou une méthode disponible dans des rails 3.1 qui peuvent télécharger automatiquement des actifs sur Amazon Cloud Front et les utiliser au lieu de servir les hôtes localement? Je suppose qu'il est facile de télécharger des actifs compilés manuellement, puis Changez la configuration de l'application Rails pour utiliser cet hôte d'actif, mais lors de la modification d'un actif, les téléchargements sur le front de nuage devraient être effectués manuellement à nouveau. Toute bonne voie là-bas pour cela?

ruby-on-rails amazon-cloudfront ruby-on-rails-3 ruby-on-rails-3.1

0 commentaires

4 Réponses :

8
votes

Jetez un coup d'œil à https://github.com/rumblelabs/asset_sync - Nous l'utilisons juste à S3 mais Je suppose que la partie cloudfront est assez facile une fois que les actifs sont sur S3.

On finit par être une tâche de râteau que vous allez simplement ajouter à exécuter dans votre processus de déploiement.

0 commentaires

1
votes

Une autre option serait https://github.com/moocode/asseet_id , le fichier README a un exemple pour l'utiliser avec CloudFront. Il devrait fonctionner avec des rails 3.1 mais je l'ai seulement utilisé sur 3.0.x.

SS JOHN a déclaré que toutes les solutions finiraient par être une tâche de râteau + un peu de logique pour changer le chemin d'actif dans les rails.

0 commentaires

11
votes

Si vous utilisez l'option CloudFronts "Personnaliser Origine", vous n'avez pas besoin de télécharger quoi que ce soit, Cloudfront va chercher les actifs de votre serveur en cas de besoin. Pour plus de détails sur la configuration, voir:

http://blog.ertesvag.no/post/10720082458

1 commentaires

... Et pour ceux qui utilisent des haricots élastiques, étant donné que vos actifs sont probablement précompilés par défaut, le serveur Nginx va les servir à CloudFront, il devrait y avoir très peu de conséquence à cette approche (la demande ne frappe jamais l'application Rails).

14
votes

Découvrez définitivement Asset_Sync sur github. Ou notre article de centre héroku device sur Utilisation d'un hôte d'actif CDN avec des rails 3.1 sur Heroku .

Il y a une amélioration assez importante de la performance dans l'utilisation d'une origine Asset_sync VS A CDN, permettant à votre demande de compiler paresseusement des actifs en production ou de les servir de manière précompilée directement sur vos serveurs d'applications. Cependant, je dirais ça. Je l'ai écrit.

avec Asset_Sync et S3, vous pouvez faire des actifs précompiliseurs, ce qui signifie que tous les actifs sont prêts à être servis sur l'hôte d'actif / CDN immédiatement
Vous ne pouvez nécessiter que les : Bundle dans Application.rb sur précompilisation, sauvegarde de la mémoire dans la production
Vos serveurs d'applications ne sont jamais frappés pour les demandes d'actifs. Vous pouvez dépenser un temps de calcul coûteux, vous savez. Informatique.
Les en-têtes de cache HTTP Meilleures pratiques sont tous définis par défaut
Vous pouvez activer la compression gzip automatique avec une configuration supplémentaire

1 commentaires

Savez-vous d'une raison pour laquelle les en-têtes de cache HTTP ne seraient pas définis par défaut? Doit-ils maintenant être défini manuellement dans le fichier de configuration Asset_Sync? quelque chose comme config.custom_headers = {'Cache-Control' => 'max-Âge = 315576000', 'expire' => 1.Year.from_now.httpdate} Je ne peux pas sembler avoir le mien pour bien définir ... Toute aide appréciée