bryanhuntesl
Elixir releases on read-only file system.. Use confex instead of releases.exs?
There’s a bit of a trend in deployments these days to deploy containers with read-only root filesystems.
All the storage is off into (NO)SQL databases or cloud storage.
I was quite keen on Confex because it’s templating mechanism (interpolating environment variables at runtime via special app configuration syntax like {:system, "ENV_NAME", default}) allowed one to deploy on a read-only filesystem.
But, for some reason, the community didn’t adopt Confex - and everyone used the default release mechanism (releases.exs).
Now I find myself in the situation that many customer security teams are demanding apps are runnable with the security constraint that they can run on read-only file systems.
The average application reads in about 10~15 values from environment variables and I want to have one place that developers can consult to ensure all values are set rather than arbitrarily loading env values throughout the codebase.
Can anyone suggest a workaround - or should I just rewrite everything to use Confex?
Trending in Discussions
Other Trending Topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance











First 10 of 20 Posts
LostKobrakai
Maybe waiting for 1.11 is an option:
https://github.com/elixir-lang/elixir/blob/master/CHANGELOG.md#configruntimeexs-and-mix-appconfig
Given that
config/runtime.exswill be loaded at runtime (no restart as withreleases.exs) it shouldn’t need to persist anything to disk. Alsoruntime.exsis not file in your release, which people can look at.bryanhuntesl
I love this community. Yeah, that will do nicely.
Adzz
What does confex give you that using
releases.exsdoesn’t? Or I guess my question is why don’t releases work with a read only file system ?LostKobrakai
Edit:
releases.exsworks by starting the beam in a minimal setup, apply thereleases.exsand write the config back in an erlang config format to disk, stopping and another beam process is then fully starting up using the erlang config written to disk.josevalim
runtime.exswill work the same asreleases.exsin the sense that it will also need to write to disk. However, there is a release option on v1.10 that disables the writing to disk:The nerves team needed this option for similar reasons as @bryanhuntesl, so we added it. The only downside is that you can’t configure kernel/stdlib via config/releases.exs if you use this option. You should still be able to configure them via vm.args though.
LostKobrakai
Interesting. This sounds like it’s actually preferable to the default of the rebooting system unless actually needed.
derek-zhou
Interesting. If I don’t use releases.exs at all, does a release work on a read only file system?
LostKobrakai
That should work out of the box. If there’s no runtime config there’s nothing to write.
hauleth
Well, there is always possibility to just create tmpfs and mount it where you need write data during startup. In that way you will achieve what you need. IIRC there is possibility to do so automatically with systemd if needed.
bryanhuntesl
That sounds a bit complicated for the happy path - a Java, Golang, Ruby application doesn’t need a writable filesystem in order to read it’s configuration at boot.