Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 3. Installing the Migration Toolkit for Applications user interface
You can install the Migration Toolkit for Applications (MTA) user interface on all Red Hat OpenShift cloud services and Red Hat OpenShift self-managed editions.
To be able to create MTA instances, you must first install the MTA Operator.
The MTA Operator is a structural layer that manages resources deployed on OpenShift, such as database, front end, and back end, to automatically create an MTA instance.
3.1. Persistent volume requirements
To successfully deploy, the MTA Operator requires 3 RWO persistent volumes (PVs) used by different components. If the rwx_supported
configuration option is set to true
, the MTA Operator requires an additional 2 RWX PVs that are used by Maven and the hub file storage. The PVs are described in the table below:
Name | Default size | Access mode | Description |
---|---|---|---|
| 10 GiB | RWO | Hub database |
| 100 GiB | RWX |
Hub file storage; required if the |
| 1 GiB | RWO | Keycloak back end database |
| 1 GiB | RWO | Pathfinder back end database |
| 100 GiB | RWX |
Maven m2 cache; required if the |
3.2. Installing the Migration Toolkit for Applications Operator and the user interface
You can install the Migration Toolkit for Applications (MTA) and the user interface on Red Hat OpenShift versions 4.13-4.15.
Prerequisites
- 4 vCPUs, 8 GiB RAM, and 40 GiB persistent storage.
- Any cloud services or self-hosted edition of Red Hat OpenShift on versions 4.13-4.15.
-
You must be logged in as a user with
cluster-admin
permissions.
For more information, see OpenShift Operator Life Cycles.
Procedure
-
In the Red Hat OpenShift web console, click Operators
OperatorHub. - Use the Filter by keyword field to search for MTA.
- Click the Migration Toolkit for Applications Operator and then click Install.
- On the Install Operator page, click Install.
-
Click Operators
Installed Operators to verify that the MTA Operator appears in the openshift-mta
project with the statusSucceeded
. - Click the MTA Operator.
Under Provided APIs, locate Tackle, and click Create Instance.
The Create Tackle window opens in Form view.
- Review the custom resource (CR) settings. The default choices should be acceptable, but make sure to check the system requirements for storage, memory, and cores.
To work directly with the YAML file, click YAML view and review the CR settings that are listed in the
spec
section of the YAML file.The most commonly used CR settings are listed in this table:
Table 3.2. Tackle CR settings Name Default Description cache_data_volume_size
100 GiB
Size requested for the cache volume; ignored when
rwx_supported=false
cache_storage_class
Default storage class
Storage class used for the cache volume; ignored when
rwx_supported=false
feature_auth_required
True
Flag to indicate whether keycloak authorization is required (single user/“noauth”)
feature_isolate_namespace
True
Flag to indicate whether namespace isolation using network policies is enabled
hub_database_volume_size
10 GiB
Size requested for the Hub database volume
hub_bucket_volume_size
100 GiB
Size requested for the Hub bucket volume
hub_bucket_storage_class
Default storage class
Storage class used for the bucket volume
keycloak_database_data_volume_size
1 GiB
Size requested for the Keycloak database volume
pathfinder_database_data_volume_size
1 GiB
Size requested for the Pathfinder database volume
maven_data_volume_size
100 GiB
Size requested for the Maven m2 cache volume; deprecated in MTA 6.0.1
rwx_storage_class
NA
Storage class requested for the Tackle RWX volumes; deprecated in MTA 6.0.1
rwx_supported
True
Flag to indicate whether the cluster storage supports RWX mode
rwo_storage_class
NA
Storage class requested for the Tackle RW0 volumes
rhsso_external_access
False
Flag to indicate whether a dedicated route is created to access the MTA managed RHSSO instance
analyzer_container_limits_cpu
1
Maximum number of CPUs the pod is allowed to use
analyzer_container_limits_memory
4GiB
Maximum amount of memory the pod is allowed to use. You can increase this limit if the pod displays
OOMKilled
errors.analyzer_container_requests_cpu
1
Minimum number of CPUs the pod needs to run
analyzer_container_requests_memory
4GiB
Minimum amount of memory the pod needs to run
Example YAML file
kind: Tackle apiVersion: tackle.konveyor.io/v1alpha1 metadata: name: mta namespace: openshift-mta spec: hub_bucket_volume_size: "25Gi" maven_data_volume_size: "25Gi" rwx_supported: "false"
- Edit the CR settings if needed, and then click Create.
-
In Administration view, click Workloads
Pods to verify that the MTA pods are running. -
Access the user interface from your browser by using the route exposed by the
mta-ui
application within OpenShift. Use the following credentials to log in:
- User name: admin
- Password: Passw0rd!
- When prompted, create a new password.
3.3. Installing the Migration Toolkit for Applications Operator in a disconnected Red Hat OpenShift environment
You can install the MTA Operator in a disconnected environment by following the instructions in generic procedure.
In step 1 of the generic procedure, configure the image set for mirroring as follows:
kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v1alpha2 storageConfig: registry: imageURL: registry.to.mirror.to skipTLS: false mirror: operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15 packages: - name: mta-operator channels: - name: stable-v7.0 - name: rhsso-operator channels: - name: stable helm: {}
3.4. Memory requirements for running MTA on Red Hat OpenShift Local
When installed on Red Hat OpenShift Local, MTA requires a minimum amount of memory to complete its analysis. Adding memory makes the analysis process run faster. The table below describes the MTA performance with varying amounts of memory.
Memory (GiB) | Description |
---|---|
| MTA cannot run the analysis due to insufficient memory |
| MTA cannot run the analysis due to insufficient memory |
| MTA works and the analysis is completed in approximately 3 minutes |
| MTA works and the analysis is completed in less than 2 minutes |
| MTA works quickly, and the analysis is completed in less than 1 minute |
The test results indicate that the minimum amount of memory for running MTA on OpenShift Local is 12 GiB.
- The tests were performed by running the MTA binary analysis through the user interface.
-
All the analyses used the
tackle-testapp
binary. - All the tests were conducted on an OpenShift Local cluster without the monitoring tools installed.
- Installing the cluster monitoring tools requires an additional 5 GiB of memory.
3.4.1. Eviction threshold
Each node has a certain amount of memory allocated to it. Some of that memory is reserved for system services. The rest of the memory is intended for running pods. If the pods use more than their allocated amount of memory, an out-of-memory event is triggered and the node is terminated with a OOMKilled
error.
To prevent out-of-memory events and protect nodes, use the --eviction-hard
setting. This setting specifies the threshold of memory availability below which the node evicts pods. The value of the setting can be absolute or a percentage.
Example of node memory allocation settings
-
Node capacity:
32 GiB
-
--system-reserved
setting:3 GiB
-
--eviction-hard
setting:100 MiB
The amount of memory available for running pods on this node is 28.9 GiB. This amount is calculated by subtracting the system-reserved
and eviction-hard
values from the overall capacity of the node. If the memory usage exceeds this amount, the node starts evicting pods.
3.5. Red Hat Single Sign-On
MTA delegates authentication and authorization to a Red Hat Single Sign-On (RHSSO) instance managed by the MTA operator. Aside from controlling the full lifecycle of the managed RHSSO instance, the MTA operator also manages the configuration of a dedicated realm that contains all the roles and permissions that MTA requires.
If an advanced configuration is required in the MTA managed RHSSO instance, such as adding a provider for User Federation or integrating identity providers, users can log into the RHSSO Admin Console through the /auth/admin
subpath in the mta-ui
route. The admin credentials to access the MTA managed RHSSO instance can be retrieved from the credential-mta-rhsso
secret available in the namespace in which the user interface was installed.
A dedicated route for the MTA managed RHSSO instance can be created by setting the rhsso_external_access
parameter to True
in the Tackle CR that manages the MTA instance.
For more information, see Red Hat Single Sign-On features and concepts.
3.5.1. Roles and Permissions
The following table contains the roles and permissions (scopes) that MTA seeds the managed RHSSO instance with:
tackle-admin | Resource Name | Verbs |
addons |
delete | |
adoptionplans |
post | |
applications |
delete | |
applications.facts |
delete | |
applications.tags |
delete | |
applications.bucket |
delete | |
assessments |
delete | |
businessservices |
delete | |
dependencies |
delete | |
identities |
delete | |
imports |
delete | |
jobfunctions |
delete | |
proxies |
delete | |
reviews |
delete | |
settings |
delete | |
stakeholdergroups |
delete | |
stakeholders |
delete | |
tags |
delete | |
tagtypes |
delete | |
tasks |
delete | |
tasks.bucket |
delete | |
tickets |
delete | |
trackers |
delete | |
cache |
delete | |
files |
delete | |
rulebundles |
delete | |
tackle-architect | Resource Name | Verbs |
addons |
delete | |
applications.bucket |
delete | |
adoptionplans |
post | |
applications |
delete | |
applications.facts |
delete | |
applications.tags |
delete | |
assessments |
delete | |
businessservices |
delete | |
dependencies |
delete | |
identities |
get | |
imports |
delete | |
jobfunctions |
delete | |
proxies |
get | |
reviews |
delete | |
settings |
get | |
stakeholdergroups |
delete | |
stakeholders |
delete | |
tags |
delete | |
tagtypes |
delete | |
tasks |
delete | |
tasks.bucket |
delete | |
trackers |
get | |
tickets |
delete | |
cache |
get | |
files |
delete | |
rulebundles |
delete | |
tackle-migrator | Resource Name | Verbs |
addons |
get | |
adoptionplans |
post | |
applications |
get | |
applications.facts |
get | |
applications.tags |
get | |
applications.bucket |
get | |
assessments |
get | |
businessservices |
get | |
dependencies |
delete | |
identities |
get | |
imports |
get | |
jobfunctions |
get | |
proxies |
get | |
reviews |
get | |
settings |
get | |
stakeholdergroups |
get | |
stakeholders |
get | |
tags |
get | |
tagtypes |
get | |
tasks |
delete | |
tasks.bucket |
delete | |
tackers |
get | |
tickets |
get | |
cache |
get | |
files |
get | |
rulebundles |
get |