缺少 elixir 应用程序文件时混合发布失败

mix release fails on missing elixir appup file

我有一个用 elixir/phoenix 编写的简单网站。 我今天做了一些更改,想将其部署到生产中。

我推送了我的存储库,将其拉到生产服务器上并构建了一个版本:

MIX_ENV=prod mix release

它失败了... 所以我 运行 再次使用 --verbosity=verbose 它失败了:

silent])===> Provider (relup) failed with: {error,
   {rlx_prv_relup,
   {relup_script_generation_error,
   systools_relup,
   {file_problem,
   {"/home/herman/alive/rel/alive/lib/elixir-1.1.1/ebin/elixir.appup",
     {error,
       {open,
        "/home/herman/alive/rel/alive/lib/elixir-1.1.1/ebin/elixir.appup",
    enoent}}}}}}}

有人知道如何解决这个问题吗?

当前版本0.0.6在elixir 1.1.0下运行,新版本0.0.7,与1.1.1。

我的mix.exs:

defmodule Alive.Mixfile do
  use Mix.Project

  def project do
    [app: :alive,
     version: "0.0.7",
     elixir: "~> 1.0",
     elixirc_paths: elixirc_paths(Mix.env),
     compilers: [:phoenix] ++ Mix.compilers,
     build_embedded: Mix.env == :prod,
     start_permanent: Mix.env == :prod,
     deps: deps]
  end

  # Configuration for the OTP application
  #
  # Type `mix help compile.app` for more information
  def application do
    [mod: {Alive, []},
   applications: [
     :phoenix,
     :phoenix_html,
     :cowboy,
     :logger,
     :phoenix_ecto,
     :timex,
     :mariaex]
   ]
  end

  # Specifies which paths to compile per environment
  defp elixirc_paths(:test), do: ["lib", "web", "test/support"]
  defp elixirc_paths(_),     do: ["lib", "web"]

  # Specifies your project dependencies
  #
  # Type `mix help deps` for examples and options
  defp deps do
    [{:phoenix, "~> 1.0.1"},
     {:phoenix_ecto, "~> 1.1"},
     {:mariaex, ">= 0.0.0"},
     {:phoenix_html, "~> 2.1"},
     {:phoenix_live_reload, "~> 1.0", only: :dev},
     {:cowboy, "~> 1.0"},
     {:timex, ">= 0.0.0"},
     {:exrm, "~> 0.19.9"},
     {:rebar3_hex, ">= 0.0.0"},
     {:plug_forwarded_peer, "~> 0.0.2" }
   ]
  end
end

您似乎正尝试在发布中使用热代码加载。这是一个很棒的功能,但如果您想更新您 运行 反对的 Elixir 版本之类的东西,它会非常复杂。

对于简单的情况,生成的应用程序很好,但对于更复杂的情况,它可能严重缺乏。主要问题是更新 运行 进程、更改状态、升级 ets 表等。您需要考虑您的应用程序以及所有依赖项。编写和测试正确的升级(和降级)指令可能会非常耗时。有时这是值得的,但我想说的是,在大多数情况下,传统的滚动发布(以保证正常运行时间)可能是一种更简单、更直接的解决方案——一个足够好的解决方案。

就个人而言,我在生产中使用发布,而不是热代码加载部分,正是出于上述原因。