Procedure

1. Navigate to the MTA download page and download one of the following operating system-specific CLI files or the src file:

   • mta-7.3.1-cli-linux-amd64.zip
   • mta-7.3.1-cli-linux-arm64.zip
   • mta-7.3.1-cli-darwin-amd64.zip
   • mta-7.3.1-cli-darwin-arm64.zip
   • mta-7.3.1-cli-windows-amd64.zip
   • mta-7.3.1-cli-windows-arm64.zip
   • mta-7.3.1-cli-src.zip
2. Extract the .zip file to the .kantra directory inside your $HOME directory. The .zip file extracts the mta-cli binary, along with other required directories and files.

3. Move the mta-cli binary to your $PATH variable.

   Note

   You can place the mta-cli binary in any folder that is included in the $PATH variable. Alternatively, you can add a folder that contains mta-cli to $PATH. This way, you do not need to specify a full path when using the CLI.

1. Download the required images by using an external computer.
2. Copying the downloaded images to the system you want to install MTA CLI on.

Procedure

1. On a connected device, perform the following steps:

   1. Authenticate to registry.redhat.io:

      $ podman login registry.redhat.io

   2. Run the mta-cli binary file. The binary file pulls the required provider images. For example:

      $ mta-cli analyze

      Important

      This command only pulls the required images. For example, if you run a command that requires Java images, a .NET image will not be pulled.

   3. Display the image list:

      $ podman images
      REPOSITORY                                                        TAG         IMAGE ID      CREATED       SIZE
      registry.redhat.io/mta/mta-generic-external-provider-rhel9        7.3.1       8b8d7fa14570  13 days ago   692 MB
      registry.redhat.io/mta/mta-cli-rhel9                              7.3.1       45422a12d936  13 days ago   1.6 GB
      registry.redhat.io/mta/mta-java-external-provider-rhel9           7.3.1       4d6d0912a38b  13 days ago   715 MB
      registry.redhat.io/mta/mta-dotnet-external-provider-rhel9         7.3.1       66ec9fc51408  13 days ago   1.27 GB

   4. Save the images:

      $ podman save <image_ID> -o <image_name>.image

   5. Copy the images onto a USB drive or directly to the file system of the disconnected device.

2. On the disconnected device, enter:

   $ podman load --input <image_name>.image

Procedure

1. Open a PowerShell with Administrator privileges.

2. Ensure Hyper-V is installed and enabled:

   PS C:\Users\<user_name>> Enable-WindowsOptionalFeature -Online ` -FeatureName Microsoft-Hyper-V-All

   PS C:\Users\<user_name>> Enable-WindowsOptionalFeature -Online ` -FeatureName Containers

   Note

   You might need to reboot Windows for the change to take effect.

3. Install Docker Desktop on Windows.

   1. Run the installer by double-clicking the Docker_Desktop_Installer.exe file.

      By default, Docker Desktop is installed to the C:\Program Files\Docker\Docker path.

   2. Ensure that Docker will run Windows containers as the backend instead of Linux containers:

      1. In the Windows task bar, right-click on the Docker icon.
      2. Click Switch to Windows containers.

4. In PowerShell, create a folder for MTA:

   PS C:\Users\<user_name>> mkdir C:\Users\<user_name>\MTA

5. Extract the mta-7.3.1-cli-windows.zip file to the MTA folder:

   PS C:\Users\<user_name>> cd C:\Users\<user_name>\Downloads

   PS C:\Users\<user_name>> Expand-Archive ` -Path "{ProductShortNameLower}-{ProductVersion}-cli-windows.zip" ` -DestinationPath "C:\Users\<user_name>\MTA"

6. Ensure that Docker is running Windows containers the OS/Arch is set to windows/amd64:

   PS C:\Users\<user_name>> docker version

   Client:
    Version:           27.0.3
    API version:       1.46
    Go version:        go1.21.11
    Git commit:        7d4bcd8
    Built:             Sat Jun 29 00:03:32 2024
    OS/Arch:           windows/amd64
    Context:           desktop-windows
   Server: Docker Desktop 4.32.0 (157355)
    Engine:
     Version:          27.0.3
     API version:      1.46 (minimum version 1.24)
     Go version:       go1.21.11
     Git commit:       662f78c
     Built:            Sat Jun 29 00:02:13 2024
     OS/Arch:          windows/amd64
     Experimental:     false

7. Set the CONTAINER_TOOL environment variable to use Docker:

   PS C:\Users\<user_name>> $env:CONTAINER_TOOL="C:\Windows\system32\docker.exe"

8. Set the DOTNET_PROVIDER_IMG environment variable to use the upstream dotnet-external-provider:

   PS C:\Users\<user_name>> $env:DOTNET_PROVIDER_IMG="quay.io/konveyor/dotnet-external-provider:v0.5.0"

9. Set the RUNNER_IMG environment variable to use the upstream image:

   PS C:\Users\<user_name>> $env:RUNNER_IMG="quay.io/konveyor/kantra:v0.5.0"

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. 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 for a CF application as an output file:

   $ mta-cli discover cloud-foundry \ --input <path_to_application-manifest> \ --output <path_to_discovery-manifest>\

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"