Per clonare le applicazioni in un cluster diverso, è necessario assicurarsi che le istanze cloud che contengono i cluster di origine e di destinazione (se non sono uguali) abbiano un bucket predefinito. Sarà necessario assegnare un bucket predefinito per ogni istanza del cloud.

Durante le operazioni di cloni, le applicazioni che necessitano di una risorsa IngressClass o di webhook per funzionare correttamente non devono disporre di tali risorse già definite nel cluster di destinazione.

Classi di storage esplicite: Se si implementa un’applicazione con una classe di storage esplicitamente impostata e si deve clonare l’applicazione, il cluster di destinazione deve avere la classe di storage specificata in origine. La clonazione di un’applicazione con una classe di storage esplicitamente impostata su un cluster che non ha la stessa classe di storage non avrà esito positivo.

Cloni e vincoli dell’utente: Qualsiasi utente membro con vincoli dello spazio dei nomi in base al nome/ID dello spazio dei nomi o alle etichette dello spazio dei nomi può clonare o ripristinare un’applicazione in un nuovo spazio dei nomi sullo stesso cluster o in qualsiasi altro cluster dell’account dell’organizzazione. Tuttavia, lo stesso utente non può accedere all’applicazione clonata o ripristinata nel nuovo namespace. Dopo la creazione di un nuovo spazio dei nomi mediante un’operazione di clone o ripristino, l’amministratore/proprietario dell’account può modificare l’account utente membro e aggiornare i vincoli di ruolo per consentire all’utente interessato di accedere al nuovo spazio dei nomi.

I cloni utilizzano bucket predefiniti: Durante il backup o il ripristino di un’applicazione, è possibile specificare un ID bucket. Un’operazione di cloni dell’applicazione, tuttavia, utilizza sempre il bucket predefinito definito. Non esiste alcuna opzione per modificare i bucket per un clone. Se si desidera controllare quale bucket viene utilizzato, è possibile farlo "modificare l’impostazione predefinita del bucket" oppure fare una "backup" seguito da un "ripristinare" separatamente.

Con Jenkins ci: Se si clonano istanze distribuite dall’operatore di Jenkins ci, è necessario ripristinare manualmente i dati persistenti. Si tratta di un limite del modello di implementazione dell’applicazione.

Con i bucket S3: I bucket S3 in Astra Control Center non riportano la capacità disponibile. Prima di eseguire il backup o la clonazione delle applicazioni gestite da Astra Control Center, controllare le informazioni del bucket nel sistema di gestione ONTAP o StorageGRID.

Versioni di Clusters e OpenShift: Se clonate un’applicazione tra cluster, i cluster di origine e di destinazione devono essere la stessa distribuzione di OpenShift. Ad esempio, se clonate un’applicazione da un cluster OpenShift 4.7, utilizzate un cluster di destinazione che è anche OpenShift 4.7.

Progetti e UID: Quando crei un progetto per ospitare un’applicazione su un cluster OpenShift, al progetto (o namespace Kubernetes) viene assegnato un UID SecurityContext. Per consentire ad Astra Control Center di proteggere la tua applicazione e spostarla in un altro cluster o progetto in OpenShift, devi aggiungere policy che consentano all’applicazione di essere eseguita come qualsiasi UID. Ad esempio, i seguenti comandi CLI di OpenShift concedono le policy appropriate a un’applicazione WordPress.