diff --git a/content/en/docs/deployment/docker-deploy/_index.md b/content/en/docs/deployment/docker-deploy/_index.md index 985b27740ae..cb94ccfc424 100644 --- a/content/en/docs/deployment/docker-deploy/_index.md +++ b/content/en/docs/deployment/docker-deploy/_index.md @@ -1,73 +1,26 @@ --- title: "Docker" -url: /developerportal/deploy/docker-deploy/ +url: /developerportal/deploy/docker/ weight: 60 -description: "Describes how to deploy using a Docker image." -#If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details. +description: "Describes how to deploy your Mendix app to a Docker environment." +no_list: false +description_list: true --- ## Introduction -Docker is an open source container technology. With Mendix, you can use it for simple deployments, particularly when running local or development versions of your app. However, it lacks some scaling and integration features. +This section describes how to deploy your Mendix app to a Docker environment. -The Docker Buildpack simplifies the creation of Docker images locally, but it falls short in terms of running, managing, and operating them effectively compared to the capabilities offered by Mendix on Kubernetes. Leveraging Mendix on Kubernetes means entrusting the Mendix Operator to automate these essential tasks whenever Kubernetes handles your containers. The following diagram illustrates the disparity between Docker Buildpack and Mendix Operator: +## Docker Deployment Options -{{< figure src="/attachments/deployment/docker-deploy/dockerbuildpack-vs-mxoperator.png" class="no-border" >}} +Mendix offers two options for Docker deployments: Portable App Distribution or the Docker Buildpack. -{{% alert color="info" %}} -Mendix suggests that, if you are planning to deploy to your own cloud platform at scale, a better solution for production apps is to use [Mendix on Kubernetes](/developerportal/deploy/private-cloud/). This provides you with structured and tested solutions for integrating with your own cloud infrastructure using comprehensive, automated, native functions, avoiding the need to create your own processes from scratch. -{{% /alert %}} +### Portable App Distribution -This page explains how to build a Docker image from your Mendix App. Every time you make changes to your app, you must create a new Docker image that can be pushed through the different stages of your application pipeline. +[Portable App Distribution](/developerportal/deploy/portable-app-distribution-deploy/) allows users to generate their portable app with a single MxBuild command. It requires fewer manual steps than the Docker Buildpack, simpler environment configuration, and no `rootfs` preparation. Running Portable App Distribution can take as little as 3-6 minutes (the time may vary based on the application's size and complexity). -This how-to teaches you how to do the following: +### Docker Buildpack -* Build the image -* Push the image to a registry +The Docker Buildpack offers custom `rootfs` configuration, but requires multiple build steps, a more complex setup process, and a longer total build time (at least 14-25 minutes). -## Prerequisites - -Before starting these instructions, make sure you have completed the following prerequisites: - -* Download the latest version of [Mendix Studio Pro](https://marketplace.mendix.com/link/studiopro/) from the *Mendix Marketplace* -* Install Docker from the [Docker site](https://docs.docker.com/engine/installation/) -* Download the [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) - -## Building the Image - -To build the Docker image, follow these steps: - -1. Install Docker on your computer. -2. Restart the computer to ensure that you have been granted access to Docker. -3. Unzip the buildpack into a location of your choice. -4. Open the **Command Prompt** and navigate to the folder where you unzipped the buildpack. -5. Open your app in Studio Pro and select the menu option **App** > **Show App Directory in Explorer**: - - {{< figure src="/attachments/deployment/docker-deploy/create-deployment-package.png" class="no-border" >}} - -6. Copy the project folder and all its subfolders to the unzipped docker build folder. The project folder needs to be in the same folder as the Docker file, otherwise Docker cannot access it. -7. Execute the following command: - - ```bash - docker build --build-arg BUILD_PATH="{relative-mendix-project-location}" -t {image name} . - ``` - - **{relative-mendix-project-location}** is the BUILD_PATH which indicates where the application model is located. It is the directory where your .MPR file is located after you copied the project into the docker build folder. If you do not specify it, it defaults to `./project`. - - A successful build will resemble the output shown below: - - {{< figure src="/attachments/deployment/docker-deploy/build-image.png" class="no-border" >}} - -{{% alert color="info" %}} -You can find much more information and links to relevant Docker documentation in the [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) GitHub repository. -{{% /alert %}} - -## Pushing the Image - -A new Docker image has been created with the name (`{image name}`) you gave it. You can see the image by using the command `docker images`. - -Next, you need to push the image to a registry. This can be a public registry or your own. To push it to your own registry, use the command `docker push {image name}`. - -## Read More - -* [How to Run a Mendix Docker Image](/developerportal/deploy/run-mendix-docker-image/) +## Documents in This Section diff --git a/content/en/docs/deployment/docker-deploy/docker-buildpack.md b/content/en/docs/deployment/docker-deploy/docker-buildpack.md new file mode 100644 index 00000000000..1015d62c22b --- /dev/null +++ b/content/en/docs/deployment/docker-deploy/docker-buildpack.md @@ -0,0 +1,88 @@ +--- +title: "Docker Buildpack" +url: /developerportal/deploy/docker-deploy/ +weight: 60 +description: "Describes how to deploy using a Docker image using a Docker Buildpack." +#If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details. +--- + +## Introduction + +This page explains how to build a Docker image from your Mendix App using a Docker buildpack. Every time you make changes to your app, you must create a new Docker image that can be pushed through the different stages of your application pipeline. + +This how-to teaches you how to do the following: + +* Build the image +* Push the image to a registry + +## Prerequisites + +Before starting these instructions, make sure you have completed the following prerequisites: + +* Download the latest version of [Mendix Studio Pro](https://marketplace.mendix.com/link/studiopro/) from the *Mendix Marketplace* +* Install Docker from the [Docker site](https://docs.docker.com/engine/installation/) +* Download the [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) + +## Compatibility + +Mendix is compatible with Docker hosts as long as there are compatible database services like PostgreSQL, RDS, or Azure SQL. External file store support can be set up with Amazon S3 or Azure Blob store. + +## Building the Image + +To build the Docker image, follow these steps: + +1. Install Docker on your computer. +2. Restart the computer to ensure that you have been granted access to Docker. +3. Unzip the buildpack into a location of your choice. +4. Open the **Command Prompt** and navigate to the folder where you unzipped the buildpack. +5. Open your app in Studio Pro and select the menu option **App** > **Show App Directory in Explorer**: + + {{< figure src="/attachments/deployment/docker-deploy/create-deployment-package.png" class="no-border" >}} + +6. Copy the project folder and all its subfolders to the unzipped docker build folder. The project folder needs to be in the same folder as the Docker file, otherwise Docker cannot access it. +7. Execute the following command: + + ```bash + docker build --build-arg BUILD_PATH="{relative-mendix-project-location}" -t {image name} . + ``` + + **{relative-mendix-project-location}** is the BUILD_PATH which indicates where the application model is located. It is the directory where your .MPR file is located after you copied the project into the docker build folder. If you do not specify it, it defaults to `./project`. + + A successful build will resemble the output shown below: + + {{< figure src="/attachments/deployment/docker-deploy/build-image.png" class="no-border" >}} + +{{% alert color="info" %}} +You can find much more information and links to relevant Docker documentation in the [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) GitHub repository. +{{% /alert %}} + +## Pushing the Image + +A new Docker image has been created with the name (`{image name}`) you gave it. You can see the image by using the command `docker images`. + +Next, you need to push the image to a registry. This can be a public registry or your own. To push it to your own registry, use the command `docker push {image name}`. + +## Running the Mendix Docker Image + +To start the container, you must provide the container with the password in order to create an administrative account for your Mendix application's `ADMIN_PASSWORD` +and `DATABASE_ENDPOINT`, as you can see in this example: + +```shell +docker run -it \ + -e ADMIN_PASSWORD=Password1! \ + -e DATABASE_ENDPOINT=postgres://username:password@host:port/mendix \ + mendix/mendix-buildpack:v1.2 +``` + +This is an example for Microsoft SQL Server: + +```powershell +docker run -it \ + -e ADMIN_PASSWORD=Password1! \ + -e DATABASE_ENDPOINT=sqlserver://username:password@host:port/mendix \ + mendix/mendix-buildpack:v1.2 +``` + +## Read More + +* [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) diff --git a/content/en/docs/deployment/docker-deploy/docker-pad.md b/content/en/docs/deployment/docker-deploy/docker-pad.md new file mode 100644 index 00000000000..7f028b4d449 --- /dev/null +++ b/content/en/docs/deployment/docker-deploy/docker-pad.md @@ -0,0 +1,119 @@ +--- +title: "Portable App Distribution for Docker" +url: /developerportal/deploy/docker-deploy-pad/ +weight: 20 +description: "Describes how to deploy using a Docker image by using Portable App Distribution." +--- + +## Introduction + +This guide provides a walkthrough for deploying your Mendix application using [Portable App Distribution](/developerportal/deploy/portable-app-distribution-deploy/) with Docker. This approach is particularly useful for containerized environments, and can significantly ease your CI/CD setup. + +{{% alert color="info" %}} +This document is not an official Mendix implementation, or a substitute for recommended production deployment strategies. For more features, such as app management or governance, we suggest using [Mendix on Kubernetes](/developerportal/deploy/private-cloud/) or [Mendix on Azure](/developerportal/deploy/mendix-on-azure/), which offer a structured, tested experience with cloud infrastructure. + +For information about the scope of support, see [Support for Different Deployment Strategies](/support/deployment-strategy-support/). +{{% /alert %}} + +## Benefits of Portable App Distribution + +Portable App Distribution revolutionizes the way in which Mendix applications are packaged and delivered. This innovative approach bundles your application code with all its necessary dependencies into a single, self-contained, and runnable artifact. This greatly simplifies the deployment of Mendix applications, whether you are targeting on-premise infrastructure or modern containerized environments like Docker, making the entire process more efficient and seamless. + +The ability to generate a Portable App Distribution with a single build command means that creating a Docker-ready artifact becomes a streamlined process, making the overall integration into existing Docker-based CI/CD pipelines more efficient and less prone to errors. + +Portable App Distribution offers a more agile, user-centric, and efficient deployment ecosystem, empowering customers with greater control over their Docker deployments and simplifying the internal deployment processes. + +## Deploying an App with Portable App Distribution + +The Portable App Distribution feature in Mendix Studio Pro provides you with the necessary application files to build a Docker image. It packages your Mendix application as a self-contained distribution, ready for integration into your Docker environment. + +To deploy your app to Docker, perform the following steps: + +1. Generate the application files. For more information, see [Portable App Distribution](/developerportal/deploy/portable-app-distribution-deploy/). + + These files are the core of your Mendix application and are ready to be included in a Docker image. + + The following is an example *Dockerfile* that incorporates them. You must create this Dockerfile yourself and place it alongside the application files generated by the Portable App Distribution. The `COPY` commands in the example below assumes that the `app`, `bin`, `etc`, and `lib` directories are in the same location as your Dockerfile. + + ```text + # This file provides an example on how to start the runtime in Docker. + # It is based on the configuration named Default. + + FROM eclipse-temurin:21-jdk + + # Set working directory + WORKDIR /mendix + + # Copy Mendix app files into the image + COPY ./app ./app + COPY ./bin ./bin + COPY ./etc ./etc + COPY ./lib ./lib + + # Environment variables (optional) + ENV MX_LOG_LEVEL=info + ENV M2EE_ADMIN_PASS=${M2EE_ADMIN_PASS} + + # Expose ports + EXPOSE 8090 + EXPOSE 8080 + + # Start command + CMD ["./bin/start", "etc/Default"] + ``` + +2. Build the Docker image by running a command like the following: `docker build -t mx/project:latest -f build/docker/Dockerfile`, where: + + * `-t mx/project:latest` - Tags your image as `mx/project` with the label `latest`. You can customize this to your project's name and version. + + * `-f build/docker/Dockerfile` - Specifies the path to your Dockerfile. + +3. Start your Mendix application in a Docker container by running a command like the following: `docker run --rm -it -p 8080:8080 -e M2EE_ADMIN_PASS= mx/project:latest`, where: + + * `--rm` - Automatically removes the container when it exits. + * `-it` - Runs the container in interactive mode and allocates a pseudo-TTY. + * `-p 8080:8080` - Maps port 8080 on your host machine to port 8080 inside the container, allowing you to access your app. + * `-e M2EE_ADMIN_PASS=` - Ensure that you set your admin password here. + * `mx/project:latest` - Refers to the image that you built. + +You can view your running Mendix application at `localhost:8080`. To stop the application, press **Ctrl-C** in your terminal. + +## Docker Compose for Multi-Container Setups + +For more complex setups involving multiple Docker containers, or for simpler local testing purposes, you can use Docker Compose. It allows you to define and run multi-container Docker applications. + +The following is an example of a *docker-compose.yaml* file that sets up your Mendix application with an HSQLDB for local testing. This example assumes you have the Portable App Distribution files (`app`, `bin`, `etc`, `lib`) in a parent directory relative to your *docker-compose.yaml* file. + +```yaml +# This file provides an example on how to start the runtime with HSQLDB. +# This setup is intended for local testing only. +# It is based on the configuration named Default. + +services: + mendix-app: + image: eclipse-temurin:21-jdk + container_name: mendix-app + working_dir: /mendix + volumes: + - ../app:/mendix/app + - ../bin:/mendix/bin + - ../etc:/mendix/etc + - ../lib:/mendix/lib + environment: + - MX_LOG_LEVEL=info + - M2EE_ADMIN_PASS=${M2EE_ADMIN_PASS} + ports: + - "8090:8090" + - "8080:8080" + command: ["./bin/start", "etc/Default"] +``` + +### Running with Docker Compose + +To use this Docker Compose configuration, perform the following steps: + +1. Set your admin port password in the **M2EE_ADMIN_PASS** variable within your environment, or directly in the *docker-compose.yaml* file. +2. Navigate to the directory containing your *docker-compose.yaml* file +3. Run a command like the following: `docker compose -f docker_compose/Default.yaml up` + +This example assumes that your configuration is named Default. \ No newline at end of file diff --git a/content/en/docs/deployment/docker-deploy/run-mendix-docker-image.md b/content/en/docs/deployment/docker-deploy/run-mendix-docker-image.md deleted file mode 100644 index f50a25ea402..00000000000 --- a/content/en/docs/deployment/docker-deploy/run-mendix-docker-image.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Run a Mendix Docker Image" -linktitle: "Run Docker Image" -url: /developerportal/deploy/run-mendix-docker-image/ -weight: 10 -description: "Describes running a Mendix Docker image." -#To update these screenshots, you can log in with credentials detailed in How to Update Screenshots Using Team Apps. ---- - -## Introduction - -Docker is an open source container technology that is used broadly in the market in highly scalable solutions and automated delivery pipelines (CI/CD). - -This how-to explains how to run a Mendix Docker image created using the Mendix Docker Buildpack. A Mendix Docker image is uniquely created for each release of a project using this buildpack. To run the Docker image, you need access to a Docker orchestration platform. See [System Requirements](/refguide/system-requirements/) for official supported orchestration platforms. - -This how-to teaches you how to do the following: - -* Check for compatibility -* Run the Mendix Docker image - -## Prerequisites - -Before starting this how-to, make sure you have completed the following prerequisites: - -* Build an image with the Mendix buildpack (for details, see [Docker: Deploy](/developerportal/deploy/docker-deploy/)) - -## Compatibility - -Mendix is compatible with the above Docker hosts as long as there are compatible database services like PostgreSQL, RDS, or Azure SQL. External file store support can be set up with Amazon S3 or Azure Blob store. - -## Running the Mendix Docker Image - -To start the container, you must provide the container with the password in order to create an administrative account for your Mendix application's `ADMIN_PASSWORD` -and `DATABASE_ENDPOINT`, as you can see in this example: - -```shell -docker run -it \ - -e ADMIN_PASSWORD=Password1! \ - -e DATABASE_ENDPOINT=postgres://username:password@host:port/mendix \ - mendix/mendix-buildpack:v1.2 -``` - -This is an example for Microsoft SQL Server: - -```powershell -docker run -it \ - -e ADMIN_PASSWORD=Password1! \ - -e DATABASE_ENDPOINT=sqlserver://username:password@host:port/mendix \ - mendix/mendix-buildpack:v1.2 -``` - -## Read More - -* [Docker: Deploy](/developerportal/deploy/docker-deploy/) -* [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) diff --git a/content/en/docs/deployment/docker-deploy/run-mendix-on-kubernetes.md b/content/en/docs/deployment/docker-deploy/run-mendix-on-kubernetes.md deleted file mode 100644 index 944d526b66b..00000000000 --- a/content/en/docs/deployment/docker-deploy/run-mendix-on-kubernetes.md +++ /dev/null @@ -1,367 +0,0 @@ ---- -title: "Use Docker with Minikube" -linktitle: "Run with Minikube" -url: /developerportal/deploy/run-mendix-on-minikube/ -weight: 20 -aliases: - - /developerportal/deploy/run-mendix-on-kubernetes/ ---- - -## Introduction - -{{% alert color="info" %}} -This document is about local deployments on [Minikube](https://kubernetes.io/docs/getting-started-guides/minikube/). For the Mendix on Kubernetes solution, see [Mendix on Kubernetes](/developerportal/deploy/private-cloud/). -{{% /alert %}} - -This how-to takes you through the process of deploying a Docker image of your Mendix app to [Minikube](https://kubernetes.io/docs/getting-started-guides/minikube/), a local version of [Kubernetes](https://kubernetes.io/docs/home/) which runs in a Windows container or virtual machine. Many of the operations you perform on Minikube are the same as those on a hosted environment and it provides a low-level entry to Kubernetes. For more information, see [Installing Kubernetes with Minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/) on the Kubernetes documentation site. - -Kubernetes is a standard container orchestration platform supported by Mendix. For details on supported version of Kubernetes see [Mendix System Requirements](/refguide/system-requirements/). - -{{% alert color="info" %}} -Deploying a Docker image on Minikube is intended for test projects on a local machine. When publishing to your cloud infrastructure, Mendix suggests you use the [Mendix on Kubernetes](/developerportal/deploy/private-cloud/) solution, as this provides you with integration with the Mendix Portal and takes away much of the heavy lifting. -{{% /alert %}} - -This how-to teaches you how to do the following: - -* Deploy and run a Mendix app using Minikube -* Separate the database deployment from your app -* Attach persistence storage to the app container - -## Prerequisites - -To follow this how-to, you should have a basic knowledge of Docker and Kubernetes. For more information, see [Docker Overview](https://docs.docker.com/engine/docker-overview/) and [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/). Although you do not need more knowledge to execute all the commands provided, some experience will help you to understand the how-to better. - -Before starting this how-to, make sure you have completed the following prerequisites: - -* Install kubectl using the instructions provided in [Install and Set Up kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl) - * The kubectl CLI is the default tool to access and manage your Kubernetes cluster -* Install Minikube using the instructions provided in [Install Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) - * Minikube allows you to create a local cluster that is convenient for exploring Kubernetes (if you have an account for one of the cloud providers and you choose to use that, this step can be skipped) -* Build your image in Minikube, using the steps in the [Docker](/developerportal/deploy/docker-deploy/) page and replacing Docker commands such as `docker build` with Minikube equivalents such as `minikube image build`. - -This how-to uses commands for a Unix-like system. The commands for Windows may be slightly different. - -## Architecture Overview{#architecture} - -Before you start, here is some background information on the components needed to deploy a Mendix app with Minikube. - -A Mendix application needs, as a minimum, a database to run. In this example you provision a PostgreSQL database within the Kubernetes cluster. In production scenarios, the database is usually provided as a service by the cloud provider, like AWS RDS or Azure SQL. For supported databases see [Mendix System Requirements](/refguide/system-requirements/). - -If the application makes use of persistable FileDocument or FileImage entities, a persistent volume (PV) storage service needs to be attached as well. See [Mendix System Requirements](/refguide/system-requirements/) for supported external storage services. In this how-to you use a node-bound storage volume as an example. For more information, see [Architecture Overview](#architecture), below. - -This architecture overview shows all the components in the deployment: - -{{< figure src="/attachments/deployment/docker-deploy/run-mendix-on-kubernetes/kubernetes.png" class="no-border" >}} - -The deployment of your Mendix app needs the following Kubernetes components: - -* [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) -* [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) -* [Service](https://kubernetes.io/docs/concepts/services-networking/service/) -* [Volume](https://kubernetes.io/docs/concepts/storage/volumes/) -* [Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod/) - -The database is deployed as a **deployment**. Deployment covers control over the pods and the ReplicaSets for these pods. **Pods** are not bound to a specific node in the cluster unless set with selector labels. A deployment can scale pods on one or mode nodes, and it recovers pods when they crash. - -The Mendix application is deployed using a **StatefulSet**. The StatefulSet generally provides the same control options as a deployment, but it will provide a stable index number for the pod as well as a network ID and storage. The StatefulSet is used to provide the application with a unique pod index number that identifies which of the instances is allowed to run scheduled events. - -Data storage should be externalized as much as possible, because pods can be created, destroyed, or moved around. Destroying a pod will also destroy any data stored inside the containers started by the pod. When scaling the app, all instances should be able to retrieve the same data. This how-to uses node-bound **volume** mounts, but please check the list of available [clustered storage](https://kubernetes.io/docs/concepts/storage/volumes/) options. - -To access your Mendix applications inside a pod from outside of the Kubernetes, a **service** must be created to expose the port. Services deal with pod discovery and pod lifecycles, so the consumer of a particular service doesn't need to know where a pod is or what IP is needed to access it. - -## Deploying the Components - -### Deploying the PostgreSQL Database - -Once Minikube is running you must configure your local environment to use the Docker daemon using the following command: - -```bash -minikube docker-env -``` - -You must first deploy your database. Minikube uses an external folder to persist the data outside of the database pod. - -{{% alert color="info" %}} -For simplicity and compatibility with Minikube, we mount a folder from the `minikube node`. This approach is not recommended for production. -{{% /alert %}} - -Here is the definition of the `postgres-deployment.yaml` database component: - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: postgres -spec: - replicas: 1 - selector: - matchLabels: - app: postgres - template: - metadata: - labels: - app: postgres - spec: - containers: - - name: postgres - image: postgres:11 - ports: - - containerPort: 5432 - env: - - name: POSTGRES_DB - value: db0 - - name: POSTGRES_USER - value: mendix - - name: POSTGRES_PASSWORD - value: mendix - volumeMounts: - - mountPath: "/var/lib/postgresql/data" - name: "mendix-pgdata" - volumes: - - hostPath: - path: "/home/docker/pgdata" - name: mendix-pgdata -``` - -To create the PostgreSQL database, Mendix uses the provided [Postgres](https://hub.docker.com/_/postgres/) image. The environment variables provided in `env` are needed to configure the default database. Instead of setting the password in the *yaml* file directly, you can choose to use [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). - -And finally, it is necessary to expose the database as a service and make it available to the application. This is the definition of such a service: - -(`postgres-service.yaml`): - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: postgres-service -spec: - type: ClusterIP - ports: - - port: 5432 - selector: - app: postgres -``` - -To create all the mentioned components, use the following: - -```bash -kubectl create -f postgres-deployment.yaml -kubectl create -f postgres-service.yaml -``` - -The database is now created. To verify the installation, check out the logs: - -```bash -kubectl logs $(kubectl get pods -lapp=postgres -o name) -``` - -The output should be similar to the following: - -`2017-09-14 08:34:37.538 UTC [1] LOG: database system is ready to accept connections` - -The host and port values will be needed to deploy the application. To get these we execute the following command: - -```bash -kubectl get service postgres-service -``` - -If you are using Windows, you need to execute these inline commands first to get the pod name: - -```bash -kubectl get pods -lapp=postgres -o name -``` - -then use the pod name to retrieve the logs: - -```bash -kubectl logs -``` - -### Adding a Persistent Volume - -The Docker Buildpack stores files in /opt/mendix/build/data/files. If you do not have any persistent storage, then these files will disappear if the pod is destroyed. If you mount a Persistent Volume (PV) into this path, any uploaded files will be stored in that PV. - -To do this, you need to ensure that the `volumeMounts` parameter in the `mendixapp.yaml` file points to `/opt/mendix/build/data/files`. This is already set up in the sample file in [Deploying the Application](#deploy), below - -{{% alert color="info" %}} -The CF Buildpack will try to set file permissions in the volume before it starts the app, so it should have permissions to do that. -{{% /alert %}} - -### Deploying the Application{#deploy} - -With the database running, we can deploy our application. You will use a sample Docker container with a Mendix app published in [hub.docker.com](https://hub.docker.com/r/mendix/sample-app-kubernetes/). To create a new Docker container for your Mendix app, see the description on the [docker-mendix-buildpack](https://github.com/mendix/docker-mendix-buildpack). - -Before deploying the app, you need to create some secrets so that sensitive information for the application doesn't need to be in the *yaml* file. The secrets file is applied once to the cluster, and the values will be kept there. For information on all the options, see [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/). - -{{% alert color="info" %}} -The Secret values in the secrets file must be base64 encoded. -{{% /alert %}} - -Create a file `mendix-app-secrets.yaml` with the following contents: - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: mendix-app-secrets -type: Opaque -data: - admin-password: YOUR_ADMIN_PASSWORD - db-endpoint: YOUR_DATABASE_ENDPOINT - license-key: YOUR_LICENSE_KEY - license-id: YOUR_LICENSE_ID -``` - -`YOUR-DATABASE-ENDPOINT` is in the form `postgres://mendix:mendix@255.255.255.255:5432/db0` (for example, `postgres://mendix:mendix@172.17.0.3:5432/db0`). You can find the correct IP address and port for your database endpoint using the following command: - -```bash -kubectl get ep postgres-service -``` - -See [Run a Mendix Docker Image](/developerportal/deploy/run-mendix-docker-image/) for expected value formats. - -Create the secrets in Kubernetes by executing the following command: - -```bash -kubectl create -f mendix-app-secrets.yaml -``` - -Once the database service and the secrets are created, you can create the application, which is defined in the file below. - -`mendix-app.yaml`: - -```yaml -apiVersion: apps/v1 -kind: StatefulSet -metadata: - name: mendix-k8s-stateful - labels: - app: mendix-k8s -spec: - serviceName: mendix-app-service - replicas: 2 - selector: - matchLabels: - app: mendix-k8s - template: - metadata: - labels: - app: mendix-k8s - spec: - containers: - - name: mendix-app - image: /: - imagePullPolicy: Always - ports: - - containerPort: 8080 - volumeMounts: - - mountPath: "/opt/mendix/build/data/files" - subPath: files - name: mendix-data - env: - - name: ADMIN_PASSWORD - valueFrom: - secretKeyRef: - name: mendix-app-secrets - key: admin-password - - name: DATABASE_ENDPOINT - valueFrom: - secretKeyRef: - name: mendix-app-secrets - key: db-endpoint - - name: LICENSE_ID - valueFrom: - secretKeyRef: - name: mendix-app-secrets - key: license-id - - name: LICENSE_KEY - valueFrom: - secretKeyRef: - name: mendix-app-secrets - key: license-key - volumes: - - hostPath: - path: "/home/docker/mendix-files" - name: mendix-data -``` - -Replace `/:` with the Docker image of your app, for example, `mendix/sample-app-kubernetes:v3`. - -Create a Docker image of your Mendix app using the instructions in the [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) on GitHub. - -Once you have created the Docker image, push it to the Docker hub using the following command: - -```bash -minikube image push /: -``` - -Where `/:` is the Docker image of your app identified in `mendix-app.yaml`. For the example above, this is again `mendix/sample-app-kubernetes:v3`. - -{{% alert color="info" %}} -In this example, you use a local storage folder on the node to show how to externalize the data stored for your app from the Docker container. For production systems, Mendix recommends using the storage provided on the selected cloud platform. -{{% /alert %}} - -Deploy the application to Kubernetes: - -```bash -kubectl create -f mendix-app.yaml -``` - -#### Some Notes on Scaling{#scaling} - -The Mendix runtime is stateless, meaning that a client can talk to any server instance. However, scheduled events and database migrations should be handled by only one instance. This is done using a container index count. The pod with index 0 will always trigger the schedule events and deal with database updates in case of an upgrade version. - -Setting `kind: StatefulSet` rather than `kind: Deployment` appends a container instance index to the container's hostname. - -It should be noted that using a StatefulSet versus a deployment involves some difference in behavior. For example, a pod won't move to a different node when it crashes, and when the node is not reachable, the pod is not recreated on another system. - -### Making the App Available - -To make the app available from the browser, it needs to be accessible outside of the cluster. For this, Mendix uses a service of the LoadBalancer or NodePort type. For Minikube we can use both, which exposes the app via an IP address. - -If you deploy to a cloud provider, the method for publishing your app may be different (for example, some cloud providers can automatically update the load balancer to forward a URL request to the cluster). For more information, see [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/). - -The definition of publishing the Mendix app as a NodePort service is described in the following file: - -`mendix-app-service.yaml`: - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: mendix-app-service - labels: - app: mendix-k8s -spec: - ports: - - port: 8080 - protocol: TCP - selector: - app: mendix-k8s - type: NodePort -``` - -Deploy the service: - -```bash -kubectl create -f mendix-app-service.yaml -``` - -Check if the application is running using the command: - -```bash -minikube service mendix-app-service -``` - -To get the URL to the application on Minikube, execute this command and open the link in your browser: - -```bash -minikube service mendix-app-service --url -``` - -Congratulations! You have deployed your first Mendix app in Kubernetes. - -## Read More - -* [Docker: Deploy](/developerportal/deploy/docker-deploy/) -* [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) diff --git a/content/en/docs/deployment/general/licensing-apps/_index.md b/content/en/docs/deployment/general/licensing-apps/_index.md index 50dfd5c5bf9..71acdb76df5 100644 --- a/content/en/docs/deployment/general/licensing-apps/_index.md +++ b/content/en/docs/deployment/general/licensing-apps/_index.md @@ -121,8 +121,6 @@ To activate a license on your app running on Kubernetes, you need the license cr Two additional environment variables, `LICENSE_ID` and `LICENSE_KEY`, need to be set to the values of the **LicenseId** and **LicenseKey** provided by Mendix Support. To do this, add them to the deployment command for your app. -For full instructions on how to do this and how to supply the keys using a **Secrets** file, see the [Deploying the Application](/developerportal/deploy/run-mendix-on-minikube/#deploy) section of *Use Docker with Minikube*. - ### Windows Server To license a Mendix app on Microsoft Windows, follow these steps: diff --git a/content/en/docs/deployment/general/pad/_index.md b/content/en/docs/deployment/general/pad/_index.md new file mode 100644 index 00000000000..e52b82289ef --- /dev/null +++ b/content/en/docs/deployment/general/pad/_index.md @@ -0,0 +1,81 @@ +--- +title: "Portable App Distribution" +url: /developerportal/deploy/portable-app-distribution-deploy/ +weight: 15 +description: "Describes the Portable App Distribution deployment method for Mendix apps." +no_list: false +description_list: true +beta: true +--- + +{{% alert color="warning" %}} This feature is in beta. For more information, see [Release Status](/releasenotes/release-status/). {{% /alert %}} + +## Introduction + +Portable App Distribution provides a flexible and straightforward method for isolated server-based deployments. By enabling customers to generate a bundled artifact packaged as a .zip file and run it directly, Portable App Distribution simplifies the deployment process. + +## Benefits + +Portable App Distribution offers the following benefits: + +* Simplified deployment - Portable apps eliminate complex installation procedures, making it easier and faster to get software up and running across different machines. This reduces setup time and potential configuration errors. +* Enhanced consistency - By bundling all dependencies, portable apps ensure a consistent operating environment for the application, regardless of the underlying system configuration. +* Improved mobility and flexibility - Teams can easily move applications between workstations, virtual machines, or even cloud instances without the need for reinstallation, fostering greater agility in project work. +* Reduced system impact - Portable apps often run in isolated environments, which can help prevent conflicts with other installed software and maintain system stability. +* Streamlined updates - Managing updates can be more straightforward, as new versions of a portable application can often be deployed by simply replacing the package. +* Layered configuration - Portable App Distribution supports defining base configurations that can be extended with environment-specific or deployment-type-specific entries (for example, distinct configurations for development, testing, or production environments). + +## Licensing + +You can test Portable App Distribution on a [Free App](/developerportal/deploy/mendix-cloud-deploy/#free-app). For more information about Free Apps and their limitations, as well as licensing apps outside of the Mendix Cloud, see [Licensing Apps](/developerportal/deploy/licensing-apps-outside-mxcloud/). + +To license a Mendix app on the Portable App Distribution, add it to your configuration. For more information, see [Obtaining a Mendix License](/developerportal/deploy/licensing-apps-outside-mxcloud/#get-license). + +## Prerequisites + +The Portable App Distribution functionality is available for Mendix Studio Pro version 11.9, 11.6.5 MTS, or above. The functionality will be enabled for more Studio Pro versions in future releases. + +You must also ensure that you have the supported version of [Java Runtime Environment](/refguide/system-requirements/#java). + +## Creating a Portable App Distribution File + +In most production environments, deployment packages are created by using the [Mx-Build](/refguide/mxbuild/) command-line tool. However, you can also [manually create a deployment package](/refguide/create-deployment-package-dialog/) if required, for example, for a local test deployment. + +## Deploying Your App + +After you create the Portable App Distribution file, deploy it to your environment. + +### Deploying Locally + +To run your app locally, perform the following steps: + +1. Extract `..\releases\YourApp_portable_YYYYMMDD_hhmm.zip` to a local folder. +2. Set the **M2EE_ADMIN_PASS** admin port password by performing one of the following actions: + + * For Windows, run the command `set M2EE_ADMIN_PASS=` + * For Linux, run the command `export M2EE_ADMIN_PASS=` + +{{% alert color="info" %}} +The Mendix admin port can be used to fetch metrics and other runtime data from an app. It requires a password for security reasons. +{{% /alert %}} + +3. Run the app by using one of the following commands: + + * For Windows, run the command `\bin\start.bat` + * For Windows Powershell, run the command `\bin\start.ps1` + * For Linux, run the command `\bin\start` + +{{% alert color="info" %}} +On Linux, if the ZIP was extracted on Windows, the +x flag is not preserved. Windows does not have the executability bit. You need to run the command `chmod +x ./bin/start` first. +{{% /alert %}} + + +### Deploying to a Self-Hosted Environment + +For more information about deploying to a self-hosted environment, refer to the following topics: + +* [Portable App Distribution for Docker](/developerportal/deploy/docker-deploy-pad/) +* [Portable App Distribution for Linux](/developerportal/deploy/linux-pad/) +* [Portable App Distribution for Cloud Foundry](/developerportal/deploy/cloud-foundry-pad/) + +## Read More diff --git a/content/en/docs/deployment/general/pad/pad-best-practices.md b/content/en/docs/deployment/general/pad/pad-best-practices.md new file mode 100644 index 00000000000..61ad41cee7a --- /dev/null +++ b/content/en/docs/deployment/general/pad/pad-best-practices.md @@ -0,0 +1,57 @@ +--- +title: "Best Practices for Managing Configuration File Precedence" +url: /developerportal/deploy/portable-app-distribution-deploy/best-practices/ +linktitle: "Best Practices" +weight: 90 +description: "Describes the best practices for managing the configuration order for Portable Apps Distribution." +--- + +## Introduction + +This section clarifies how configuration files are processed, particularly concerning the order of application and how to manage environment variables and custom settings effectively. + +## Key Principle + +The core concept governing configuration file processing is *last definition wins.* This means that if the same configuration setting is defined in multiple files, the value from the file processed last overrides all previous definitions. + +This principle is crucial when managing both standard configuration files and environment variables. If a custom file is processed after environment variables, its settings will take precedence. + +By default, the configurations are loaded in the following order: + +```text +include file("etc/StudioPro.conf") +include file("etc/constants/defaults.conf") +include file("etc/configurations/Default.conf") +include file("etc/variables.conf") +include file("etc/constants/variables.conf") +``` + +Because of that, for example, if the same setting is present in `StudioPro.conf` and `etc/variables.conf`, the version from `etc/variables.conf` takes precedence. + +## Managing the Configuration Order + +To ensure your desired configuration values are applied correctly, especially when custom settings must override or be overridden by environment variables, you have two primary approaches: + +* Explicitly list configuration files: + + Instead of relying on a default include file (for example, `etc/Default`), you can explicitly list each configuration file as an argument when launching your application. + + This gives you precise control over the order. You can place your custom configuration file before files that define environment variables (for example, `variables.conf`) if you want your environment variables to take precedence, or after if you want your custom settings to override them. + +* Create a custom `etc/Default` file: + + You can also make a copy of the standard `etc/Default` file and modify your custom copy to include your own configuration file at the desired position within its include list. + + This allows you to maintain a single entry point for configuration while still controlling the order of included files. + +## The `etc/Default` File + +The `etc/Default` file is primarily provided for convenience and serves as an example. It is not mandatory to use it as-is. + +The system is designed to support multiple configuration files, allowing you to pick and choose which ones you want to use. This is particularly beneficial in Cloud environments where specific configurations (for example, `StudioPro.conf` for local testing) might be replaced with custom, deployment-specific files. + +In a typical Cloud deployment, it is often recommended to replace files like `StudioPro.conf` (which is geared towards local testing) with your own custom configuration tailored for the Cloud environment. + +## Supported Configuration File Formats + +You do not need to use the `.conf` extension for your configuration files. You can use any extension you prefer, or no extension at all. The content of the file determines how it is parsed. diff --git a/content/en/docs/deployment/general/pad/pad-reference.md b/content/en/docs/deployment/general/pad/pad-reference.md new file mode 100644 index 00000000000..486ea9b8ae7 --- /dev/null +++ b/content/en/docs/deployment/general/pad/pad-reference.md @@ -0,0 +1,286 @@ +--- +title: "Reference Guide for Portable Apps Distribution" +url: /developerportal/deploy/portable-apps-distribution/reference/ +linktitle: "Reference Guide" +weight: 100 +description: "Describes the folder structure and commmand line parameters for the Portable Apps Distribution deployment method for Mendix apps." +--- + +## Introduction + +In the following Reference Guide document, you can find information about the folder structure of the .zip file generated by Portable App Distribution, as well as the available command-line parameters for the start script. The Reference Guide also suggests some best practices for managing the order of your custom configuration files. + +## Folder Structure + +The .zip file generated by Portable App Distribution contains the following files and directories: + +* `app/` - The application, containing the following directories (similar to the .mda file): + + * `data/` + * `model/` + * `native/` + * `sass/` + * `tmp/` + * `web/` + +* `bin/` - Scripts to start the runtime: + + * `start` - Shell script for Linux and OSX + * `start.bat` - Batch file for Windows + * `start.ps1` - Batch file for Windows - PowerShell + +* `etc/` - Runtime config files for all configurations in the model + + * `example.conf` - An example runtime configuration file containing all possible parameters with the default values and documentation + * `StudioPro.Conf` - The configuration that is set in StudioPro; this file is to be included in the specific configurations + * `$ConfigName` - The runtime configuration for the configuration named `$ConfigName` + * `variables.conf` - Environment variable overrides for all public settings + * `configurations/` - The configurations as defined in the **App Settings** + + * `$ConfigName.conf` - Specific settings for the configuration named `$ConfigName` + + * `constants/` - All microflow constants + + * `defaults.conf` - Default values for all constants in the project + * `variables.conf` - Environment variable overrides for all constants + +* `lib/` - All included dependencies + + * `runtime/` - All required runtime files + + * `bundles/` - All jar file that are needed to start the runtime server + * `launcher/` - The jar file for launching the runtime server + * `lib/` - Additional library files + * `mxclientsystem/` - The runtime client files + +## Command Line Parameters for the Start Script + +The start script has the following parameters: + +```text +start [options...] [config-file...] +``` + +There can be multiple configuration files. If omitted, the script uses the default configuration. + +If a setting occurs multiple times across different files, the definition from the last file is used. + +The following options are supported: + +* `-h` or `--help` - Print the command line usage. +* `-J $JvmOption` - Pass `$JvmOption` to the JVM. + +## Database Settings + +The [database settings](/refguide/custom-settings/#database-settings) have the following parameters: + +```text +# Database configuration +runtime.params { + DatabaseType = Type of Database (*) + DatabaseHost=host:port + DatabaseName = MyMendixDB + DatabaseUserName = mymendixusername + DatabasePassword=mymendixusernamepassword +} +``` + +### Example Settings for PostgreSQL + +```text +# Database configuration +runtime.params { + DatabaseType = POSTGRESQL + DatabaseHost = "localhost:5432" + DatabaseName = MyMendixDB + DatabaseUserName = mymendixusername + DatabasePassword=mymendixusernamepassword +} +``` + +### Example Settings for AzureSQL + +```text +# Database configuration +runtime.params { + DatabaseType = SQLSERVER + DatabaseHost = ""your-database-host.database.windows.net:1433"" + DatabaseName = MyMendixDB + DatabaseUserName = mymendixusername + DatabasePassword=mymendixusernamepassword +} +``` + +### Example Settings for JDBC + +```text +# Database configuration +runtime.params { + DatabaseType = MYSQL + DatabaseJdbcUrl=mysql://db:3306/mendix + DatabaseName = MyMendixDB + DatabaseUserName = mymendixusername + DatabasePassword=mymendixusernamepassword +} +``` + +## File Storage + +The *example.conf* file in the Portable App Distribution .zip file contains example file storage settings for AWS S3 and Azure Blob Storage. + +### AWS S3 + +```text +runtime.params { + # Acts as the username to authenticate with the S3 service. + # Type: String + # com.mendix.storage.s3.AccessKeyId = "" + # Name of the bucket where the files are stored on S3. + # Type: String + # com.mendix.storage.s3.BucketName = "" + # Overrides the default maximum connections limit in the S3 service. + # The default value is enough for most applications, so we do not recommend explicitly setting this to a custom value unless a larger maximum connections limit is absolutely necessary. + # Type: Duration (use suffixes like s(econds), m(inutes) or h(ours); without suffix the value is taken as milliseconds) + # com.mendix.storage.s3.ClientExecutionTimeout = + # Sets the amount of time to wait (in milliseconds) when initially establishing a connection before giving up and timing out. + # A value of 0 means infinity and is not recommended. + # For more information, see the AWS Java SDK. + # Type: Duration (use suffixes like s(econds), m(inutes) or h(ours); without suffix the value is taken as milliseconds) + # com.mendix.storage.s3.ConnectionTimeout = + # List of keys which can be used to encrypt and decrypt data at rest in S3. + # The right key to decrypt the data with is automatically selected depending on with which key it was encrypted. + # Each encryption key consists of a key id, the encryption algorithm and the actual key (Base64 encoded). + # Type: Array of objects + # com.mendix.storage.s3.EncryptionKeys = [] + # Overrides the default endpoint. + # This setting is required when the storage is on a non-AWS location (for example, IBM Cloud Object Storage). + # Both the endpoint (for example, s3.example.com) or the full URL (including the protocol) are supported (for example, https://s3.example.com). + # Note that when setting a custom endpoint, path style access will be enabled. + # For more information, see Class S3ClientOptions. + # Type: String + # com.mendix.storage.s3.EndPoint = "" + # The value true allows the server to route requests to a different region than specified in these settings (false disallows it). + # Type: Boolean + # com.mendix.storage.s3.ForceGlobalBucketAccessEnabled = true + # Overrides the default maximum connections limit in the S3 service. + # The default value is enough for most applications, so we do not recommend explicitly setting this to a custom value unless a larger maximum connections limit is absolutely necessary. + # Type: Integer + # com.mendix.storage.s3.MaxConnections = + # Sets the region in which the S3 bucket is located. + # This will be used to determine the service endpoint, unless overridden in com.mendix.storage.s3.EndPoint. + # This setting will also be used as the signing region for requests. + # Type: String + # com.mendix.storage.s3.Region = "" + # Sets the amount of time to wait (in milliseconds) for the request to complete before giving up and timing out. + # A value of 0 means no timeout. + # For more information, see the AWS Java SDK. + # Type: Duration (use suffixes like s(econds), m(inutes) or h(ours); without suffix the value is taken as milliseconds) + # com.mendix.storage.s3.RequestTimeout = + # Prefix for the keys under which objects are stored. + # Separators are not added automatically to keys. + # For keys like prefix/key1, com.mendix.storage.s3.ResourceNamePrefix should have value prefix/. + # Type: String + # com.mendix.storage.s3.ResourceNamePrefix = "" + # Suffix for the keys under which objects are stored. + # This can be used when S3 buckets are divided into different segments for different users with different credentials (for example, store objects as [key].customer1 for customer1 and as [key].customer2 for customer2). + # Separators are not added automatically to keys. + # For keys like key1.customer1, com.mendix.storage.s3.ResourceNameSuffix should have value .customer1. + # Type: String + # com.mendix.storage.s3.ResourceNameSuffix = "" + # Acts as the password to authenticate with the S3 service. + # Type: String + # com.mendix.storage.s3.SecretAccessKey = "" + # Sets the amount of time to wait (in milliseconds) for data to be transferred over an established, open connection before the connection times out and is closed. + # A value of 0 means infinity and is not recommended. + # For more information, see the AWS Java SDK. + # Type: Duration (use suffixes like s(econds), m(inutes) or h(ours); without suffix the value is taken as milliseconds) + # com.mendix.storage.s3.SocketTimeout = + # Set this value to true to use the configured CACertificates for the connection to the S3 service. + # Type: Boolean + # com.mendix.storage.s3.UseCACertificates = false + # Lets the authentication policy use Signature Version 2 instead of the default Signature Version 4. + # Set this setting to true when the endpoint does not support Signature Version 4. + # Type: Boolean + # com.mendix.storage.s3.UseV2Auth = false +} +``` + +### Azure Blob Storage + +```text +runtime.params { + # Account key to authenticate with the Azure blob storage service. + # Type: String + # com.mendix.storage.azure.AccountKey = "" + # Account name to authenticate with the Azure blob storage service. + # Type: String + # com.mendix.storage.azure.AccountName = "" + # Set the blob endpoint. + # This setting is required when authentication by SharedAccessSignature or UseDefaultAzureCredential is used. + # Type: String + # com.mendix.storage.azure.BlobEndpoint = + # Name of the container containing the blob. + # Type: String + # com.mendix.storage.azure.Container = "" + # Indicates whether to check if the container exists, and creates it if it does not exist. + # Type: Boolean + # com.mendix.storage.azure.CreateContainerIfNotExists = true + # Maximum number of parallel multi-part file uploads/downloads. + # We advise not changing this setting unless you experience slow file transfers for large files. + # Choosing larger values will lead to higher memory usage. + # Type: Duration (use suffixes like s(econds), m(inutes) or h(ours); without suffix the value is taken as milliseconds) + # com.mendix.storage.azure.MaximumExecutionTimeInMs = + # Sets the maximum execution time (in milliseconds) to use when making this request. + # For more information, see the Azure libraries. + # Type: Int + # com.mendix.storage.azure.ParallelismFactor = 5 + # Provides delegated access to resources in your storage account. + # For more information, see Shared Access Signature on docs.microsoft.com. + # Type: String + # com.mendix.storage.azure.SharedAccessSignature = + # Sets the amount of time (in milliseconds) to allow a call to the storage service to complete. + # For more information, see the Azure libraries. + # Type: Duration (use suffixes like s(econds), m(inutes) or h(ours); without suffix the value is taken as milliseconds) + # com.mendix.storage.azure.TimeoutIntervalInMs = + # Enables the use of the credential information present in the running environment. + # For more information, see DefaultAzureCredential on Microsoft Learn. + # Type: Boolean + # com.mendix.storage.azure.UseDefaultAzureCredential = false + # For enabling or disabling secure connections using HTTPS. + # Can be true or false. + # Type: Boolean + # com.mendix.storage.azure.UseHttps = true +} +``` + +## Certificates + +The *example.conf* file in the Portable App Distribution .zip file contains example runtime settings for certificates. + +```text +runtime.params { + # A comma-separated list of paths to CA certificates. + # Example: D:\App\CA1.pem, D:\App\CA2.pem, D:\App\CA3.pem, D:\App\CA4.pem + # Type: String + # CACertificates = "" + # Comma-separated list of passwords for Client Certificates (should match the ClientCertificates order). + # Example: pwd1, pwd2, pwd3, pwd4 + # Type: String + # ClientCertificatePasswords = "" + # Only use this when you have multiple client certificates and you want to configure specific certificates for specific servers. + # This setting defines which service must use which client certificate. + # See NoClientCertificateUsages if you want to make sure that no client certificate is used for a certain host or web service. + # The value of ClientCertificateUsages must be a comma-separated list of key/value items. + # A key/value item must be specified as "identifier": "path to certificate". + # For web services, use the imported web service name as the identifier. + # For REST services, use the host name of the remote server as the identifier. + # Please note that any backslash in the path must be doubled. + # The whole value must be enclosed by braces ({ }). + # Type: Object + # ClientCertificateUsages = {} + # Comma-separated list of paths to Client Certificates. + # Example: D:\App\Mx1.pfx, D:\App\Mx2.pfx, D:\App\Mx3.pfx, D:\App\Mx4.pfx + # Type: String + # ClientCertificates = "" +} +``` \ No newline at end of file diff --git a/content/en/docs/deployment/on-premises-design/cloud-foundry/_index.md b/content/en/docs/deployment/on-premises-design/cloud-foundry/_index.md new file mode 100644 index 00000000000..4404136188c --- /dev/null +++ b/content/en/docs/deployment/on-premises-design/cloud-foundry/_index.md @@ -0,0 +1,13 @@ +--- +title: "Cloud Foundry" +url: /developerportal/deploy/cloud-foundry/ +weight: 50 +no_list: false +description_list: true +--- + +## Introduction + +This section describes how to deploy your Mendix app to an on-premise Cloud Foundry environment. + +## Documents in This Section diff --git a/content/en/docs/deployment/on-premises-design/cloud-foundry/cloud-foundry-deploy-pad.md b/content/en/docs/deployment/on-premises-design/cloud-foundry/cloud-foundry-deploy-pad.md new file mode 100644 index 00000000000..3cf0bd7373e --- /dev/null +++ b/content/en/docs/deployment/on-premises-design/cloud-foundry/cloud-foundry-deploy-pad.md @@ -0,0 +1,51 @@ +--- +title: "Portable App Distribution for Cloud Foundry" +url: /developerportal/deploy/cloud-foundry-pad/ +weight: 20 +description: "Describes how to deploy to a Cloud Foundry environment by using Portable App Distribution." +--- + +## Introduction + +Cloud Foundry is a platform-as-a-service (PaaS) that automates the deployment, scaling, and management of applications, abstracting away the underlying infrastructure. On-premise deployment, conversely, involves hosting applications and their entire infrastructure within a company's own data centers, giving them full control. + +This documentation provides guidance on understanding Cloud Foundry on-premise deployments and serves as a helpful reference rather than official implementation support. + +{{% alert color="info" %}} +For information about the scope of support, see [Support for Different Deployment Strategies](/support/deployment-strategy-support/). +{{% /alert %}} + +## Prerequisites + +To deploy your app to an on-premises Cloud Foundry configuration using [Portable App Distribution](/developerportal/deploy/portable-app-distribution-deploy/), ensure that you fulfill the following prerequisites: + +* You have access to the Cloud Foundry organization and space where the application is deployed. +* You have access to the database configuration from the database service. +* You have access to binding other required Cloud Foundry services. +* The Cloud Foundry CLI is installed. +* You have generated the [Portable App Distribution .zip file](/developerportal/deploy/portable-app-distribution-deploy/). + +## Deploying an App with Portable App Distribution + +To deploy your app to Cloud Foundry, perform the following steps: + +1. Log in to Cloud Foundry, and then access the organization and space where the application is deployed. +2. Save the [Portable App Distribution .zip file](/developerportal/deploy/portable-app-distribution-deploy/) to an accessible location. +3. Create a *manifest.yml* file in the root directory of your app. + + By default, the `cf push` command uses the *manifest.yml* file in the app directory. To specify a different location for the manifest, you must pass its local path to the `-f` flag when you run `cf push`. + +4. Add the following content to the file: + +```yaml +applications: +- name: + path: + memory: + buildpacks: + services: + env: +``` + +5. Run the `cf push` command. +6. Verify that the Mendix app has started successfully. \ No newline at end of file diff --git a/content/en/docs/deployment/cloud-foundry-deploy.md b/content/en/docs/deployment/on-premises-design/cloud-foundry/cloud-foundry-deploy.md similarity index 96% rename from content/en/docs/deployment/cloud-foundry-deploy.md rename to content/en/docs/deployment/on-premises-design/cloud-foundry/cloud-foundry-deploy.md index e17d0af523c..5642e0a4bbf 100644 --- a/content/en/docs/deployment/cloud-foundry-deploy.md +++ b/content/en/docs/deployment/on-premises-design/cloud-foundry/cloud-foundry-deploy.md @@ -1,6 +1,6 @@ --- -title: "Cloud Foundry" -url: /developerportal/deploy/cloud-foundry-deploy/ +title: "Cloud Foundry Buildpack (Deprecated)" +url: /developerportal/deploy/cloud-foundry-buildpack/ weight: 50 description: "Describes how to deploy to a Cloud Foundry environment which does not have Mendix support in the Mendix Portal." aliases: @@ -14,13 +14,18 @@ aliases: - /refguide/deploying-a-mendix-app-to-cloud-foundry - /refguide8/deploying-a-mendix-app-to-cloud-foundry - /refguide9/deploying-a-mendix-app-to-cloud-foundry + - /developerportal/deploy/cloud-foundry-deploy/ #To update these screenshots, you can log in with credentials detailed in How to Update Screenshots Using Team Apps. #If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details. --- ## Introduction -{{% alert color="warning" %}} Cloud Foundry deployment from Studio Pro is deprecated in version 10 and removed in version 11. {{% /alert %}} +{{% alert color="warning" %}} +Cloud Foundry buildpack deployment from Studio Pro is deprecated in version 10 and removed in version 11. Consider using the [Portable App Distribution for Cloud Foundry](/developerportal/deploy/cloud-foundry-pad/) option instead. + +The following documentation is provided for reference purposes only. +{{% /alert %}} Mendix apps can be deployed to a variety of different environments, for example Mendix Cloud, on-premises, or Kubernetes. diff --git a/content/en/docs/deployment/on-premises-design/linux/_index.md b/content/en/docs/deployment/on-premises-design/linux/_index.md new file mode 100644 index 00000000000..1bce35d84d9 --- /dev/null +++ b/content/en/docs/deployment/on-premises-design/linux/_index.md @@ -0,0 +1,13 @@ +--- +title: "Linux" +url: /developerportal/deploy/linux/ +weight: 55 +no_list: false +description_list: true +--- + +## Introduction + +This section describes how to deploy your Mendix app to an on-premise Linux environment. + +## Documents in This Section diff --git a/content/en/docs/deployment/on-premises-design/linux/linux-pad.md b/content/en/docs/deployment/on-premises-design/linux/linux-pad.md new file mode 100644 index 00000000000..29e946941c1 --- /dev/null +++ b/content/en/docs/deployment/on-premises-design/linux/linux-pad.md @@ -0,0 +1,112 @@ +--- +title: "Portable App Distribution for Linux" +url: /developerportal/deploy/linux-pad/ +description: "How to install and configure Mendix on a Linux system using Portable App Distribution." +weight: 20 +--- + +## Introduction + +Portable App Distribution refers to packaging applications in a self-contained format that includes all necessary dependencies, allowing them to run on various Linux systems without requiring traditional installation. + +This documentation provides guidance for deploying Portable App Distribution in a Linux environment and serves as a helpful reference rather than official implementation support. + +{{% alert color="info" %}} +For information about the scope of support, see [Support for Different Deployment Strategies](/support/deployment-strategy-support/). +{{% /alert %}} + +## Prerequisites + +To deploy your app to an on-premises Cloud Foundry configuration using [Portable App Distribution](/developerportal/deploy/portable-app-distribution-deploy/), ensure that you fulfill the following prerequisites: + +* A Linux environment. This can be a virtual machine, a physical server, or a cloud instance (for example, AWS EC2, Azure VM, Google Cloud VM). You will need `sudo` or `root` privileges for some commands. +* Java Development Kit (JDK). Your application requires a compatible Java runtime. For installation instructions, refer to the following sections. +* Your [Portable App Distribution .zip file](/developerportal/deploy/portable-app-distribution-deploy/). +* A method to transfer the .zip file onto your Linux machine, for example: + + * Cloud storage - If your Linux machine is in the cloud, you can use the cloud provider's CLI (for example, AWS S3, Azure Blob Storage, Google Cloud Storage). + * SFTP/SCP - For direct file transfer from your local machine. + * Version Control System (VCS) - If your .zip is stored in a repository. + * Artifactory/Nexus: For artifact management. + +## Deploying an App with Portable App Distribution + +To deploy your app to Linux, perform the following steps: + +1. Connect to your Linux server by running the following command: `ssh -i ".pem" @` + +2. Optional: Update your package lists and installed packages by running one of the following commands: + + * For Debian/Ubuntu-based systems: + + ```text + sudo apt update -y + sudo apt upgrade -y + ``` + + * For RHEL/CentOS/Amazon Linux-based systems: `sudo yum update -y` or `sudo dnf update -y` + +3. Install the Java Development Kit by running one of the following commands: + + * For Amazon Linux: `sudo yum install java-21-amazon-corretto -y` + * For Debian/Ubuntu-based systems: `sudo apt install temurin-21-jdk -y` + * For RHEL/CentOS-based systems: `sudo yum install temurin-21-jdk -y` or `sudo dnf install temurin-21-jdk -y` + +If your application requires it, you can change the Java version on vendor as needed, for example, `openjdk-21-jdk` or `java-17-amazon-corretto`. + +{{% alert color="info" %}} +Your Portable App Distribution only requires a Java Runtime Environment (JRE) to run, but it is often recommended to install a full JDK as it includes the JRE and development tools. +{{% /alert %}} + +4. Verify that Java is correctly installed by running the following command: `java -version`. +5. Upload the Portable App Distribution .zip file to a location where your Linux server can access it by using one of the following options, depending on the location and configuration of your Linux machine. + + * For Azure Blob Storage (often done as part of a CI/CD pipeline): `az storage blob upload --account-name --container-name --name .zip --file /build/distributions/your-app.zip --auth-mode login` + + You may need to log in to Azure CLI first with the `az` login. + + * For Cloud Storage (often done as part of a CI/CD pipeline): ` cp /build/distributions/your-app.zip s3:///` + + Adjust the `cp` command for your specific cloud provide (for example, `gsutil cp` for Google Cloud, or `aws s3` for AWS S3). + + * For SFTP/SCP (when transferring directly from your local machine to the Linux server): `scp -i ".pem" @:/home//` + + * For JFrog Artifactory or similar: `curl -u ":" -X PUT "https://.zip" -T .zip` + + Use the `-O` flag to save the file with its original name. + + * From a public URL using `wget`: `wget https://.zip` + +6. Download the .zip file onto your Linux server by using one of the following options, depending on the location and configuration of your Linux machine. + + * For Azure Blob Storage: `az storage blob download --account-name --container-name --name .zip --file /home//.zip --auth-mode login` + + Ensure that the user running this command on the Linux instance has the necessary permissions to access the Azure Storage account and container. You may need to log in to Azure CLI first with the `az` login. + + * For Cloud Storage: ` cp s3:///.zip /home//.zip` + + Adjust the `cp` command for your specific cloud provide (for example, `gsutil cp` for Google Cloud, or `aws s3` for AWS S3). + + Ensure that the user running this command on the EC2 instance has read permissions for the specified S3 Bucket. + + * For SFTP/SCP (when transferring directly from your local machine to the Linux server): `scp -i ".pem" @:/home//` + + * For JFrog Artifactory or similar: `curl -u ":" -0 "https://.zip" -T .zip` + + You can also retrieve the files using `wget`. + +7. Extract the .zip file by running the following command: `unzip .zip -d `. +8. Navigate into the extracted directory and execute the start script by running the following command: + + ```text + cd your-desired-directory + sh bin/start + ``` + + The `bin/start` script is a common convention for Portable App Distributions using the Default configuration. If your application uses a different configuration, start script, or command, adjust accordingly. + +9. Verify that the application is running by opening the following URL in your browser: `http://:8080`. + + `8080` is the default port. If your application is configured to run on a different port, adjust accordingly. + + Ensure that the port is open in your Linux server's firewall (for example, `firewalld`, `ufw`), and any cloud security groups or network access control lists (NACLs). \ No newline at end of file diff --git a/content/en/docs/deployment/on-premises-design/linux.md b/content/en/docs/deployment/on-premises-design/linux/linux.md similarity index 87% rename from content/en/docs/deployment/on-premises-design/linux.md rename to content/en/docs/deployment/on-premises-design/linux/linux.md index 1b68f283bc3..7f9081c39d6 100644 --- a/content/en/docs/deployment/on-premises-design/linux.md +++ b/content/en/docs/deployment/on-premises-design/linux/linux.md @@ -1,13 +1,13 @@ --- -title: "Linux Deployment" -url: /developerportal/deploy/linux/ -description: "How to install and configure Mendix on a Linux system" +title: "Linux Deployment with M2ee-Tools" +url: /developerportal/deploy/linux-m2ee/ +description: "How to install and configure Mendix on a Linux system using m2ee-tools." weight: 99 aliases: - /developerportal/deploy/unix-like/ --- -{{% alert color="warning" %}} Linux deployment is only supported on Debian 10 (buster) for the [Mendix Runtime version 9, 10, and 11](https://docs.mendix.com/releasenotes/studio-pro/lts-mts/). We will not add support for any other versions of the Mendix Runtime. {{% /alert %}} +{{% alert color="warning" %}} Linux deployment is only supported on Debian 10 (buster) for the [Mendix Runtime version 9, 10, and 11](https://docs.mendix.com/releasenotes/studio-pro/lts-mts/). We will not add support for any other versions of the Mendix Runtime. Consider using the [Portable App Distribution for Linux](/developerportal/deploy/linux-pad/) option instead. {{% /alert %}} ## Introduction diff --git a/content/en/docs/refguide/general/mxbuild.md b/content/en/docs/refguide/general/mxbuild.md index 5fe988e5a87..9b1c9d5c9c9 100644 --- a/content/en/docs/refguide/general/mxbuild.md +++ b/content/en/docs/refguide/general/mxbuild.md @@ -68,7 +68,7 @@ Command-line options are described in the table below: | `-h`, `--help` | Prints a short description of the MxBuild and a list of all available options. | | `--java-home=DIRECTORY` | (Required). The directory in which the JDK is installed.
For example, `--java-home=/usr/lib/jvm/java-8-oracle`.
For Windows, *DIRECTORY* should be enclosed in double-quotes `"`. | | `--java-exe-path=FILENAME` | (Required). The full path to the Java executable.
For example, `--java-exe-path=/usr/lib/jvm/java-8-oracle/bin/java`.
For Windows, *DIRECTORY* should be enclosed in double-quotes `"` and must contain the complete file name `...\java.exe`. | -| ––target=[package|deploy] | `package`: default if option is omitted; creates a deployment package (*.mda file*).
`deploy`: deploys the app without making a deployment package.
`sbom`: generates a [Software Bill of Materials](/refguide/sbom-generation/) (SBOM) in the CycloneDX format for the app. | +| ––target=[package|deploy] | `package`: default if option is omitted; creates a deployment package (*.mda file*).
`portable-app-package`: creates a [Portable App Distribution](/developerportal/deploy/portable-app-distribution-deploy/) package
`deploy`: deploys the app without making a deployment package.
`sbom`: generates a [Software Bill of Materials](/refguide/sbom-generation/) (SBOM) in the CycloneDX format for the app. | | `--loose-version-check` | Creates a deployment package from an app which was created with a lower Mendix version.
The app will be upgraded to the MxBuild version before the deployment package is created.
Any changes included as a result of this upgrade will not be stored in your app. | | `--write-errors=FILENAME` | Writes all errors, warnings, and deprecations encountered during deployment of the app to the specified file in JSON format.
This file is only written when the app contains errors.
If the file already exists, it will be overwritten without a warning.
For a description of the format of this file, see the [App Errors](#app-errors) section below. | | `--generate-sbom` | Generates a Software Bill of Materials (SBOM) file as a part of the `package` and `deployment` targets. The SBOM will be included in the deployment package if this option is used and is saved under its default location: `deployment\sbom.json` | @@ -79,7 +79,7 @@ Command-line options are described in the table below: ### Options When Creating a Package {{% alert color="info" %}} -The following options are only applicable with the `--target=package` option. +The following options are only applicable with the `--target=package` or `--target=portable-app-package` options. {{% /alert %}} Options when creating a package are described in the table below: diff --git a/content/en/docs/refguide/installation/system-requirements.md b/content/en/docs/refguide/installation/system-requirements.md index 81e2f9a2a99..751205c078d 100644 --- a/content/en/docs/refguide/installation/system-requirements.md +++ b/content/en/docs/refguide/installation/system-requirements.md @@ -280,8 +280,6 @@ For container-based deployments using Docker, Kubernetes, or Cloud Foundry, the * SAP AWS S3 Object Storage * SAP Azure Blob Storage -For container-mounted storage in Kubernetes, provided by an external storage class, see also [Use Docker with Minikube](/developerportal/deploy/run-mendix-on-minikube/). - ### Storage Types for Servers For server-based installations, the following storage types mounted by the OS are supported: diff --git a/content/en/docs/refguide/modeling/menus/app-menu/create-deployment-package-dialog.md b/content/en/docs/refguide/modeling/menus/app-menu/create-deployment-package-dialog.md index c597c98ebe4..42d637d824e 100644 --- a/content/en/docs/refguide/modeling/menus/app-menu/create-deployment-package-dialog.md +++ b/content/en/docs/refguide/modeling/menus/app-menu/create-deployment-package-dialog.md @@ -23,6 +23,32 @@ This is the uncompressed size of the deployment package (*.mda* file). You can f Unfortunately, from the error shown on the log during deployment, it is not always clear if the package size is a problem. But if you have issues deploying your app, the package size is one possible cause. {{% /alert %}} +## Portable Package + +Here, you can decide whether you will create a portable deployment package. + +A portable deployment package bundles your application code with all its necessary dependencies into a single, self-contained artifact. For more information about portable packages, see [Portable App Distribution](/developerportal/deploy/portable-app-distribution-deploy/). + +{{< figure src="/attachments/refguide/modeling/menus/app-menu/create-deployment-package-dialog/create-portable-package.png" alt="Create Deployment Package dialog with the portable option selected" width="500" >}} + +{{% alert color="info" %}} +Unlike regular packages, portable packages are created as .zip files, in order to make their deployment more convenient for cloud environments. For more information about the structure and contents of the .zip file, see [Reference Guide for Portable Apps Distribution](/developerportal/deploy/portable-apps-distribution/reference/). +{{% /alert %}} + +## Options for Portable Packages + +If you are creating a portable package, enter the information outlined below. + +## Export Secrets + +If you toggle the **Export secrets** option to **Yes**, the created package will include passwords and private constants. Enable or disable this option as required for your application + +## File Name + +The **Disk location** section displays the location where the deployment package will be saved. This is shown in the **File name** field. This is not editable. + +All packages are placed in a **releases** directory inside your app directory. This directory is automatically ignored so that these packages are not committed to the repository. You can always recreate a deployment package (using the Studio Pro version you originally used), so there is no need to put them on the Team Server. + ## Versioned Here, you can decide whether you will create a versioned deployment package. diff --git a/content/en/docs/refguide/runtime/clustered-mendix-runtime.md b/content/en/docs/refguide/runtime/clustered-mendix-runtime.md index f8991fdb43d..a3161f06034 100644 --- a/content/en/docs/refguide/runtime/clustered-mendix-runtime.md +++ b/content/en/docs/refguide/runtime/clustered-mendix-runtime.md @@ -15,7 +15,7 @@ The main feature enabling clustering is Mendix's stateless runtime architecture. Clustering support is built natively into our Cloud Foundry buildpack implementation. This means that you can simply scale up using Cloud Foundry. The buildpack ensures that your system automatically starts behaving as a cluster. -Clustering is also supported on Kubernetes, but you will have to use a *StatefulSet*. There is more information on this in the [Some Notes on Scaling](/developerportal/deploy/run-mendix-on-minikube/#scaling) section of *Use Docker with Minikube*. +Clustering is also supported on Kubernetes, but you will have to use a *StatefulSet*. ## Cluster Infrastructure diff --git a/content/en/docs/refguide10/installation/system-requirements.md b/content/en/docs/refguide10/installation/system-requirements.md index ffc33b9d3fe..00ce106a2c9 100644 --- a/content/en/docs/refguide10/installation/system-requirements.md +++ b/content/en/docs/refguide10/installation/system-requirements.md @@ -273,8 +273,6 @@ For container-based deployments using Docker, Kubernetes, or Cloud Foundry, the * SAP AWS S3 Object Storage * SAP Azure Blob Storage -For container-mounted storage in Kubernetes, provided by an external storage class, see also [Use Docker with Minikube](/developerportal/deploy/run-mendix-on-minikube/). - ### Storage Types for Servers For server-based installations, the following storage types mounted by the OS are supported: diff --git a/content/en/docs/refguide10/runtime/clustered-mendix-runtime.md b/content/en/docs/refguide10/runtime/clustered-mendix-runtime.md index 4c5f6a1f3a4..a2b984f970c 100644 --- a/content/en/docs/refguide10/runtime/clustered-mendix-runtime.md +++ b/content/en/docs/refguide10/runtime/clustered-mendix-runtime.md @@ -15,7 +15,7 @@ The main feature enabling clustering is Mendix's stateless runtime architecture. Clustering support is built natively into our Cloud Foundry buildpack implementation. This means that you can simply scale up using Cloud Foundry. The buildpack ensures that your system automatically starts behaving as a cluster. -Clustering is also supported on Kubernetes, but you will have to use a *StatefulSet*. There is more information on this in the [Some Notes on Scaling](/developerportal/deploy/run-mendix-on-minikube/#scaling) section of *Use Docker with Minikube*. +Clustering is also supported on Kubernetes, but you will have to use a *StatefulSet*. ## Cluster Infrastructure diff --git a/content/en/docs/refguide8/general/system-requirements.md b/content/en/docs/refguide8/general/system-requirements.md index 69796550858..b54b6ba1187 100644 --- a/content/en/docs/refguide8/general/system-requirements.md +++ b/content/en/docs/refguide8/general/system-requirements.md @@ -127,8 +127,6 @@ For container-based deployments using Docker, Kubernetes, or Cloud Foundry, the * SAP AWS S3 Object Storage * SAP Azure Blob Storage -For container-mounted storage in Kubernetes, provided by an external storage class, see also [Use Docker with Minikube](/developerportal/deploy/run-mendix-on-minikube/). - ### Storage types for Servers For server-based installations, the following storage types mounted by the OS are supported: diff --git a/content/en/docs/refguide8/runtime/clustered-mendix-runtime.md b/content/en/docs/refguide8/runtime/clustered-mendix-runtime.md index 26e71ffa966..39b29e6cfa6 100644 --- a/content/en/docs/refguide8/runtime/clustered-mendix-runtime.md +++ b/content/en/docs/refguide8/runtime/clustered-mendix-runtime.md @@ -14,7 +14,7 @@ The main feature enabling clustering is Mendix's stateless runtime architecture. Clustering support is built natively into our Cloud Foundry buildpack implementation. This means that you can simply scale up using Cloud Foundry. The buildpack ensures that your system automatically starts behaving as a cluster. -Clustering is also supported on Kubernetes, but you will have to use a *StatefulSet*. There is more information on this in the [Some Notes on Scaling](/developerportal/deploy/run-mendix-on-minikube/#scaling) section of *Use Docker with Minikube*. +Clustering is also supported on Kubernetes, but you will have to use a *StatefulSet*. ## Cluster Infrastructure diff --git a/content/en/docs/refguide9/general/system-requirements.md b/content/en/docs/refguide9/general/system-requirements.md index 4785e60fe85..2e89a390fbb 100644 --- a/content/en/docs/refguide9/general/system-requirements.md +++ b/content/en/docs/refguide9/general/system-requirements.md @@ -232,8 +232,6 @@ For container-based deployments using Docker, Kubernetes, or Cloud Foundry, the * SAP AWS S3 Object Storage * SAP Azure Blob Storage -For container-mounted storage in Kubernetes, provided by an external storage class, see also [Use Docker with Minikube](/developerportal/deploy/run-mendix-on-minikube/). - ### Storage Types for Servers For server-based installations, the following storage types mounted by the OS are supported: diff --git a/content/en/docs/refguide9/runtime/clustered-mendix-runtime.md b/content/en/docs/refguide9/runtime/clustered-mendix-runtime.md index 047565ac27c..a097850d0a6 100644 --- a/content/en/docs/refguide9/runtime/clustered-mendix-runtime.md +++ b/content/en/docs/refguide9/runtime/clustered-mendix-runtime.md @@ -15,7 +15,7 @@ The main feature enabling clustering is Mendix's stateless runtime architecture. Clustering support is built natively into our Cloud Foundry buildpack implementation. This means that you can simply scale up using Cloud Foundry. The buildpack ensures that your system automatically starts behaving as a cluster. -Clustering is also supported on Kubernetes, but you will have to use a *StatefulSet*. There is more information on this in the [Some Notes on Scaling](/developerportal/deploy/run-mendix-on-minikube/#scaling) section of *Use Docker with Minikube*. +Clustering is also supported on Kubernetes, but you will have to use a *StatefulSet*. ## Cluster Infrastructure diff --git a/content/en/docs/support/deployment-strategy-support.md b/content/en/docs/support/deployment-strategy-support.md index a8c5669ba3f..e8dfda2ac12 100644 --- a/content/en/docs/support/deployment-strategy-support.md +++ b/content/en/docs/support/deployment-strategy-support.md @@ -13,7 +13,7 @@ With our Multi-Cloud strategy, Mendix allows the apps that you build to be deplo The full stack is depicted in the table below. This indicates which components are **Mendix** supported, or supported by a **Mendix Partner** or a third party. If no support is indicated, then you will need to arrange support of this component yourself. Each of the components is described in more detail in [Components of the Mendix Stack](/support/mendix-stack-components/). -| Stack (refer to [Components of the Mendix Stack](/support/mendix-stack-components/) for more information) | Mendix Cloud | Cloud Dedi­cated | Mendix on Kubernetes - Con­nected | Mendix on Kubernetes - Stand­alone | Private Mendix Platform | SAP BTP | Cloud Foundry, Docker & Kuber­netes, Tradi­tional³ | +| Stack (refer to [Components of the Mendix Stack](/support/mendix-stack-components/) for more information) | Mendix Cloud | Cloud Dedi­cated | Mendix on Kubernetes - Con­nected | Mendix on Kubernetes - Stand­alone | Private Mendix Platform | SAP BTP | Cloud Foundry, Docker & Kuber­netes, Portable App Distribution, Tradi­tional³ | | --- | --- | --- | --- | --- | --- | --- | --- | | **Appli­cation** | | | | | | | | | | **Platform Support­ed Marketplace content** | Mendix | Mendix | Mendix | Mendix | Mendix | Mendix | Mendix | @@ -81,10 +81,12 @@ Mendix Support does not have access to app health, logs, graphs and monitoring {{< figure src="/attachments/support/sap-cloud-platform.png" width="40%" class="no-border" >}} -## Cloud Foundry / Docker and Kubernetes / Traditional Architectures +## Cloud Foundry / Docker and Kubernetes / Portable App Distribution / Traditional Architectures Mendix is compatible with all the well-known cloud providers: IBM Cloud, Microsoft Azure, Amazon Web Services (AWS), Red Hat OpenShift, and Google Cloud Platform. -Depending on the Cloud architecture a Mendix application is built using the [Mendix Cloud Foundry buildpack](https://github.com/mendix/cf-mendix-buildpack), the [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) or to a Unix-like or Windows server. + +Depending on the Cloud architecture a Mendix application is built using the [Portable App Distribution](/developerportal/deploy/portable-app-distribution-deploy/), the [Mendix Cloud Foundry buildpack](https://github.com/mendix/cf-mendix-buildpack), the [Mendix Docker Buildpack](https://github.com/mendix/docker-mendix-buildpack) or to a Unix-like or Windows server. + Check our [System Requirements](/refguide/system-requirements/) for the supported components of any Cloud Foundry / Docker and Kubernetes / traditional architecture. Mendix Support does not have access to app health, logs, graphs and monitoring. If you run into issues or want to ask a question on these supported components, please always provide relevant logs, data and your own analysis that explains why you suspect the issue is caused by one of our supported components. diff --git a/content/en/docs/support/mendix-stack-components.md b/content/en/docs/support/mendix-stack-components.md index a7778814183..5cd87171457 100644 --- a/content/en/docs/support/mendix-stack-components.md +++ b/content/en/docs/support/mendix-stack-components.md @@ -33,11 +33,11 @@ Mendix Support can analyze this component if your app is running on Mendix Cloud Mendix is responsible for setting up and maintaining the component, as well as applying the default configuration. This component cannot be customized or optimized for individual customers or applications outside the supported configuration options available to our customers. If it is running on SAP BTP instead, the selected third party can analyze this component. -## Buildpack, m2ee, and Service Console {#buildpack-m2ee-and-service-console} +## Buildpack, m2ee, Service Console, and Portable App Distribution {#buildpack-m2ee-and-service-console} The Mendix buildpacks for [Cloud Foundry](https://github.com/mendix/cf-mendix-buildpack) and [Docker](https://github.com/mendix/docker-mendix-buildpack) are available in GitHub repositories. The documentation for the buildpacks and m2ee tools is contained within these GitHub repositories. Because they are released under an open-source license, the code can be inspected, and the functionality and options can be understood by customers who wish to use these buildpacks. -If you want to run Mendix apps on a Unix-like server, you will need the [m2ee tools](https://github.com/mendix/m2ee-tools), available on GitHub. Read more about installing on systems running Unix-like operating systems in [Linux Deployment](/developerportal/deploy/linux/). +If you run Mendix apps on a Unix-like server using the [m2ee tools](https://github.com/mendix/m2ee-tools), refer to the [documentation](https://github.com/mendix/m2ee-tools) for more information about installing on systems running Unix-like operating systems. Mendix Support can analyze these components if your app is running on Mendix Cloud or Mendix Cloud Dedicated. Mendix is responsible for setting up and maintaining the component, as well as applying the default configuration. This component cannot be customized or optimized for individual customers or applications outside the supported configuration options available to our customers. diff --git a/static/attachments/refguide/modeling/menus/app-menu/create-deployment-package-dialog/create-deployment-package.png b/static/attachments/refguide/modeling/menus/app-menu/create-deployment-package-dialog/create-deployment-package.png index dfcd33b25a6..8507048bf5c 100644 Binary files a/static/attachments/refguide/modeling/menus/app-menu/create-deployment-package-dialog/create-deployment-package.png and b/static/attachments/refguide/modeling/menus/app-menu/create-deployment-package-dialog/create-deployment-package.png differ diff --git a/static/attachments/refguide/modeling/menus/app-menu/create-deployment-package-dialog/create-portable-package.png b/static/attachments/refguide/modeling/menus/app-menu/create-deployment-package-dialog/create-portable-package.png new file mode 100644 index 00000000000..140fe19c482 Binary files /dev/null and b/static/attachments/refguide/modeling/menus/app-menu/create-deployment-package-dialog/create-portable-package.png differ