Importa server da Laravel Forge o Ploi

L'importazione porta in Vimonto Deploy i server che gestisci con Laravel Forge o Ploi, con i loro siti, processi, cron job, database e regole del firewall. Ogni server viene rilevato sul posto: non viene reinstallato nulla, i tuoi domini continuano a puntare alle stesse macchine e i siti continuano a funzionare mentre vengono trasferiti.

Dai a Vimonto Deploy un token API della piattaforma, scegli i server, e ogni server viene rilevato in un'attività a sé. Poi gestisci il server in Vimonto Deploy come qualsiasi altro e lo archivi in Forge o Ploi.

Prima di iniziare#

• Permessi. Per importare serve il permesso di creare server: il ruolo Proprietario, Amministratore o Manager.
• Spazio nel tuo piano. Ogni server importato e ogni sito che ospita contano per il tuo piano. La pagina controlla prima di iniziare che i server e i siti scelti ci stiano, e ogni server lo ricontrolla quando parte la sua attività. Con il piano gratuito (1 server e 3 siti) è un server con al massimo tre siti; per averne di più, cambia piano prima.
• Un token API della piattaforma, con i permessi descritti sotto.
• La tua chiave SSH (consigliata). Aggiungi la tua chiave pubblica in Account → Chiavi SSH per poter continuare ad accedere tu stesso; vedi chiavi SSH.

Crea il token API#

La pagina rimanda al punto giusto per la piattaforma scelta:

• Laravel Forge: crea un token su forge.laravel.com/profile/api. Vimonto Deploy usa l'API delle organizzazioni di Forge ed elenca i server di ogni organizzazione Forge che il token può vedere. Il token deve poter leggere server e siti (compresi il file di ambiente e lo script di deploy), creare ed eseguire recipe e disattivare il push to deploy.
• Ploi: crea una chiave API su ploi.io/profile/api-keys. Deve poter leggere server e siti (compresi il file di ambiente e lo script di deploy), creare ed eseguire script e disattivare il quick deploy.

Il token serve solo a leggere i tuoi server e a eseguire uno script che dà accesso a Vimonto Deploy. Viene salvato cifrato e cancellato non appena ogni server di quell'account è importato (o è già nella tua organizzazione). Anche Usa un altro account lo cancella.

Se la piattaforma rifiuta il token, la pagina lo dice sotto il campo: … ha rifiutato il token API, Al token di … manca un permesso necessario oppure … sta limitando le richieste; riprova tra un minuto.

Importa server passo dopo passo#

1. Vai su Server, apri la freccia accanto a Nuovo server e scegli Importa da Forge o Ploi. Si apre la pagina Importa server.
2. In Dove sono ora i tuoi server? scegli Laravel Forge o Ploi.
3. Incolla il token in Token API e fai clic su Leggi i miei server. Sui tuoi server non cambia ancora nulla: Vimonto Deploy legge soltanto l'account.
4. Il pannello Server in Laravel Forge (o Server in Ploi) elenca ogni server con indirizzo IP, versione di PHP, database, versione di Ubuntu e i domini dei suoi siti. I server il cui indirizzo IP è già nella tua organizzazione mostrano Già qui e non si possono scegliere; gli altri mostrano Pronto per l'importazione e sono tutti spuntati. Togli la spunta a quelli che vuoi lasciare.
5. Leggi la nota accanto al pulsante, poi fai clic sul pulsante di importazione (ad esempio Importa 2 server).

Ogni server diventa un'attività a sé, Importa … da …. Il suo stato passa a In coda, poi Importazione in corso, poi Importato o Non riuscito. Sotto ogni server la pagina mostra il passaggio in corso e, man mano, un resoconto di cosa è stato fatto e di cosa richiede la tua attenzione. Puoi chiudere la pagina: le attività continuano, ricevi un messaggio nella scheda che hai aperta quando ognuna finisce, e le trovi con l'output completo nella pagina attività.

Cosa succede a ogni server?#

L'attività ha sei passaggi.

1. Leggi il server e i suoi siti#

Vimonto Deploy legge tutto ciò che la piattaforma sa del server: i suoi siti, i processi in background e i queue worker, i cron job, i database, gli utenti del database e le regole del firewall. Ciò che la piattaforma invia e non si può usare in sicurezza (ad esempio un dominio, una cartella o un nome utente non valido) resta indietro, e il resoconto dice … non è stato importato: la piattaforma ha inviato impostazioni che non si possono usare in sicurezza.

2. Aggiungi il server qui#

Il server entra nella tua organizzazione come App server, con nome, indirizzo IP pubblico e privato, versione di PHP, database e versione di Ubuntu. Riceve una coppia di chiavi SSH tutta sua, come ogni server in Vimonto Deploy. Non è collegato a un account cloud: lo gestisci come un custom VPS.

3. Ottieni l'accesso al server#

Tramite la piattaforma, Vimonto Deploy esegue uno script come root su quel server: una recipe in Forge, uno script in Ploi. Lo script aggiunge la nuova chiave pubblica del server a /root/.ssh/authorized_keys. Se SSH era impostato su PermitRootLogin no, lo cambia in prohibit-password, così root può accedere con una chiave, mai con una password. Poi Vimonto Deploy attende fino a 5 minuti che SSH lo faccia entrare.

Quindi esamina la macchina stessa: la versione di Ubuntu, le versioni di PHP installate, i programmi Supervisor e, per ogni sito, se la cartella esiste, se è un'app Laravel e se gira sul posto o da release. Le versioni di PHP trovate compaiono nella pagina PHP del server, e SSH, HTTP e HTTPS come regole del firewall standard del server.

4. Rileva processi e cron job#

• Database e regole del firewall vengono registrati così come sono: i database, gli utenti del database e i database che possono usare, e le regole del firewall oltre a SSH, HTTP e HTTPS. Sul server non cambia nulla.
• Programmi Supervisor: ogni programma che non è di Vimonto Deploy passa da /etc/supervisor/conf.d a /root/vimonto-takeover-backup/supervisor, e Vimonto Deploy scrive i propri processi in base a ciò che la piattaforma ha riportato. Il resoconto elenca i programmi spostati.
• Cron job: una copia del crontab dell'utente di sistema e di root va in /root/vimonto-takeover-backup/cron, e le righe che eseguono un cron job della piattaforma vengono tolte; il resto di ogni crontab rimane. Lo stesso avviene in /etc/crontab (copiato prima), e i file in /etc/cron.d che eseguono un job della piattaforma vanno nella cartella di backup. Vimonto Deploy riscrive i job come job pianificati.

I queue worker di un sito e i cron job che eseguono lo schedule:run di un sito non vengono creati qui: si spostano con il loro sito nel passaggio successivo.

5. Trasferisci i siti#

I siti vengono trasferiti uno alla volta. Un sito che non si può trasferire non blocca gli altri: il resoconto dice … non è stato trasferito: con il motivo, ad esempio quando la sua cartella non è sul server.

Per ogni sito:

1. Il sito viene aggiunto con dominio e alias, cartella, cartella web, versione di PHP, repository e branch, e il suo framework (Laravel, Statamic, WordPress, Symfony, HTML statico, Nuxt, Next.js o PHP semplice). Un sito che girava con un proprio utente Linux resta isolato sotto quell'utente. Il .env viene letto dalla piattaforma. Non viene aggiunta una nuova deploy key: il server mantiene l'accesso a Git che la piattaforma ha configurato.
2. Lo script di deploy viene tradotto: le righe che fanno cd nel sito o eseguono git pull, fetch, reset, checkout o clean vengono tolte (qui ogni deploy parte da un checkout nuovo), le variabili di Forge e Ploi diventano quelle di Vimonto Deploy ($FORGE_SITE_PATH e {SITE_DIRECTORY} diventano $VIMONTO_RELEASE_PATH e così via), i comandi di release di Forge vengono tolti, e il reload di PHP-FPM sparisce, perché ogni deploy ricarica PHP-FPM da sé. Se resta una variabile della piattaforma, il resoconto dice Lo script di deploy usa ancora …; controllalo in Deploy. Vedi deployment.
3. Il certificato attivo viene portato con sé: il certificato e la chiave con cui la configurazione Nginx della piattaforma serve il sito vengono installati come certificato del sito, così HTTPS continua durante il passaggio.
4. Il codice passa alla struttura delle release: il codice live viene copiato (non spostato) in releases/000000-migrated, il .env va in shared/.env, lo storage di Laravel in shared/storage, e current punta alla release. È la struttura di ogni deployment in Vimonto Deploy.
5. Nginx commuta con un solo reload: Vimonto Deploy scrive la propria configurazione del sito, sposta i file Nginx della piattaforma per i nomi del sito in /root/vimonto-takeover-backup/nginx e controlla il risultato con nginx -t. Se Nginx non lo accetta, i file della piattaforma tornano al loro posto e il sito continua a funzionare come prima. Altrimenti Nginx si ricarica una volta. storage viene copiato di nuovo dopo il passaggio, così gli upload arrivati nel frattempo restano, e PHP-FPM si ricarica.
6. La vecchia copia viene rimossa: per un sito che girava sul posto, tutto ciò che si trova nella cartella del sito tranne releases, shared, current e .ssh viene rimosso, perché la release contiene tutto. Un sito che aveva già delle release (i deployment zero-downtime di Forge o quelli di Ploi) mantiene le sue cartelle, perché lì ci sono i suoi file condivisi.
7. Worker e funzionalità: i queue worker del sito diventano i worker del sito e puntano dentro current. Un worker che esegue artisan horizon diventa la funzionalità del sito Horizon, e un sito Laravel per cui è stato trovato un cron job con schedule:run riceve la funzionalità scheduler.
8. Il push to deploy viene disattivato presso la piattaforma, così un push non fa il deploy due volte. Il resoconto lo segnala; riattivalo qui in Deployment del sito (Deploy a ogni push).
9. Viene richiesto un certificato Let's Encrypt per un sito arrivato con un certificato. Da quel momento Vimonto Deploy lo rinnova. Se la richiesta non riesce, il certificato portato con sé continua a servire il sito. Se un sito Forge aveva HTTPS ma il suo certificato non è stato letto, il resoconto ti dice di richiederne uno in Domini e SSL.

6. Completa#

Vimonto Deploy installa il suo agente di monitoraggio e imposta il server su Attivo. Il resoconto termina con … ora è gestito qui. Archivialo in … così non viene gestito da entrambi.

Cosa resta uguale?#

• La macchina e il suo indirizzo. Il server resta presso il tuo provider con lo stesso indirizzo IP, quindi domini e DNS non devono cambiare. Continui a pagare direttamente il provider.
• L'utente di sistema. Il server mantiene il suo utente di sistema, forge o ploi, e i siti restano nella sua home.
• I tuoi siti continuano a funzionare. Il codice live continua a servire fino al passaggio di Nginx, che è un solo reload, quindi i visitatori non notano nulla.
• Software, database e dati. Non viene reinstallato né aggiornato nulla, e i database non vengono toccati.
• Password. La password sudo del server e le password dei database sono quelle della piattaforma. Vimonto Deploy non le ha mai avute, quindi non le mostra.

Cosa fai tu dopo?#

• Archivia il server in Forge o Ploi, così lo gestisce una sola delle due piattaforme. Archivialo invece di eliminarlo: eliminare un server nella piattaforma può eliminare la macchina presso il tuo provider.
• Leggi il resoconto sotto ogni server e occupati dei suoi avvisi.
• Riattiva il push to deploy in Deployment del sito, e controlla lì lo script di deploy tradotto.
• Fai un deploy con Fai il deploy per verificare che il sito si costruisca qui.
• Siti Ploi con domini aggiuntivi: l'API di Ploi non li invia, quindi aggiungili in Domini e SSL del sito.
• Rimuovi la recipe o lo script di accesso da Forge o Ploi se vuoi; ha fatto il suo lavoro.
• Disdici l'abbonamento a Forge o Ploi quando ogni server è stato trasferito, se non ti serve più.

Come annulli un rilevamento?#

Nulla di ciò che la piattaforma ha creato viene eliminato: si trova in /root/vimonto-takeover-backup sul server.

Per tornare indietro accedi come root, rimetti i file in /etc/supervisor/conf.d, /etc/nginx/sites-enabled e /etc/cron.d, ripristina un crontab con crontab -u forge /root/vimonto-takeover-backup/cron/forge.crontab, togli la configurazione del sito di Vimonto Deploy da /etc/nginx/sites-enabled, poi esegui supervisorctl reread && supervisorctl update, nginx -t e systemctl reload nginx. Il codice di un sito che girava sul posto ora si trova in releases/000000-migrated (tramite current), quindi fai puntare la root Nginx della piattaforma a current oppure rimetti il codice al suo posto. Poi elimina il server in Vimonto Deploy.

Cosa fare se un'importazione non riesce?#

Il server mostra Non riuscito con l'errore nel suo resoconto, e l'output completo dell'attività è nella pagina attività. Cause comuni:

• Lo script di accesso non è partito in tempo. L'attività dice Non siamo riusciti ad accedere come root a … su …. Controlla che la recipe o lo script sia stato eseguito nella piattaforma, poi riprova tra qualche minuto.
• Il server non ha un indirizzo IP nella piattaforma, o non è più nell'account.
• Manca la cartella di un sito: viene saltato solo quel sito, il resto del server viene importato.

Un server non riuscito si può spuntare di nuovo: risolvi la causa e fai clic sul pulsante di importazione. Un server mai raggiunto viene rimosso e quindi aggiunto da capo; uno raggiunto viene riutilizzato. L'importazione non si può annullare mentre è in corso.

Domande frequenti#

I miei siti vanno offline durante l'importazione?#

No. Il codice viene copiato, non spostato, e continua a servire finché Nginx non passa alla nuova configurazione con un solo reload. Se Nginx non accetta la nuova configurazione, torna quella vecchia.

Posso continuare a usare Forge o Ploi in parallelo?#

Non per lo stesso server. Entrambi ci scriverebbero programmi Supervisor, cron job e configurazioni Nginx. Archivia ogni server nella piattaforma appena è importato. I server che non importi restano in Forge o Ploi così come sono.

Quali server si possono importare?#

Ogni server dell'account Forge o Ploi che ha un indirizzo IP e su cui la piattaforma può eseguire uno script come root. Un server il cui indirizzo IP è già nella tua organizzazione mostra Già qui. I server importati diventano app server; i loro siti devono avere un dominio valido e una cartella che esiste sul server.

E Envoyer o i siti zero-downtime?#

I siti che fanno già il deploy in release (i deployment zero-downtime di Forge o quelli di Ploi) sono supportati: la release attuale viene copiata in releases/000000-migrated e le loro cartelle restano al loro posto. Envoyer non viene letto: un sito distribuito da Envoyer viene importato in base a ciò che riporta Forge, quindi disattiva i suoi deployment in Envoyer e fai il deploy da Vimonto Deploy.

Devo disdire l'abbonamento a Forge o Ploi?#

Non per l'importazione: serve un account attivo e un token. Quando ogni server è stato trasferito e archiviato, puoi disdirlo tu. Vimonto Deploy non lo fa al posto tuo.

Viene reinstallato o aggiornato qualcosa?#

No. L'importazione non esegue il provisioning. PHP, il database, Nginx e il resto restano alle versioni installate dalla piattaforma.