I’ve been semi-successful in managing virtual hosts in the brXM/Hippo platform in that by modifying existing
.yaml files which have the virtual host information in them I’ve been able to get these changes or new hosts in some cases apply to the environments in which the project is deployed and the content & configuration bootstrapped.
The problem however is that when making changes to virtual hosts or adding new virtual host groups through the CMS Console with the auto export feature enabled I’ve noticed what seems to me to be some strange behavior in that the new virtual host configuration files are written to paths under
Reasons this seems to be a concern:
- From all that I’ve read it seems that virtual host setup should be considered “configuration” and not “content” and based on the various places in the Bloomreach documentation it seems to be the case that there is supposed to be “strict separation” between configuration and content so immediately this seems like an issue to me.
- All of our current host configuration is stored, what seems to be redundantly, under two different places (
repository-data\application\src\main\resources\hcm-config\hst\hosts\www.example.com.yaml) so the content oriented directory specified above would be a possible third redundant place where virtual host information is expressed within the source code for the project.
- The files that are being created by the auto-export module do not have the typical
config:nodes at the top of the file like I’d expect based on the documentation about configuration in general.
Part of the reason why bootstrapping has been difficult is that it’s unclear whether there is:
- a problem with the auto-export module in general.
- a problem within our configuration which is preventing the auto-export module from working correctly.
- an issue in how our established virtual host configuration is setup and perhaps the auto-export module is correct in attempting to store virtual configuration under the
hcm-contentsubdirectories and the
hcm-configfiles should be removed from application-data.
- a problem in our existing
hosts.yamland individual host yaml files (ex.
www.example.com.yaml) which were originally migrated from
.xmland could be a problem all on their own with regard to bootstrapping regardless of the behavior of the auto-export module.
The confusing thing in general with the Documentation on the site is that the example snippets don’t always match up 1:1 with how the actual content or configuration files end up after being auto-exported to the file system for version control. So for example in some of the examples it shows that all of the hosts are configured in a single
.yaml file which seems to pretty much match the intentions of the
hosts.yaml file that we have but it’s not called out specifically in the documentation and in our case we have what appear to be individual
hst:platform configurations stored under
repository-data\application\src\main\resources\hcm-config\hst\hosts\ which I would guess are supposed to represent the platform configurations normally found in the console under
hst:platform in v13+ but even though the directory structure may not be relevant to the bootstrapping behavior of configuration files it’s not clear whether the current organization is effectively the same as what the auto-export feature would produce if I could verify whether it’s working correctly or not in the first place.
Besides the rambling above I suppose it would be easier in some ways to simply ask whether there is a simple best practice or convention on how these virtual host configuration files should be organized in the file system for a typical project? And the secondary question I suppose is what is the expected behavior of the auto-export feature with regard to host configuration and the layout of those configuration files? Based on answers to these two questions I should be able to determine whether there is something specific in our project which is causing us additional problems.