Alfresco is an open-source, enterprise content services platform. It provides a cloud-native platform for managing documents, web content, images, records, and other types of digital assets.
A key strength of Alfresco's is its ability to support different deployment methodologies. In the last few years, we've seen truly enterprise methods of deployment emerge. These include support for docker containers, Ansible scripts and Helm while continuing to support the classic 'Zip' based deployment.
However with this flexibility, comes complexity and it can become a struggle to decide which approach is most suitable. In this technical blog, Inpute’s Head of Alfresco, James Dickson, provides an overview of the various methods to deploy Alfresco Content Services. This overview is relevant for any new deployment or an upgrade of an existing Alfresco system.
For further information, please reach out to James or any member of the Inpute team.
Defined by Redhat as an open source IT automation engine that automates provisioning, configuration management, application deployment and orchestration.
What does this mean from an ACS deployment perspective? It means Hyland developers can safely define an Alfresco deployment script in Ansible that will run repeatably on supported platforms whether locally or remotely. Scripts can be run by CI/CD jobs to deploy ACS after Infrastructure is provisioned. They can be easily customised and versioned by DevOps engineers and their repo's integrated into the deployment pipeline.
In short, Ansible is flexible, it’s easy to understand and you can have a standalone ACS instance up and running on a VM in a matter of minutes with the attendant services and security expected of a production server.
Helm simplifies the process of deployment in Kubernetes by automating the distribution of your applications using a packaging format called a Helm chart. Helm manages Helm charts for Kubernetes. Charts provide consistency across containers while also determining how specific requirements for an application are met.
As the package manager for Kubernetes, Helm enables you to apply the same configuration framework to multiple instances using variable overrides, all based on what matters most to your specific configuration.
If that sounds complex, it’s because it is - relatively speaking. Application development and deployment in Kubernetes for an ACS solution is complex. There are a lot of variables and that's before you get into customisations or adding features (Alfresco Enterprise Viewer for instance) to your deployment.
Creating production ready Kubernetes clusters requires specialist skills. Kubernetes as a service is almost always associated with cloud computing providers, so much so that we now have specialists in cloud infrastructure deployment. The major cloud providers all have their own managed Kubernetes services, such as AKS, EKS and GKE, all of which abstract away the control plane components (responsible for scheduling, scaling pods, recovering pods, detecting cluster events etc) leaving engineers responsible for the pod deployments and contents of containers.
This is precisely where Helm charts come in. Helm charts define the services for the containers, the runtime variables, the services for pods and how they interact with other pods in the cluster (for instance between the repository and search services pods).
Underpinning the deployment are the docker images themselves. Hyland provide reference linux images for amd64 and arm64 architecture. Reference images are based on Rocky Linux with Alfresco components deployed and startup scripts to boot Tomcat etc.
Due to the way Alfresco extensions are built with Java, any in-process extensions (AMP or jar) need to be deployed into a custom container before deployment. Usually this is done using a custom 'Dockerfile' file which has the docker commands to import external components to the image and run OS commands for instance, to apply AMPs to the Alfresco war file. Building customer docker images for deployment requires a docker container registry to store them. Images should be version tagged for consistency to ensure the deployment environment has a consistent versioning.
Whilst it is possible to host your own registry, customers will typically use registries in the same cloud environment they are deploying their platform onto so as to streamline the deployment of their Kubernetes service.
There have been many independent pages written about how to install ACS manually using zip files. It is not a small task. Have a look at this very detailed 25 (printed) page post setup-acs70-ass201-and-transformation-service which I think is the most extensive I have found (credit to Abhinav Kumar Mishra).
Zip deployments are predominantly used when installing on Windows servers as it is currently the only supported method for Windows. Services need to be manually created using the Apache Commons Daemon or similar wrapper since java applications cannot run as services natively in Windows.
In my own experience very few ACS installations are running on MS Windows.. Those that are, typically do not have Linux skills in house and/or have a large Windows investment.
To conclude, Alfresco provides an array of enterprise grade deployment approaches. The approach you take for your Alfresco deployment should suit the skills available to you and the scalability requirements of the solution. The ability to support and upgrade your Alfresco solution should be factored into your choice. Ensure you can maintain version concurrency to avoid support issues and increased costs when running deprecated versions.
At Inpute we have experience in building custom deployments for ACS projects using all the methods discussed above. Whether you’re installing from scratch, upgrading, or migrating into the cloud, we can help you deploy to your environments, your way.