nTraum

nTraum

App env specific runtime files with Releases

I have a Phoenix application that is happily using runtime.exs to configure settings at runtime. The Phoenix app is deployed via a Dockerfile and a mix release.

In that phoenix application we set our own app_env config setting to distinguish between staging / prod / demo environment settings. The file has been growing steadily, so I’d like to introduce app-env specific runtime config files, similar to what mix does with compile-time settings.

My runtime.exs therefore contains generic configuration that is applicable to all envs - and at the very bottom:

# runtime.exs

# [... generic config here] ...

# Import app env specific config. This must remain at the bottom
# of this file so it overrides the configuration defined above.

runtime_file = "runtime_#{app_env}.exs"
IO.puts("Requiring #{runtime_file}")
Code.require_file(runtime_file, __DIR__)

With my config dir looking like this:

 $ tree config/
config/
├── config.exs
├── dev.exs
├── prod.exs
├── runtime_dev.exs
├── runtime.exs
├── runtime_prod.exs
├── runtime_staging.exs
├── runtime_test.exs
└── test.exs

This works well locally and on CI, but inside the Dockerfile the application is packaged and run via mix release. When starting the app, it rightfully complains that it cannot find config/runtime_prod.exs anymore.

Is there a way I can have these app-env specific runtime files while using mix releases? Looking at my Dockerfile, nothing special is happening with the default runtime.exs, it’s simply copied over:

# Changes to config/runtime.exs don't require recompiling the code
COPY config/runtime.exs config/

COPY rel rel
RUN mix sentry.package_source_code
RUN mix release

My attempt to include the other runtime config files via wildcard does not work:

# Changes to config/runtime.exs don't require recompiling the code
COPY config/runtime*.exs config/

COPY rel rel
RUN mix sentry.package_source_code
RUN mix release

First 4 of 4 Posts Switch mode

nTraum

nTraum OP

I dived a bit deeper into the mix release documentation, ConfigProvider specifically supports loading config files from multiple files (Config.Provider — Elixir v1.20.2), but as far as I can see that would require me to build different releases per app-env.

So that

releases: [
  demo: [
    config_providers: [
      {Config.Reader, {:system, "RELEASE_ROOT", "/runtime_demo.exs"}}
    ]
  ],
  staging: [
    config_providers: [
      {Config.Reader, {:system, "RELEASE_ROOT", "/runtime_staging.exs"}}
    ]
  ]
]

the correct runtime file would be included in the release. Currently I am building one Docker image for all app environments, which is very convenient. I guess I need to somehow put in some custom logic to only execute the relevant app-env-specific runtime file if possible.

hubertlepicki

hubertlepicki

You can do if/case/switch clauses inside runtime.exs, that’s what I do.

Instead of requiring “runtime_#{app_env}.exs” you can do conditional configs inside the same file, then you don’t have to include additional runtime_XXX.exs files at all.

nTraum

nTraum OP

Yep, while not as pretty, we decided to go with the naive solution too. Thanks!

arcanemachine

arcanemachine

I’m a big fan of dotenv config, so I would say to use Dotenvy.

— All posts loaded —

Where Next?

Trending in Questions Top

stjefim
Hello! Suppose you are building workflow (order / task / payment) processing system with the following requirements: Each workflow con...
New
jonnycharles
I’m in search of an Elixir library that offers PDF generation capabilities similar to Ruby’s Prawn. While there have been discussions abo...
New
spammy
I’m looking to build a personal workflow to quickly deploy web applications written in elixir/phoenix, for local consumption (ie not on t...
New
silverdr
Using Phoenix.LiveView.TagEngine as an EEx.Engine is deprecated! To compile HEEx, use Phoenix.LiveView.TagEngine.compile/2 instead. Sta...
New
dli
Before I dive in myself, did anyone successfully sprinkle Hologram into their existing LiveView app? Looking for hints regarding: Addi...
New
bottlenecked
Hi all, I wanted to ask how the community is dealing with post-release steps. Today we have Ecto migrations, which make sure that the db...
New
michallepicki
I am using Oban and occasionally, shortly after a deployment, a handful of jobs can fail because of dependency on other parts of the syst...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
ausimian
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New
type1fool
I just stumbled on a newly redesigned elixir-lang.org. :tada: It looks like @Software_Mansion did the work, and I think it is generally a...
New
akoutmos
@hugobarauna and I (Alex Koutmos) have been hard at work on writing a book on Nerves that takes you from simply blinking LEDs to building...
New

We're in Beta

About us Mission Statement