{"id":11574,"date":"2020-09-18T12:50:25","date_gmt":"2020-09-18T12:50:25","guid":{"rendered":"https:\/\/newblog.siteground.com\/it\/?p=11574"},"modified":"2023-03-02T12:15:18","modified_gmt":"2023-03-02T12:15:18","slug":"resoconto-sul-passaggio-cpanel-site-tools","status":"publish","type":"post","link":"https:\/\/it.siteground.com\/blog\/resoconto-sul-passaggio-cpanel-site-tools\/","title":{"rendered":"Rapporto sullo stato del passaggio da CPanel a Site Tools"},"content":{"rendered":"\n

\u00c8 passato poco pi\u00f9 di un anno da quando abbiamo lanciato la nostra nuova interfaccia<\/a>: l\u2019Area Cliente totalmente rinnovata e il Site Tools, entrambi sviluppati internamente per sostituire il cPanel. Nell’agosto 2019 abbiamo iniziato a caricare tutti i nuovi clienti sulla nuova interfaccia e subito dopo abbiamo iniziato a lavorare sulla migrazione dei vecchi clienti. Oggi tutti i nostri clienti stanno utilizzando la nuova Area Cliente e abbiamo anche convertito con successo pi\u00f9 di 9000 server da cPanel a Site Tools.<\/p>\n\n\n\n

Riguardando gli ultimi 12 mesi e considerando sia la complessit\u00e0 del processo di migrazione, sia le sfide alle quali il 2020 ci ha posto di fronte, credo che siamo riusciti a mantenere un ottimo ritmo di trasferimento. Questo risultato \u00e8 stato ottenuto grazie all’enorme lavoro svolto da tutti i team coinvolti nel processo. Tuttavia, abbiamo ancora molti account e server da trasferire e molti di voi potrebbero chiedersi perch\u00e9 ci vuole cos\u00ec tanto tempo e quando arriver\u00e0 il turno del proprio sito. Questo \u00e8 il motivo per cui abbiamo deciso di raccontarvi ci\u00f2 che abbiamo fatto nell\u2019ultimo anno e quali sono le previsioni per i prossimi mesi.<\/p>\n\n\n\n

<\/span>L’innata complessit\u00e0 della migrazione<\/span><\/h2>\n\n\n\n

Non sorprende che la migrazione di oltre un milione di siti live da cPanel a Site Tools sia un processo estremamente complesso. Posso tranquillamente dire che, in termini di sforzi e risorse necessarie, \u00e8 paragonabile alla creazione delle interfacce stesse. \u00c8 una vera sfida spostare i siti da una piattaforma con una certa struttura a una nuova piattaforma con una impostazione completamente diversa, senza compromettere il funzionamento dei siti in alcun modo.<\/p>\n\n\n\n

All\u2019apparenza sembra che ci sia poca differenza tra i due framework: si passa da siti aggiuntivi all\u2019avere tutti i siti sotto uno stesso tetto. In realt\u00e0 questo significa che dobbiamo essere in grado di districare eventuali siti subordinati dall’account cPanel principale e ricrearli come account indipendenti nella nostra nuova piattaforma. E per illustrare quanto possa essere complesso questo processo per diverse configurazioni di siti, elencher\u00f2 alcuni esempi di seguito:<\/p>\n\n\n\n

Pi\u00f9 domini aggiuntivi che utilizzano lo stesso database<\/h3>\n\n\n\n

Normalmente questa non \u00e8 una cosa che non dovrebbe accadere poich\u00e9 ogni sito, anche se aggiuntivo, dovrebbe utilizzare il proprio database. Tuttavia, questo era tecnicamente possibile con cPanel e ci sono siti impostati in questo modo dai nostri clienti. Quando un sito di questo tipo deve essere migrato, il nostro script di migrazione deve rilevare il caso specifico e creare un database separato per ogni sito e copiare i dati. Dopodich\u00e9 lo script riconfigura automaticamente ogni sito per utilizzare il rispettivo database.<\/p>\n\n\n\n

Applicazioni con percorsi assoluti nella loro configurazione<\/h3>\n\n\n\n

Un’altra cosa che lo script di migrazione deve correggere \u00e8 il fatto che pi\u00f9 applicazioni sono impostate per utilizzare percorsi assoluti nella loro configurazione. Il sistema deve rilevarli e, una volta che diventano siti indipendenti con diversi utenti , riconfigurarli automaticamente per utilizzare i nuovi percorsi di sistema.<\/p>\n\n\n\n

Opzioni di configurazione infinite di domini aggiuntivi, parcheggiati e sottodomini<\/h3>\n\n\n\n

Per il processo di trasferimento, la sfida pi\u00f9 grande sono il numero infinito di modi in cui gli utenti possono configurare (e talvolta rovinare) con cPanel i root path dei documenti per le diverse applicazioni quando utilizzano funzionalit\u00e0 di domini aggiuntivi, parcheggiati e sottodomini. Siamo riusciti a individuare oltre 30 diversi metodi \u201cnon ortodossi\u201d di configurazione dei root path. Uno degli esempi pi\u00f9 comuni \u00e8 quando pi\u00f9 di un dominio aggiuntivo \u00e8 configurato per utilizzare la stessa cartella. Questo \u00e8 un comune “hack” del sistema cPanel che le persone usano per parcheggiare un secondo dominio in un sito aggiuntivo – un’opzione che ufficialmente non sarebbe consentita in cPanel. Quindi, in tali configurazioni, il sistema deve decidere automaticamente a quale sito sta andando ciascun dominio e in quale ruolo (principale o parcheggiato). In alcuni casi la configurazione \u00e8 cos\u00ec complessa che i domini non possono essere configurati automaticamente e la migrazione deve essere eseguita manualmente.<\/p>\n\n\n\n

[subscribe_cta]<\/p>\n\n\n\n

<\/span>Compiti complessi di sviluppo<\/span><\/h2>\n\n\n\n

Automatizzare tutti i processi possibili<\/h3>\n\n\n\n

Abbiamo iniziato le nostre prime migrazioni nel settembre dello scorso anno con molta cautela. I siti migrati sono stati esaminati manualmente e ciascuno dei problemi sopra descritti, pi\u00f9 molti altri che sono apparsi, sono stati risolti con nuove iterazioni dello script di migrazione. Inutile dire che i controlli manuali delle prime migrazioni hanno richiesto molto tempo e non erano qualcosa che potesse essere sostenibile a lungo termine, quindi abbiamo aggiunto diverse automazioni allo script di migrazione.<\/p>\n\n\n\n

Ora eseguiamo controlli preliminari automatici di tutti gli account da migrare. Se c’\u00e8 un’indicazione di un possibile problema, lo risolviamo prima che la migrazione abbia inizio. Dopodich\u00e9 l’account viene effettivamente migrato da cPanel a Site Tools. Al termine della migrazione, eseguiamo un altro controllo automatico per gli eventuali problemi post-migrazione. Se viene rilevato un problema, l’account viene contrassegnato per la revisione manuale. Inoltre, abbiamo sviluppato un sistema automatizzato per comunicare lo stato di avanzamento di questo processo con il cliente di cui vengono migrati gli account. Con tutti questi sistemi ora in uso, siamo in grado di convertire circa 900 account cPanel al giorno con un tasso di problemi riscontrati molto basso.<\/p>\n\n\n\n

Passare alla nuova Area Cliente<\/h3>\n\n\n\n

All’inizio avevamo pianificato di migrare ogni cliente contemporaneamente alla nuova Area Cliente e al Site Tools. Tuttavia, ci siamo presto resi conto che sarebbe stato molto meglio slegare la nuova Area Cliente da Site Tools e spostare prima tutti i clienti su di essa. Questa decisione \u00e8 stata presa per diversi motivi:<\/p>\n\n\n\n