Procedure

1. Optional: List available target technologies for an analysis:

   $ mta-cli analyze --list-targets

2. Run the analysis:

   $ mta-cli analyze --input <path_to_input> --output <path_to_output> --source <source_name> --target <target_name>

   Specify the following arguments:

   • --input: An application to be evaluated.

   • --output: An output directory for the generated reports. mta-cli analyze creates the following analysis reports:

     • analysis.log
     • dependencies.yaml
     • output.yaml
     • shim.log
     • static-report
     • static-report.log
   • --source: A source technology for the application migration, for example, weblogic.
   • --target: A target technology for the application migration, for example, eap8.

3. Access the generated analysis report:

   1. In the output of the mta-cli analyze command, copy a path to the index.html analysis report file:

      Report created: <output_report_directory>/index.html
                	Access it at this URL: file:///<output_report_directory>/index.html

   2. Paste the path to the browser of your choice.

   Alternatively, press Ctrl and click on the path to the report file.

Procedure

1. Run the analysis for multiple applications.

   Important

   You must enter one input per analyze command, but make sure to enter the same output directory for all inputs.

   For example, to analyze example applications A, B, and C, enter the following commands:

   1. For input A, enter:

      $ mta-cli analyze --bulk --input <path_to_input_A> --output <path_to_output_ABC> --source <source_A> --target <target_A>

   2. For input B, enter:

      $ mta-cli analyze --bulk --input <path_to_input_B> --output <path_to_output_ABC> --source <source_B> --target <target_B>

   3. For input C, enter:

      $ mta-cli analyze --bulk --input <path_to_input_C> --output <path_to_output_ABC> --source <source_C> --target <target_C>

2. Access the analysis report. MTA generates a single report, listing all issues that must be resolved before the applications can be migrated.

Procedure

1. Optional: Display all mta-cli analyze command options:

   $ mta-cli analyze --help

2. Run the application analysis:

   $ mta-cli analyze --overwrite --input <path_to_input> --output <path_to_output> --target <target_source>

   Note

   The --overwrite option overwrites the output folder if it exists.

Procedure

1. List language providers supported for the analysis:

   $ mta-cli analyze --list-providers

2. Run the application analysis for the selected language provider:

   $ mta-cli analyze --input <path_to_input> --output <path_to_output> --provider <language_provider> --rules <path_to_custom_rules>

   Important

   Note that if you do not set the --provider option, the analysis might fail because it detects unsupported providers. The analysis will complete without --provider only if all discovered providers are supported.

Procedure

1. Log in to the MTA Hub with the following command.

   $ mta-cli config login

2. Enter the Host, Username, and Password to connect to the Hub.

   $ mta-cli config login
   Host: https://mta-namespace.apps.cluster.example.com/hub
   Username: <my_user_name>
   Password: <my_password>

   Note

   • The Host is the tackle URL of MTA deployed in your cluster that exposes the hub endpoint.
   • The Username and Password are the keycloak credentials that you use to log in to MTA in your cluster.

3. Sync the application with its remote repository and download the profile and custom rules files from the Hub.

   $ mta-cli config sync --url https://github.com/<my-app-repository> --application-path <path/to/my-app> --insecure

   Note

   MTA downloads the profile and custom rule files in the .konveyor/profiles/ path in your local application.

4. Check the path where MTA downloaded the configuration:

   $ mta-cli config list --profile-dir <path/to/my_app>

5. Run an analysis by using the downloaded profile configuration.

   $ mta-cli analyze -i <path/to/my_app> -o <path/to/my_app_report> --overwrite --mode source-only

   Tip

   For Java applications, you can use the full mode while running an analysis. For non-Java applications, the analysis mode must be source-only.

   Note

   The following command overrides the values of target in the analysis profile with quarkus.

   mta-cli analyze -i <path/to/my_app> -o <path/to/my_app_report> --overwrite --target quarkus --mode source-only

Procedure

1. Open the analysis report. For more information, see Accessing an analysis report.
2. Click Issues.
3. Click on the issue you want to check.
4. Under the File tab, click on a file to display an incident or incidents that triggered the issue.

5. Display the incident message by hovering over the line that triggered the incident, for example:

   Use the Quarkus Maven plugin adding the following sections to the pom.xml file:
   <properties>
   <quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
   <quarkus.platform.version>3.1.0.Final</quarkus.platform.version>
   </properties>
   <build>
   <plugins>
   <plugin>
   <groupId>$</groupId>
   <artifactId>quarkus-maven-plugin</artifactId>
   <version>$</version>
   <extensions>true</extensions>
   <executions>
   <execution>
   <goals>
   <goal>build</goal>
   <goal>generate-code</goal>
   <goal>generate-code-tests</goal>
   </goals>
   </execution>
   </executions>
   </plugin>
   </plugins>
   </build>

Procedure

1. Display the available OpenRewrite recipes:

   $ mta-cli transform openrewrite --list-targets

2. Transform the application source code:

   $ mta-cli transform openrewrite --input=<path_to_source_code> --target=<target_from_the_list>

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

3. Generate the discovery manifest:

   $ mta-cli discover cloud-foundry --input <path_to_input> --output-dir <path_to_output-directory>

Procedure

1. Optional: Investigate the contents of the remote CF instance

   $ cf spaces
   $ cf apps

2. Copy the CF configuration file to the directory of your choice:

   $ mkdir <path_to_the_directory>/.cf

3. Run the live discovery in a remote CF instance:

   $ mta-cli discover cloud-foundry --use-live-connection --orgs=<org_name> --spaces=<space_name> --output-dir <path_to_output_directory> --cf-config=<path_to_CF_config_file>

   The command runs the discovery for all applications from each space in the specified organization.

   If you want to run the discovery for a specific application, enter, for example:

   $ mta-cli discover cloud-foundry --use-live-connection --orgs=<org_name> --spaces=<space_name> --app-name=<application_name> --output-dir <path_to_output_directory> --cf-config=<path_to_CF_config_file>

Procedure

1. Display the contents of the CF manifest and locate sensitive data:

   $ cat <manifest_name>.yaml
   name: <manifest_name>
   disk_quota: 512M
   memory: 500M
   timeout: 10
   docker:
    image:myregistry/myapp:latest
    username: docker-registry-user

2. Generate the discovery manifest for the CF application as an output file and conceal sensitive data:

   $ mta-cli discover cloud-foundry --conceal-sensitive-data=true --input <path_to_application_manifest> --output-dir <path_to_output_directory>

Verification

1. Display the repository structure:

   $ tree <path_to_discovery_manifest>
   <path_to_discovery_manifest>
   ├── discover_manifest_<app-name>.yaml
   ├── secrets_<discovery_manifest_name>.yaml
   
   1 directory, 2 files

2. Display the contents of the discovery manifest:

   $ cat <discovery_manifest_name>.yaml
   name: <discovery_manifest_name>
   timeout: 10
   docker:
    image:myregistry/myapp:latest
    username: $(f0e9ea9e-1913-446f-8483-da9301373eef)
   disk: 512M
   memory: 500M
   instances: 1

   The sensitive data was replaced with a UUID (Universally Unique Identifier).

3. Display the contents of the secrets_<discovery_manifest_name>.yaml file:

   $ cat secrets_<discovery_manifest_name>.yaml
   f0e9ea9e-1913-446f-8483-da9301373eef: docker-registry-user

   The file contains the mapping of the UUID to the concealed sensitive data.

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> \

3. Verify the ConfigMap:

   $ mta-cli cd <location_of_deployment_manifest> \
   $ cat configmap.yaml
   $ cat Dockerfile

4. Verify the Dockerfile:

   $ mta-cli cd <location_of_deployment_manifest> \
   $ cat Dockerfile

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

3. Generate the discovery manifest:

   $ mta-cli discover cloud-foundry \ --input cf-nodejs-app.yaml \ --output discover.yaml \

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

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

6. Check the contents of the Dockerfile in the newDir directory:

   $ cat ./newDir/Dockerfile
   FROM busybox:latest
   
   RUN echo "Hello cf-nodejs!"

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"

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 \

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"