Drush 3.0 - lo strumento di amministrazione di Drupal

10 contenuti / 0 new

Accedi o registrati per inserire commenti.

Ven, 04/06/2010 - 23:51

Bene, sto dedicando un paio di giorni ad aggiornare i miei script per aggiornare e configurare Drupal. Precendentemente usavo Drush quasi esclusivamente per creare i miei progetti Drupal in locale.

Insieme ad altri script per creare la basedati, e costruire gli indirizzi del progetto sul hard disk, Drush mi aiutava scaricare la versione di Drupal, ed anche moduli e temi contribuiti. Non sono l'unico qui di aver apprezzato i suoi doti, ed anche il notevole tempo risparmiato. Posso creare un sito in locale, già visibile dal browser, tramite Apache, con una manciata di moduli installati, in meno di 10 minuti.

Per quanto riguardava i siti su hosting invece, usavo altri script per aggiornare la basedati e files. Essenzialmente questo significa avere un accesso ssh, ed anche rsync. Sceglo appositamente hosting che forniscono questi servizi, perchè senza il costo di mantenimento di un sito (tramite phpmyadmin e ftp) è troppo alto. Costretto ad usare Aruba per un cliente, mi rendo conto che ci impiego forse 15/30 minuti per fare operazioni che con ssh e rsync costono meno di 5 minuti.

Quote:
Drush, ssh, rsync - ma sono davvero necessario?
Dipende - per me si, anche se gestisci un sito solo. Ricordi com'era debuggare una pagina HTML prima di Firebug? Stessa cosa passando da phpmyadmin/FTP a questo trio.
Drush ti permette di pilotare il tuo sito Drupal dal command line. Vuoi aggiungere un modulo - "c'è un comando per quello"™, aggiornare il sito, metterlo offline, abilitare o disabilitare un modulo, cancellare il cache? Credo che hai capito.
ssh è una finestra sul server. Qui PuTTY è il tuo amico. Basta imparare una manciata di comandi Unix, ed inizi a volare - creare archivi dei files, fare un dump della basedati. Se impari anche fare il tunneling, poi usare strumenti potenti quale MySQL Query Browser sul tuo PC, ma guardando la basedati del server.
rsync sincronizzare due file system - anche remoto. Comprime i files, trasferendo solo quelli cambiati. E' funzione sempre. Lascia che lui lavora, bevi un buon caffè, ed è tutto pronto. Puoi dire lo stesso per FTP?

Ad ogni versione nuovo di Drush, ho potuto mettere in pensione qualche script mio in più - li tengo per altri sistemi ovviamente, oltre che per pure nostalgia. Inoltre, ci sono sempre più moduli contribuiti che includono comandi drush - backup and migrate per esempio, è questo aumenta sempre di più la sua potenza.

Di solito occore ogni tanti in tanti aggiornare il sito, o fare modifiche. Io li faccio sempre in locale. Quindi devo copiare la basedati, ed i files cambiati dal server in locale. Adesso con Drush puoi farlo in due mosse drush rsync e drush sql-sync. In più adesso ha dei alias quindi non sono più costretto ad entrare nel root di Drupal per un sito o l'altro per eseguire Drush, posso farlo altrove e semplicemente specificare l'alias del sito, @dev o @prod.

Non è senza spigoli, quindi cercerò di annotare i risultati dei miei esperimenti più avanti.

Se vuoi aggiungere i tuoi incantesimi preferiti, o altri osservazioni - ben vengono.

Dom, 06/06/2010 - 02:00

jhl.verona

Progresso è una parola fuori del mio vocabolario. Negli ultimi due giorni non ho avuto tempo per procedere.
Nel frattempo, una spiegazione su come usare ssh senza dover digitare il password ogni volta. Non è solo questione di pigrizia, ci possono essere dei script che hanno bisogno di collegarsi tramite ssh più di una volta, e se vuoi che lavorano in automatico puoi usare una copia di chiavi pubblico/privato.

Qui l'articolo che ho seguito io http://www.ibm.com/developerworks/library/l-keyc.html e qui un altro in italiano http://blog.trix.it/?p=24

Più imparo, più dubito.

Dom, 06/06/2010 - 19:11

jhl.verona

Bene, oggi il progresso c'è...
Ho fatto i primi passi (sostituendo i miei script) usando Drush 3.0.
Sono riuscito a copiare una basedati dal server in locale. Woohoo!

Premessa.
Per semplificare, userò /home/local per l'indirizzo root della mia macchina, e /home/server per l'indirizzo root del server.
In entrambi ho la stessa struttura:

/backups
  /sito1.it
  /sito2.it
/drush
/sito1.it
/sito2.it

La struttura degli alias.
Prima gli alias in locale:

$aliases['dev.sito1.it'] = array(
  'uri' => 'dev.sito1.it',
  'root' => '/home/local/sito1.it',
  'db-url' => 'mysql://sito1utente:sito1password@localhost/sito1db',
  'path-aliases' => array(
    '%dump' => '/home/local/backups/sito1.it/sync.sql',
  ),
);

Poi quello del server. Prima una serie di valori condivisi da tutti gli alias sul server:

$aliases['hosting'] = array(
  'remote-host' => 'remote.it',
  'remote-port' => 3306,
  'remote-user' => 'remote',
  'ssh-options' => '-p 22222',
);

Poi l'alias per il sito specifico:

$aliases['prod.sito1.it'] = array(
  'parent' => '@hosting',
  'uri' => 'www.sito1.it',
  'db-url' => 'mysql://sito1utente:[email protected]:4407/sito1db',
  'root' => '/home/server/sito1.it',
  'path-aliases' => array(
    '%drush-script' => '/home/server/drush/drush',
    '%dump' => '/home/server/backups/sito1.it/sync.sql',
  ),
);

Nota che il valore parent viene usato per ereditare valori da altri alias (si plurale se vuoi). Poi il db-url tiene conto dal fatto che sto faccendo tunneling verso mysql sul server (quindi 127.0.0.1 invece di localhost - bug in mysql, e porta 4407 invece del solito 3306).

I comandi.
Ho usato i comandi:

drush -y @prod.sito1.it sql-dump --ordered-dump --result-file=/home/server/backups/sito1.it/2010-06-06.sql
drush -y rsync @prod.sito1.it:/home/server/backups/sito1.it/ @dev.sito1.it:/home/local/backups/sito1.it
mysql -usito1utente -psito1password sito1db < /home/local/backups/sito1.it/2010-06-06.sql

Fin qui tutto bene. Adesso il gran finale: sql-sync. Prima ho cancellato tutte le tabelle in locale.
drush -y sql-sync @prod.sito1.it @dev.sito1.it
Funziona. 20 secondi ed ho una basedati clonato in locale. Fantastico.

Più imparo, più dubito.

Dom, 06/06/2010 - 23:31

Pinolo

Sono senza parole… mitico John!

Lun, 07/06/2010 - 10:43

mavimo

Grande John, metto in doc ;)

Ciao
Marco
--
My blog
Working at @agavee

Mar, 08/06/2010 - 14:18

jhl.verona

Ci sono un paio di opzioni per sql-sync molto utile:

Il primo è --ordered-dump (documentato in sql-dump, ma non in sql-sync) che salva l'SQL riga per riga. Questo è utile per chi usa diff, o vuole salvare il db nel suo sistema di controllo versione del progetto.

Il secondo è --no-cache, perchè di default Drush non scarica il db se l'ultimo sync è più recente di 24 ore - questo opzione lo forza a scaricarlo comunque.

Il risultato è:
drush -y sql-sync --ordered-dump --no-cache @prod.sito1.it @dev.sito1.it

Più imparo, più dubito.

Mar, 08/06/2010 - 19:44

jhl.verona

La prossima tappa nel mio viaggio è rsync.

Prima ho provato su un nuovo sito, sviluppato il locale, ma ancora da installare sul server.
Personalmente uso un pò di codice in settings.php per selezionare il db corretto basato sul host:

if ($_SERVER['HTTP_HOST'] == 'www.sito.it' || $_SERVER['HTTP_HOST'] == 'sito.it') {
  $db_url = 'mysql://sito_drpl1:password@localhost/sito_drpl1';
}
else {
  $db_url = 'mysql://sitoit:sitoit@localhost/sitoit';
}

questo mi permette di copiarlo da locale al server senza problemi. (Ma è solo una mia idea, niente di obbligatorio).

Drush di default non trasferisce settings.php, ma si può forzarlo aggiungendo --include-conf.
Così ho provato:
drush -y rsync --include-conf @dev.sito1.it @prod.sito1.it
ed ha trasferito 5,800 file (44MB) in un pò meno di 9 minuti - circa 90KB/s. In FTP ci ha impiegato oltre 35 minuti.
Ma ovviamente siamo sincronizzando, quindi se rilanci il comando, torna in pocchi secondi - perchè non c'è niente da aggiornare. FTP ovviamente impiegerà un altro 35 minuti...

Situazioni più 'classici' sarebbe la sincronizzazione del indirizzo files (da produzione in sviluppo) e l'aggiornamento del codebase (da sviluppo in produzione) cioè drupal core, moduli, temi, ecc - ma senza toccare l'indirizzo files.

Per il primo c'è il pseudo-variable %files:
drush -y rsync @prod.sito1.it:%files @dev.sito1.it:%files
e per scrupolo ho usato -d -v per vedere cosa facceva drush esattamente:
Calling system(rsync -e 'ssh -p 22222' -azv --exclude="*.svn*" --stats --progress [email protected]:/home/server/sito1.it/sites/default/files/ /home/local/sito1.it/sites/default/files)

Per il secondo c'è l'opzione --exclude-files. Esempio:
drush -y rsync --include-conf --exclude-files @dev.sito1.it @prod.sito1.it
e di nuovo per scrupolo, il comando immesso è:
Calling system(rsync -e 'ssh -p 22222' -azv --exclude="*.svn*" --exclude="sites/default/files" --stats --progress /home/local/sito1.it// [email protected]:/home/server/sito1.it/)

E così posso eliminare altri due scripts miei...

Più imparo, più dubito.