2016-04-20 9 views
0

Nach dieser tutorial, ich versucht wurde, eine Rails-Anwendung auf einem ec2 unbuntu Instanz, läuft nginx Webserver und Puma App-Server, entfaltet mit capistrano 3. Allerdings werden keine meiner Assets angezeigt, und ich bekomme Routing-Fehler für grundlegende Funktionen des Devise-Edelsteins, wie zum Beispiel Abmelden. Die Chrome-Dev-Tool-Konsole zeigt 404 Fehler für die kompilierten application.css- und application.js-Dateien an.Schienen 4.2 Capistrano 3 Unbuntu Nginx Puma, Geting Routing-Fehler/keine Assets angezeigt

Ich denke, die Assets sind da, wenn ich ssh in die Instanz und gehe zu dem Ordner, wo meine App ist, kann ich eine Reihe von Dateien unter öffentlichen/Assets. Wenn ich die Capistrano-Protokolle überprüfe, kann ich auch die Zeile bundle exec rake assets:precompile finden, und der Status dafür ist erfolgreich. Ich probierte Dinge wie in die production.rb-Datei gehen und c onfig.serve_static_files = ENV['RAILS_SERVE_STATIC_FILES'].present? zu config.serve_static_files = true

ändern, aber immer noch keine Vermögenswerte. Ich denke, der größte Verdächtige ist, dass es einen Routing-Fehler gibt, weil ich nicht wirklich verstehe, wie Webserver, App-Server und aws-Instanzen miteinander interagieren. Könnte mir jemand bei der Fehlersuche in die richtige Richtung weisen? Wenn Sie eine bestimmte Konfigurationsdatei sehen möchten, kommentieren Sie bitte unten.

+0

Haben Sie einen besonderen Bedarf für die Bereitstellung verwenden Capistrano haben? Für Rails Apps bei der AWS-Bereitstellung mit ElasticBeanstalk vereinfachen sich die Dinge dramatisch. – hephalump

+0

Ich mag den Workflow von Capistrano und mag auch die Tatsache, dass es relativ unkompliziert ist, Ihre Bereitstellungsaufgaben mit Capistrano anzupassen. Auch würde ich gerne verstehen, wie man einen Server im Allgemeinen eher als auf einer Plattform – ChaiTea

+0

immer gerecht zu konfigurieren. Mit ElasticBeanstalk können Sie auch Ihre Bereitstellungsaufgaben anpassen und den Container beliebig konfigurieren. – hephalump

Antwort

0

Ok es stellt sich heraus, dass ich nur die secrets.yml aus dem lokalen Repo für meine App in den freigegebenen Ordner kopieren musste, der sich in [mein_App_Name]/shared/config befindet. Also wusste meine App nicht, wo sie nach der geheimen Schlüsselbasis suchen sollte.

Obwohl ich bin immer noch verwirrt darüber, warum aus bedient würde verhindern, dass Vermögenswerte, die nicht die secret.yml mit ...

+0

Ohne die secrets.yml zu sehen, würde Ihnen niemand sagen können. Wenn Ihre Assets in einem S3-Bucket gespeichert sind, müssen Sie möglicherweise die Anmeldeinformationen der IAM-Benutzer angeben, um auf sie zuzugreifen. Das könnte ein Grund sein. Zwei Erinnerungen: 1) Sie sollten Produktionsanmeldeinformationen in Umgebungsvariablen auf dem Server und NICHT in der Datei secrets.yml speichern und 2) vergessen Sie nicht, secrets.yml zum .gitignore hinzuzufügen, damit Sie Ihre Geheimnisse nicht versehentlich weitergeben zu einem Repo. – hephalump