Skip to main content
A newer release of this product is available.

Clone and migrate apps

Contributors netapp-dbagwell
PDFs

You can clone an existing app to create a duplicate app on the same Kubernetes cluster or on another cluster. When Astra Control clones an app, it creates a clone of your application configuration and persistent storage.

Cloning can help if you need to move applications and storage from one Kubernetes cluster to another. For example, you might want to move workloads through a CI/CD pipeline and across Kubernetes namespaces. You can use the Astra Control Center UI or the Astra Control API to clone and migrate apps.

Note If you add a namespace filter to an execution hook that runs after a restore or clone operation and the restore or clone source and destination are in different namespaces, the namespace filter is only applied to the destination namespace.
Before you begin

  • Check destination volumes: If you clone to a different storage class, ensure that the storage class uses the same persistent volume access mode (for example, ReadWriteMany). The clone operation will fail if the destination persistent volume access mode is different. For example, if your source persistent volume uses the RWX access mode, selecting a destination storage class that is not able to provide RWX, such as Azure Managed Disks, AWS EBS, Google Persistent Disk or ontap-san, will cause the clone operation to fail. For more information about persistent volume access modes, refer to the Kubernetes documentation.

  • To clone apps to a different cluster, you need to make sure the cloud instances containing the source and destination clusters (if they are not the same) have a default bucket. You'll need to assign a default bucket for each cloud instance.

  • During clone operations, apps that need an IngressClass resource or webhooks to function properly must not have those resources already defined on the destination cluster.

Note

During app cloning in OpenShift environments, Astra Control Center needs to allow OpenShift to mount volumes and change the ownership of files. Because of this, you need to configure an ONTAP volume export policy to allow these operations. You can do so with the following commands:

  1. export-policy rule modify -vserver <storage virtual machine name> -policyname <policy name> -ruleindex 1 -superuser sys

  2. export-policy rule modify -vserver <storage virtual machine name> -policyname <policy name> -ruleindex 1 -anon 65534
Clone limitations

  • Explicit storage classes: If you deploy an app with a storage class explicitly set and you need to clone the app, the target cluster must have the originally specified storage class. Cloning an application with an explicitly set storage class to a cluster that does not have the same storage class will fail.

  • ontap-nas-economy-backed storage class: If your app uses a storage class backed by the ontap-nas-economy driver, the backup portion of a clone operation is disruptive. The source application is not available until the backup is complete. The restore portion of the clone operation is non-disruptive.

  • Clones and user constraints: Any member user with namespace constraints by namespace name/ID or by namespace labels can clone or restore an app to a new namespace on the same cluster or to any other cluster in their organization's account. However, the same user cannot access the cloned or restored app in the new namespace. After a new namespace is created by a clone or restore operation, the account admin/owner can edit the member user account and update role constraints for the affected user to grant access to the new namespace.

  • Clones use default buckets: During an app backup or app restore, you can optionally specify a bucket ID. An app clone operation, however, always uses the default bucket that has been defined. There is no option to change buckets for a clone. If you want control over which bucket is used, you can either change the bucket default or do a backup followed by a restore separately.

  • With Jenkins CI: If you clone an operator-deployed instance of Jenkins CI, you need to manually restore the persistent data. This is a limitation of the app's deployment model.

  • With S3 buckets: S3 buckets in Astra Control Center do not report available capacity. Before backing up or cloning apps managed by Astra Control Center, check bucket information in the ONTAP or StorageGRID management system.

OpenShift considerations

  • Clusters and OpenShift versions: If you clone an app between clusters, the source and destination clusters must be the same distribution of OpenShift. For example, if you clone an app from an OpenShift 4.7 cluster, use a destination cluster that is also OpenShift 4.7.

  • Projects and UIDs: When you create a project for hosting an app on an OpenShift cluster, the project (or Kubernetes namespace) is assigned a SecurityContext UID. To enable Astra Control Center to protect your app and move the app to another cluster or project in OpenShift, you need to add policies that enable the app to run as any UID. As an example, the following OpenShift CLI commands grant the appropriate policies to a WordPress app.

    oc new-project wordpress
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:wordpress
    oc adm policy add-scc-to-user privileged -z default -n wordpress

Steps

  1. Select Applications.

  2. Do one of the following:

    • Select the Options menu in the Actions column for the desired app.

    • Select the name of the desired app, and select the status drop-down list at the top right of the page.

  3. Select Clone.

  4. Specify details for the clone:

    • Enter a name.

    • Choose a destination cluster for the clone.

    • Enter destination namespaces for the clone. Each source namespace associated with the app maps to the destination namespace you define.

      Note Astra Control creates new destination namespaces as part of the clone operation. Destination namespaces that you specify must not be already present on the destination cluster.

    • Select Next.

    • Choose whether you want to create the clone from an existing snapshot or backup. If you don't select this option, Astra Control Center creates the clone from the app's current state.

      • If you chose to clone from an existing snapshot or backup, choose the snapshot or backup that you'd like to use.

    • Select Next.

    • Choose to keep the original storage class associated with the app or select a different storage class.

      Note You can migrate an app's storage class to a native cloud provider storage class or other supported storage class, migrate an app from a storage class backed by ontap-nas-economy to a storage class backed by ontap-nas on the same cluster, or copy the app to another cluster with a storage class backed by the ontap-nas-economy driver.
      Note If you select a different storage class and this storage class doesn't exist at the moment of restore, an error will be returned.

  5. Select Next.

  6. Review the information about the clone and select Clone.

Result

Astra Control clones the app based on the information that you provided. The clone operation is successful when the new app clone is in Healthy state on the Applications page.

After a new namespace is created by a clone or restore operation, the account admin/owner can edit the member user account and update role constraints for the affected user to grant access to the new namespace.

Note After a data protection operation (clone, backup, or restore) and subsequent persistent volume resize, there is up to a twenty-minute delay before the new volume size is shown in the UI. The data protection operation is successful within minutes, and you can use the management software for the storage backend to confirm the change in volume size.