Hi all,
this is to continue the discussion from [1] as Jörg suggested on the
mailing list - it would be great to hear many opinions about that.
Disclaimer before we start: For the majority of configurations, the
well-proven runmode-based mechanism for OSGi configs (and replication
agents) works perfectly fine, but there are certain aspects where it has
its downsides:
* Hosts/ports for relations between environments (or servers of one
environment) and external url(s) of environment/system
** for the case the config values are not even known at build time (e.g.
if operations decides to spin up a PRE-PROD2 env for some performance
tests or if you deal with immutable servers in the cloud)
** for the case that a env "AEM UAT" might have to point to "Other
System UAT" or "Other System PROD" (and the link to be used is decided
at deploy time and possibly even changed again after deployment)
* Passwords (especially production passwords) that should not leave a
certain network zone and definitely not be stored in version control
(CryptoSupport mitigates the issue, but is your master key really safe?)
* Duplication - often there are one or two values that differ for one
config PID and the whole property set has to be copied
Possible solutions:
1. Generate a package with the configurations for a particular
environment on the fly using your favourite provisioning toolchain
(AWS/Chef/Puppet/Jenkins etc.) - merging of SW-delivered configs with
generated configs is error-prone, you reinvent the wheel depending on
what toolchain you are using (or you have to use for a particular
client)
2. Tweak the configurations directly on system via REST calls - fairly
complex to implement and make changes to, troubleshooting of why a
system is configured as is might be hard
3. Use an install hook to apply env specific values - IMHO currently the
best available option, follows the approach [2], see [3] for an install
hook that can be quickly introduced to a project and is provisioning
tool independent. Downside: JVM restart required for OS env var changes
and package installation to apply them ([3] has some configuration
options for that though)
4. Introduce a filtering mechanism in FileVault (like JCRVLT-254
suggested) - not available at the moment, could work similar to 3
5. Use a distributed configuration service like ZooKeeper - can be nice
to keep the env-specific configuration of all systems of one environment
in one place, but fairly complicated to integrate ([3] has POC-level
support for it)
6. Use install folder to put *.config files - does not work well to
overwrite existing configurations, does not work for replication agents
7. Introduce a lower level mechanism that works on OSGi level, this
could e.g. provide certain values for PID/propertyName as system
properties that would then take higher priority than anything else (like
config sets coming from JCR). I'm not aware of such a mechanism in OSGi,
but maybe something like that already exists?
What solution do you use today?
What would be the best solution for the problem?
- Georg
[1]
https://issues.apache.org/jira/browse/JCRVLT-254?focusedCommentId=16419919&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16419919
[2] https://12factor.net/config
[3] https://github.com/Netcentric/system-env-install-hook
