Make 'we-retail' sample replaceable to dispatcher AMS config from the archetype

[krystian-panek-vmltech]

Expected Behaviour

Dispatcher config generated from archetype could be used easily in built image
or in other words... sample/weretail config could be replacable to dispatcher.ams config from archetype

Actual Behaviour

Such config cannot be easily used. No idea how to supplement missing files.

Context

I want to test the dispatcher config on my dev machine locally and have configuration & runtime as close compatible with AMS-one as it is possible. When I tried to replace we retail config bundled in this repo with the config generated from archetype https://github.com/adobe/aem-project-archetype/tree/develop/src/main/archetype/dispatcher.ams I found out that config has references to /etc/httpd/conf.d/proxy but this configuration is not contained anywhere.

I built your image and check for the existence of a "proxy" dir which is referenced by archetype code:

References:

How about such a case?

It is just surprising that you noted that:

This is a simple dispatcher image that is very close to an AMS setup.

but in fact dispatcher.ams config from the archetype cannot be easily used with it.

WDYT?

[mgoszczynski]

Cześć Krystian!

How are you replacing the configuration? The easiest way to do it is dispatcher-mount. You can point it at any dispatcher configuration folder coupled with env.sh file (Environmental file present on AMS) and have it working correctly, without need to rebuild the image itself.

There are couple other ways to do it as well (https://github.com/adobe/aem-dispatcher-docker#using-your-own-dispatcher-config)

Let me know if this works for you.

[rbotha78]

The issue appears to be with the archetype's config.
If you don't select the commerce module, it still includes the mod_proxy block, but this is not using an IncludeOptional and we don't create the proxy folder in our scripts.
Furthermore, the SSLProxyEngine directive used in the archetype config is not available in the AMS RHEL 7 version of apache. I'd suggest logging an issue against the archetype project.
To fix it in your local, just delete the <IfModule mod_proxy.c> blocks
lines 65-68 in the generated src/conf.d/available_vhosts/aem_author.vhost file and
lines 60-63 in the generated src/conf.d/available_vhosts/mysite_publish.vhost

[rbotha78]

I've opened an issue on the archetype project for this:
adobe/aem-project-archetype#1069

[rbotha78]

Once you've removed the block from the config, you can run the dispatcher container against this config using the following command:

❯ docker run -p 80:8080 -p 443:8443 -it --rm --name dispatcher \
  --mount type=bind,src=$(pwd)/src/conf,dst=/etc/httpd/conf,readonly=true \
  --mount type=bind,src=$(pwd)/src/conf.d,dst=/etc/httpd/conf.d,readonly=true \
  --mount type=bind,src=$(pwd)/src/conf.dispatcher.d,dst=/etc/httpd/conf.dispatcher.d,readonly=true \
  --mount type=bind,src=$(pwd)/src/conf.modules.d,dst=/etc/httpd/conf.modules.d,readonly=true \
  --mount type=tmpfs,dst=/tmp \
  --env-file env.sh \
  dispatcher

Just copy the env.sh file from the repo.

[krystian-panek-vmltech]

#19 (comment) Yep, that's exactly what I meant. It would be nice to have it also documented.

Thank you @rbotha78 for taking follow-up actions. My intention was to initiate them :)

[krystian-panek-vmltech]

@mgoszczynski I am not sure if I am able/want to use it. My case is rather about providing AMS-compatible Dockerfile with code coming from the archetype. My goal is to provide complete automation for AEM with only a few commands. I don't want to introduce too much extra code except the one coming from the archetype.

Some references about what I am doing...

[1] https://github.com/wttech/aemc#cli---aem-project-quickstart
[2] https://github.com/wttech/aemc/blob/main/pkg/project/app_classic/dispatcher/Dockerfile

right now I am trying to change [2] to be more looking like the dockerfile available in that repo as I believe it's more working like on AMS ;)