Last year, developers, engineers, marketing and sales, customers, enthusiasts, and evangelists were all together in Lisbon, Portugal, attending the Alfresco DevCon 2018.

DevCon is an international developer conference entirely dedicated to Alfresco technology, where you can increase your technical knowledge and connect with the community.

As the second article of this blog series, today we propose the presentation made by Roxana Angheluta, Senior ECM Engineer at Xenit, about how to build Alfresco images with Docker.

Together with the developer and systems engineer team, Roxana worked on three main challenges:

• Automating the process of installing and maintaining Alfresco
• Having Alfresco image(s) ready, both for the Community and Enterprise, with or without Solr and LibreOffice running inside, for clustered environments as well as non-clustered, remotely or on our hosted  platform – reusing services such as the smtp server, with easy configuration changes and easy upgrades
• Keeping track of all changes involved and installing a full monitoring system, which alerts in case of problems and helps in capacity planning for resources.

1. The architecture

“We started simple, with docker-compose files to start and stop services. We use Consul and registrator for service discovery and the Consul template for rendering load balancing configurations and restarting the load balancer. Consul was developed by Hashicorp and is a key-value store for storing services, adding or removing them on the fly based on health checks. The actual registration  is done by registrator developed at GliderLabs.” – Roxana Angheluta.

 The architecture has been deployed to our customers, with a 100% success rate.

2. The Docker images 

The team started running the installer on a base Ubuntu image, very simple to implement and to upgrade to higher Alfresco versions. 
When more flexibility is needed, like a specific version of java/tomcat, Installer is not the right choice. The team moved therefore to a different method to build images.
As the base layer they started from java, on top of which they added Tomcat, then a skeleton for an Alfresco including the init script, then the war files. Finally, client-specific modules were added on top.

3. The monitoring system

The monitoring stack is complex and includes a number of parts:
• Kibana, for log monitoring
• Grafana, for numerical data
• Cabot for alerting
• Alerta which aggregates Cabot warnings and alerts and allows you to spot and prioritize issues, across multiple clients.

“Our next challenge is using reporting data to automatically produce SLA (Service Level Agreement) reports” – Roxana Angheluta.