This operation audit guideline is intended for Solution Architects who will be performing the review.
If you want to learn more about the guidelines and how to go through it, contact Andrew Warinner
| Check | Why | What | Notes |
|---|---|---|---|
Magnolia public instance is regularly backed up. | Magnolia backups can be used to restore content on a failed Magnolia public instance or new Magnolia instance. | Best practice: Magnolia recommended | |
| Backup WAR, filesystem and DB at the same time | Magnolia uses three different locations to store its contents/configs/files:
This means that all of three have to be backed up at the same time. A snapshot of a virtual machine holding all is recommended. | Best practice: Magnolia recommended | |
Avoid using modules and bootstrapping to populate content. | Creating content with bootstrapping and Magnolia modules can be error prone and doesn't work well in a multi-environment (development, test, and production). | Best practice: Magnolia recommended | |
| A restore or recovery procedure, preferably automated, is in place. | Recovering from a major malfunction of a Magnolia environment is necessary for high availability operations. Implementing a disaster recovery strategy and taking regular backups goes a long way towards ensuring availability. Recovery process is necessary is deployments go wrong. Every time a deployment is done, a backup should be available and be possible to be recovered in case of failure. | Best practice: Magnolia recommended | |
Public instances should set magnolia.develop=false. | Setting magnolia.develop=false will improve performance on public instances. | Best practice: Magnolia recommended | |
The magnolia.resources.dir property should not include the tmp directory. | The directory specified by magnolia.resources.dir should point to a directory containing light module content. Changes to this directory will be detected by Magnolia, including the tmp directory used by publication and activation will consume additional resources. If the tmp directory must be placed under magnolia.resources.dir, use the Magnolia property | Best practice: Magnolia recommended | |
| Production deployments should use the Magnolia certified stack | The environments are using the Certified stack for operating system, java version, application server and database. | Best practice: Magnolia recommended | |
| Magnolia instances should have sufficient heap settings. | The JVM of each instance has at least 2GB assigned. | Best practice: Magnolia recommended | |
| Production Magnolia instances use relational databases for the JCR repository. | In-memory and file system based databases should only be used on environments other than production. | Best practice: Magnolia recommended | |
| The network transmission time from Magnolia to the database hosting the JCR repository should be minimized. | To ensure fast transactions between Magnolia and the content store the database should be on the same physical machine as Magnolia. | Best practice: Magnolia recommended | |
| Traffic to Magnolia public instances should be distributed by a load balancer. | A distributed instance setup allows you to respond to high availability requirements and sudden increases in traffic. There should be at least 2 publics. | Best practice: Magnolia recommended | |
| Avoid Magnolia author clustering. | While clustering the authoring environment can increase availability for hundreds of concurrently working editors, it has little benefit for disaster recovery since all nodes in the cluster share one single repository and any sort of corruption to the repository will bring down all the cluster nodes. | Best practice: Magnolia recommended | |
| Stage and QA Magnolia environments are used. | The QA environment is intended for user acceptance testing prior to a release. The staging environment is used to ensure stability and non-regression for a release. | Best practice: Magnolia recommended | |
| Git or another version control system is used for Magnolia WAR sources and light development sources. | All files needed to build a WAR file and/or install light modules is managed by version control system like Git. | Best practice: Magnolia recommended | |
| Jenkins/Bamboo or another build/continuous integration platform is used to build the Magnolia web app. | Magnolias deployment on different environments is managed by a platform like Jenkins/Bamboo with a release based approach. | Best practice: Magnolia recommended | |
| Magnolia author instance and public instances use the same built WAR web app. | The WAR file contains the compiled Java code, templates, definitions and resources necessary for the project to function correctly within Magnolia, or to adapt the existing configuration to changes introduced with a new release. Building different versions of the WAR web app for author and public instances can introduce discrepancies and incompatibilities between author and public instances. | Best practice: Magnolia recommended | |
| Light modules should be deployed along with the Magnolia web app. | You can use WAR for Java and bootstraps, while you can use light modules for front-end development. This combination can be deployed together with an additional trigger in the orchestration service to trigger light module deployment via Git update on deployment of a new WAR. | Best practice: Magnolia recommended | |
| Light modules reside on a shared file system. | Git repository on a shared mount or alternatively, that each environment to be configured with access rights to any kind of Git repository you might be using and having a clone of such repository locally. | Best practice: Magnolia recommended | |
| Integration testing of Magnolia rendered web pages is recommended. | Integration testing can be performed using Magnolia’s Selenium test packages: UI tests | Best practice: Magnolia recommended | |
| Passive Author/Public approach for updates | Passive author and public instances are used when updating QA and production environments in order to reduce down time when swapping old releases for new ones. | Best practice: Magnolia recommended | |
| Publishing workflows on hold while updating | Magnolia’s workflow is flexible and configurable enough to allow the implementation of a verification process that will deactivate the publication process during the time that the passive author instance gets updated. | Best practice: Magnolia recommended | |
| Sync of passive and active instances while updating | Even if there were an activation or publication lock set on the active author, as described previously, there may still be items queued for publication or changes made to content by authors on the active author instance. | Best practice: Magnolia recommended | |
| Cache everything but dynamic content. | Cache improves performance greatly by using a filesystem based cache to serve previously rendered contents. Ensure that cache is enabled for all static pages. | Best practice: Magnolia recommended | |
| Magnolia caches should only be flushed when necessary. | Flushing policy can impact the performance of the cache greatly and hence Magnolia's ability to serve content. The default policy will flush all contents registered, which would generally mean all pages and assets. Ensure that flushing only happens when pages/assets or contents used in pages are activated. | Best practice: Magnolia recommended |