DX Cloud Architecture

A typical DX Cloud deployment contains productive and non-productive cluster(s) with our Magnolia Platform Services providing metrics, logs, alert management, and cluster orchestration. Clusters can be on AWS, Azure, or GCP.

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

As shown in Deployment options, users must be authenticated and authorized to access the core elements of DX Cloud, which include:

• Monitoring
• the Cockpit
• Kubernetes
• Source control (git)

In fact, even the elements themselves require authentication (via Bearer Token) to perform tasks, further securing your Magnolia deployment.

Deployment options

There are three deployment options for Magnolia using PaaS. These depend mainly on the size of your project.

• Basic
• Standard
• Premium

Basic

DX Cloud Basic offers:

• 1 Kubernetes cluster

• 4 nodes

  All nodes must be in the same Availability Zone (e.g., us-east-1a).

• 1 node for the Development environment (dev)

  The dev environment includes a Public and Author instance on the node.

• 3 dedicated nodes for the Production environment (prod)

  The prod environment includes one Author and two Public instances on the each node.

If you require more than two environments, you should upgrade to DX Cloud Standard or Premium.

Standard

DX Cloud offers:

• 2 Kubernetes clusters
  • 1 cluster for non-production environments such as dev.
  • 1 cluster for production environments.

If you require more than two clusters, you should upgrade to DX Cloud Premium.

Premium

DX Cloud Premium offers:

• 3 Kubernetes clusters
  • 1 cluster for non-production environments such as dev.
  • 2 clusters for production environments including a satellite cluster for high availability.

Satellite cluster communication:

Secure communication between the author cluster and satellite clusters is maintained through mTLS (mutual TLS) authentication on current Helm chart releases. The author cluster authenticates itself to satellite clusters using certificates, ensuring trusted interactions without compromising cluster independence.

• Recommended: Use the latest Helm chart (${helm-chart-version}) with mTLS authentication between the author cluster and satellite clusters.
• Minimum for mTLS multicluster: Helm chart ${minimum-helm-version-multicluster-mtls} or later.
• Older Helm charts (before ${minimum-helm-version-multicluster-mtls}): Cross-cluster communication relies on Linkerd. Do not remove or disable Linkerd unless you have upgraded your Helm chart and completed migration to mTLS.

To migrate from Linkerd to mTLS-based multicluster communication, open a Helpdesk ticket. DX Cloud operations will handle the migration for you.

We set up everything in the backend for your multiregion cluster approach.

Traffic routing via CDN

It’s important to understand how your traffic is routed within a Kubernetes and Fastly CDN setup. The diagram here provides a general sequence flow for traffic routing.

1. User Browser: The user initiates the request from their browser.
2. DNS Resolution: The browser resolves the website URL to the Fastly edge server.
3. Fastly Edge Server: The request is routed to the nearest Fastly edge server.
4. Is Content Cached? The edge server checks if the content is cached.
5. Yes: If cached, the content is served directly from Fastly.
6. No: If not cached, the request is forwarded to the Kubernetes load balancer.
7. Kubernetes Load Balancer: This distributes the request to an appropriate pod within the Kubernetes cluster.
8. Pod in Kubernetes Cluster: The pod processes the request and sends the response back.
9. Response Back to Fastly: The response is sent back to Fastly, where it may be cached for future requests.
10. Response Back to User: Finally, the content is delivered to the user.

Kubernetes and sidecars

DX Cloud uses Kubernetes for baseline orchestration of its environments.

Sidecars

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

Sidecar container after the main container.