Un trasferimento sposta un server, con i suoi siti, i database e tutto ciò che contiene, da un'organizzazione di Vimonto Deploy a un'altra. Offri il server a qualcuno via email; questa persona lo accetta in una delle sue organizzazioni e da quel momento è suo. Sul server non cambia nulla: continua a funzionare e i suoi siti restano online.
Usalo per consegnare un server a un cliente, per spostarlo nell'organizzazione di un collega o per spostarlo tra due delle tue organizzazioni.
Chi può trasferire un server?
- Inviare un trasferimento richiede il permesso di eliminare server nell'organizzazione attuale: il ruolo Proprietario, Amministratore o Manager. Vedi membri e ruoli.
- Accettare un trasferimento richiede un account Vimonto Deploy con l'indirizzo email a cui è stato inviato, e il permesso di creare server nell'organizzazione di destinazione: anche qui Proprietario, Amministratore o Manager.
Il destinatario non deve essere membro della tua organizzazione. Se non ha ancora un account, può crearne uno dal link nell'email.
Inviare un trasferimento
- Apri il server e scegli Impostazioni nella barra laterale.
- In Zona pericolosa, fai clic su Trasferisci server.
- Inserisci l'Indirizzo email del nuovo proprietario e fai clic su Invia il trasferimento.
Il destinatario riceve un'email con il pulsante Vedi il trasferimento. Finché non accetta, non cambia nulla: il server resta nella tua organizzazione e funziona come prima. La Zona pericolosa mostra a chi è offerto il server e fino a quando.
Alcune regole:
- Puoi inviare un trasferimento solo quando sul server non è in corso nessuna attività, come un deployment o il provisioning.
- Un server ha un solo trasferimento aperto alla volta. Inviarne uno nuovo sostituisce l'offerta precedente, e il vecchio link smette di funzionare.
- Puoi inviare un trasferimento al tuo indirizzo email solo se sei membro di un'altra organizzazione, per spostarci il server.
- Quando il trasferimento viene accettato, la tua organizzazione perde l'accesso: le chiavi SSH della tua organizzazione e dei suoi membri vengono rimosse dal server, e cambiano la password sudo del server e gli URL di deploy dei siti. Vedi Come perde l'accesso la vecchia organizzazione? più sotto.
Per quanto tempo vale un trasferimento?
Sette giorni. Dopo, il link non funziona più e, se serve, invii un nuovo trasferimento. Il link smette di funzionare anche quando il trasferimento è stato accettato o annullato, o quando il server non è più nell'organizzazione da cui è stato offerto.
Per ritirare un'offerta, fai clic su Annulla il trasferimento nella Zona pericolosa delle impostazioni del server. I trasferimenti scaduti vengono eliminati automaticamente.
Accettare un trasferimento
- Apri il link nell'email. Se non hai effettuato l'accesso, scegli Accedi o Crea account con l'indirizzo email a cui è stato inviato il trasferimento; poi torni al trasferimento.
- La pagina Prendi in carico … mostra il server, il suo indirizzo IP e il numero di siti. In Prima di accettare elenca per questo server Cosa facciamo noi per te e Da fare ancora tu (vedi sotto), poi cosa resta indietro.
- In Nell'organizzazione, scegli l'organizzazione in cui spostare il server. Compaiono solo le organizzazioni in cui puoi creare server.
- Fai clic su Accetta il server.
Il server e i suoi siti contano per il piano dell'organizzazione in cui lo sposti: con il piano gratuito l'accettazione viene rifiutata se non ci stanno.
Il server viene spostato subito e la sua pagina si apre nella tua organizzazione. Se sul server è ancora in corso qualcosa, aspetta un minuto e riprova. Se non hai un'organizzazione che può ricevere il server, creane prima una (vedi organizzazioni).
Subito dopo l'accettazione ricevi un'email, … ora è tuo: cosa fare adesso, con le stesse due liste e un pulsante Visualizza server. La nuova password sudo non c'è: arriva in un'email separata appena viene impostata.
Cosa si sposta con il server?
Si sposta tutto ciò che si trova sul server: i siti con i loro domini, certificati, environment, script di deploy e cronologia dei deployment, i database e gli utenti del database, le versioni di PHP, i processi, i job pianificati, le regole del firewall, il monitoraggio e le sue impostazioni. Le chiavi SSH non si spostano, tranne quelle della tua organizzazione e dei suoi membri (vedi sotto).
Si spostano anche la coppia di chiavi del server e la sua chiave host SSH, quindi Vimonto Deploy continua a collegarsi come prima.
Cosa resta nella vecchia organizzazione?
Ciò che appartiene all'organizzazione e non al server non si sposta:
| Cosa | Cosa succede |
|---|---|
| Account del provider | Il server non è più collegato all'account cloud con cui è stato creato. Continua a funzionare lì e viene ancora fatturato a quell'account: spostalo tu dal provider se serve. Dalla nuova organizzazione, eliminarlo interrompe solo la gestione; la macchina presso il provider non può più essere eliminata. |
| Connessioni Git | I siti perdono la loro connessione Git, e il Quick deploy viene disattivato. |
| Backup | Le pianificazioni dei backup e il loro elenco di backup vengono rimossi. I file di backup restano nello storage della vecchia organizzazione. |
| Team | Il server viene tolto dai team della vecchia organizzazione. |
| Load balancer | I collegamenti tra questo server e i load balancer della vecchia organizzazione vengono rimossi in entrambe le direzioni, e la configurazione Nginx dei siti interessati viene riscritta. Vedi bilanciamento del carico. |
Il trasferimento viene registrato nel registro di audit di entrambe le organizzazioni: l'invio, l'annullamento e l'accettazione.
Come perde l'accesso la vecchia organizzazione?
Nel momento in cui il server si sposta, e in un'attività subito dopo, Vimonto Deploy toglie l'accesso che la vecchia organizzazione ha ancora:
| Cosa | Cosa succede |
|---|---|
| URL di deploy | Ogni sito riceve subito un nuovo URL di deploy. Il vecchio URL non funziona più, quindi la vecchia organizzazione non può più avviare deployment dalla sua CI o dal suo webhook Git. |
| Chiavi SSH | L'attività Proteggi server dopo il trasferimento rimuove ogni chiave che Vimonto Deploy ha messo sul server e che non è una chiave della nuova organizzazione o una chiave dell'account di uno dei suoi membri: le chiavi della vecchia organizzazione, quelle dei suoi membri e le chiavi aggiunte nella pagina Chiavi SSH del server. Poi aggiunge le chiavi SSH della nuova organizzazione. |
| Password sudo | La stessa attività dà all'utente di sistema una nuova password sudo. Solo chi ha accettato la vede, una volta, nella finestra Password di server della panoramica, e ne riceve una copia via email. Vedi impostazioni del server. |
| Avvisi | Monitor e heartbeat scrivono da quel momento a chi ha accettato invece che ai vecchi indirizzi. |
| Comando di collegamento | Un VPS personalizzato che aspettava ancora il suo comando di collegamento ne riceve uno nuovo; quello vecchio non funziona più. |
Nella panoramica il nuovo proprietario vede Questo server ti è stato trasferito, con cosa è stato fatto e cosa resta da fare. Se l'attività non è riuscita, per esempio perché il server non era raggiungibile, fai clic su Riprova. Fai clic su Ho capito per nascondere l'avviso.
Vimonto Deploy non cambia ciò che metterebbe offline i tuoi siti o ciò che non conosce: la password del database (i siti la leggono dal loro ambiente), i segreti nell'ambiente dei siti come APP_KEY e gli accessi configurati sul server al di fuori di Vimonto Deploy. Anche gli URL di ping degli heartbeat restano gli stessi, perché li chiamano i job pianificati sul server, e le deploy key dei siti possono ancora leggere i repository della vecchia organizzazione finché questa non le rimuove dal suo host Git.
Dopo l'accettazione: cosa deve fare il nuovo proprietario?
La lista Da fare ancora tu nella pagina di accettazione, nell'email e nell'avviso della panoramica mostra i punti qui sotto che valgono per il tuo server.
- Ricollega Git. Collega i siti a una tua connessione Git e riattiva il Quick deploy dove lo vuoi. Vedi deployment. La deploy key dei siti può ancora leggere il repository della vecchia organizzazione finché non la rimuove dal suo host Git.
- Salva la nuova password sudo dalla finestra Password di server nella panoramica, poi fai clic su Le ho salvate. Accettando diventi il creatore del server nella panoramica, quindi solo tu la vedi lì (Mostra una volta).
- Aggiorna la tua CI. Ogni sito ha un nuovo URL di deploy: copialo dalla pagina Deployment del sito nella tua CI.
- Pianifica i backup verso il tuo storage nella pagina backup.
- Cambia la password del database se il server ha un database: nella pagina Database fai clic su Cambia password sull'utente di sistema, poi inserisci la nuova password nel
.envdei siti che la usano. Vimonto Deploy non la cambia per te, perché i siti la leggono dal loro.enve andrebbero offline. Cambia anche gli altri segreti che il vecchio proprietario conosce, comeAPP_KEYe le chiavi API. - Ricrea gli heartbeat se i loro URL devono restare segreti. Gli URL di ping degli heartbeat restano gli stessi, perché li chiamano i job pianificati sul server; quindi la vecchia organizzazione li conosce. Elimina gli heartbeat nella pagina Monitoring, aggiungili di nuovo e inserisci i nuovi URL nei tuoi job.
- Controlla gli accessi al di fuori di Vimonto Deploy. Le chiavi aggiunte a mano in
authorized_keyse gli utenti Linux in più non sono noti a Vimonto Deploy e restano. Rimuovili se serve. - Aggiungilo ai tuoi team se i membri della tua organizzazione vedono solo i server dei loro team. Fino ad allora lo vedono solo i membri che vedono tutti i server.
- Configura di nuovo il bilanciamento del carico se il server era dietro un load balancer.
Domande frequenti
Il server va offline durante un trasferimento?
No. Un trasferimento cambia solo l'organizzazione che gestisce il server in Vimonto Deploy. Sul server non viene eseguito nulla e i suoi siti continuano a servire i visitatori.
Posso spostare un server tra le mie organizzazioni?
Sì. Invia il trasferimento al tuo indirizzo email, apri il link e scegli l'altra organizzazione in Nell'organizzazione. Ti serve il permesso di eliminare server nella prima organizzazione e di crearne nella seconda.
La vecchia organizzazione può ancora accedere al server?
Non tramite Vimonto Deploy: i suoi URL di deploy smettono subito di funzionare, e le sue chiavi SSH e la vecchia password sudo vengono rimosse dal server subito dopo. Restano come prima solo ciò che è stato configurato al di fuori di Vimonto Deploy e la password del database; cambiali tu. Finché la macchina è nel loro account del provider, la vecchia organizzazione può ancora gestirla lì. Anche gli URL di ping degli heartbeat restano gli stessi, finché non ricrei gli heartbeat.
Anche la fatturazione presso il provider cloud si sposta?
No. Il server resta nell'account del provider in cui è stato creato, che continua a fatturarlo. Per spostarlo su un altro account del provider, usa la funzione di trasferimento del provider; dopo viene gestito in Vimonto Deploy come un VPS personale.
E se il destinatario non accetta mai?
Allora non succede nulla. Il trasferimento scade dopo sette giorni e il server resta dov'è. Puoi anche annullarlo prima con Annulla il trasferimento.