With this configuration and deployment command, the FQDN for this Mule app becomes “.” For example, to deploy to the test environment: 1 mvn -DmuleDeploy deploy -Denv=test The env Maven property defaults to dev but can be overridden at deployment time. This means that a CloudHub application name must be unique across all these regions, across all Anypoint Platform organizations and business groups, and across all their Anypoint Platform environments (dev, test, prod, etc.).įor this reason, CloudHub application names are typically constructed to include elements identifying the organization and environment. The US control plane, which is implicitly used in the above configuration, supports deployments to CloudHub runtime planes in most regions of the world. At the time of this writing (January 2020), MuleSoft hosts two general-purpose instances of the Anypoint Platform control plane, one in the US and one in the EU. CloudHub requires this name to be unique amongst all CloudHub deployments performed through the chosen Anypoint Platform control plane. Of particular interest here is the setting of the CloudHub application name via name. Here, we have done this only for the Studio-generated app.runtime and the newly introduced properties env and name. These properties and their value ranges are documented here.Īs a best practice, most of these values should be supplied via Maven properties. In real-world deployment scenarios, it is typically necessary to explicitly set most of these values, for example: 1 Overall, this determines the main load-balanced (though only to one worker) fully-qualified domain name (FQDN) for this Mule app to be “.” No properties set on the deployed Mule app.CloudHub application name (deployment name) of “mysystemapi,” that is, the value of.Deployment to the CloudHub runtime plane in the us-east-1 region.Directly to the master organization rather than a business group of the chosen Anypoint Platform organization (see below).
Deployment via the MuleSoft-hosted Anypoint Platform control plane in the U.S.This configuration makes use of several defaults pertaining to the CloudHub deployment model, such as: To deploy to CloudHub using MMP, we must add at a minimum the following details to the MMP configuration: 1 Extending the Mule Maven plugin configuration for deployment to CloudHub Here, however, we want to automate the deployment to CloudHub. (The artifact name is determined by, and in pom.xml.) This artifact is a deployable Mule app archive, and could be manually uploaded to Runtime Manager for deployment to CloudHub (or other deployment targets). This configuration supports building and packaging this Mule app into an artifact named “mysystemapi-1.0.0-SNAPSHOT-mule-application.jar” in the target directory. Studio generates the following MMP configuration in pom.xml 1 This Mule app is an implementation of a System API, which the app therefore exposes. Building Mule apps with the Mule Maven pluginįor this demonstration, we will create a new, simple Mule app called “mysystemapi” with Studio 7.4.2 for Mule runtime 4.2.2 and MMP 3.3.6. In a second step, we optimize this MMP configuration to automatically make the most of Anypoint Visualizer, an intuitive and powerful application network visualization and insight generation tool available in Anypoint Platform. This requires us to address the most important specifics of the CloudHub deployment model. In this article, we extend the standard MMP configuration generated by Studio to automate deployment to CloudHub. MuleSoft Training course “Anypoint Platform Development: This article uses content from the recently released
0 kommentar(er)
