Supported Providers

Last update: Edit

1 Introduction

Mendix for Private Cloud depends on external services to deploy and run Mendix apps. This document covers which providers and services are officially supported by the Mendix Operator.

2 Kubernetes Cluster Types

2.1 Supported Cluster Types

We currently support deploying to the following Kubernetes cluster types:

2.2 Cluster Requirements

To install the Mendix Operator, the cluster administrator will need permissions to do the following:

  • Create Custom Resource Definitions
  • Create roles in the target namespace or project
  • Create role bindings in the target namespace or project

The cluster should have at least 2 CPUs and 2 GB memory available. This is enough to run one simple app.

In OpenShift, the cluster administrator must have a system:admin role.

2.3 Unsupported Cluster Types

It is not possible to use Mendix for Private Cloud in OpenShift Online because OpenShift Online doesn’t allow the installation of Custom Resource Definitions.

3 Container Registries

3.1 Local Registry

A local, self-hosted, registry is supported for non-production use with the following bring-your-own infrastructure clusters:

  • MicroK8s
  • k3s
  • minikube

To use a local registry, it must be available from Kubernetes pods (for pushing images) and from the cluster itself (for pulling images). In most cases, the push URL and pull URL will be different.

It is possible to have username/password authentication or to push without authentication.

3.2 Externally Hosted Registry

Externally hosted registries are supported if they allow username/password authentication. This includes:

When using ACR in combination with Azure Combination Service, it is possible to set up native authentication for pulling images from ACR.

3.3 OpenShift Image Registry

The local image registry can be used in an OpenShift cluster. It is not possible to use an OpenShift registry in a non-OpenShift cluster.

Image pull authentication will be configured out of the box.

OpenShift 4 registries don’t need any configuration and will be configured automatically.

For an OpenShift 3 registry, the pull URL should be set to docker-registry.default.svc:5000. The push URL should be set to <registry ip>:5000 where <registry ip> can be obtained by running oc get svc docker-registry -n default.

The OpenShift registry must be installed and enabled for use.

3.4 Amazon Elastic Container Registry(ECR)

Amazon ECR can only be used together with EKS clusters.

To use an ECR registry, the Mendix Operator will need an AWS Identity and Access Management (IAM) account with permissions to push and pull images.

The EKS cluster should be configured so that it can pull images from ECR.

4 Databases

4.1 Ephemeral Database

The ephemeral database plan uses an in-memory database running directly in a Mendix Runtime container. It doesn’t require any external database or provider and is great for quick tests or apps that don’t require any file storage.

4.2 Standard PostgreSQL Database

The following standard PostgreSQL databases are supported:

  • PostgreSQL 9.6
  • PostgreSQL 10

A standard PostgreSQL database is an unmodified PostgreSQL database installed from a Helm chart or from an installation package.

The following managed PostgreSQL databases are supported:

Amazon PostgreSQL instances require additional firewall configuration to allow connections from the Kubernetes cluster.

Azure PostgreSQL databases require additional firewall configuration and SSL to be disabled to allow connections from the Kubernetes cluster.

Some managed PostgreSQL databases might have restrictions or require additional configuration.

These features are currently not supported:

  • SSL/TLS
  • Custom CAs for SSL/TLS

4.3 Microsoft SQL Server

The following Microsoft SQL Server editions are supported:

  • SQL Server 2017

The following managed Microsoft SQL Server databases are supported:

Amazon and Azure SQL servers require additional firewall configuration to allow connections from the Kubernetes cluster.

Some managed SQL Server databases might have restrictions or require additional configuration.

4.4 Dedicated JDBC database

This allows you to use an existing database (schema) database configuration parameters directly as supported by the Mendix Runtime.

5 File storage

5.1 Ephemeral file storage

The ephemeral file storage plan will store files directly in the Mendix Runtime container. It doesn’t require any external file storage provider and is great for quick tests or stateless apps that don’t require any file storage.

5.2 MinIO

The latest version of MinIO is supported if it is running in server mode.

5.3 Amazon S3

Amazon S3 is supported.

5.3.1 Amazon S3 (create on-demand)

To use S3, the Mendix Operator will need an IAM account with the following policy so that it can create a new IAM user and bucket for each Mendix app environment:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "bucketPermissions",
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:DeleteBucket"
            ],
            "Resource": "arn:aws:s3:::mendix-*"
        },
        {
            "Sid": "iamPermissions",
            "Effect": "Allow",
            "Action": [
                "iam:DeleteAccessKey",
                "iam:PutUserPolicy",
                "iam:DeleteUserPolicy",
                "iam:DeleteUser",
                "iam:CreateUser",
                "iam:CreateAccessKey"
            ],
            "Resource": [
                "arn:aws:iam::<account_id>:user/mendix-*"
            ]
        }
    ]
}

5.3.2 Amazon S3 (existing bucket)

The Mendix Operator can access an existing S3 bucket, with an existing IAM account access and secret key.

6 Networking

6.1 OpenShift route

OpenShift routes are supported only in OpenShift.

The only configuration option currently supported is turning TLS on or off. When TLS is turned on, Edge termination will be used, with automatic redirection from HTTP to HTTPS.

6.2 Ingress

We currently support the following ingress controllers:

For ingress, it is possible to do the following: * Turn TLS on and off * Provide a domain name (e.g. mendix.example.com) * Add ingress annotations

For each environment, the URL will be automatically generated based on the domain name. For example, if the domain name is set to mendix.example.com, then apps will have URLs such as myapp1-dev.mendix.example.com, myapp1-prod.mendix.example.com and so on.

The DNS server should be configured to route all subdomains (the * subdomain, e.g. *.mendix.example.com) to the ingress/load balancer.

For TLS, the ingress should have a default certificate with a wildcard domain (e.g. *.mendix.example.com).