Este contenido no está disponible en el idioma seleccionado.

Chapter 8. Generating platform assets for application deployment


Starting from MTA version 7.3.0, you can use the discover and generate commands in containerless mode to automatically generate the manifests needed to deploy a Cloud Foundry (CF) application in the OpenShift Container Platform:

  • Use the discover command to generate the discovery manifest in the YAML format from the CF application manifest. The discovery manifest preserves the specifications found in the CF manifest that define the metadata, runtime, and platform configurations.
  • Use the generate command to generate the deployment manifest for OCP deployments by using the discovery manifest. The deployment manifest is generated by using a templating engine, such as Helm, that converts the discovery manifest into a Kubernetes-native format. You can also use this command to generate non-Kubernetes manifests, such as a Dockerfile or a configuration file.
Important

Generating platform assets for application deployment is a Developer Preview feature only. Developer Preview features are not supported by Red Hat in any way and are not functionally complete or production-ready. Do not use Developer Preview features for production or business-critical workloads. Developer Preview features provide early access to upcoming product features in advance of their possible inclusion in a Red Hat product offering, enabling customers to test functionality and provide feedback during the development process. These features might not have any documentation, are subject to change or removal at any time, and testing is limited. Red Hat might provide ways to submit feedback on Developer Preview features without an associated SLA.

Benefits of generating deployment assets

Generating deployment assets has the following benefits:

  • Generating the Kubernetes and non-Kubernetes deployment manifests.
  • Generating deployment manifests by using familiar template engines, for example, Helm, that are widely used for Kubernetes deployments.
  • Adhering to Kubernetes best practices when preparing the deployment manifest by using Helm templates.

8.1. Generating a discovery manifest

You can generate the discovery manifest for the Cloud Foundry (CF) application by using the discover command. The discovery manifest preserves configurations, such as application properties, resource allocations, environment variables, and service bindings found in the CF manifest.

Prerequisites

  • You have Cloud Foundry (v3) as a source platform.
  • You have OpenShift Container Platform as a target platform.
  • You installed MTA CLI version 7.3.0.
  • You have a CF application manifest as a YAML file.

Procedure

  1. Open the terminal application and navigate to the <MTA_HOME>/ directory.
  2. List the supported platforms for the discovery process:

    $ mta-cli discover --list-platforms
    Copy to Clipboard Toggle word wrap
  3. Generate the discovery manifest for a CF application as an output file:

    $ mta-cli discover cloud-foundry \ --input <path_to_application-manifest> \ --output <path_to_discovery-manifest>\
    Copy to Clipboard Toggle word wrap

8.2. Generating a deployment manifest

You can auto-generate the Red Hat OpenShift Container Platform deployment manifest for the Cloud Foundry (CF) application by using the generate command. Based on the Helm template that you provide, the command generates manifests, such as a ConfigMap, and non-Kubernetes manifests, such as a Dockerfile, for application deployment.

Prerequisites

  • You have Cloud Foundry (v3) as a source platform.
  • You have OpenShift Container Platform as a target platform.
  • You installed MTA CLI version 7.3.0.
  • You generated a discovery manifest.
  • You created a Helm template with the required configuration for the OCP deployment.

Procedure

  1. Open the terminal application and navigate to the <MTA_HOME>/ directory.
  2. Generate the deployment manifest as an output file:

    $ mta-cli generate helm --chart-dir helm_sample \ --input <path_to_discovery-manifest> \ --output-dir <location_of_deployment_manifest> \
    Copy to Clipboard Toggle word wrap
  3. Verify the ConfigMap:

    $ mta-cli cd <location_of_deployment_manifest> \
    $ cat configmap.yaml
    $ cat Dockerfile
    Copy to Clipboard Toggle word wrap
  4. Verify the Dockerfile:

    $ mta-cli cd <location_of_deployment_manifest> \
    $ cat Dockerfile
    Copy to Clipboard Toggle word wrap

8.3. The discover and generate command options

You can use the following options together with the discover or generate command to adjust the command behavior to your needs.

Expand
Table 8.1. Options for discover and generate commands
CommandOptionDescription

discover

-h, --help

Display details for different command arguments.

--list-platforms

List the supported platforms for the discovery process.

discover cloud-foundry

 

Discover Cloud Foundry applications.

--input

Specify the location of the <app-manifest-name>.yaml file to discover the application configurations.

--output

Specify the location to save the <discovery-manifest-name>.yaml file.

generate

-h, --help

Display details for different command arguments.

generate helm

 

Generate a deployment manifest by using the Helm template.

--chart-dir

Specify a directory that contains the Helm chart.

--input

Specify a location of the <discovery-manifest-name>.yaml file to generate the deployment manifest.

--non-k8s-only

Generate only non-Kubernetes templates, such as a Dockerfile.

--output-dir

Specify a location to which the deployment manifests are saved.

--set

Override values of attributes in the discovery manifest with the key-value pair entered from the CLI.

8.4. Assets generation example

The following is an example of generating discovery and deployment manifests of a Cloud Foundry (CF) Node.js application.

For this example, the following files and directories are used:

  • CF Node.js application manifest name: cf-nodejs-app.yaml
  • Discovery manifest name: discover.yaml
  • Location of the application Helm chart: helm_sample
  • Deployment manifests: a ConfigMap and a Dockerfile
  • Output location of the deployment manifests: newDir

Assumed that the cf-nodejs-app.yaml is located in the same directory as the MTA CLI binary. If the CF application manifest location is different, you can also enter the location path to the manifest as the input.

Prerequisites

  • You installed MTA CLI 7.3.0.
  • You have a CF application manifest as a YAML file.
  • You created a Helm template with the required configurations for the OCP deployment.

Procedure

  1. Open the terminal application and navigate to the <MTA_HOME>/ directory.
  2. Verify the content of the CF Node.js application manifest:

    $ cat cf-nodejs-app.yaml
    name: cf-nodejs
    lifecycle: cnb
    buildpacks:
      - docker://my-registry-a.corp/nodejs
      - docker://my-registry-b.corp/dynatrace
    memory: 512M
    instances: 1
    random-route: true
    Copy to Clipboard Toggle word wrap
  3. Generate the discovery manifest:

    $ mta-cli discover cloud-foundry \ --input cf-nodejs-app.yaml \ --output discover.yaml \
    Copy to Clipboard Toggle word wrap
  4. Verify the content of the discover manifest:

    $ cat discover.yaml
    name: cf-nodejs
    randomRoute: true
    timeout: 60
    buildPacks:
    - docker://my-registry-a.corp/nodejs
    - docker://my-registry-b.corp/dynatrace
    instances: 1
    Copy to Clipboard Toggle word wrap
  5. Generate the deployment manifest in the newDir directory by using the discover.yaml file:

    $ mta-cli generate helm \ --chart-dir helm_sample \ --input discover.yaml --output-dir newDir
    Copy to Clipboard Toggle word wrap
  6. Check the contents of the Dockerfile in the newDir directory:

    $ cat ./newDir/Dockerfile
    FROM busybox:latest
    
    RUN echo "Hello cf-nodejs!"
    Copy to Clipboard Toggle word wrap
  7. Check the contents of the ConfigMap in the newDir directory:

    $ cat ./newDir/configmap.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cf-nodejs-config
    data:
      RANDOM_ROUTE: true
      TIMEOUT: "60"
      BUILD_PACKS: |
        - docker://my-registry-a.corp/nodejs
        - docker://my-registry-b.corp/dynatrace
      INSTANCES: "1"
    Copy to Clipboard Toggle word wrap
  8. In the ConfigMap, override the name to nodejs-app and INSTANCES to 2 :

    $ mta-cli generate helm \ --chart-dir helm_sample \ --input discover.yaml --set name="nodejs-app" \ --set instances=2 \ --output-dir newDir \
    Copy to Clipboard Toggle word wrap
  9. Check the contents of the ConfigMap again:

    $ cat ./newDir/configmap.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: nodejs-app
    data:
      RANDOM_ROUTE: true
      TIMEOUT: "60"
      BUILD_PACKS: |
        - docker://my-registry-a.corp/nodejs
        - docker://my-registry-b.corp/dynatrace
      INSTANCES: "2"
    Copy to Clipboard Toggle word wrap
Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat