Castle is a package I put together to assist with building Elixir releases capable of being live-upgraded via the ‘official’ release handling mechanisms.
It augments existing Elixir release support, providing:
build-time support for appup and relup handling and release generation.
runtime support for sys.config generation (incl. support for runtime.exs)
It additionally provides script support for release mgmt, adding commands to unpack, install, commit and remove releases in running systems.
This is an early release, there’s definitely a few rough edges notably:
No support for config providers
Untested on umbrella apps
No Windows support
I will definitely get to the first two in the short term.
Edit - Just to add, it will not generate your appup scripts for you and is unlikely to. If you need hot-code upgrades for your app, it is assumed you understand the implications and will write your own appups.
Support for config providers is added. Like runtime.exs, Castle takes over the invocation of these providers in a separate instance prior to boot, or in the running instance before hot-code upgrades/downgrades.
The generation correctly honours the config_env/0 property during config generation.
Out of curiosity: would it be possible for libraries to include appup files in their packaging, which can then be used in the generated relups? I’ve seen apps in OTP itself that have them and I was wondering how that worked.
I would like to see more maintainers provider appup files with their libraries, but i recognise this is out of scope for many of them. I think the appup generation tooling itself needs to improve as well.
From a technical perspective, it is the responsibility of the build tool to move appup files into the ebin folder of the compiled application. Castle does this currently via its appup compiler.
Fully agree with you here. For most libraries like you said it is probably out of scope, but at least having stub appups that just restart the application on upgrade would be a start.
I’ve just tested this, and like you said it is very straightforward to add an appup to libraries: including Castle in the library’s dependencies with the appup compiler and writing the appup is sufficient to get the appup in the ebin of the end application
Is my understanding correct that in this case, the library can specify runtime: false for Castle, as it only uses it at compile time?
Is my understanding correct that in this case, the library can specify runtime: false for Castle, as it only uses it at compile time?
Castle is also used at runtime, specifically, when you upgrade/downgrade a release e.g.
myapp> ./bin/myapp install 1.2.3 # Hot upgrade to release v1.2.3
The shell script sends an RPC into Castle (e.g. Castle.install/1) to prepare the sys.config for that version, prior to asking the release handler to perform the upgrade.
I’m considering whether to split out the build time and runtime parts into separate apps.
I should have phrased my question a bit better: I meant having runtime: false in the dependency that ships an appup whilst still having it included in the runtime in the final application - in that case my understanding is that the release command will still include Castle into the main release for the app?
In such case if somebody installs the library that doesn’t use hot code upgrades, the app won’t be loaded - so it’s easier to justify adding it as a library dependency.
This version separates out all the build-time support (release assembly, appup/relup handling etc) into a separate dependency, Forecastle. Applications should continue to use Castle as their dependency.
Mix Projects that don’t define a release, but do wish to generate an appup into their ebin folder, can bring in Castle as runtime: false.
Projects that do define a release, should bring in Castle as a runtime dependency. Due to its separation from build-time concerns, the dependency now consists of a single small module.
Prior versions of Castle wrapped the existing shell script in the release’s bin folder, which was a kludge. This version replaces the shell script entirely, with the new release handling commands now integrated directly.
