Web applications and services which are developed in 2016 have to be cloud ready. This includes more than deploying them to an “Infrastructure as a Service” (e.g. at Amazon) instead of a dedicated (virtual) machine. It means that you can deploy your application to a platform which selects and configures the system your application runs on based on the individual needs. This saves time and money for installing and maintaining the infrastructure. Other useful features are health management, scaling and load balancing.
The lack of a fixed binding to a specific machine can be challenging. Not all applications are cloud ready out of the box. More complexity is added by the need for persistent database services or file storage. When your system architecture consists of several interacting applications, it can be even more complicated. The Magnolia content management system is one of the more complex systems when it comes to cloud deployment. This article starts a series of blog posts which describe what needs to be done for deploying Magnolia to Pivotal Cloud Foundry.
Standard Magnolia Setup vs. Cloud Setup
The following picture shows a standard Magnolia setup. It consists of one Author application and two or more Public applications. Each application stores the content in its own Jackrabbit JCR repository which is usually persisted in a database like MySQL.
Standard Magnolia Setup
How can Magnolia benefit from a platform like Pivotal Cloud Foundry? Of course it is possible to deploy one Author application and two or more Public applications to Cloud Foundry. Just like a normal Magnolia setup, only using a different infrastructure. So what’s the benefit? You don’t have to care about the maintenance of the Magnolia infrastructure. That’s good, but not good enough. A much larger benefit would be if horizontal scaling is as easy as adding a new instance to a single Public application. No need for an additional Cloud Foundry application, no need for configuring a new environment in Magnolia’s single WAR deployment, no need for setting up a new database service, no need for importing a content dump and no need for subscriber registration. Sounds great! Such a setup looks like this:
Magnolia Cloud Foundry Setup
This overall goal can be split into several milestones. The first milestone, deploying Magnolia to Cloud Foundry, is covered in the rest of this article. Following topics like persisting the data or making the Public application scalable will be handled in upcoming blog posts.
Milestone 1: Deploying Magnolia to the Cloud
Application-specific Magnolia configuration
Magnolia allows a single WAR deployment, meaning that Author and Public Cloud Foundry Web Applications use the same WAR file and only differ by configuration. The configuration can amongst others depend on environment variables, the server name, or the context path. This mechanism is configured in the context parameter magnolia.initialization.file in web.xml. Since we want to deploy all our applications to the ROOT context and have no control over which server the application runs on, it is a good idea to use an environment variable, let’s call it magnoliaInstanceType, for context loading. This can be reached in web.xml with the following context parameter:
This allows us to place different property files in WEB–INF/config/ to configure different Cloud Foundry Applications. Since we want to deploy two applications, one for Magnolia Author and one for Magnolia Public, we create two property files, let’s say cfauthor.properties andcfpublic.properties, which will be loaded depending on the environment variable magnoliaInstanceType.
Environment variables in Cloud Foundry can be set in the application specific manifest.yml. The cfauthor–manifest.yml contains the following property:
The cfpublic–manifest.yml works likewise.
The most important configuration for running Magnolia in the cloud is the one for Jackrabbit JCR. Since our first goal is only to get Magnolia up and running and not to get a persistent application, we can use the default Derby persistence manager which uses the file system. But as the file system on Cloud Foundry is elusive anyway and won’t survive rebooting, we can also use an in-memory database to speed up the system. This is done by pointing the Magnolia property magnolia.repositories.jackrabbit.config to the following file:
While using an in-memory database, the configuration for Author and Public can point to the same Jackrabbit JCR configuration. As soon as external services are used for persistence, different configuration is required.
Cloud Foundry Deployment
Like this, the applications can be deployed to Pivotal Cloud Foundry using cf push –f cfauthor–manifest.yml or cf push –f cfpublic–manifest.yml. The following shows a complete Cloud Foundry Manifest for the Author:
The only thing worth mentioning here is the timeout, which is increased from the default 60 seconds to 180 seconds because Magnolia might take longer to startup, especially for the initial installation process (which in our case is performed on each startup since there is no persistence).
Automatic Subscriber Configuration
To make working with Cloud Foundry more comfortable, there is a Magnolia Cloud Foundry Module. This adds some nice features like handling of Cloud Foundry services (which will be covered in an upcoming blog post) or setting up the activation process. When this module is added, the Public application can automatically be configured as a subscriber by passing it as an environment variable to the Author.
That’s it. Magnolia can be pushed to the cloud. Even the content activation is already working. Just make sure you never restart one of the two apps, otherwise all of its data is gone. Read about how this and other issues can be solved in upcoming articles of this series. Follow us on Twitter so you don’t miss it!