Mix release and config files priority

Phoenix Forum Questions / Help
,
1

I have a phoenix application I deploy using mix release.
This is my mix release file:

import Config

database_url = System.fetch_env!("DATABASE_URL")

pool_size = System.fetch_env!("POOL_SIZE")
application_port = System.fetch_env!("APP_PORT")
secret_key_base = System.get_env("SECRET_KEY_BASE")
live_view_sigining_salt = System.fetch_env!("SIGNING_SALT")
initial_user_password = System.fetch_env!("INITIAL_PASSWORD")
s3_component_bucket = System.fetch_env!("S3_COMPONENT_BUCKET")
dynamo_db_component_upload_table = System.fetch_env!("DYNAMODB_COMPONENT_UPLOAD_TABLE")
s3_models_bucket = System.fetch_env!("S3_MODELS_BUCKET")
aws_access_key_id = System.fetch_env!("AWS_ACCESS_KEY_ID")
aws_secret_access_key = System.fetch_env!("AWS_SECRET_ACCESS_KEY")

config :cybord, Cybord.Repo,
  # ssl: true,
  url: database_url,
  pool_size: String.to_integer(pool_size)

config :cybord, CybordWeb.Endpoint,
  http: [
    :inet6,
    port: String.to_integer(application_port),
    transport_options: [socket_opts: [:inet6]],
    protocol_options: [idle_timeout: :infinity]
  ],
  # This is critical for ensuring web-sockets properly authorize.
  url: [host: "localhost"],
  render_errors: [view: CybordWeb.ErrorView, accepts: ~w(json), layout: false],
  pubsub_server: Cybord.PubSub,
  live_view: [signing_salt: live_view_sigining_salt],
  secret_key_base: secret_key_base

config :cybord,
  cool_text: System.fetch_env!("COOL_TEXT"),
  initial_password: initial_user_password,
  component_images_storage_bucket: s3_component_bucket,
  dynamo_db_component_table: dynamo_db_component_upload_table,
  models_storage_bucket: s3_models_bucket

As you can see idle_timeout: :infinity. But I get a timeout on my production server (deployed on AWS ECS)
The timeout happens after 60 sec which is the cowboy default idle timeout.

This makes me think that for some reason the EndPoint is read from my prod.exs where there is no mentioning of timeout.

prod.exs

config :cybord, CybordWeb.Endpoint, server: true
config :cybord, open_api_path: "priv/static/swagger.json"

config :ex_aws,
  json_codec: Jason,
  access_key_id: {:system, "AWS_ACCESS_KEY_ID"},
  secret_access_key: {:system, "AWS_SECRET_ACCESS_KEY"},
  region: "us-east-2"

What is the precedence order of config files in release?

Anybody has a better idea on why this is happening?

2

You should also verify that this isn’t from the load-balancing layer on AWS because each of those have idle timeouts as well. It’s typically in the strict sense of “no bytes have flowed in or out in this time” though.

2 Likes
3

In terms of precedence, I typically tell people to use a remote console (or whatever the non-Distillery name for the release’s subcommand is) and check Application.get_all_env/1 to see if their desired configuration is being realized on the running release. If not, work backwards from there.

Elixir 1.11 will bring a unifying idea of runtime config that behaves the same in dev/test/prod/releases and should make this question of precedence slightly less ambiguous/hard to teach.

2 Likes
4

Precedence is quite simple actually:

config.exs is evalutated by mix, so for releases at the time the release is built. Everything import_config follows the order of execution.

releases.exs is evaluated when a release is started.

1 Like
5

I have a clear defined precedence in my setup, because my releases.exs file is always evaluated first, no matter what env I am working on, therefore I override production config in development, not the other way around. See my reply with an example here:

config.exs

# This file is responsible for configuring your application
# and its dependencies with the aid of the Mix.Config module.
#
# This configuration file is loaded before any dependency and
# is restricted to this project.

# General application configuration
use Mix.Config

# Keep consistency between environments. Development will derive from a
#  production environment, not the other way around. Having separated
#  configuration as Elixir and Phoenix currently promote can lead to adding a
#  new configuration field in `dev.exs` that you then forgot to add in
#  `prod.exs` and/or `releases.exs`, therefore you then have a broken production
#  deployment.
import_config "releases.exs"

config :mnesia,
  dir: '.mnesia/#{Mix.env}/#{node()}'

# Import environment specific config. This must remain at the bottom
# of this file so it overrides the configuration defined above.
import_config "#{Mix.env()}.exs"
1 Like
6

So at build time you’re evaluating releases.exs just to override it with prod.exs, which at release startup is then overriden by releases.exs contents. This to me sounds like way backwards.

2 Likes
7

Thanks for this. It was a good tip.

8

I am going to use this pattern. It is great.

1 Like
9

The example is a very simplified one.

In releases.exs I will put all the config that is for a production environment, and then in each environment test and development environment I override only what I need.

From the example comments:

# Keep consistency between environments. Development will derive from a
#  production environment, not the other way around. Having separated
#  configuration as Elixir and Phoenix currently promote can lead to adding a
#  new configuration field in `dev.exs` that you then forgot to add in
#  `prod.exs` and/or `releases.exs`, therefore you then have a broken production
#  deployment.
10

I saw that the last time you posted it, but I still feel this is problematic. To me it works like that:

config.exs (baseline)
-> #{Mix.exs} (Mix level override)
—> releases.exs (system/runtime level override)

Config is by no means separate. The stuff from config.exs and prod.exs is fully available to your release. What you did by no means solved the problem because someone adding a config in dev.exs will still make it be not configured in a prod release.

1 Like
11

What if I have both prod.exs, config.exs(obviously importing prod.exs) and release.exs. Both prod and release configure the same env attribute. Will release triumph? and have its data used?

12

config.exs + prod.exs will be evaluated at built time and at releases startup releases.exs will be evaluated and merged into the app env. Therefore releases.exs trumps config.exs and everything imported from there.

13

As I said you add it first in releases.exs and then you just add it in dev.exs if you need to override it.

ALERT: Rant ahead :wink:

The Elixir way of using configuration was never good, and still continues to be far away from being a nice experience for new developers… It’s just not explicit and/or intuitive.

In my opinion would have been much better if the commonly .env file used across so many stacks had been officially adopted in Elixir.

That being said I will play with just using the releases file and configure everything through a .env file, and this is more easy for me because I use Docker.

14

In the next version of Elixir, there will be a config/runtime.exs that is like config/releases.exs, but will be evaluated both in release and in dev. This will mean you can finally get unified configs for release and dev. :slight_smile: More info: https://github.com/elixir-lang/elixir/blob/master/CHANGELOG.md#configruntimeexs-and-mix-appconfig

3 Likes
15

To me .env was never a great experience for development. ENV variables are often unnecessarily verbose and type conversion makes handling them even more a pain. Considering in production I only override like a handful of the lines I like having releases.exs be the only place I need to deal with that. Most of the config I have is making libraries work a certain way, which is project specific, maybe mix env specific, but certainly not runtime specific.

1 Like
16

I am in the opposite side for sure. For me was the best idea across the several stacks I have worked with until now. Cannot be more simple and universal :wink: