Сервер не может видеть статические ресурсы, скомпилированные с помощью Brunch (Phoenix Framework)

Question

У меня самая странная техническая проблема. В то время как мой сайт отлично работал в разработке и раньше работал нормально в производственной среде, во время последней сборки он по непонятным причинам прекратил распознавать статические активы и обслуживает старую версию favicon. Я даже пытался откатить весь репо, но у меня точно такая же проблема. Старый фавикон больше не существует в репо.

У меня есть обратный прокси-сервер nginx перед процессом сервера Cowboy со следующим конфигом:

upstream phoenix {
        server 127.0.0.1:4000;
}


# Default server configuration
#

server {
        listen      80;
        server_name haaksploits.com www.haaksploits.com;
        return      301 https://$server_name$request_uri;
}

server {
    # SSL configuration
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

        rewrite ^/(.*)/$ /$1 permanent;

        server_name haaksploits.com wwww.haaksploits.com;

        ssl_certificate /etc/letsencrypt/live/haaksploits.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/haaksploits.com/privkey.pem;
        ssl_dhparam /etc/nginx/ssl/dhparam.pem;

        ssl_stapling on;
        ssl_stapling_verify on;

        access_log /var/log/nginx/sub.log combined;

    root /var/www/haaksploits.com/html;

    # Add index.php to the list if you are using PHP
    index index.html index.php index.htm;

    location / {
                allow all;

                # Proxy Headers
                proxy_http_version 1.1;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_set_header X-Cluster-Client-Ip $remote_addr;

                # WebSockets
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";

                proxy_pass http://phoenix;

                include /etc/nginx/mime.types;
    }

        location ~ /.well-known {
                allow all;
        }

        # Enable browser caching

        location ~*  \.(jpg|jpeg|png|gif|ico|css|js)$ {
                 expires 365d;
        }

        location ~*  \.(pdf)$ {
                expires 10d;
        }

    # pass PHP scripts to FastCGI server

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;

        # With php-fpm (or other unix sockets):
        fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
    }

}

Как вы можете видеть, у меня включено кэширование, но я попытался установить его на одну секунду, и это не помогает, и в любом случае я загрузил новый значок до того, как возникла проблема, поскольку он работал без проблем. Мой mix.exs:

defmodule Haaksploits.Mixfile do
  use Mix.Project

  def project do
    [
      app: :haaksploits,
      version: "0.2.3",
      elixir: "~> 1.4",
      elixirc_paths: elixirc_paths(Mix.env),
      compilers: [:phoenix, :gettext] ++ Mix.compilers,
      start_permanent: Mix.env == :prod,
      aliases: aliases(),
      deps: deps()
    ]
  end

  def application do
    [
      mod: {Haaksploits.Application, []},
      extra_applications: [:logger, :runtime_tools, :ueberauth, :ueberauth_google]
    ]
  end

  defp elixirc_paths(:test), do: ["lib", "test/support"]
  defp elixirc_paths(_),     do: ["lib"]

  defp deps do
    [
      {:phoenix, "~> 1.3.0"},
      {:phoenix_pubsub, "~> 1.0"},
      {:phoenix_ecto, "~> 3.2"},
      {:postgrex, ">= 0.0.0"},
      {:phoenix_html, "~> 2.10"},
      {:phoenix_live_reload, "~> 1.0", only: :dev},
      {:gettext, "~> 0.11"},
      {:cowboy, "~> 1.0"},
      {:ueberauth_google, "~> 0.2"},
      {:ja_serializer, "~> 0.11.2"},
      {:guardian, "~> 0.14.2"}
    ]
  end

  defp aliases do
    [
      "ecto.setup": ["ecto.create", "ecto.migrate", "run priv/repo/seeds.exs"],
      "ecto.reset": ["ecto.drop", "ecto.setup"],
      "test": ["ecto.create --quiet", "ecto.migrate", "test"]
    ]
  end
end

И мой prod.exs:

use Mix.Config

config :haaksploits, HaaksploitsWeb.Endpoint,
  http: [port: 4000],
  url: [host: "haaksploits.com", port: 80],
  cache_static_manifest: "priv/static/cache_manifest.json",
  server: true,
  code_reloader: false

config :logger, level: :info

import_config "prod.secret.exs"

Единственное, о чем я могу подумать, это то, что в последней сборке до того, как возникла проблема, произошла ошибка, сообщающая о том, что Distillery отсутствовал, поэтому я добавил ее обратно, чтобы завершить сборку. С тех пор я удалил Distillery и Edeliver, так как в данный момент они мне действительно не нужны, и, хотя проблема не исчезла, мне интересно, если это что-то изменило с файлами, из-за чего сервер выглядит неправильно место для активов.

Если это так, все, что мне действительно нужно, это знать, где Distillery ищет эти файлы, и как заставить Phoenix снова искать правильные места для статических ресурсов. Или разрешить доступ к файлам, если доступ каким-либо образом заблокирован.

Когда я смотрю в / priv / static все файлы там, где они должны быть.

Обновить:

Я тестировал на машине без nginx, и это, похоже, не проблема Phoenix/Distillery, а что-то, связанное с конфигурацией nginx... Так что, возможно, проблема с кэшированием в конце концов........

Обновить:

Это не было проблемой, так как она по-прежнему не срабатывает, когда вы полностью выводите nginx из уравнения. Он также дает сбой при использовании бранча или ликеро-водочного завода для сборки релиза, но только на двух производственных серверах (один Debian, один Ubuntu), а не на моем Mac разработки. Я пытаюсь встраивать свою среду разработки, затем вручную подбираю архив сборки из рабочей среды.

Обновить:

Решение tarball не работает из-за архитектурных различий между машиной для разработки и машиной для производства. Попытка использовать edeliver, чтобы обойти.

Обновить:

Кажется, что работает нормально, когда к процессу обращаются напрямую с IP-адреса, так что единственное, что я могу вспомнить, это что-то не так между этапом разрешения имени домена и доступом к статическим ресурсам. Оставляя решение edeliver и вместо этого пытаясь использовать Cloudflare, посмотрите, поможет ли это.

Answer 1

Источник (по крайней мере для моего основного сервера, казалось, были другие проблемы, вызывающие ту же ошибку на другом, что странно, но не очень) проблемы в итоге оказались не так с сертификатами SSL, которые каким-то образом привели к тому, что доступ был заблокирован только часть контента (???).

Я очистил все настройки nginx, удалил все настройки SSL certbot, зарегистрировал сайт для Cloudflare и включил вместо этого их службу SSL. Это решило проблему.