| Note |
|---|
It is an open question whether Dockerizing / containerizing Magnolia is best practice. Why? 1. Magnolia is stateful - it's difficult to do k8s stateful set. 2. JCR clustering is difficult - You cannot easily run two Magnolia instances on the same DB. JCR clustering uses a log - this log is used to spin up new instances and sync (index) them relatively quickly. But the log grows fast; to clean it, you need to activate the janitor. If you activate the janitor, you can't spin up new instances (unless using a snapshot taken from a synch'd cluster node after the last janitor run, or some other workaround) since part of the history will be missing (even with this mechanism, creating the new instance is not something obvious). Because of those two things, we can't leverage advanced cloud features which are provided out-of the box by k8s or AWS such as auto-scalability or B/G deployment. You may have to implement a lot of glue code to make it work, which removes some of the benefits of using such platforms. With container-based orchestration, the situation is even worse, because you can reallocate dynamically the containers to different hosts. This is the way failover is implemented and that the whole cluster scales. Magnolia instances must be declared as "fixed" instances, which cannot be moved to a different host, again peeling away the advantages of having k8s (or other container-based orchestrator). Dockerizing Magnolia is not considered best practice. You have been warned |
However, since using Docker together with Magnolia is clearly popular and growing in popularity, even if we do not advise Dockerizing Magnolia, we need to be able to provide a solution to those who must use it. This section will go through some aspects of Dockerizing Magnolia.
...
Docker containers are basically lightweight type II virtual machines. Another way to think of it: Docker containers are like apps that come bundled with all their dependencies. That's really it. You can drop a Docker container into any system running Docker, and it should just work. For example, you can run a Docker container on an EC2 instance, as long as that instance has Docker installed. In fact, you can run N Docker containers on any 1 or N EC2 instances. The key question here is: Why would I want to do something like this? Well, let's assume some business rules force you to use Docker. Or, our customers ask for k8s because they have invested in this technology to leverage these otb features and to have a consistent way of managing "services".
Next - Why (Not) Docker?
Advantages
...
| Expand | |||||
|---|---|---|---|---|---|
See how it is "using cache" for all those steps? This took no time at all to run (literally less than one second). |
Links
https://blogsblog.magnolia-cms.com/nicolas-barbe/detail~&magnolia-devops-series--part-1--a-docker-image-for-magnolia~.html https://blogsblog.magnolia-cms.com/nicolas-barbe/detail~&magnolia-devops-series--part-2--orchestration-with-docker-compose~.html https://blogsblog.magnolia-cms.com/nicolas-barbe/detail~&magnolia-devops-series--part-3--automate-your-deployment-on-multiple-hosts~.html https://blogsblog.magnolia-cms.com/jan-haderka/detail~&docker--amazon-ec2-and-continuous-builds-using-jenkins~.html
...