Alfresco Module Management

Peter Lesty, May 30, 2016, 11:37 pm

At Parashift, we deploy and run a large number of different Alfresco instances for different clients, and it can be unwieldy managing different versions of AMPs and Alfresco for each different environment. In order to provide a rapid response and ensure we’re always up to date, we’ve paid lots of attention to the deployment process of Alfresco.

Some of the questions we’ve asked are:

How quick can we spool up a test instance of a particular environment?
How do we ensure that each environment has the right modules and the right versions of Alfresco?
How do we ensure that upgrades are as painless as possible?
If there is a security patch, how can we deploy this rapidly reducing the risk to our clients?

Alfresco’s Module Management Tool
Alfresco’s Module Management tool is the default tool to install AMPs into an Alfresco environment. This has a few deficiencies which is at ends with our approach. Newer orchestration tools like Salt Stack and Docker; treat application sources as ‘read only’, rather than files to be changed.

Alfresco MMT on the other hand, modifies the WAR by default, which can cause issues integrating it with these tools.

If we’re looking at Docker, having a base image, with only the AMPs applied as the variable, it is impossible in this scenario without some shell script trickery, causing unneeded complexity. We should be able to have a base image, and only make light adjustments to add the AMPs, or even externalise them, so that you can replace the Docker image and go.

Essentially, the ideal would be if we could simply say: Give me alfresco with this version and these modules.

Introducing Paramp
We have created a tool which is a replacement for Alfresco MMT. This will, rather than modifying a WAR file, create an output directory with the WAR and modules installed.

The code for this is Open Source and available here:

https://github.com/cetra3/paramp

This is a simple tool written in Rust used to treat the WAR and AMP files as read only sources, rather than sources to be modified, allowing more of a functional approach to packaging.

In this way, if we have a repository of amps and alfresco versions, we can simply create a YAML file to deploy this:

files:
  - example-module.amp
  - example-module2.amp
  - /path/to/alfresco.war

output_dir: /var/lib/tomcat7/webapps/alfresco

Advantages over MMT
While not the official way to package amps, there are a number of advantages over MMT:

It outputs to a directory rather than a WAR file. This means that the original WAR file is unchanged by design, and you can keep it vanilla.
There are not any restrictions as to which modules are installed in which order. If your modules have dependencies on other modules, MMT will fail if they aren’t installed first. This tool assumes the user will handle dependencies themselves.
It’s self documenting: you know what modules you’ve installed as they’re in the YAML file. A directory of AMPs may not have all AMPs installed, or the WAR may have extra ones installed.
Easy to upgrade to a new version: just replace the WAR location and run it again.
It’s lightweight, fast and doesn’t require java to run. Takes a few seconds to create a directory.
Great for bundling a standalone Docker image or use via server orchestration such as Salt Stack.

Conclusion
While not a complete solution to deployment in its own right, it’s a step in the right direction. Allowing a more functional and repeatable approach reduces the risks of human error and paves the way for things such as a pure Docker environment for Alfresco.