AWSのレールイメージのNginx 404（見つからない）のみ

Question

私のアプリをプロダクションモードでテストして、奇妙な問題に遭遇しています。画像アセットがウェブページに読み込まれていません。すべてのCSSとjavascriptは正常に読み込まれていますが、どの画像もnginxから404 (Not Found)になります。私のアプリケーションをドッカーでAWSサービスにプッシュする私は資産をプリコンパイルするとき、彼らはそこにする必要がありますので、画像が出力に含まれています：

I, [2017-08-30T12:10:50.092655 #7] INFO -- : Writing /livingrecipe/public/assets/default-user-d39e051d757a0f45602b6065147cec0a307c6a2a070834f6fe6fc2b0fc914207.jpg 
I, [2017-08-30T12:10:50.104846 #7] INFO -- : Writing /livingrecipe/public/assets/default_recipe-be8d509a8e34dfec514c097b119753d4aaadbfd1dd6747e3c868ed454b8a36b3.jpg 
I, [2017-08-30T12:10:50.108486 #7] INFO -- : Writing /livingrecipe/public/assets/edit-4e381318428d71d55ed0cbdc32b4ce99db6622140c6e7c751ae0f1bfb40d3963.png 
I, [2017-08-30T12:10:50.111606 #7] INFO -- : Writing /livingrecipe/public/assets/favorite-91432751e505915d80cf4e24d7a8d0abd3493d05d2d447c1cebb055d99757ac8.png 
I, [2017-08-30T12:10:50.115720 #7] INFO -- : Writing /livingrecipe/public/assets/icon_email-203dcd7bdcf7559d742f76a9d8c21e98694d45b9556b29ab9ce286a7dd37af11.png 
I, [2017-08-30T12:10:50.118457 #7] INFO -- : Writing /livingrecipe/public/assets/icon_facebook-0140437ec6cb29bc6ac6f8505f05f11603a430298e48c1ea483f7de390ba34a9.png 
I, [2017-08-30T12:10:50.121393 #7] INFO -- : Writing /livingrecipe/public/assets/icon_google-2a98026430dddc53539d283c04a2ad4b50536c93d0becadb03f3f61443e52c9c.png 
I, [2017-08-30T12:10:50.125228 #7] INFO -- : Writing /livingrecipe/public/assets/star-half-db15fb9b3561d5c741d8aea9ef4f0957bd9bc51aa1caa6d7a5c316e083c1abd5.png 
I, [2017-08-30T12:10:50.127714 #7] INFO -- : Writing /livingrecipe/public/assets/star-off-6aaeebdaab93d594c005d366ce0d94fba02e7a07fd03557dbee8482f04a91c22.png 
I, [2017-08-30T12:10:50.130083 #7] INFO -- : Writing /livingrecipe/public/assets/star-on-fd26bf0ea0990cfd808f7540f958eed324b86fc609bf56ec2b3a5612cdfde5f5.png 
I, [2017-08-30T12:10:50.132442 #7] INFO -- : Writing /livingrecipe/public/assets/unfavorite-7000a53c81f55cf94c88031a8529f847e5a6abd7460e0e54ae0b581b0cde85a3.png 

そして、ここでは、nginxのための私は、default.confファイルです：

upstream PLACEHOLDER_BACKEND_NAME { 
    # The web app. 
    server PLACEHOLDER_BACKEND_NAME:PLACEHOLDER_BACKEND_PORT; 
} 

# Redirect 'www' addresses to the non-www version, and also take care of 
# redirects to HTTPS at the same time. 
server { 
    listen 80; 
    server_name www.PLACEHOLDER_VHOST; 
    return 301 https://$host$request_uri; 
} 

server { 
    # "deferred" reduces the number of formalities between the server and client. 
    listen 80 default deferred; 
    server_name PLACEHOLDER_VHOST; 

    # Static asset path, which is read from the PLACEHOLDER_BACKEND_NAME 
    # container's VOLUME. 
    root /PLACEHOLDER_BACKEND_NAME/public; 

    # Serve static assets. 
    # 
    # gzip_static is enabled because the assets are already gzipped to a maximum 
    # level due to Rail's asset pipeline. 
    # 
    # Add headers to set the maximum amount of cache time. 
    # 
    # We can do this because the Ruby on Rails asset pipeline md5 hashes all of 
    # the file names for us. When a file changes, its md5 will change, and the 
    # cache will be automatically busted. Other frameworks can do this as well. 
    location ~ ^/assets/ { 
    gzip_static on; 

    # Set a maximum cache time period and null out a few headers to address 
    # certain browsers from occasionally requesting cached content. 
    expires max; 
    add_header Cache-Control public; 
    add_header Last-Modified ""; 
    add_header ETag ""; 
    } 

    # Ensure timeouts are equal across browsers. 
    keepalive_timeout 60; 

    # Disallow access to hidden files and directories. 
    location ~ /\. { 
    return 404; 
    access_log off; 
    log_not_found off; 
    } 

    # Allow optionally writing an index.html file to take precedence over the upstream. 
    try_files $uri $uri/index.html $uri.html @PLACEHOLDER_BACKEND_NAME; 

    # Attempt to load the favicon or fall back to status code 204. 
    location = /favicon.ico { 
    try_files /favicon.ico = 204; 
    access_log off; 
    log_not_found off; 
    } 

    # Force SSL connections on agents (browsers) who support this header. 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;"; 

    # Load the web app back end with proper headers. 
    location @PLACEHOLDER_BACKEND_NAME { 
    proxy_set_header Host $http_host; 
    proxy_set_header X-Forwarded-Proto $scheme; 
    proxy_set_header X-Real-IP $remote_addr; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    proxy_set_header X-Forwarded-Ssl on; 
    proxy_redirect off; 

    if ($http_x_forwarded_proto = "http") { 
     return 301 https://$host$request_uri; 
    } 

    proxy_pass http://PLACEHOLDER_BACKEND_NAME; 
    } 
} 

Answer 1

私からお答えするつもりです私はNginx + Djangoと同じ問題を抱えていました。私の状況を救ったのは、画像にアクセスするためのサーバー（おそらくwww-dataかもしれない）を実行するユーザーに私に与えた特権です。はい、それは他のファイルへのアクセス権を持っているので馬鹿だとは思いますが、それが助けになりました。試してください

sudo chmod -R 750 /root/of/website 

これは再帰的にそのディレクトリ内のすべてのファイルに750を与えます。それが役に立てば幸い！

注：これは問題ではない可能性がありますので、助けにならない場合は、ダウンボールドしないでください。

Answer 2

したがって、資産を参照するのは間違った方法の間違いです。開発モードでまだ資産を示したが、本番では、それはそれはすでに資産フォルダはとても資産/資産/画像で見ていた追加原因それを見つけるcouldntの

<%= asset_path('/assets/image.png') %> 

：レールでは私はこれを使用していました。すべてを次のように変更しました：

<%= asset_path('image.png') %>