Magnolia PaaS Architecture

A typical Magnolia PaaS deployment contains a productive and non-productive cluster with our Magnolia Platform Services providing metrics, logs, alert management, and cluster orchestration.

These metrics can be viewed directly via the Cockpit.

The Docker Registry, pipeline, source control (git), Jira support, cluster orchestration, the CDN, and of course, the Cockpit are all accessible by the customer.

major tom standard deployment overview
Figure 1. Standard Magnolia PaaS deployment

Kubernetes and sidecars

Magnolia PaaS uses Kubernetes for baseline orchestration of its environments. This is an explicit dependency. Helm charts are used to deploy releases on the Kubernetes cluster.

architectural overview
Item Note

A

The CDN is deployed between the end user and the Magnolia instances.

B

Magnolia instances (author/public) are each deployed in a Kubernetes pod containing their own sidecars and K8s workers.

C

Sidecar containers are deployed to initialize containers before Magnolia CMS starts.

Sidecars are secondary containers that focus on a specific task. They are placed in the same pod as the primary container because resources are shared. Typically sidecars come after the main container in the configuration so the main container is the default target for kubectl execute as shown in the example below (1):
apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  volumes:
    - name: shared-logs
      emptyDir: {}

  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

    - name: sidecar-container (1)
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"]
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

D

The K8s workers handle pod availability.

Feedback