diff --git a/content/en/docs/deployment/mx-azure/_index.md b/content/en/docs/deployment/mx-azure/_index.md index 82e15d51e6e..2ef92b20e16 100644 --- a/content/en/docs/deployment/mx-azure/_index.md +++ b/content/en/docs/deployment/mx-azure/_index.md @@ -9,83 +9,26 @@ description_list: true ## Introduction -Mendix on Azure provides a simplified, integrated way to deploy Mendix applications to a Microsoft Azure environment. With this solution, users are empowered to deploy their Mendix applications in Azure environments without the need for intricate infrastructure setup in cloud services. They can also seamlessly manage infrastructure services through an intuitive user interface. No matter their IT skills, users can realize their project value quickly and securely with Azure. +Mendix on Azure offers a streamlined, fully integrated approach to deploying Mendix applications on Microsoft Azure. This solution eliminates the need for complex cloud infrastructure setup, enabling users to focus on building and delivering value faster. Through an intuitive interface, teams can easily manage their application environment and infrastructure services. Regardless of technical background, users can deploy, scale, and secure their Mendix apps efficiently on Azure. ## Benefits of Mendix on Azure -By eliminating manual setup and maintenance, Mendix on Azure allows your teams to: +By eliminating manual setup and maintenance, Mendix on Azure enables your teams to: -* Focus on developing business value instead of configuring infrastructure. -* Avoid delays caused by cross-team dependencies or architectural discussions. -* Accelerate time-to-market for critical applications. -* Address deployment and operational bottlenecks by automating the setup and management of Mendix applications on Azure. -* Eliminate the need for specialized cloud engineers and reduce setup time to under 30 minutes. -* Focus on innovation and deliver value faster, reduces labor costs, and ensure consistency, security, and compliance. +* Deliver business value faster instead of managing infrastructure. +* Accelerate time-to-market and reduce deployment bottlenecks. +* Minimize cross-team dependencies and technical complexity. +* Deploy applications in under 30 minutes without specialized cloud expertise. +* Lower operational costs while maintaining security, compliance, and consistency. -## Mendix on Azure and Mendix on Kubernetes +## Comparing Mendix on Azure and Mendix on Kubernetes -Mendix on Azure is a new deployment option that makes use of some of the features of Mendix on Kubernetes, but does so in an opinionated way. +Mendix on Azure is a deployment option that uses the same core Mendix engine as Mendix on Kubernetes, but is delivered in a standardized way within Azure environments. -Mendix on Kubernetes offers its users flexibility coupled with the ability to keep their deployment within their enterprise firewall, but requires more effort to configure and more time to value than deployments on Mendix Cloud. +While Mendix on Kubernetes gives organizations flexibility and the ability to host applications securely behind their own firewall, it demands more hands-on configuration and can take longer to realize full value when compared to deployments managed by public Mendix Cloud.​ -Mendix on Azure builds on that by providing an automated, preconfigured solution with access to private customer networks, which can be deployed in 30 minutes by a user without IT skills at no extra operational costs. The architecture, its maintenance, updates, and security hardening are all fully managed by Mendix. This helps prevent issues with setting up the infrastructure, which can sometimes be very technical and complicated for citizen developers. +Mendix on Azure aims to bring the best of both worlds, by offering users a preconfigured solution that can be integrated within their private networks. Deployment is simplified to such an extent that even business users without deep IT knowledge can launch production-ready environments in under 30 minutes—without incurring extra operating costs. Mendix manages the infrastructure, ongoing updates, and security hardening, eliminating technical hurdles and freeing up teams to focus on business innovation rather than infrastructure setup.​ -## Architecture - -Mendix on Azure provides a managed service to host Mendix apps in an Azure subscription you own. The Mendix on Azure service is composed of several underlying Azure services combined with the following Mendix-specific components: - -* [Mendix Runtime](/refguide/runtime/) -* [Mendix Operator](/developerportal/deploy/private-cloud-cluster/) -* [Mendix Agent](/developerportal/deploy/private-cloud-cluster/) - -Mendix operates all services and components within the scope of the Mendix on Azure service for you. The service leverages several underlying Azure services that are preconfigured to optimally host your Mendix apps. - -### Components - -Mendix deploys, operates and is responsible for overall service functionality of the following components as part of Mendix on Azure: - -* Azure Kubernetes Service with Managed NGINX Ingress Controller (app routing add-on) -* Azure PostgreSQL Flexible Server -* Azure Container Registry -* Azure Blob Storage -* Azure Managed Grafana -* Azure Managed Prometheus -* Azure Virtual Network with private endpoints and private DNS zones -* Mendix Runtime -* Mendix Operator -* Mendix Agent - -You cannot alter these managed components yourself beyond what is offered in the Mendix on Azure and Mendix on Kubernetes self-service portals. Mendix limits customization to ensure a consistent, predictable, and scalable customer experience. - -### Diagram - -The diagram in this section presents the high-level architecture of the Mendix for Azure solution. - -{{< figure src="/attachments/deployment/mx-azure/architecture.png" class="no-border" >}} - -The architecture is assessed against the [Azure well-architected framework](https://learn.microsoft.com/en-us/azure/well-architected/) to ensure its reliability, accessibility, and performance. - -## Security - -Mendix accesses customer environments in a secure, auditable way: - -* We use [cross-tenant access](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview), which is native to Azure and complies with Microsoft best practices. -* Most access is performed programmatically, that is, by the system rather than manually by normal users. There is usually no human intervention into the customer environments. -* In rare cases where human intervention is required, for example, because of a support request that requires access to the customer environment to resolve, the access is automated, auditable, and governed by Mendix support processes. The Mendix employee working on the support request receives temporary access which is then revoked. -* The network connectivity is done using a private Azure link service, not through the public internet. - -### SOC 2 Type 2 Compliance Exceptions - -The Azure Policy add-on is not enabled inside Mendix Azure clusters, because Mendix can control which workloads can access the cluster. Because of that, the following exceptions to the SOC 2 Type 2 policy are considered acceptable: - -* Azure Container Registry: - * [Container registries should be encrypted with a customer-managed key](https://www.azadvertizer.net/azpolicyadvertizer/5b9159ae-1701-4a6f-9a7a-aa9c8ddd0580.html) - The standard Microsoft key is used instead. -* AKS - cluster resource: - * [Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters](https://www.azadvertizer.net/azpolicyadvertizer/0a15ec92-a229-4763-bb14-0ea34a568f8d.html) - The cluster is deployed and managed by Mendix, so the policy is not needed. - * [Azure Kubernetes Service clusters should have Defender profile enabled](https://www.azadvertizer.net/azpolicyadvertizer/a1840de2-8088-4ea8-b153-b4c723e9cb01.html) - This is not automated for cost-saving reasons. -* AKS - cluster VNET: - * [All Internet traffic should be routed via your deployed Azure Firewall](https://www.azadvertizer.net/azpolicyadvertizer/fc5e4038-4584-4632-8c85-c0448d374b2c.html) - This is not automated, but the customer can deploy their own Firewall if required. -* Storage Account: - * [Storage accounts should use customer-managed key for encryption](https://www.azadvertizer.net/azpolicyadvertizer/6fac406b-40ca-413b-bf8e-0bf964659c25.html) - The cluster is deployed and managed by Mendix, so this is not needed. +This managed approach helps ensure reliable operations and secure best practices, while empowering citizen developers and IT professionals alike to harness the full potential of Mendix with minimal friction. ## Read More diff --git a/content/en/docs/deployment/mx-azure/backups.md b/content/en/docs/deployment/mx-azure/backups.md deleted file mode 100644 index 19556c313be..00000000000 --- a/content/en/docs/deployment/mx-azure/backups.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -title: "Backups for Mendix on Azure" -url: /developerportal/deploy/mendix-on-azure/backups/ -weight: 13 -description: "Describes the backups functionality for apps running on Mendix on Azure." -#To update these screenshots, you can log in with credentials detailed in How to Update Screenshots Using Team Apps. ---- - -## Introduction - -For apps running in Mendix on Azure, the [Backups](/developerportal/operate/backups/) functionality enables you to create/restore database or file document backups. Other backup functionalities are also supported for Mendix on Azure environments. This includes functionalities such as uploading and downloading backup snapshots and scheduling nightly, weekly, or monthly backups. - -Backup snapshots contain both the database and file documents referred to in the database. - -## Enabling Backups - -If you would like to enable creating and restoring backups, select **Try new Backup and Restore** on the **Backups** page. - -{{< figure src="/attachments/deployment/mx-azure/backups/backup-controls.png" alt="" >}} - -You must have permission to **Manage Apps Backups** for the namespace. - -## Creating a Backup {#creating-backup} - -1. In the [Apps](https://sprintr.home.mendix.com) page, select your app. -2. In the navigation pane, click **Backups**. -3. Select the environment for which you want to create a backup from the dropdown on the right. - -{{% alert color="info" %}} -You may not create backups while the environment status is any of the following: - -* Environment creation is in progress -* Environment creation failed -* A deployment package is being deployed in the environment -* The environment is in transition state (runtime is processing) -{{% /alert %}} - -4. Click **Create Backup**. -5. To check the status of the backup, see the **Status** column. - -{{% alert color="info" %}} -If you want to restart your environment after creating a backup archive, wait until the backup completes. Tables are locked while the database is in the process of creating a backup, so you may receive a timeout error if you try to start your environment while the backup is being created. -{{% /alert %}} - -### Backup Details {#backups-details} - -You can view details of a backup by clicking **More Options** ({{% icon name="three-dots-menu-horizontal" %}}) and then **Details**. The following details are displayed: - -| Backup Details | Description | -| --- | --- | -| **Status** | The status of the backup (**Processing**,**Failed**, or **Finished**) | -| **Snapshot ID** | A unique identifier for the backup snapshot | -| **Created on** | The creation date and time of the backup | -| **Deployment Package** | The version of the deployment package used during backup creation | -| **Comment** | A comment added to the backup | - -{{< figure src="/attachments/deployment/mx-azure/backups/backup-details.png" alt="Backup Details" max-width=60% class="no-border" >}} - -## Deleting a Backup {#backups-delete} - -To delete a backup snapshot, perform the following steps: - -1. Click **More Options** ({{% icon name="three-dots-menu-horizontal" %}}) by a backup that you want to delete. -2. Click **Delete**. - -The backup file is retained until you delete it from the portal. - -## Restoring a Backup {#restore-backup} - -You can restore a backup that has been created in your Mendix on Azure environment. Backups from other cloud providers are not supported. - -{{% alert color="info" %}} -You can only restore a backup if you have **Manage Apps Backups and Stop Apps** permissions in the respective namespace. -{{% /alert %}} - -To restore a backup, perform the following steps: - -1. If your app is running, stop it by clicking **Stop Application**. -2. Click **More Options** ({{% icon name="three-dots-menu-horizontal" %}}) by a backup that you want to restore. - - If you select a backup snapshot that was originally deployed with a different Mendix version, you will see a warning. You can still restore the data, but you must deploy the same model afterwards. - -4. Click **Restore**. - - {{< figure src="/attachments/deployment/mx-azure/backups/backups-restore.png" alt="Backup Restore" max-width=60% class="no-border" >}} - -5. Choose the destination environment to which you want to restore the backup snapshot. This allows you to, for example, restore a production environment backup to an acceptance environment. - -{{% alert color="info" %}} -Do not update the environment while the restore process is in progress. -{{% /alert %}} - -Your environment details page displays a message while the backup is being restored. After the restore process is completed, the environment activity log shows the status as **FINISHED**. If a backup restore fails, the backup activity log of your environment shows the status as **FAILED**. - -## Uploading a Backup {#upload-backup} - -To upload a backup, click **Upload Backup**, and then select the backup archive which you want to upload. For information on downloading backup archives, see [Downloading a Backup](#download-backup). - -You can upload archives containing a Full Snapshot. - -Uploading a backup creates a new backup item in your backup list. You can then restore the new backup item by following the regular restore process, as described in [Restoring a Backup](#restore-backup). This ensures less downtime for your application. - -## Downloading a Backup {#download-backup} - -To download a backup, click **More Options** ({{% icon name="three-dots-menu-horizontal" %}}) > **Download** on the backup which you want to download. - -You can download archives containing a Full Snapshot. - -{{% alert color="info" %}} -Because the download archive is generated on request, it is not possible to estimate the file size before requesting a download. -{{% /alert %}} - -To download a backup of an app, follow these steps: - -1. Go to [Apps](https://sprintr.home.mendix.com) and open your app. -2. In the [navigation pane](/developerportal/#navigation-pane), click **Backups**. -3. On the backup you want to download, click **More Options** ({{% icon name="three-dots-menu-horizontal" %}}). -4. Select **Download** from the drop-down list. -5. Click **Start** to submit a backup download request. -6. After the download request is processed and the backup is completed, click on the **Download** button to retrieve the backup file. -7. You can click on the **Show URL** button to view/copy the download link. - -## Nightly/Weekly/Monthly Backups - -Backups are created and retained as follows: - -| Frequency | Timing | Type | Retention Period | -| --- | --- | --- | --- | -| Nightly | Each night | Automatic | 14 days (counting from yesterday) | -| Weekly | Each Sunday | Automatic | Three months(counting from yesterday) | -| Monthly | First Sunday of each month | Automatic | One year(1st Sunday of each month) | -| On demand | On demand | Manual (user initiated) | 14 days (counting from yesterday) | - -Each backup is automatically deleted when its retention period is over, but you can always manually delete it before then. By default, backups are retained for exactly the specified period; for example, a weekly backup created at on October 22nd expires at January 22nd. If you want to keep a backup for longer than scheduled, you can download the backup to your computer. - -{{% alert color="info" %}}Automatic backups are only created when the app is deployed.{{% /alert %}} - -### Notes on Retention - -The monthly backup occurs on the first Sunday of the month. If the first nightly backup takes place after the first Sunday in the month, then there is no monthly backup retained for that month. In this case, you can download a copy of a nightly or weekly backup if you need to retain a backup for longer than three months. - -## Known Limitations - -* If a backup restore fails, all data that was restored until the point of failure is present in the database. This leaves the database only partially restored. -* There is currently no API support for the backup and restore process. -* The portal interface appears to allow restoring backups across different namespaces, but in reality this operation is unsupported. Backup and restore operations must be performed within the same namespace only. diff --git a/content/en/docs/deployment/mx-azure/configuration/_index.md b/content/en/docs/deployment/mx-azure/configuration/_index.md new file mode 100644 index 00000000000..aebb397a642 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/configuration/_index.md @@ -0,0 +1,101 @@ +--- +title: "Configuring Mendix on Azure" +url: /developerportal/deploy/mendix-on-azure/configuration/ +description: "Describes Mendix on Azure configuration." +weight: 6 +--- +## Introduction + +Mendix on Azure is delivered with default configuration settings optimized for evaluation and initial deployments, providing a seamless experience for trying out the solution. + +For production environments or to meet specific organizational requirements, additional configuration is typically needed. + +Mendix on Azure offers advanced configuration through the following methods: + +* Self-service configuration in the Mendix on Azure Portal +* Self-service configuration in the Microsoft Azure Portal +* Self-service configuration in the Mendix on Kubernetes Portal +* Configuration assistance upon request by submitting a support ticket through the Mendix on Azure Portal + +This document outlines the available configuration options and their functionalities. + +## Self-service Configuration Available in the Mendix on Azure Portal + +The [Mendix on Azure Portal](https://mendixonazure.mendix.com) provides a variety of self-service configuration options that can be modified anytime or specified once during initial cluster setup. The following sections categorize available options: + +### Networking Settings {#networking-settings} + +| Advanced Option | Description | Editable after initial creation | +| --- | --- | --- | +| Load Balancer Type | Controls whether your applications are reachable publicly or only privately via your own (Virtual) Network or Private Endpoints. | Yes | +| AKS Node CIDR IP Range | Defines the IP address range on the VNet hosting AKS cluster nodes. This can only be set during initial deployment and should align with your organization's IP plan if you plan to connect Mendix on Azure to other networks via peering. Default is acceptable when no interconnection is required. | No | +| AKS Network Isolated Cluster | When set to true will lead to a cluster without egress configuration, please carefully read the [documentation on cluster networking modes ](/developerportal/deploy/mendix-on-azure/configuration/ingress-egress/) to understand the implications | No | + +For more information, see [Configuring Ingress and Egress](/developerportal/deploy/mendix-on-azure/configuration/ingress-egress/). + +### Application Cluster Settings + +| Advanced Option | Description | Editable after Initial Creation | +| --- | --- | --- | +| AKS Node VM Size | The VM size used on the AKS application cluster. Default should suffice in most circumstances. You can change the default size in case of performance issues (for example, using non-burstable instances can improve Mendix Runtime performance), or if your Mendix app environment instances require more RAM than available under current selection. In case a Mendix app environment instance is configured to require more RAM than available on the current VM size, switching to a larger VM size might be required to have the app instance start at all. | Yes | +| AKS Maximum Node Count | The number of available cluster nodes will be increased and decreased automatically based on the combined capacity requirement of all deployed Mendix apps. This setting controls the upper limit to the number of available nodes in order to avoid cost surprises. | Yes | +| AKS Service Tier | The [AKS service tier](https://learn.microsoft.com/en-us/azure/aks/free-standard-pricing-tiers) determines the service level Microsoft provides on the Mendix on Azure Kubernetes cluster control plane. This does not impact application performance, only Microsoft's SLA. The Free tier is sufficient in most situations. Standard can be considered by organizations that value a financially backed SLA. For information about the associated costs, refer to Microsoft documentation. The Premium tier does not offer any additional value in combination with Mendix on Azure and is not recommended. | Yes | + +### Database Settings + +| Advanced Option | Description | Editable after initial creation | +| --- | --- | --- | +| Enable Read Replica | Enables a read replica for direct app database access. For more information, see [Direct Database Access](/developerportal/deploy/mendix-on-azure/configuration/direct-database-access/). | Yes | +| Compute Tier and Size | Specifies the DB Compute Tier for the shared PostgreSQL database used by all Mendix app environments. You may need to increase it for better app performance. For more information, see [Compute options in Azure Database for PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-compute) in Microsoft documentation. | Yes | +| Storage Performance Tier | Specifies the Storage Performance Tier for the shared PostgreSQL database. Consider increasing if performance issues arise. For more information, see [Storage in Azure Database for PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-storage) in Microsoft documentation. | Yes | + +### Observability Settings + +| Advanced Option | Description | Editable after initial creation | +| --- | --- | --- | +| Managed Grafana Accessibility | Determines whether the Managed Grafana observability dashboard is accessible publicly or only via private endpoints. [Virtual network peering](/developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks/#network-peering) is required for private access. | Yes | + +## Self-service configuration available via Microsoft Azure Portal + +The following configurations can be modified directly through the [Microsoft Azure portal](https://portal.azure.com) on resources within the Managed Resource Group of your Mendix on Azure Managed Application: + +| Configuration Option | Description | +| --- | --- | +| Configure virtual network peering on the vNet hosting Mendix on Azure | For more information, see [Implementing private connectivity using Azure Virtual Network Peering](/developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks/#network-peering). | +| Deploy Private Link Service to expose Mendix apps in other Azure virtual networks | For more information, see [Using Private Link Service to expose Mendix apps in other Azure virtual networks](/developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks/#pls). | +| Deploy Private Endpoints to establish connectivity between Mendix apps and other services | For more information, see [Accessing private services via Private Endpoints](/developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks/#pe-internal). | +| Override DNS configuration on the vNet hosting Mendix on Azure | For more information, see [DNS name resolution towards resources in other networks](/developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks/#name-resolution-dns-override). | + +### The Mendix on Azure Managed Resource Group {#mrg} + +Many Azure Portal configurations require modifying Azure resources located within the Managed Resource Group (MRG) of your Mendix on Azure environment. This resource group can be found through the Mendix on Azure Managed Application: + +{{< figure src="/attachments/deployment/mx-azure/mrg.png" class="no-border" >}} + +## Self-service Configuration Available in the Mendix on Kubernetes Portal + +In addition to extensive individual app environment configuration options, the [Mendix on Kubernetes Portal](https://privatecloud.mendixcloud.com) also offers cluster-wide settings applicable to Mendix on Azure clusters: + +### Adding Additional Cluster Managers {#cluster-manager} + +The Mendix account that initializes the cluster automatically gains the Cluster Manager role. + +The Mendix on Kubernetes portal lets you add additional cluster managers. These users can view and manage the cluster through both the Mendix on Azure and Mendix on Kubernetes portals, provided they have an Owner or Contributor role on the Azure Managed Application hosting the cluster. + +Additional cluster managers have the same configuration privileges as the original initializer. They can also view and comment on support tickets related to the cluster via the Mendix on Azure portal but cannot access the full Zendesk ticket. + +{{% alert color="info" %}} +Before adding a cluster manager, ensure the invited user signs in to the Mendix on Azure portal prior to accepting the invitation. Otherwise, the invitation might show as accepted, but the user will not have access to any Mendix on Azure resources. +{{% /alert %}} + +## Configuration Assistance Available by Submitting a Support Ticket through the Mendix on Azure Portal + +Certain configuration changes require Mendix intervention and can only be performed by submitting a support ticket through the Mendix on Azure portal: + +| Configuration Change | Description | +| --- | --- | +| PostgreSQL Maintenance Window | Configure a dedicated maintenance window for the PostgreSQL database hosting your Mendix app databases. Since maintenance might cause temporary app downtime, you can request a custom schedule instead of the default system-managed one. For more information, see the [Microsoft documentation on PostgreSQL maintenance windows](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-maintenance). | + +{{% alert color="info" %}} +Please submit Mendix on Azure support tickets exclusively through the Mendix on Azure portal. Tickets created here automatically capture vital context such as cluster identifiers and logs, enabling faster, more accurate support. +{{% /alert %}} diff --git a/content/en/docs/deployment/mx-azure/configuration/mx-azure-direct-database-access.md b/content/en/docs/deployment/mx-azure/configuration/mx-azure-direct-database-access.md new file mode 100644 index 00000000000..bbbf0d55be5 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/configuration/mx-azure-direct-database-access.md @@ -0,0 +1,73 @@ +--- +title: "Direct App Database Access" +url: /developerportal/deploy/mendix-on-azure/configuration/direct-database-access/ +description: "Provides details about obtaining Direct Database Access using the read replica feature." +weight: 40 +--- + +## Introduction + +This document describes how you can achieve direct app database access by enabling a read replica for the PostgreSQL database hosting the Mendix app data in a Mendix on Azure cluster. It also provides examples on how to read data from the read replica. + +### What is a Read Replica and Why Is It Needed? + +Read replicas are synchronized copies of the primary database. They are commonly used to serve read-only queries, reducing load on the primary database by separating reads from writes. + +In the case of Mendix on Azure, read queries still go to the primary database, but the read replica is created specifically to give customers secure, read-only access to the data. This feature is particularly useful for data ingestion (data lake) purposes, and when the customer needs to have read-only access to Mendix app data in a secure manner that does not impact app performance. + +## Prerequisites + +Before you begin, make sure to fulfill the following prerequisites: + +* Ensure that you have established working connectivity to the Mendix on Azure virtual network by enabling [virtual network peering]( /developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks/#network-peering) +* Ensure that your Postgres database has the **General Purpose** or **Memory Optimized** compute tier settings. + +{{% alert color="info" %}} Leveraging Direct Database Access is only possible in combination with virtual network peering, not with Azure Private Link / Private Endpoints. {{% /alert %}} + +## Enabling the Read Replica in the Mendix on Azure Portal + +By default, the read replica for Postgres database is disabled. To enable it, perform the following steps: + +1. On the **Provision > Database Settings** section of the **Initialize Cluster** page, set the **Enable Read Replica** option to **Yes**. + +{{% alert color="info" %}} For existing clusters, you can also enable or disable the read replica in the **Edit Cluster** flow.{{% /alert %}} + +2. Click **Next** to initialize the cluster. + + {{< figure src="/attachments/deployment/mx-azure/enableReadReplica.png" class="no-border" >}} + + After the cluster is initialized, the read replica for PostgreSQL database is enabled, and a read replica for the PostgreSQL database has been created automatically. + + {{< figure src="/attachments/deployment/mx-azure/readReplicaEnabled.png" class="no-border" >}} + +3. Copy the address value from the record set within the private DNS zone created for your PostgreSQL database. You can find this private DNS zone in the [Managed Resource Group of your Mendix on Azure environment](/developerportal/deploy/mendix-on-azure/configuration/#mrg). + + {{< figure src="/attachments/deployment/mx-azure/copyAddressValue.png" class="no-border" >}} + +4. Add Entra ID users who should be able to access the replica database by performing the following steps: + + 1. In the Azure portal, go to the [Managed Resource Group of your Mendix on Azure environment](/developerportal/deploy/mendix-on-azure/configuration/#mrg). + 2. Select the PostgreSQL master database resou.rce (type: Azure Database for PostgreSQL Flexible Server). + 3. Go to **Security > Authentication** + 4. Add any user needing to access the read replica as an Microsoft Entra administrator. + + {{< figure src="/attachments/deployment/mx-azure/adduser.png" class="no-border" >}} + +{{% alert color="info" %}}Never delete the existing ServicePrincipal user.{{% /alert %}} + +{{% alert color="info" %}}Users added here only have full Read access to the database, as network access is restricted to the read replica only using [Network Security Group](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview) rules.{{% /alert %}} + +## Enabling Virtual Network Peering and DNS Name Resolution + +VNet peering to the Mendix on Azure vNet is required to access the database. It enables IP traffic to flow to the read replica instance from other networks using private IPs. If you have not already configured vNet peering, you should follow the [instructions](/developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks/#network-peering) to do so. + +After enabling IP traffic to flow by enabling vNet peering, you need to make sure the read replica instance can be resolved from the source network(s). This can be done by associating the Private DNS Zone hosting records for your read replica instance to the virtual networks where you want to access the read replica from: + +1. Locate the Private DNS Zone containing the record pointing to the read replica. This Private DNS zone can be found in the [Managed Resource Group of your Mendix on Azure environment](/developerportal/deploy/mendix-on-azure/configuration/#mrg) and has a domain suffix ending in **database.azure.com**. +2. Create a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links) to link the PostgreSQL database's private DNS zone with the virtual networks your read replica clients originate from. This enables seamless name resolution from your source network(s). + +Users in the source network(s) can now connect to the read replica using any PostgreSQL clieny by [utilizing Microsoft Entra ID authentication](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/security-entra-configure#authenticate-with-microsoft-entra-id). + +The following diagram illustrates the network connectivity made possible by combining vNet peering with Private DNS zone name resolution: + +{{< figure src="/attachments/deployment/mx-azure/vnetpeeringreadReplicaEnabled.png" class="no-border" >}} diff --git a/content/en/docs/deployment/mx-azure/configuration/mx-azure-ingress-egress-configuration.md b/content/en/docs/deployment/mx-azure/configuration/mx-azure-ingress-egress-configuration.md new file mode 100644 index 00000000000..5d298558ecb --- /dev/null +++ b/content/en/docs/deployment/mx-azure/configuration/mx-azure-ingress-egress-configuration.md @@ -0,0 +1,64 @@ +--- +title: "Configuring Ingress and Egress for Mendix on Azure" +url: /developerportal/deploy/mendix-on-azure/configuration/ingress-egress +description: "This document explains the available configuration options and summarises them in cluster networking modes for easier comprehension." +weight: 20 +--- + +## Introduction + +Mendix on Azure supports various ingress and egress network configurations that allow customers to integrate Mendix applications seamlessly within their existing network infrastructure. This document explains the available configuration options and summarises them in cluster networking modes for easier comprehension. + +### Key Concepts and Terminology {#key-concepts} + +* Ingress - Inbound traffic entering the cluster for accessing Mendix apps +* Egress - Outbound traffic leaving the cluster to external networks such as the internet +* Internal Load Balancer (ILB) - A load balancer with an internal IP address limited to the cluster's virtual network +* Network Isolated Cluster - A cluster with restricted outbound traffic, requiring explicit configuration for egress +* AKS Node IP CIDR Range - The IP address range used by the Azure Kubernetes Service cluster's nodes +* VNet - Azure Virtual Network, a private network space within Azure + +## Available Networking Configuration Options {#networking-configuration-options} + +| Configuration Option | Default Value | Effect | Changeable After Deployment | Microsoft Documentation Reference | +| --- | --- | --- | --- | --- | +| **Internal Load Balancer** | False | When true, Mendix apps are exposed only internally within the AKS cluster IP CIDR range via ILB.| Yes | [Internal Load Balancer](https://learn.microsoft.com/en-us/azure/aks/internal-lb) | +| **Network Isolated Cluster** | False | When true, outbound traffic (egress) is blocked by default unless configured otherwise. | No | [Network Isolated Cluster](https://learn.microsoft.com/en-us/azure/aks/concepts-network-isolated) | +| **AKS Node IP CIDR Range** | `192.168.0.0/22` | IP range for the cluster network; must be unique and ideally /22 or larger to avoid IP shortages.| No | [IP Address Planning](https://learn.microsoft.com/en-us/azure/aks/concepts-network-ip-address-planning) | + +## Cluster Networking Modes Overview {#networking-overview} + +The configuration options in the previous section can be combined into four possible cluster modes: + +| Mode | Internal Load Balancer | Network Isolated Cluster | Typical Use Case | +| --- | --- | --- | --- | +| **Fully Public Cluster** | False | False | Hosting Mendix apps publicly without private network integration. | +| **Semi Public Cluster** | False | True | Public access with restricted or blocked outbound traffic. | +| **Semi Private Cluster** | True | False | Apps accessible only internally with allowed outbound traffic. | +| **Fully Private Cluster** | True | True | Private apps with no outbound internet access without extra setup. | + +## Detailed Networking Modes Description {#networking-modes-description} + +### Mode A: Fully Public Cluster (Default) + +* Description: Apps are exposed publicly through a public load balancer and can send outbound traffic directly to the internet. This mode is most similar to public Mendix Cloud. +* When to use: Hosting public Mendix applications on Azure with minimal network setup. +* When not to use: If your Azure environment restricts public IP usage or outbound internet traffic. + +### Mode B: Semi Public Cluster + +* Description: Apps are publicly accessible via a public load balancer, but outbound internet traffic is blocked unless configured. +* When to use: When public app access is required but egress must be controlled or blocked by policy. +* When not to use: If your apps need unrestricted outbound internet access. + +### Mode C: Semi Private Cluster + +* Description: Apps are accessible only within the cluster's virtual network via an internal load balancer; outbound internet traffic is allowed. +* When to use: Hosting internal apps only reachable from company networks. +* When not to use: If public internet access to apps is required. + +### Mode D: Fully Private Cluster + +* Description: Apps are internal-only with no outbound internet traffic allowed by default, offering the highest security posture. +* When to use: Hosting sensitive applications isolated from public networks. +* When not to use: Enforcing stringent security policies on network diff --git a/content/en/docs/deployment/mx-azure/configuration/mx-azure-network-interconnecting-networks.md b/content/en/docs/deployment/mx-azure/configuration/mx-azure-network-interconnecting-networks.md new file mode 100644 index 00000000000..fe912609133 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/configuration/mx-azure-network-interconnecting-networks.md @@ -0,0 +1,138 @@ +--- +title: "Enabling Connectivity between Mendix on Azure and Other Private Networks" +url: /developerportal/deploy/mendix-on-azure/configuration/interconnecting-networks +description: "Describes interconnecting Mendix on Azure with private networks." +weight: 10 +--- +## Introduction + +Mendix on Azure supports various use cases where connectivity to other private Azure networks is required. This section explains those use cases, outlines supported connectivity methods, and provides detailed guidance on establishing such network connectivity. + +## Use Cases + +Typical use cases depending on private connectivity between Mendix on Azure and other private networks include: + +* Ensuring Mendix apps are exposed only to internal private networks for security and compliance, allowing access only to authorized personnel. +* Integrating Mendix applications with services available solely within your organization's private network for security and compliance reasons. +* Establishing direct read-only database access to the databases supporting your Mendix applications, for example in case your company policy mandates secure ingestion of all corporate data into a central Data Lake. + +## Supported Private Connectivity Methods + +During cluster initialization, Mendix on Azure automatically deploys into a new Azure Virtual Network. Resources on this network can connect with other resources via two native Azure methods: + +* [Azure Virtual Network Peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview) +* [Azure Private Link](https://learn.microsoft.com/en-us/azure/private-link/private-link-overview) with [Azure Private Endpoints](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview) + +{{% alert color="info" %}} Mendix on Azure always deploys a dedicated Azure virtual network during cluster initialization. Deploying onto an existing Azure virtual network is currently not supported. {{% /alert %}} + +### Pros and Cons of vNet Peering and Private Link with Private Endpoints + +The table below compares the possibilities and constraints of both supported methods. More details are available in the Microsoft documentation linked above. + +| Aspect | Azure VNet Peering | Azure Private Link with Azure Private Endpoints | +| --- | --- | --- | +| Primary Use | Connect entire virtual networks | Secure access to specific services | +| Security Level | High (exposes entire vNet) | Highest (exposes only a single endpoint) | +| Overlapping IP space | Not supported | Supported (exposes one endpoint using NAT) | +| Supported use-cases | All use-cases | All except direct database access | + +## Implementing Supported Private Connectivity Methods + +The diagram below shows a scenario where a secondary Azure virtual network co-exists alongside the virtual network hosting a customer's Mendix on Azure environment. The next two sections provide step-by-step instructions for interconnecting these networks using Azure Virtual Network Peering and Azure Private Link with Private Endpoints. + +{{< figure src="/attachments/deployment/mx-azure/separate-access-groups.png" class="no-border" >}} + +### Solution 1: Azure Virtual Network Peering {#network-peering} + +The following diagram illustrates bi-directional [virtual network peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview) connecting the Mendix on Azure virtual network with another virtual network. + +{{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings.png" class="no-border" >}} + +To enable virtual network peering between your Mendix on Azure virtual network and another virtual network: + +1. In the Microsoft Azure portal, [set up a new bi-directional virtual peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering?tabs=peering-portal#create-a-virtual-network-peering) +2. Locate the Mendix on Azure virtual network inside the [Managed Resource Group of your Mendix on Azure environment](/developerportal/deploy/mendix-on-azure/configuration/#mrg). + + {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-add.png" class="no-border" >}} + +3. Adjust routing tables and/or network security groups as needed to allow traffic between the Mendix on Azure cluster virtual network and your other networks. + +#### DNS Name Resolution towards Mendix App cluster + +Virtual network peering enables IP traffic flow but DNS resolution must also be configured so users in other networks can reach Mendix apps by name. For apps using the default URL format (`xxx.azure.mendixapps.io`), perform the following actions: + +1. Create an [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone). +2. In the **Instance details**, enter the domain suffix of your Mendix app, e.g., *azure.mendixapps.io*. + + {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-name.png" class="no-border" >}} + +3. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for your Mendix app: + + * **Name** - The app name (e.g., *myapp*), or use a wildcard (*) for automatic resolution of new apps. + * **IP** - The IP address of the internal load balancer, found on the Load Balancer resource in the [Managed Resource Group](/developerportal/deploy/mendix-on-azure/configuration/#mrg). + +4. Create a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links) to link this DNS zone to the virtual networks hosting the users who need access. + +Users in linked networks can now access Mendix apps using the usual URLs. + +#### DNS Name Resolution towards Resources in Other Networks {#name-resolution-dns-override} + +To allow Mendix apps to resolve internal services in your network, configure DNS resolution selecting one of the following options: + +* Create or use an existing Private DNS Zone for the internal service's FQDN and link it to the Mendix virtual network by using a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links). +* Configure the Mendix virtual network to use your own DNS server that resolves internal service names, as described in [Microsoft's DNS configuration instructions](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances). The Mendix virtual network is located in the [Managed Resource Group](/developerportal/deploy/mendix-on-azure/configuration/#mrg). + +### Solution 2: PrivateLink with Private Endpoints + +Alternatively, connectivity can be established with [Azure Private Endpoints](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview). The diagram below shows private endpoints added to each virtual network, enabling direct connections to Mendix apps or services in other networks. + +{{< figure src="/attachments/deployment/mx-azure/private-endpoints.png" class="no-border" >}} + +#### Creating a Private Endpoint to Mendix Apps {#pls} + +To create a Private Endpoint for accessing Mendix on Azure apps from another virtual network: + +1. In the Azure portal, configure a new [Azure Private Link service](https://learn.microsoft.com/en-us/azure/private-link/private-link-overview) targeting the Mendix AKS cluster load balancer in the [Managed Resource Group](/developerportal/deploy/mendix-on-azure/configuration/#mrg). Follow the [Microsoft instructions](https://learn.microsoft.com/en-us/azure/private-link/create-private-link-service-portal?tabs=dynamic-ip#create-a-private-link-service). + + {{< figure src="/attachments/deployment/mx-azure/private-link.png" class="no-border" >}} + +2. Create an Azure Private Endpoint in a virtual network accessible to your users. +3. Under the **Resource** tab, specify the following: + + * **Resource type** - **privateLinkServices** + * **Resource** - The private link service created in step 1 + +4. Under the **Virtual Network** tab, specify the following: + + * **Virtual network**: The network reachable by your users + +5. Configure additional settings as needed. +6. Create an [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone) and enter the Mendix app domain suffix, for example, *azure.mendixapps.io*, under **Instance details**. + + {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-name.png" class="no-border" >}} + +7. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for your Mendix app: + + * **Name** - The app name (for example, *myapp*), or use a wildcard (`*`) for automatic resolution of new apps. + * **IP** - The private endpoint IP address. + +8. Link the DNS zone with the virtual networks of users via a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links). + +Users in these networks can now access Mendix apps through the standard URLs. + +#### Creating a private endpoint to internal services {#pe-internal} + +To enable Mendix apps to connect to internal services in another virtual network: + +1. Ensure the internal service is exposed through an Azure Private Link service, as described in Microsoft documentation. +2. Create an Azure Private Endpoint in the [Managed Resource Group](/developerportal/deploy/mendix-on-azure/configuration/#mrg). +3. On the **Resource** tab, specify: + + * **Resource type** - **privateLinkServices** + * **Resource** - The private link service exposing the internal service. + +4. On the **Virtual Network** tab, specify the following: + + * **Virtual network** - The Mendix-managed virtual network. + +5. Configure DNS resolution by creating a Private DNS zone pointing the service's FQDN to this Private Endpoint. Link this DNS zone to the Mendix virtual network using a virtual network link as detailed in the [Managed Resource Group](/developerportal/deploy/mendix-on-azure/configuration/#mrg). diff --git a/content/en/docs/deployment/mx-azure/mx-azure-architecture.md b/content/en/docs/deployment/mx-azure/mx-azure-architecture.md new file mode 100644 index 00000000000..0256e4635a1 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/mx-azure-architecture.md @@ -0,0 +1,34 @@ +--- +title: "Architecture" +url: /developerportal/deploy/mendix-on-azure/architecture/ +weight: 6 +description: "Describes the security and compliance considerations for apps running on Mendix on Azure." +--- +## Architecture + +Mendix on Azure provides a managed service to host Mendix apps in an Azure subscription you own. + +Mendix operates all services and components within the scope of the Mendix on Azure service for you. The service leverages several underlying Azure services that are preconfigured to optimally host your Mendix apps. + +### High-level Architecture Diagram + +The diagram in this section presents the high-level architecture of the Mendix for Azure solution. + +{{< figure src="/attachments/deployment/mx-azure/architecture.png" class="no-border" >}} + +### Components Used in Mendix on Azure + +Mendix deploys, operates and is responsible for overall service functionality of the following components as part of Mendix on Azure: + +* Azure Kubernetes Service with Managed NGINX Ingress Controller (app routing add-on) +* Azure PostgreSQL Flexible Server +* Azure Container Registry +* Azure Blob Storage +* Azure Managed Grafana +* Azure Managed Prometheus +* Azure Virtual Network with private endpoints and private DNS zones +* [Mendix Runtime](/refguide/runtime/) +* [Mendix Operator](/developerportal/deploy/private-cloud-cluster/) +* [Mendix Agent](/developerportal/deploy/private-cloud-cluster/) + +You cannot alter these managed components yourself beyond what is offered in the Mendix on Azure and Mendix on Kubernetes self-service portals. Mendix limits customization to ensure a consistent, predictable, and scalable customer experience. diff --git a/content/en/docs/deployment/mx-azure/mx-azure-backups.md b/content/en/docs/deployment/mx-azure/mx-azure-backups.md new file mode 100644 index 00000000000..279fdbe03b0 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/mx-azure-backups.md @@ -0,0 +1,140 @@ +--- +title: "Backups for Mendix on Azure" +url: /developerportal/deploy/mendix-on-azure/backups/ +weight: 13 +description: "Describes the backups functionality for apps running on Mendix on Azure." +--- + +## Introduction + +Mendix on Azure integrates backup and restore functionality that allows you to create and restore database snapshots for your Mendix application environments hosted on the platform. + +Backup snapshots include both the database and the file documents associated with the Mendix app environment. + +## Enabling Backups + +To start using backups, select **Try new Backup and Restore** on the **Backups** page in the Mendix for Kubernetes portal. + +{{< figure src="/attachments/deployment/mx-azure/backups/backup-controls.png" alt="" >}} + +You must have **Manage Apps Backups** permission for the namespace to use this feature. + +## Creating a Backup {#creating-backup} + +1. On the [Apps](https://sprintr.home.mendix.com) page, select your app. +2. Click **Backups** in the navigation pane. +3. Choose the environment to back up from the environment dropdown. + +{{% alert color="info" %}} +Backups cannot be created while the environment is in any of these states: +* Creation in progress +* Creation failed +* Deployment package is being deployed +* Environment is in transition state (runtime processing) +{{% /alert %}} + +4. Click **Create Backup**. +5. Monitor progress in the **Status** column. + +{{% alert color="info" %}} +Tables are locked during backup creation, so if you attempt to start the environment while a backup is in progress, you may encounter a timeout error. Wait for backup completion before restarting. +{{% /alert %}} + +### Backup Snapshot Details {#backups-details} + +Click **More Options** ({{% icon name="three-dots-menu-horizontal" %}}) > **Details** to view: + +| Backup Detail | Description | +| --- | --- | +| **Status** | Backup status: **Processing**, **Failed**, or **Finished** | +| **Snapshot ID** | Unique identifier | +| **Created on** | Date and time created | +| **Deployment Package** | Version at backup creation | +| **Comment** | User-added comment | + +{{< figure src="/attachments/deployment/mx-azure/backups/backup-details.png" alt="Backup Details" max-width=60% class="no-border" >}} + +## Deleting a Backup Snapshot {#backups-delete} + +To delete a backup snapshot, perform the following steps: + +1. Click **More Options** ({{% icon name="three-dots-menu-horizontal" %}}) next to the desired backup. +2. Click **Delete**. + +## Restoring a Backup Snapshot {#restore-backup} + +{{% alert color="info" %}} +Restore requires **Manage Apps Backups** and **Stop Apps** permissions on the namespace. +{{% /alert %}} + +To restore a backup snapshot, perform the following steps: + +1. Stop the app if running by clicking **Stop Application**. +2. Click **More Options** ({{% icon name="three-dots-menu-horizontal" %}}) next to the backup to restore. + + If restoring a backup from a different Mendix model version, you will be warned. You must deploy the matching model after restore. + +3. Click **Restore**. + + {{< figure src="/attachments/deployment/mx-azure/backups/backups-restore.png" alt="Backup Restore" max-width=60% class="no-border" >}} + +4. Select the destination environment (for example, restoring production backup to acceptance). + +{{% alert color="info" %}} +Avoid modifying the environment during restore. +{{% /alert %}} + +The environment details page will show restore progress. Activity log shows **FINISHED** on success or **FAILED** on failure. + +## Uploading a Backup Snapshot {#upload-backup} + +To upload a backup, perform the following steps: + +1. Click **Upload Backup**. +2. Select the archive to upload (must contain a Full Snapshot). + +Uploaded backups appear in the backup list and can be restored normally. + +{{% alert color="info" %}} +You can upload backups from Mendix Cloud to migrate app data to Mendix on Azure. +{{% /alert %}} + +## Downloading a Backup {#download-backup} + +To download a backup, perform the following steps: + +1. Click **More Options** ({{% icon name="three-dots-menu-horizontal" %}}) > **Download** on the desired backup. +2. Click **Start** to request the download. +3. After processing completes, use the **Download** button to retrieve the archive. +4. Optional: Click **Show URL** to copy the download link. + +{{% alert color="info" %}} +File size cannot be estimated before request completion. +{{% /alert %}} + +Backup archives are compatible with Mendix Cloud backups allowing migration from Mendix on Azure to Mendix Cloud. + +## Automated Backups Schedule + +| Frequency | Timing | Type | Retention Period | +| --- | --- | --- | --- | +| Nightly | Every night | Automatic| 14 days (from previous day) | +| Weekly | Every Sunday | Automatic| 3 months (from previous day) | +| Monthly | First Sunday of each month | Automatic| 1 year (on that Sunday) | +| On demand | When triggered | Manual | 14 days (from previous day) | + +Backups older than retention are deleted automatically but can be manually removed earlier. To keep backups longer, download them locally. + +{{% alert color="info" %}} +Automatic backups only run when the app is deployed. +{{% /alert %}} + +### Retention Notes + +If the first nightly backup occurs after the first Sunday, no monthly backup will be retained that month. Download a nightly or weekly backup to extend retention. + +## Known Limitations + +* Partial data restoration may occur if a restore process fails. +* No API support exists currently for backup and restore. +* Although the portal UI suggests cross-namespace restores, only restores within the same namespace are supported. diff --git a/content/en/docs/deployment/mx-azure/mx-azure-delete.md b/content/en/docs/deployment/mx-azure/mx-azure-delete.md new file mode 100644 index 00000000000..38b67688741 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/mx-azure-delete.md @@ -0,0 +1,50 @@ +--- +title: "Offboarding Mendix on Azure" +url: /developerportal/deploy/mendix-on-azure/offboarding/ +description: "Provides information about offboarding Mendix on Azure." +weight: 99 +--- + +## Introduction + +Offboarding from Mendix on Azure is an automated procedure that permanently deletes all components of the service. This includes the database and storage accounts holding all Mendix application data. As a consequence, all Mendix application data and configuration will be permanently deleted through this offboarding process. + +{{% alert color="warning" %}} +Offboarding Mendix on Azure following this process will permanently and irreversibly delete all Mendix application data and configuration. Data recovery is not possible. Proceed with extreme caution. +{{% /alert %}} + +## Nature of the Offboarding Process + +The Mendix on Azure offboarding process: + +* Is an irreversible action that deletes all Mendix application data and configuration—**there is no way to recover deleted app data once the process completes**. +* May require several hours to fully finish. +* Can only be started by the customer via the Microsoft Azure Portal, using the procedure described below. + +{{% alert color="warning" %}} +Offboarding Mendix on Azure following this process will permanently and irreversibly delete all Mendix application data and configuration. Data recovery is not possible. Proceed with extreme caution. +{{% /alert %}} + +## Initiating the Offboarding Process + +{{% alert color="warning" %}} +Offboarding Mendix on Azure following this process will permanently and irreversibly delete all Mendix application data and configuration. Data recovery is not possible. Proceed with extreme caution. +{{% /alert %}} + +1. Sign into the [Microsoft Azure Portal](https://portal.azure.com) using an account assigned the Owner role on the Mendix on Azure Managed Application object. You can recognize the object in Azure Portal as shown below: + + {{< figure src="/attachments/deployment/mx-azure/initializable-clusters.png" class="no-border" >}} + +2. Click **Delete** button, and then confirm deletion by clicking **Yes**. + + {{< figure src="/attachments/deployment/mx-azure/deletepopup.png" class="no-border" >}} + +{{% alert color="warning" %}} +Offboarding Mendix on Azure following this process will permanently and irreversibly delete all Mendix application data and configuration. Data recovery is not possible. Proceed with extreme caution. +{{% /alert %}} + +The deletion proceeds after confirmation, and may take several hours to complete. When the process is finished, as indicated by a notification in Microsoft Azure Portal, all related resources will have been permanently and automatically deleted. + +## Suspending, Hibernating, or Stopping Mendix on Azure + +Currently, Mendix on Azure does not offer functionality for temporarily suspending, hibernating, or stopping the service. All operations are limited to running or permanently deleting the service. A pause or temporary stop option is unavailable at this time. diff --git a/content/en/docs/deployment/mx-azure/mx-azure-deploy.md b/content/en/docs/deployment/mx-azure/mx-azure-deploy.md new file mode 100644 index 00000000000..6613da3eb22 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/mx-azure-deploy.md @@ -0,0 +1,90 @@ +--- +title: "Deploying Mendix on Azure" +url: /developerportal/deploy/mendix-on-azure/deploy/ +description: "Documents the pre-implementation tasks for Mendix on Azure." +weight: 5 +--- + +## Introduction + +Before deploying your Mendix on Azure cluster, ensure all prerequisites are met. Once confirmed, you can proceed with the deployment. + +## Prerequisites + +To deploy Mendix on Azure, make sure you have the following available: + +* A Mendix platform account +* An Azure account with the following permissions: + * Permission to grant admin consent on the Mendix on Azure portal app registration (e.g. Global Administrator in Entra ID) + * Owner role assigned on the target subscription (temporary elevated Privileged Identity Management - PIM - access does not suffice) +* In case you want to integrate the Mendix on Azure environment into your existing corporate network, be sure to consider the [network configuration options](/developerportal/deploy/mendix-on-azure/configuration/#networking-settings) that cannot be changed after initial environment deployment + +## Deploying the Mendix on Azure offering from Azure Marketplace + +To deploy the solution, perform the following steps: + +1. Open the [Mendix on Azure marketplace offering](https://portal.azure.com/#create/mendixtechbv.mxonazure) in the Azure Portal while signed into the correct Azure account. +2. Choose the **Standard** plan and proceed to the next step by clicking **Create**. + + {{< figure src="/attachments/deployment/mx-azure/create-managed-app.png" class="no-border" >}} + +3. Deploy the offering in a resource group and Azure location (region) of your choosing. Keep in mind that the Azure location chosen here will be used to host *all* Mendix on Azure resources. + + {{< figure src="/attachments/deployment/mx-azure/resource-group-name.png" class="no-border" >}} + +4. Finish the wizard by clicking **Create** in order to start the deployment of the managed application. +5. After deployment of the Mendix on Azure managed application has succesfully completed, please navigate to the Mendix on Azure portal by clicking on the **Mendix on Azure Portal** button or, alternatively, by using [this](https://mendixonazure.mendix.com) direct link. +6. Connect to your Azure account by clicking **Connect Azure Account**, and then login with the same account that you used to deploy the Mendix on Azure offering. + + After successfully connecting the accounts, the Mendix Portal shows a list of clusters with the following possible statuses: + + * Ready to initialize clusters (=clusters that have not been initialized yet to start hosting Mendix apps) + * Initialized cluster (=clusters ready to start hosting Mendix apps) + * Failed clusters (= cluster that failed to initialize for any reason). + + {{< figure src="/attachments/deployment/mx-azure/available-clusters.png" class="no-border" >}} + + +7. Identify the entry belonging to the Managed Application you deployed in previous steps. In the **Actions** column, click the dropdown menu icon, and then select **Initialize**. + + The preflight check launches to verify the conditions are in place to successfully initialize a Mendix on Azure cluster. + + {{< figure src="/attachments/deployment/mx-azure/preflight-check.png" class="no-border" >}} + +8. In the **Preflight Check** screen, click **Next** to be redirected to the **Provision** screen. When all preflight checks have passed, the status is displayed as **Done** in the **Preflight Check** section, as shown below: + + {{< figure src="/attachments/deployment/mx-azure/preflight-check-successful.png" class="no-border" >}} + +9. In the **Provision** screen, optionally add any custom tags that will be used to tag deployed resoources and optionally review the configuration in the **Advanced Options** section. + + For more information, refer to the [configuration documentation](/developerportal/deploy/mendix-on-azure/configuration/). The default settings suffice for a test deployment. Note that certain settings have influence on the Azure costs charged by Microsoft. + +10. In the **Review & Initialize** screen, review the information and click **Initialize**. + + {{< figure src="/attachments/deployment/mx-azure/initializeCluster.png" class="no-border" >}} + + The initialization process takes approximately 15 minutes. It deploys resource into the managed resource group belonging to the Managed App that you created in step 3 above as shown below: + + {{< figure src="/attachments/deployment/mx-azure/resourceGroup.png" class="no-border" >}} + +11. To view the cluster's initialization progress, click **Details** in the **Actions** column. + + {{< figure src="/attachments/deployment/mx-azure/infrastructure-details.png" class="no-border" >}} + +12. If there are deployment issues, the cluster status is **Failed**. To view details about which component(s) failed (if available), click **Details**. + + {{< figure src="/attachments/deployment/mx-azure/failed-cluster.png" class="no-border" >}} + + Some issues can be resolved by retrying the deployment. You can do this by clicking **Rerun** to manually re-trigger the cluster deployment. If the cluster still fails after a second rerun, a support ticket is automatically created with Mendix Support, and the Mendix team will contact you to resolve the issue. + + After the cluster is initialized successfully, the status of the cluster in the Portal changes to **INITIALIZED**. The cluster and its namespace are immediately available for deploying apps. + +{{% alert color="info" %}} Due to the managed nature of Mendix on Azure, creating additional namespaces within a Mendix on Azure cluster is not supported. Similarly, it is not possible to create a Mendix on Azure cluster using APIs. Furthermore, Mendix on Azure clusters cannot be deleted through either the Mendix on Kubernetes Portal or the Mendix on Azure Portal. + +For detailed steps on how to properly delete a Mendix on Azure cluster, see [Offboarding Mendix on Azure](/developerportal/deploy/mendix-on-azure/offboarding/). {{% /alert %}} + +## Deploying a Mendix App to a Mendix on Azure Cluster + +After creating your cluster in Microsoft Azure, you can proceed to deploy your applications to it. The deployment process is identical to that used with Mendix on Kubernetes. For more information, see [Deploying a Mendix App to a Mendix on Kubernetes Cluster](/developerportal/deploy/private-cloud-deploy/). + +{{% alert color="info" %}} Mendix on Azure app environments will begin to consume cloud tokens starting from 120 days after their creation. For more information, see [Licensing Mendix on Azure](/developerportal/deploy/mendix-on-azure/license/). {{% /alert %}} diff --git a/content/en/docs/deployment/mx-azure/mx-azure-getting-started.md b/content/en/docs/deployment/mx-azure/mx-azure-getting-started.md deleted file mode 100644 index 19416fcdc10..00000000000 --- a/content/en/docs/deployment/mx-azure/mx-azure-getting-started.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Getting Started with Mendix on Azure" -url: /developerportal/deploy/mendix-on-azure/quickstart/ -description: "Documents the pre-implementation tasks for Mendix on Azure." -weight: 10 ---- - -## Introduction - -Before you can deploy your Mendix app on Azure, you must plan and complete a number of pre-implementation tasks. - -## Prerequisites - -To adopt Mendix on Azure, you need to have the following: - -* A Mendix account; Mendix Studio Pro 10.10 or newer is required -* As an optional best practice, add multiple cluster manager to your clusters -* An Azure account with the following permissions: - * Permission to grant admin consent on the Mendix on Azure portal app registration - * Owner role assigned on the target subscription - -## Next Steps - -Once all the prerequisites are met, you will be granted access to the [Mendix on Azure](https://portal.azure.com/#create/mendixtechbv.mxonazure) offering in Azure Marketplace. You must use this listing to purchase and deploy to a resource group of your choice. - -After purchasing the offering, you can initialize your first Mendix on Azure cluster by following the [installation instructions](https://docs.mendix.com/developerportal/deploy/mendix-on-azure/installation/). - -## Licensing - -Mendix on Azure is available for purchase from the the [Azure Marketplace](https://azuremarketplace.microsoft.com/). Connecting to Azure services may also include additional cost. For more information, refer to Azure documentation. - -For production environments, you also need a runtime license for your Mendix app. For more information, refer to [Licensing Apps](/developerportal/deploy/licensing-apps-outside-mxcloud/). The Operator license is applied automatically when using Mendix on Azure. diff --git a/content/en/docs/deployment/mx-azure/mx-azure-installation.md b/content/en/docs/deployment/mx-azure/mx-azure-installation.md deleted file mode 100644 index f00c7dcf561..00000000000 --- a/content/en/docs/deployment/mx-azure/mx-azure-installation.md +++ /dev/null @@ -1,259 +0,0 @@ ---- -title: "Installing and Configuring Mendix on Azure" -url: /developerportal/deploy/mendix-on-azure/installation/ -description: "Documents the initial configuration tasks for Mendix on Azure." -weight: 20 ---- - -## Introduction - -To get started with your Mendix on Azure deployment, you must first register your Microsoft Azure cloud cluster in the Mendix Portal. This will provide you with the resources required to deploy the Mendix Operator and host your Mendix app in an Azure deployment. - -### Prerequisites - -Before starting the installation and implementation process, make sure that you have all the necessary prerequisites: - -* Obtain and configure a Microsoft Azure account. For more information, refer to the the Microsoft Azure documentation. -* Purchase the Mendix on Azure offering in the [Azure Marketplace](https://azuremarketplace.microsoft.com/). -* Cloud tokens are not required for trial deployment. -* You must sign in to the Mendix on Azure portal with the same Azure account that was used to purchase the offering. If you sign in with another account, the cluster is not visible for initialization. - -{{< figure src="/attachments/deployment/mx-azure/coadmin-permission.png" class="no-border" >}} - -* Familiarize yourself with the [Mendix on Kubernetes](https://docs.mendix.com/developerportal/deploy/private-cloud/) concepts. -* Ensure that your Mendix Studio Pro is in version 10.10 or above. -* As an optional best practice, add multiple cluster manager to your clusters. - -## Creating an Azure Cluster - -To create a cluster for your Mendix on Azure app, perform the following steps: - -1. In the Mendix Portal, in Mendix on Kubernetes Cluster Manager, click **Mendix on Azure**. -2. Connect to your Azure account by clicking **Connect Azure Account**, and then logging in with the same account that you used to purchase the Mendix on Azure offering. If required, you can also purchase an Azure offering after you log in. - - After you successfully connect the accounts, the Mendix Portal shows a list of available clusters (that is, any Azure clusters that you have already linked with Mendix), initializable clusters (that is, any clusters that you have not yet linked with Mendix), and clusters that failed to initialize for any reason. For initialized clusters, means that the all the required resources are provisioned on the cluster. For uninitialized clusters, no resources are provisioned yet. - - {{< figure src="/attachments/deployment/mx-azure/available-clusters.png" class="no-border" >}} - -3. In the Microsoft Azure portal, add a new managed Mendix on Azure application with **Standard** as the plan. - - {{< figure src="/attachments/deployment/mx-azure/create-managed-app.png" class="no-border" >}} - -4. Provide a name for the resource group. The resource group contains all the resources that must be initialized for your Mendix deployment. - - {{< figure src="/attachments/deployment/mx-azure/resource-group-name.png" class="no-border" >}} - -5. Follow the **Create** wizard to create the managed application. - -6. After the resource deployment finishes, click **Go to resource**, and then click **Mendix on Azure Portal**. - - The managed app that you created is now visible as a new initializable cluster. - - {{< figure src="/attachments/deployment/mx-azure/initializable-clusters.png" class="no-border" >}} - -7. In the **Actions** column, click the icon, and then select **Initialize**. - - The preflight check launches to verify that the required resources can be registered in the cluster. The check also validates if the Azure account used for the initialization has the Owner role. - - Mendix apps are hosted with virtual machines, so the preflight check determines whether the cluster contains the required type of virtual machine. To view a list of the required resource providers, hover your cursor over the **Information** icon. If required, you can register any missing providers in the **Resource providers** section of the Microsoft Azure portal. - - {{< figure src="/attachments/deployment/mx-azure/preflight-check.png" class="no-border" >}} - -9. In the **Preflight Check** screen, click **Next** to be redirected to the **Provision** screen. When all preflight checks are passed, the status is displayed as **Done** in the **Preflight Check** section, as in the following figure: - - {{< figure src="/attachments/deployment/mx-azure/preflight-check-successful.png" class="no-border" >}} - - The platform account check is used to validate that only one platform account is associated with the customer ID. - -10. In the **Provision** screen, add the custom tags if required and review the information in the **Advanced Options** section. If required, adjust any settings as needed. Note that selecting higher service tiers will also incur higher costs. - - You can update the following advanced options: - - * AKS Service Tier - * AKS Node VM Size - * AKS Maximum Node Count - * Load Balancer Type - * AKS Node CIDR IP Range - * AKS Network Isolated Cluster - * Managed Grafana - * Postgres Flexible Server: - - * Enable Read Replica - * Compute Tier - * Compute Size - * Storage Performance Tier - - {{% alert color="info" %}}If you plan to use [virtual network peering](#network-peering), you must set the **Load Balancer Type** to **Private (Internal)**.{{% /alert %}} - - {{% alert color="info" %}}If **Managed Grafana** is set to **False**, private access to a Grafana dashboard is required. Make sure that the required network is set up to accomodate private access.{{% /alert %}} - - {{< figure src="/attachments/deployment/mx-azure/provision-additional-option.png" class="no-border" >}} - -11. In the **Review & Initialize** screen, review the information and click **Initialize**. - - {{< figure src="/attachments/deployment/mx-azure/initializeCluster.png" class="no-border" >}} - - The initialization process takes approximately 15 minutes. It creates a resource group in the managed app that you created in step 3 above as shown below: - - {{< figure src="/attachments/deployment/mx-azure/resourceGroup.png" class="no-border" >}} - -12. Once the cluster is initialized successfully, a corresponding cluster and a namespace within it is created in the the Mendix on Kubernetes Portal. The namespace is configured automatically, as described in [Standard Operator: Running the Tool](https://docs.mendix.com/developerportal/deploy/standard-operator/#running-the-tool). - - {{% alert color="info" %}}You cannot create additional namespaces for a Mendix on Azure cluster. You also cannot use APIs to create or modify the cluster. Also, the cluster cannot be deleted from the Mendix on Kubernetes Portal or the Mendix on Azure portal. If you want to remove it, you must delete the Managed application (created in Step 3) in the Microsoft Azure portal.{{% /alert %}} - -13. Once the cluster is initialized successfully, the status of the cluster in the Portal changes to **INITIALIZED**. - -14. The Infrastructure details of the cluster can be seen in the **Details** option visible under **Actions** column. - - {{< figure src="/attachments/deployment/mx-azure/infrastructure-details.png" class="no-border" >}} - -## Rerunning Failed Clusters - -If a cluster fails for any reason, its status in the Mendix Portal changes to **Failed**. To view more information about the issue, click the icon in the **Actions** column, and then select **Details**. - -{{< figure src="/attachments/deployment/mx-azure/failed-cluster.png" class="no-border" >}} - -To fix the issue, you can click **Rerun** to manually re-run the cluster. If a cluster still fails after a manual rerun, a support ticket is automatically opened with Mendix Support. For more information, see [Support Policy for Mendix on Azure: Automatic Support Tickets](/developerportal/deploy/mendix-on-azure/support/#tickets-automatic). - -{{% alert color="warning" %}}Do not initialize a cluster while it is in a Failed status.{{% /alert %}} - -## Editing the Cluster in the Mendix on Azure Portal - -If required, you can change the following options for your cluster. The **Edit** page might take few second to open. - -* AKS Service Tier -* AKS Node VM size -* AKS Maximum Node Count -* Load balancer type -* AKS Node CIDR IP Range -* Managed Grafana -* Postgres Compute SKU -* Postgres Storage Performance Tier -* Postgres Compute Tier -* Postgres Compute Size -* Enable Read Replica - -{{< figure src="/attachments/deployment/mx-azure/editClusterPage.png" class="no-border" >}} - -## Enabling Connections Between Different Azure Resource Groups - -If your Mendix managed app is in a different Azure resource group than the user machines which must connect to it, you may need to perform additional steps to enable connections between these resource groups. - -### Example Situation - -The following diagram shows two managed resource groups. One of them contains the Mendix managed app, and the other - a user machine that must access Mendix, along with a backend virtual machine that the Mendix app must access. Connections between the two resource groups are not enabled, resulting in access issues. - -{{< figure src="/attachments/deployment/mx-azure/separate-access-groups.png" class="no-border" >}} - -#### Potential Solution 1: Virtual Network Peering {#network-peering} - -The following diagram shows one potential solution to the access issue. Bi-directional [virtual network peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview) has been configured between the two resource groups. - -{{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings.png" class="no-border" >}} - -To enable virtual network peering for your Mendix on Azure app, perform the following steps: - -1. In the Microsoft Azure portal, [add a new bi-directional virtual peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering?tabs=peering-portal). - - {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-add.png" class="no-border" >}} - -2. Create an [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone). -3. In the **Instance details** section, in the **Name** field, enter the domain of your Mendix app, for example, *azure.mendixapps.io*. - - {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-name.png" class="no-border" >}} - -4. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for the Mendix application. -5. In the **Name** field, enter the name of our Mendix app, for example, *myapp*. -6. In the **IP** field, enter the IP address of the internal load balancer. -7. Create a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links) and link it with your custom virtual network. - - Users in the other virtual network can now connect to your Mendix app. - -8. If you want to enable connections from your Mendix app to a virtual back-end machine in the other network, perform the following additional steps: - - 1. In the Azure portal, create another private DNS zone for the virtual machine, with auto-registration enabled. - 2. In the Mendix portal, in the **Environment Details** page, go to [Model Options](/developerportal/deploy/environments-details/#model-options). - 3. In the [Constants](/developerportal/deploy/environments-details/#constants) section, find and edit the **RestClient.RestServiceUrl** constant. - 4. In the **New value** field, enter the URL and port of your back-end machine, and then click **Save and Apply**. - 5. In the Azure portal, configure the virtual network link to link the private DNS zone with the virtual network of your managed Mendix application. - - Your Mendix app can now connect to a back-end server in the other virtual network. - -#### Potential Solution 2: Private Endpoints - -Another possible solution can be achieved by using [private endpoints](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview). In the following diagram, a private endpoint has been added to each resource group. The private endpoint connects to a private link in the other resource group, which in turn connects to an internal load balancer. - -{{< figure src="/attachments/deployment/mx-azure/private-endpoints.png" class="no-border" >}} - -To enable private endpoints for your Mendix on Azure app, perform the following steps: - -1. In the Microsoft Azure portal, add a new [private link](https://learn.microsoft.com/en-us/azure/private-link/private-link-overview) for the Mendix AKS load balancer. - - {{< figure src="/attachments/deployment/mx-azure/private-link.png" class="no-border" >}} - -2. Create a private endpoint in your custom resource group. -3. In the **Resource** tab, specify the following settings: - - * **Resource type** - **privateLinkServices** - * **Resource** - the private link that you created in step 1 above - -4. In the **Virtual Network** tab, specify the following settings: - - * **Virtual network** - the virtual network where the user's machine is located - -5. Configure other settings as needed. -6. Create an [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone). -7. In the **Instance details** section, in the **Name** field, enter the domain of your Mendix app, for example, *azure.mendixapps.io*. - - {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-name.png" class="no-border" >}} - -8. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for the Mendix application. -9. In the **Name** field, enter the name of our Mendix app, for example, *myapp*. -10. In the **IP** field, enter the IP address of the private endpoint. -11. Create a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links) and link it with your Mendix managed virtual network. - - Users in the other virtual network can now connect to your Mendix app. - -12. If you want to enable connections from your Mendix app to a virtual back-end machine in the other network, perform the following additional steps: - - 1. Create a load balancer that points to the back-end machine. - 2. Add a new [private link](https://learn.microsoft.com/en-us/azure/private-link/private-link-overview) for the back-end load balancer. - - Make sure to select the back-end load balancer in the **Load balancer** field of the **Outbound settings** tab. - - 3. Configure other settings as needed. - 4. Create a private endpoint in your Mendix managed resource group. - 5. In the **Resource** tab, specify the following settings: - - * **Resource type** - **privateLinkServices** - * **Resource** - the private link that you created in step 12-b above. - - 6. In the **Virtual Network** tab, specify the following settings: - - * **Virtual network** - the virtual network managed by Mendix - - 7. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for the IP address of the back-end service's private endpoint. - 8. In the Mendix portal, in the **Environment Details** page, go to [Model Options](/developerportal/deploy/environments-details/#model-options). - 9. In the [Constants](/developerportal/deploy/environments-details/#constants) section, find and edit the **RestClient.RestServiceUrl** constant. - 10. In the **New value** field, enter the URL and port of your back-end machine, and then click **Save and Apply**. - - Your Mendix app can now connect to a back-end server in the other virtual network. - -## Deploying an App to an Azure Cluster - -After creating your cluster in Microsoft Azure, you can now deploy your applications to the cluster. The deployment process is the same as with Mendix on Kubernetes. However, in order to use the Mendix on Azure Platform service, you need to have a minimum of 14 cloud tokens to create an environment. For more information, see [Deploying a Mendix App to a Mendix on Kubernetes Cluster](/developerportal/deploy/private-cloud-deploy/). - - -## Backing up and Restoring Eenvironments - -For more information about backing up and restoring Mendix on Azure environments, see [Backups in Mendix on Azure](/developerportal/deploy/mendix-on-azure/backups/). - -## Adding a New Cluster Manager - -Once the cluster is successfully created and initialized in the Mendix on the Azure portal, you can [add additional cluster managers](/developerportal/deploy/private-cloud-cluster/#managing-the-cluster). - -After being added, the new cluster manager has the ability to view and manage the cluster within the Mendix on the Azure portal. They can also access and update the support ticket associated with the cluster in the Mendix on Azure portal. However, the newly added cluster manager does not have access to the Zendesk ticket linked to the cluster's support ticket. - -{{% alert color="info" %}}Before adding a cluster manager, ensure that the invited user signs in to the Mendix on Azure portal (https://mendixonazure.mendix.com) before accepting the invitation. If they do not, the invitation may show as accepted, but the user will not have access to resources on Mendix on Azure.{{% /alert %}} - -If a cluster manager is deleted, they can no longer view the associated cluster or its support ticket in the Mendix on Azure portal. diff --git a/content/en/docs/deployment/mx-azure/mx-azure-licensing.md b/content/en/docs/deployment/mx-azure/mx-azure-licensing.md new file mode 100644 index 00000000000..2da0b05cbc2 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/mx-azure-licensing.md @@ -0,0 +1,30 @@ +--- +title: "Licensing Mendix on Azure" +url: /developerportal/deploy/mendix-on-azure/license/ +description: "Provides information about licensing Mendix on Azure." +weight: 35 +--- + +## Introduction + +Mendix on Azure is one of the deployment options for Mendix, featuring its own licensing model separate from the base Mendix platform and user fees. + +{{% alert color="info" %}} +All details below apply exclusively to Mendix on Azure charges. Licensing and user fees for the Mendix platform itself are billed separately. +{{% /alert %}} + +## Trial Period + +Mendix on Azure is available to deploy via the Azure Marketplace. While the marketplace offering itself is free to deploy, Microsoft will charge you directly for any Azure resources deployed under your organization's Azure subscription according to your agreement with Microsoft. + +For the first 120 days after creating any new app environment within your Mendix on Azure cluster, Mendix does not charge for usage of Mendix on Azure. + +## Paid Period + +After 120 days from an app environment's creation, Mendix begins charging a fixed number of [Cloud Tokens](/control-center/cloud-tokens/) per app environment (14 tokens as of 2025). If your token balance is insufficient, Mendix will contact you to arrange replenishment. + +## Frequently Asked Questions + +### Will I Still Need to Request Runtime Licenses for my Mendix Apps? + +Yes. For production environments, you must supply runtime licenses for your Mendix apps to move the Mendix Runtime out of trial mode. This licensing process aligns with how Mendix on Kubernetes works (for example, requesting and applying subscription keys). For more information, see [Licensing Apps outside Mendix Cloud](http://localhost:1313/developerportal/deploy/licensing-apps-outside-mxcloud/). diff --git a/content/en/docs/deployment/mx-azure/mx-azure-security-and-compliance.md b/content/en/docs/deployment/mx-azure/mx-azure-security-and-compliance.md new file mode 100644 index 00000000000..ad6d92e9583 --- /dev/null +++ b/content/en/docs/deployment/mx-azure/mx-azure-security-and-compliance.md @@ -0,0 +1,33 @@ +--- +title: "Security and Compliance for Mendix on Azure" +url: /developerportal/deploy/mendix-on-azure/security-and-compliance/ +weight: 20 +description: "Describes the security & compliance considerations for apps running on Mendix on Azure." +--- + +## Security and Compliance + +### Compliance Frameworks + +Every release of Mendix on Azure is automatically assessed against selected compliance frameworks using Azure Policy. Currently this asssessment is limited to SOC2, but this will be extended in future versions based on customer demand. + +#### SOC 2 Type 2 Compliance {#soc2} + +The automatic SOC2 assessment currently has identified the following compliance deviations which are accepted: + +| Policy | Acceptance Rationale | +| --- | --- | +| Azure Container Registry: [Container registries should be encrypted with a customer-managed key](https://www.azadvertizer.net/azpolicyadvertizer/5b9159ae-1701-4a6f-9a7a-aa9c8ddd0580.html) | The standard Microsoft key is used instead to ease adoption of the product. | +| AKS - cluster resource: [Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters](https://www.azadvertizer.net/azpolicyadvertizer/0a15ec92-a229-4763-bb14-0ea34a568f8d.html) | The cluster is deployed and managed by Mendix, so this policy is not needed. | +| AKS - cluster resource: [Azure Kubernetes Service clusters should have Defender profile enabled](https://www.azadvertizer.net/azpolicyadvertizer/a1840de2-8088-4ea8-b153-b4c723e9cb01.html) | This is not automated for cost-saving reasons. | +| AKS - cluster VNET: [All Internet traffic should be routed via your deployed Azure Firewall](https://www.azadvertizer.net/azpolicyadvertizer/fc5e4038-4584-4632-8c85-c0448d374b2c.html) | This is not automated, but customers can deploy their own Firewall if required. | +| Storage Account: [Storage accounts should use customer-managed key for encryption](https://www.azadvertizer.net/azpolicyadvertizer/6fac406b-40ca-413b-bf8e-0bf964659c25.html) | The cluster is deployed and managed by Mendix, so this is not needed. | + + +### Access to Customer Environments by Mendix + +Mendix accesses customer environments securely by leveraging native Azure capabilities and adhering to Microsoft's best practices: + +* Access is provided through [cross-tenant access](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview), a secure Azure-native mechanism. +* The majority of access operations are automated and performed programmatically at scale using infrastructure as code, limiting manual human intervention to exceptional cases. +* All network connectivity between Mendix and customer environments utilizes private links, ensuring communication is not exposed to the public internet. diff --git a/content/en/docs/deployment/mx-azure/mx-azure-support.md b/content/en/docs/deployment/mx-azure/mx-azure-support.md index ee41f2b1d87..b87060b5031 100644 --- a/content/en/docs/deployment/mx-azure/mx-azure-support.md +++ b/content/en/docs/deployment/mx-azure/mx-azure-support.md @@ -1,164 +1,149 @@ --- -title: "Support Policy for Mendix on Azure" +title: "Support for Mendix on Azure" url: /developerportal/deploy/mendix-on-azure/support/ description: "Provides information about the support model for Mendix on Azure." weight: 30 --- -{{% alert color="info" %}} This feature is currently available to participating customers. For more information, contact your Customer Success Manager. {{% /alert %}} +{{% alert color="info" %}} +To facilitate sharing this information with internal stakeholders, a downloadable PDF version is available [here](https://blob.mendix.technology/mxonazure/MXonAzure-Support-Policy-for-Mendix-on-Azure.pdf). If discrepancies arise between this document and the PDF, the PDF version takes precedence. +{{% /alert %}} ## Introduction -This document describes the technical support policies and limitations for Mendix on Azure, based on the shared responsibility model underlying the offering. +This document outlines the technical support policies and limitations for Mendix on Azure, based on the shared responsibility model that underpins the offering. -{{% alert color="info" %}}Before you begin, familiarize yourself with the general Mendix support policies, as outlined in [Mendix Support](/support/).{{% /alert %}} +{{% alert color="info" %}} +Before proceeding, familiarize yourself with the general Mendix support policies available in [Mendix Support](/support/). +{{% /alert %}} ## Shared Responsibility Model for Mendix on Azure -Under the shared responsibility model for Mendix on Azure deployments, Mendix, Microsoft, and customer organizations all have their own responsibilities in the deployment process and business-as-usual operations. Familiarize yourself with the responsibilities listed below: +Mendix on Azure deployments follow a shared responsibility model where Mendix, Microsoft, and customers have distinct roles throughout deployment and ongoing operations. Below are the key responsibilities: ### Microsoft Responsibilities -Microsoft is responsible for operating and securing the Azure services underlying the Mendix on Azure service. This includes the following services: - -* Compute - * Azure Kubernetes service -* Storage - * Azure Blob Storage - * Azure Container Registry -* Database - * PostgreSQL Flexible Server -* Networking - * Virtual networks - * Load balancer - * Private endpoints -* Monitoring - * Managed Grafana and Prometheus +Microsoft manages and secures the Azure services that underlie Mendix on Azure. This includes: + +* Compute - Azure Kubernetes Service (AKS) +* Storage - Azure Blob Storage, Azure Container Registry +* Database - PostgreSQL Flexible Server +* Networking - Virtual Networks, Load Balancer, Private Endpoints +* Monitoring - Managed Grafana and Prometheus ### Mendix Responsibilities -Mendix is responsible for orchestrating, operating, maintaining, securing, and supporting the Mendix on Azure service. This includes the following tasks: +Mendix is responsible for orchestrating, operating, maintaining, securing, and supporting the Mendix on Azure service, including: -* Orchestrating - Ensure that the underlying Azure services function together as one cohesive offering. -* Operating - Resolve regressions in how the underlying Azure services come together as one service. -* Maintaining - Ensure that the service absorbs changes in the underlying Azure services without impact on customers. -* Securing - Ensure that the service remains compliant with relevant security best practices and frameworks. -* Supporting - Reactively address customer issues with using the service. +* Orchestrating - Ensuring Azure services work cohesively as a single offering +* Operating - Fixing regressions in service integration +* Maintaining - Adapting to Azure service changes without affecting customers +* Securing - Maintaining compliance with security best practices and frameworks +* Supporting - Reactively resolving customer issues with the service ### Customer Responsibilities -Customers are responsible for developing, deploying, operating, integrating, and securing apps on top of the Mendix on Azure service. This includes the following tasks: +Customers are accountable for developing, deploying, operating, integrating, and securing Mendix applications running on Mendix on Azure, including: -* Developing - Create apps that deliver business outcomes. -* Deploying - Deploy apps. -* Operating - Monitor app behavior and address deviations. -* Integrating - Securely integrate apps with backend services and IAM. -* Securing - Comply with Mendix best practices for secure apps. +* Developing - Building apps that achieve business goals +* Deploying - Deploying applications +* Operating - Monitoring app behavior and addressing issues +* Integrating - Securing integrations with backend services and IAM +* Securing - Following Mendix best practices for secure apps ## Available Customizations -When a Mendix on Azure cluster is initialized, all components that are required to host Mendix apps are automatically deployed inside an Azure Resource group of your choosing. Mendix and Microsoft regularly push all required updates to your cluster to ensure that it remains compliant and secure. - -Because the updates are automated for all Mendix on Azure customers, you cannot modify any of these components directly in Azure. You also cannot influence the upgrade process. Because of that, you can only implement customizations that are offered in the Mendix on Azure and Mendix on Kubernetes portals. Currently this includes the following customizations: +During cluster initialization, all components needed to host Mendix apps are deployed automatically inside an Azure Resource Group you select. Mendix and Microsoft regularly apply mandatory automated updates to keep clusters compliant and secure. -* Adding custom tags to Azure resources -* Changing the Azure Kubernetes Service tier -* Changing the Azure Kubernetes agent node VM type -* Overriding the maximum AKS agent node pool (upper autoscaling limit) -* Changing the Azure for PostgreSQL Flexible server computing SKU and storage performance tier -* Switching to internal load balancer exposure to enable apps that can only be reached privately -* Changing IP address prefix of the subnet hosting AKS nodes (only at initial deployment) +Due to this automation, direct modification of these components in Azure or control over the upgrade process is not possible. Customizations are limited to options exposed via the Mendix on Azure, Microsoft Azure, and Mendix on Kubernetes portals. Current allowed customizations include those documented in the [Configuration section](/developerportal/deploy/mendix-on-azure/configuration/). -Any customization beyond what is offered as self-service through the Mendix on Azure and Mendix on Kubernetes portal is not possible. +Any modifications outside this documented scope are not supported. ## Support Tickets -Since your Mendix on Azure resources contain private and sensitive data, Mendix Support cannot access your resources. To be able to troubleshoot incidents on your behalf, the Mendix on Azure portal allows you to raise a support ticket that includes recent logs for your environment, as well as provide consent to Mendix personnel for accessing your resources temporarily while processing your support ticket. +Since Mendix on Azure resources contain sensitive data, Mendix Support does not have direct access. To enable effective troubleshooting, you can create support tickets through the Mendix on Azure portal, which automatically include recent logs. ### Raising Support Tickets -To raise a support ticket, press **Support Center** on the **Cluster Overview** page, as shown in the following figure: +To raise a support ticket, perform the following steps: -{{< figure src="/attachments/deployment/mx-azure/support-center-option.png" class="no-border" >}} +1. Open the [Mendix on Azure Portal](https://mendixonazure.mendix.com) +2. On the **Cluster Overview** page, select **Support Center** -This opens the **Support Tickets** page, which shows your current and past support issues. To open a new ticket, click **Open a Ticket** and fill out the required information. + {{< figure src="/attachments/deployment/mx-azure/support-center-option.png" class="no-border" >}} + +3. On the **Support Tickets** page, click **Open a Ticket** and complete the form. The page also shows your existing tickets. {{% alert color="info" %}} -By opening a support ticket, you consent to sharing the relevant logs with the Mendix Support team for the purpose of troubleshooting the reported issue. +By submitting a support ticket, you consent to sharing the pertinent logs with the Mendix Support team to assist in issue resolution. {{% /alert %}} -When you create a support ticket in the Mendix on Azure portal, a Zendesk ticket is automatically created for you. To view it, click **Go to ticket**. You can then add additional comments on the Zendesk ticket if required. +After submitting, a Zendesk ticket is automatically created. Access it by clicking **Go to ticket** to add comments or check status. {{< figure src="/attachments/deployment/mx-azure/support-overview.png" class="no-border" >}} -Your tickets can have the following statuses: +#### Ticket Statuses + +Ticket statuses include: -* **On Hold** -* **Awaiting your reply** +* **On Hold** +* **Awaiting your reply** * **Solved** -The status is updated based on the current status of the ticket in the Zendesk. To see the latest status of the ticket, click the **Refresh** button. +Status updates reflect the current Zendesk ticket state. Refresh the page to view the latest status. {{% alert color="info" %}} -If you delete a cluster, all support tickets opened for that cluster are also deleted. +If you offboard your Mendix on Azure cluster, all related support tickets will be deleted. For more information, see [offboarding](/developerportal/deploy/mendix-on-azure/offboarding/). {{% /alert %}} ### Automatic Support Tickets {#tickets-automatic} -Mendix on Azure can also automatically create support tickets for you. If a cluster fails to initialize and rerunning it manually does not resolve the issue, a support request is automatically created in the Support Center. Mendix Support is notified about the issue through Zendesk. You can follow the link from the support ticket to Zendesk to view its status or add additional comments. +If cluster initialization fails and manual retries do not resolve the issue, Mendix on Azure automatically creates a support ticket. Mendix Support is notified and will reach out to you. You can follow ticket progress or add comments via Zendesk. ## Service Updates and Releases -All components in Mendix on Azure are managed and are upgraded to newly available versions on a quarterly basis by Mendix and Microsoft. Mendix conducts pro-active regression testing to ensure the updated set of components keep working well together. +Mendix and Microsoft manage all components, applying upgrades quarterly with proactive regression testing to ensure stability. -All node-level OS components in Mendix on Azure receive weekly security patches (as per Microsoft's NodeImage auto-upgrade Node OS upgrade channel). In case critical security patches are found in the Mendix components running in your cluster (i.e. Operator and Agent) these will be patched as soon as possible (but at the end of the quarter latest). +Node-level OS components receive weekly security patches through Microsoft's NodeImage auto-upgrade process. Critical security patches for Mendix components (e.g., Operator, Agent) are applied promptly but no later than quarter-end. -These quarterly and weekly upgrade cadences are fully automatic and cannot be influenced by the customer. +These automated upgrade cadences cannot be modified by customers. -## Mendix Support Coverage +## Mendix Support Coverage Examples -Mendix provides technical support for the following example scenarios: +The following scenarios are supported: -* Cluster initialization fails despite passing pre-flight validation checks. -* The customer is impacted by issues with service availability and is unable to recover the situation using the self-service recovery option. +* Cluster initialization fails despite passing pre-flight checks. +* Service availability issues are not resolvable through self-service recovery. -Mendix does not provide technical support in the following example scenarios: +The following scenarios are not supported: -* Requests about how to integrate with other Azure Services that are beyond the scope of the product. Such requests can be supported by Mendix Expert Services or Mendix (infra) partners as part of (paid) consultancy engagements. -* Requests to make configuration changes to underlying Azure services beyond what is offered as self-service in the Mendix on Azure and Mendix on Kubernetes Portal. Since such changes are not possible with this service, customer may consider to adopt Mendix on Kubernetes instead. -* Requests for any other type of customization on the resources deployed in customer's Azure subscription. Since such customization is not possible with this service, customer may consider to adopt Mendix on Kubernetes instead. -* Requests to fix security vulnerabilities in one of the managed components beyond what is automatically pushed during the weekly and quarterly update cycles. +* Consultations on integrations with other Azure services outside the Mendix on Azure scope; consider Mendix Expert Services or partners for consultancy. +* Configuration changes to Azure services beyond self-service options; Mendix on Kubernetes may offer more flexibility. +* Customizations to Azure subscription resources beyond the supported scope. +* Manual fixes for security vulnerabilities beyond the automated update cycles. ## Customer Responsibilities for Mendix on Azure Resources -The customer is responsible for optionally integrating the solution with the rest of their internal network (for example, to access backend services) by correctly configuring VNet Peerings, routing tables and DNS name resolution as per documentation. - -The customer is responsible for reporting service availability issues to Mendix in the case these cannot be resolved using self-service options. +Customers must manage integration with internal networks by properly configuring VNet Peerings, routing, and DNS as documented. -If the customer chooses to deploy the solution into a network that limits egress, it is the customer's responsibility that appropriate egress exceptions are made for the underlying Azure services (particularly AKS). +Customers should report service availability issues to Mendix if self-service options do not resolve them. ## Issues and Bugs in Underlying Azure Services -Because Mendix on Azure relies on several rapidly evolving underlying Azure services (especially AKS), bugs and issues may arise in those services. Some of these limitations and bugs cannot be worked around within Mendix on Azure itself, but must be fixed in the underlying Azure services. +Mendix on Azure depends on evolving Azure services (notably AKS). Some bugs may require upstream fixes beyond Mendix control. -Mendix strives to minimize the impact of such bugs and issues for our customers in the following ways: +Mendix mitigates these impacts by: -* By conducting quarterly testing to detect regressions early and work around them to the degree that we can. -* By working with Microsoft Support and engineering teams in case a bug or issue needs to be resolved upstream. -* By communicating to our customers why an upstream bug or issue affects their Mendix on Azure cluster, and providing workarounds where possible. +* Quarterly regression testing and workarounds where feasible +* Collaboration with Microsoft Support and engineering for upstream fixes +* Transparent communication and guidance on workarounds for affected customers ## Compliance Frameworks -The solution is being benchmarked against SOC2 Azure Policy Compliance controls. Security highlights include the following: - -* Deploys a managed Mendix environment within the customer's Azure subscription. -* Incorporates built-in security features and adheres to Azure Best Practices. -* Utilizes reporting tools to prove compliance. - -There are some exceptions; for more information, see [SOC 2 Type 2 Compliance Exceptions](https://docs.mendix.com/developerportal/deploy/mendix-on-azure/#soc-2-type-2-compliance-exceptions). +Mendix on Azure aligns with SOC 2 Azure Policy automated controls. For more information, see [SOC 2 Type 2 Compliance Exceptions](/developerportal/deploy/mendix-on-azure/security-and-compliance/#soc2). ## Known Limitations -* Mendix on Azure only supports hosting apps on Mendix versions 10.10 or later. Any app on an earlier version will fail to deploy successfully. -* Due to the managed nature of this product, the following Mendix on Kubernetes Deploy APIs are irrelevant and thus unavailable to customers: Create/Edit/Delete cluster and Create/Update/Delete namespace. All other build and deploy APIs are available and function as usual. -* Because Mendix on Azure is directly dependent on Mendix on Kubernetes, issues that affect the Mendix on Kubernetes may also affect Mendix on Azure deployments. For example, if the Mendix on Kubernetes is down, it is not possible to create new Mendix on Azure clusters. +* Only apps on Mendix version 10.10 or later are supported; deployment for earlier versions will fail. +* Certain Mendix on Kubernetes APIs (Create, Edit, or Delete cluster and namespace operations) are unavailable in Mendix on Azure due to managed architecture. Other APIs function normally. +* Downtime or issues with Mendix on Kubernetes may affect Mendix on Azure availability (for example, cluster creation may notbe possible). diff --git a/content/en/docs/deployment/mx-azure/read-replica-database-access.md b/content/en/docs/deployment/mx-azure/read-replica-database-access.md deleted file mode 100644 index d1e6eef8846..00000000000 --- a/content/en/docs/deployment/mx-azure/read-replica-database-access.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: "Read Replicas for Postgres Databases" -url: /developerportal/deploy/mendix-on-azure/read-replica-database-access/ -description: "Provides details about the read replica for Postgres databases." -weight: 30 ---- - -## Introduction - -This document describes how you can enable read replicas for the Postgres database and provides examples on how to read data from the read replica database. The read replica is the database instance holding the Mendix app databases. - -### What is a Read Replica and Why Is It Needed? - -Read replicas are synchronized copies of the primary database. They are commonly used to serve read-only queries, reducing load on the primary database by separating reads from writes. - -In the case of Mendix on Azure, read queries still go to the primary database, but the read replica is created specifically to give customers secure, read-only access to the data. This feature is particularly useful for data ingestion (data lake) purposes, and when the customer needs to have read-only access to Mendix app data in a secure manner that does not impact app performance. - -## Prerequisites - -Before you begin, make sure to fulfill the following prerequisites: - -* Refer to Postgres documentation to familiarize yourself concepts related to read replicas and VNet peering. -* Ensure that your Postgres database has the **General Purpose** or **Memory Optimized** compute tier settings. - -## Enabling Read Replicas in the Mendix on Azure Portal - -By default, the read replica for Postgres database is disabled. To enable it, perform the following steps: - -1. On the **Provision > Database Settings** section of the **Initialize Cluster** page, set the **Enable Read Replica** option to **Yes**. - -{{% alert color="info" %}}You can also update, enable, or disable the read replica in the **Edit Cluster** flow.{{% /alert %}} - -2. Click **Next** to initialize the cluster. - - {{< figure src="/attachments/deployment/mx-azure/enableReadReplica.png" class="no-border" >}} - - After the cluster is initialized, the read replica for Postgres database is enabled, and a read replica for the Postgres database is created in the managed cluster. - - {{< figure src="/attachments/deployment/mx-azure/readReplicaEnabled.png" class="no-border" >}} - -3. Copy the address value from the record set within the private DNS zone created for your Postgres database. - - {{< figure src="/attachments/deployment/mx-azure/copyAddressValue.png" class="no-border" >}} - -4. Add the users who should be able to access the replica database by performing the following steps: - - 1. In the Azure portal, go to the resource group where you created the managed app. - 2. Under the resource group, go to the managed resource group and click on the Postgres master database resource. - 3. Go to **Security > Authentication** - 4. Add a Microsoft Entra administrator. - - {{< figure src="/attachments/deployment/mx-azure/adduser.png" class="no-border" >}} - -{{% alert color="info" %}}Do not delete the existing ServicePrincipal user.{{% /alert %}} - -## Enabling Virtual Network Peering - -VNet peering to the Mendix on Azure vNet is required to access the database. It enables connections between two virtual networks (VNets) so resources can talk to each other using private IPs. If you have not already configured VNet peering, you should do it now. - -The following diagram shows one potential solution to the access issue. Bi-directional [virtual network peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview) has been configured between the two resource groups. - -{{< figure src="/attachments/deployment/mx-azure/vnetpeeringreadReplicaEnabled.png" class="no-border" >}} - -To enable virtual network peering for your Mendix on Azure app, perform the following steps: - -1. In the Microsoft Azure portal, [add a new bi-directional virtual peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering?tabs=peering-portal) in the resource group where your Mendix app is deployed. - - {{< figure src="/attachments/deployment/mx-azure/virtual-network-peerings-add.png" class="no-border" >}} - -2. Create a [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone) in another resource group from where you need to connect to the replica database. Private DNS zone resolves domain names in a Postgres read replica to a private IP addresses. -3. In the **Instance details** section, in the **Name** field, enter the domain of your Mendix app, for example, *azure.mendixapps.io*. -4. Create a [DNS record](https://learn.microsoft.com/en-us/azure/dns/dns-operations-recordsets-portal) for the Mendix application. The record set maps a host name to a private IP. - - 1. In the **Name** field, enter the name of our Mendix app, for example, *myapp*. - 2. In the **IP** field, enter the IP address of the read replica. Refer to the value of the record set in step 3 above. - 3. Create a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links) to connect the Postgres database's private DNS zone with your custom virtual network. This enables seamless name resolution within your VNet. - -Users in the other virtual network can now connect to your Mendix app. diff --git a/content/en/docs/releasenotes/deployment/mendix-azure.md b/content/en/docs/releasenotes/deployment/mendix-azure.md index 888ef0774ef..2783aa80065 100644 --- a/content/en/docs/releasenotes/deployment/mendix-azure.md +++ b/content/en/docs/releasenotes/deployment/mendix-azure.md @@ -18,17 +18,17 @@ For information on the current status of Mendix deployment, see [Mendix Status]( * We have added a new preflight check in Cluster Initialization flow to validate that only one platform account should be used to initialize the cluster. * Mendix on Azure users can now upload and download environment backups through Mendix on Kubernetes Portal. For more information, see [Backups in Mendix on Azure](/developerportal/deploy/mendix-on-azure/backups/). * We have added a new feature which performs automatic nightly, weekly, or monthly backups of the environment. For more information, see [Backups in Mendix on Azure](/developerportal/deploy/mendix-on-azure/backups/). -* [Cloud tokens](/control-center/cloud-tokens//) are now required for environment creation in Mendix on Azure after the trial period (120 days). +* [Cloud tokens](/control-center/cloud-tokens/) are now consumed by environments which have been created more than 120 days ago. This effectively means that after the first 120 days (4 months) after app environment creation, Mendix starts charging for the use of Mendix on Azure via Cloud Tokens. In case insufficient Cloud Tokens are available, the customer will be contacted by Mendix. ### Release date: October 16, 2025 -* After being added to a [Mendix on Azure](/developerportal/deploy/mendix-on-azure/) cluster in the Mendix on Kubernetes Portal, a [cluster manager](/developerportal/deploy/mendix-on-azure/installation/#adding-a-new-cluster-manager) can now view and edit the cluster from the Mendix on Azure Portal. +* After being added to a [Mendix on Azure](/developerportal/deploy/mendix-on-azure/) cluster in the Mendix on Kubernetes Portal, a [cluster manager](/developerportal/deploy/mendix-on-azure/configuration/#cluster-manager) can now view and edit the cluster from the Mendix on Azure Portal. * We have resolved the validation error for PostgreSQL tiers that occurred when enabling Read replicas on existing clusters. ### Release date: September 25, 2025 * In order to ensure app availability during infrastructure upgrades, the number of default replicas for newly created Mendix apps is set to 2. -* To provide greater flexibility in data access, we have added a new feature that allows you to **Enable Read Replica Database access** when creating new clusters. Please note that this feature is set to **No** (disabled) by default. For details on how to enable it, see [Read Replicas for Postgres Databases](/developerportal/deploy/mendix-on-azure/read-replica-database-access/). +* To provide greater flexibility in data access, we have added a new feature that allows you to **Enable Read Replica Database access** when creating new clusters. Please note that this feature is set to **No** (disabled) by default. For details on how to enable it, see [Direct App Database Access](/developerportal/deploy/mendix-on-azure/configuration/direct-database-access/). * We have improved the labels on the default Grafana dashboard to better reflect the metrics being displayed. * We have fixed an issue where support tickets created by users were not visible to other users in the same subscription. * We have rephrased some wording and updated the structure on the **Initialize Cluster** and **Edit Cluster** pages for better readability and understanding. diff --git a/static/attachments/deployment/mx-azure/deletepopup.png b/static/attachments/deployment/mx-azure/deletepopup.png new file mode 100644 index 00000000000..902a2c08f96 Binary files /dev/null and b/static/attachments/deployment/mx-azure/deletepopup.png differ diff --git a/static/attachments/deployment/mx-azure/mrg.png b/static/attachments/deployment/mx-azure/mrg.png new file mode 100644 index 00000000000..18776db2a01 Binary files /dev/null and b/static/attachments/deployment/mx-azure/mrg.png differ