Buongiorno,
ho la necessità di trovare uno strumento che mi consenta di gestire gli aggiornamenti e cmq le parti comuni a più siti web realizzati on dupral.
In particolare, gli aggiornamenti dei moduli.
Avendo diversi siti, diventa una rottura doverli aggiornare tutti uno ad uno, anche se usi drush, serve un sistema più versatile per l'ammistrazione di più siti.
sapete darmi delle indicazioni in merito?
prova
http://groups.drupal.org/aegir-hosting-system
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits
per aegir se non sbaglio, è necessario un server dedicato con root access. è complesso e mi sembra pure che i siti da gestire debbano trovarsi sullo stesso server (?)
Di quanti siti stiamo parlando?
drush update-invio-
y-invio-
(nel caso ci sia da aggiornare il db)
-invio-
non mi pare tanto tedioso...
Certified to Rock
e di questo cosa ne pensate?
http://drupal.org/project/network_manager
http://www.sanisapori.eu
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits
Per quanto reguarda il monitoraggio di tanti siti Victor Kane ha una soluzione interessante: http://awebfactory.com.ar/node/421
Più imparo, più dubito.
Il mio interesse è mirato a far si che questi siti si vengano aggiornati senza doverlo fare a mano su ogni sito, anche con drush.
E' pur vero che posso fare un scriptino facile in bash che mi aggiorni tutto, dopo averlo lanciato... ma vuoi mettere una struttura fatta appositamente che non faccia solo upgrade ma anche check e servizi vari?!
lo testerò in futuro... non adesso.
http://www.sanisapori.eu
Penso che la tua richiesta di questo thread sta a cuore di tanti utenti qui, ma...
non credo che esiste, nè che può esistere - almeno come vuoi tu. Io ho 'solo' 5-6 siti da gestire per ora, ma immagino che 'i grandi' come Pinolo, kiuz, e Mavimo hanno tanti di più...
Propongo un pò di specifiche per vedere dove possiamo arrivare...
1. Monitoraggio. Bisogna sapere se:
Perchè preferisco sapere io che il sito non va, piuttosto che mi lo dice il cliente
2. Unit tests. Il sito si comporta correttamente.
Perchè ci possono essere spiacevole interazioni fra moduli aggiornati, o patch incompatibile.
3. Procedura di aggiornamento. Il più automatizzato possibile.
Perche è noioso, ripetetivo, e faccio errori.
Per il punto 1, mi piace Nagios. Mi piace l'idea di usare un strumento per capire se qualcosa va storto - con avviso email.
Per il punto 2, ho usato Selenium ed il suo IDE. Il costo nel creare i test è ovviamante proporzionale alla copertura necessario. Niente test, niente assicurazione. Per il casco bisogna pagare (molto) di più...
Per il punto 3, drush va bene (anche se non aggiorna Drupal core) e si può aggiungere scripts quanto vuoi (o quanto permette il tuo hosting).
Io preferisco comunque fare tutto in localhost, l'unico script che tengo sul server è per fare un dump del db insieme ai files del sito. E uso rsync server side. Per riuscire ad avvicinarsi alla nirvana (auto-aggiornamento) però mi sto convincendo che serve anche dei test selenium, se non, non sai veramente se l'aggiornamento ha lasciato intatto il comportamento del sito.
Non sono ancora arrivato a questo punto. Per il momento non ho niente per punto 1 (sigh), e mi limito a seguire una procedura (salvato in formatto advanced help) per capire cosa deve fare il sito - punto 2. Questo lo seguo a mano. Mi rendo conto che tenere il sito offline per 1, 2 o più ore non è ideale, ma (per me) cosi è - per ora.
Il mio nirvana personale sarebbe:
Per ogni sito che necessità di un aggiornamento {fare backup del db e sito // script (esiste)
metterlo in maintenance mode // script (non esiste, ma sarà SQL)
copiarlo in localhost // script localhost (esiste)
aggiornare drupal e/o i moduli // drush + script per drupal core (esiste)
testare il comportamento {
se corretto {
spedirlo sul server // script (rsync localhost + mysql server side)
togli maintenance mode // già fatto nel db
}
else {
smanetta furiosamente... // aargh
}
}
}
Il motivo perchè credo che non ci sarà mai un totale automatizzazione del aggiornamento e nel
elsesopra. A me succede qualche volta...Comunque, per ora, 5 siti con un aggiornamento media di ogni 3 mesi, non richiede tutto questo automazione. Ma se forse 50 siti...
John
Più imparo, più dubito.
Se devo discutere di monitoring, perchè utilizzare strumenti esterni?... si può benissimo restare all'interno dell'ambito drupal usando http://groups.drupal.org/aegir-hosting-system oppure http://drupal.org/project/network_manager
Con entrambi gli strumenti vengono molto bene soddisfatte le necessitèà di monitoring senza dover ricorrere a strumenti esterni (seppur utili, tipo open view, nagios, autosys, ecc ecc).
Quello che invece è importante è come installare un aggiornamento su una moltitudine di siti web dopo averlo testato sul sito di test.
Se usi una sola installazione di drupal su filesystem con cui controllo tutti i siti, allora hai da considerare che drush ti aggiorna l'alberatura del modulo su /sites/all/modules di conseguenza uno script che usi drash deve la prima volta fare un update e tutte le altre volte un updatedb (X ESEMPIO, parlando così alla buona).
Un'altra cosa che è tremendamente importante è il backup dei dati. I miei siti hanno già raggiunto db non compressi dell'ordine di GB, al momento va benissimo usare backup&migrate, ma mi rendo conto che tra qualche tempo, l'operazione di backup sarà da svincolare dalle pagine web di drupal. Quindi biosognerà applicare un script in cron che esegua il dump di tutti i DB. La questione può essere: una volta che il dump compresso supera i 10MB come fare a gestire il restor del backup stesso? Preciso che 10MB non sono niente si fa il restore in un attimo, ma se diventa troppo grande il restore potrebbe fallire. Di conseguenza può avere senso fare un backup che crei un dump suddivino in file di dimensioni definite. Per esempio su un dump da 100MB, fa in modo che questo dump sia un insieme di 10file da 10MB e che poi il restore li carichi uno alla volta. Tutto questo per evitare che il restore fallisca tutte le volte x mancanza di memoria o perchè ci mette troppo.
In più per evitare che un dump di un grosso db debba tutte le volte essere rifatto da zero... può avere senso fare un backup differenziale o incrementale.
http://www.sanisapori.eu
Io vedo ogni problema per conto suo. Non credo che Drupal sia una piattaforma idoneo per fare tutto. Nagios e un alternativo (anche per chi ha siti non Drupal) tutto qua. Aegir comunque è un alternativo molto Drupalesque.
Questo continua ad essere un problema 'ben noto' con varie soluzione - ma nessuna soluzione 'universale'.
Io ho iniziato (se ho capito bene quello che hai scritto) usando un 'repository' Drupal + modules, e dei symbolic links per i siti. Al inizio sembrava una buon'idea, ma poi mi sono reso conto che i siti hanno tempi e costrizioni diversi. Dopo 4/5 mesi iniziavo avere dei pasticci problematici. Aggiornare Drupal core va sempre bene, ma ci possono essere dei buoni motivi (patch/incompatibilità/nuovi bugs) per non fare l'upgrade 'en masse' dei moduli. Nella mia esperienza ho visto un modulo aggiornato funzionare su un sito, e creare dei bei problemi su un altro.
Adesso preferisco avere multipli codebase. Drupal core è un tipo di animale, i moduli sono bestie molto diverse. Comunque questo problema è tipico anche di Drupal multisite.
Altro problema 'ben noto', ancora senza soluzione universale. B&M è una soluzione splendida per 80% dei siti Drupal - quelli con DB 'piccoli'. Più grande, e bisogna pensare a soluzioni RDBMS invece di Drupal. Tipo mysqldump insieme a tar.
La natura dei dump è di recreare le tabelle da zero, perchè possono aggiungere i constraints dopo l'aggiornamento. Se no è quasi impossibile recreare i primary key uguale. Dopo tutto i dump non recreano i record nella stessa sequenza di quanto creati dal sito Drupal. Posso recreare tutti i campi CCK prima di recreare i nodi, per esempio. Ma con i PK o altri constraints questo non sarebbe possibile.
Di solito ci sono tools specifici che aiutino a risolvere questo problema per un specifico RDBMS. Ci sono tanti per MySQL per esempio. Ma non sono perfetto. Funzionano meglio quando c'è molto metadata (PK, FK, constraints), cose che mancano nei db di Drupal (eccetto PK).
Adesso con D7 mirando verso soluzioni 'enterprise', forse la situazione migliorerà. Arriveranno i transactions per esempio. Oggi come oggi (D6) non c'è neanche una chiamata al db coperta da transaction, quindi non si può nemmeno garantire che il db è sana.
Forse vedremmo anche qualche constraint nella schema in futuro...
Quindi riassumendo (per me almeno):
Punto 1 e 2 hanno la tendenza di essere 'opzionale'. Continuo fare tutto in locale (aggiornamenti con Drush, /update.php) per poi copiare tutto db compreso sul server. E una doppia operazione. Primo copio il db server + files (sites/default/files per intenderci), poi modifico i moduli, aggiorno, e spedisco. Sto guardando Features per recreare modifiche sistemistiche (es: nuovo view) sul server, dopo il talk di Mavemo al DrupalCamp...
John
Più imparo, più dubito.
Arrivo tardi ma:
Una volta che c'è da fare l'aggiornamento si usa la copia del sito di produzione in locale, si fanno tutti i test di aggiornamento con drush e di controlla che tutto vada bene (selenium è ottimo per questo, ma effettivamente perdi talmente tanto tempo per ogni sito che ha senso solo in certi casi). una volta che tutto va bene si aggiorna anche in remoto con la stessa procedura (facendo all'inizio il backup).
PS: per aggiornare il core con drush c'è uno script apposito da aggiungere.
PS2: per settare le variabili della maintenance mode usate pure:
drush vsetCiao
Marco
--
My blog
Working at @agavee
questo sembra andare nella direzione giusta: http://drupal.org/project/drd
è per D7 ma può monitorare anche siti in D6
Certified to Rock
lo testerò appena mi sarà possibile...
http://www.sanisapori.eu
Stavo valutando la possibilità di testare il modulo indicato da Bohz perchè in effetti sembra interessante.
Però visti gli ultimi sviluppi, dovuti all'incremento dei siti web del network ed alla pianificazione dell'aggiunta di nuovi siti che potrebbero in breve tempo raddoppiare quelli già esistenti, mi ritrovo un dilemma ...che un pò da sconforto e senso di impotenza nel migliorare la situazione, riferito all'amministrazione della configurazione di tutti i siti web.
Insomma, la questione che se fai un modifica di configurazione su un sito web xkè si sceglie una nuova strategia o un nuovo modulo, cambia tutto, o installi un modulo non presente prima e devi configurarlo, fare questi interventi repliandoli su tutti i siti diventa snervante.
Esiste un modo, qualsiasi modo, per far si che una modifica possa essere ereditata/propagata su tutti gli altri siti?
Sarebbe una manna!!!
http://www.sanisapori.eu
http://drupal.org/project/features ?
Certified to Rock