Objective
One of the key challenges while automating deployments through cloudmanager is to manage dispatcher configurations especially since almost all of AEM deployments be it in Adobe Managed services deployment or AEM as a Cloud Native service. In both these type of platform hosting, deployment cease to be manual and has to be automated through AEM Cloudmanager.
While, the overall build process uses AEM Project Archetype[1] as a starting point, Adobe documentation does not entirely explain the process of including dispatcher as a module in the Multi-Module maven project. This article helps in bridging the gap between various documentations for customisers to easily integrate their dispatcher builds into their maven projects.
Modularisation of Dispatcher Configurations
As customers migrated to AEM 6.4 and above , Adobe managed services provided a modular dispatcher configuration as part of their standard build and customers adopted to the new structure similar to what we see below [2]. Customer has a freedom to modularize virtual hosts, dispatcher farm files for each and every property making it easier to manage the configurations and one configuration not affecting other properties. This also made managing the source configurations in repository and opened up the possibility of packaging the configurations as part of the overall build and deploy pipeline.
The New Challenge Imposed by Linux Based Soft links
With the onset of Dispatcher 2.0 configurations, the deployment process involved detailed documentation and steps involved for the Infrastructure implementation engineer a.k.a. customer success engineer to create soft links manually on the production dispatchers. While this approach is easy when the CSE has to deal with a couple of dispatchers, the complexity increases exponentially when there are multiple environments and each having multiple dispatchers.
Apart from this as we migrate onto AEM as a Cloud Native service, the option of logging into the containers is totally ruled out as dispatchers are enabled for dynamic scaling along with the increase in Load.
This bring about a definite necessity to manage the dispatcher configurations through the build process as making manual changes by logging onto the dispatcher is completely ruled off in the containerised environments.
The challenge with the dispatcher build is that it involves creating Linux based soft links in GIT and committing the file to GIT. A number of developers who typically work in windows based environment have faced the challenge while developers working in MAC or Linux based systems have found it extremely easy to handle this challenge.
Creating Softlinks in MAC:
Softlinks have to be relative to directory where the softlink is created. For example, in the below example:
The soft links are created in /etc/httpd/conf.d/enabled_vhosts but relative to enabled_vhosts directory. The steps would be as below:
1. cd $GIT_HOME/dispatcher/src/conf.d/enabled_vhosts
2. ln -s ../available_vhosts/wonderwall_publish_prod.vhost wonderwall_publish_prod.vhost
Please note: The soft link is created relative to the current working directory (enabled_vhosts).
Creating Softlinks in Windows
If the developer is used to using GIT BASH on Windows, softlinks has to be enabled while installing GIT Bash
Once Symbolic links is enabled, navigate to the GIT source directory and create a symbolic / soft link similar to the approach followed in MAC (Please note: The soft link is created relative to the current working directory)
Symbolic Links cannot be created using "Source Tree"
One of the key challenges while automating deployments through cloudmanager is to manage dispatcher configurations especially since almost all of AEM deployments be it in Adobe Managed services deployment or AEM as a Cloud Native service. In both these type of platform hosting, deployment cease to be manual and has to be automated through AEM Cloudmanager.
While, the overall build process uses AEM Project Archetype[1] as a starting point, Adobe documentation does not entirely explain the process of including dispatcher as a module in the Multi-Module maven project. This article helps in bridging the gap between various documentations for customisers to easily integrate their dispatcher builds into their maven projects.
Modularisation of Dispatcher Configurations
As customers migrated to AEM 6.4 and above , Adobe managed services provided a modular dispatcher configuration as part of their standard build and customers adopted to the new structure similar to what we see below [2]. Customer has a freedom to modularize virtual hosts, dispatcher farm files for each and every property making it easier to manage the configurations and one configuration not affecting other properties. This also made managing the source configurations in repository and opened up the possibility of packaging the configurations as part of the overall build and deploy pipeline.
The New Challenge Imposed by Linux Based Soft links
With the onset of Dispatcher 2.0 configurations, the deployment process involved detailed documentation and steps involved for the Infrastructure implementation engineer a.k.a. customer success engineer to create soft links manually on the production dispatchers. While this approach is easy when the CSE has to deal with a couple of dispatchers, the complexity increases exponentially when there are multiple environments and each having multiple dispatchers.
Apart from this as we migrate onto AEM as a Cloud Native service, the option of logging into the containers is totally ruled out as dispatchers are enabled for dynamic scaling along with the increase in Load.
The challenge with the dispatcher build is that it involves creating Linux based soft links in GIT and committing the file to GIT. A number of developers who typically work in windows based environment have faced the challenge while developers working in MAC or Linux based systems have found it extremely easy to handle this challenge.
Creating Softlinks in MAC:
Softlinks have to be relative to directory where the softlink is created. For example, in the below example:
The soft links are created in /etc/httpd/conf.d/enabled_vhosts but relative to enabled_vhosts directory. The steps would be as below:
1. cd $GIT_HOME/dispatcher/src/conf.d/enabled_vhosts
2. ln -s ../available_vhosts/wonderwall_publish_prod.vhost wonderwall_publish_prod.vhost
Please note: The soft link is created relative to the current working directory (enabled_vhosts).
Creating Softlinks in Windows
If the developer is used to using GIT BASH on Windows, softlinks has to be enabled while installing GIT Bash
Once Symbolic links is enabled, navigate to the GIT source directory and create a symbolic / soft link similar to the approach followed in MAC (Please note: The soft link is created relative to the current working directory)
Symbolic Links cannot be created using "Source Tree"
** Incase you have previously installed GIT Bash Use the below command **
run GIT Bash as Administrator
Copy & paste this command in GIT Bash export MSYS=winsymlinks:nativestrict
Creating Symbolic Links in Windows 10
1. Windows user must enable developers mode on his desktop (Settings > Update & Security > For Developers and select “Developer mode”)
2. use the mklink command to create symbolic link. Detailed instructions are provided in Microsoft blog[3]
The Final battle: Getting the Build compiled and generating a Dispatcher Package
Maven Assembly Plugin
Maven Assembly plugin[4] helps in building non-standard builds especially generating a ZIP file with all symbolic links intact
A simple extract from [5] shows the structure of the assembly plugin needed for Dispatcher build:
<assembly xmlns="http://maven.apache.org/ASSEMBLY/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 http://maven.apache.org/xsd/assembly-2.0.0.xsd">
<id>distribution</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>${basedir}/src</directory>
<includes>
<include>**/*</include>
</includes>
<outputDirectory></outputDirectory>
</fileSet>
</fileSets>
</assembly>
Final Notes: Once a build is successfully generated , please get your infrastructure implementation engineer to run a controlled deployment with your dispatcher package and ensure configuration checks pass successfully and apache restarts successfully. If the controlled deployment is successful , please get it embedded in the build process.
Reference:
[1] https://docs.adobe.com/content/help/en/experience-manager-core-components/using/developing/archetype/overview.html
[2] https://helpx.adobe.com/experience-manager/kb/ams-dispatcher-manual/explanation-config-files.html
[3] https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/
[4] http://maven.apache.org/plugins/maven-assembly-plugin/
[5]https://docs.adobe.com/content/help/en/experience-manager-cloud-manager/using/getting-started/dispatcher-configurations.html
Nice article... very helpful :)
ReplyDelete