consiglie ed idee su aggiornamento automatico di un applicazione J2EE
Massimo Caliman
me,sinceramente non mi sono mai posto un problema del genere,ma mi
hanno chiesto una bozza di studio o ipotesi per poter fare quanto
segue:
Attualmente per l'applicazione che produciamo rilasciamo un file .war
che deployato da origine ad un installazione "vergine",i dati che
l'applicazione produce sono sia sul filesystem che su database. Per
"migrare" i dati (quindi un installazione) abbiamo un metodo
attualmente percepito come primitivo. Una volta deployata la nuova
versione "vergine" viene lanciato uno script (.sh o .bat a seconda del
sistema operativo) che copia i file di configurazione dalle cartelle
della precedente versione a quella nuova. Manualmente poi viene
cambiato nel file di configurazione il database a cui puntare.Questo
con il servizio ovviamente offline (quindi l'application server di
turno "giù")
Quello che mi si chiede è di realizzare è una modalità di
aggiornamento simile a quella di windows (tranne che per il riavvio
della macchina "a tradimento" quando uno proprio non lo voleva).
Una considerazione preliminare : non penso si possa fare senza
"riavviare" il tomcat o websphere di turno (qui sono ignorante,magari
è banale ma non lo so..), infatti nuovi jar o classi devono essere
ricaricati.
Veniamo alla mia ipotesi (artigianale):
Oltre alla applicazione principale che chiameremo CMS, viene sempre
installata un applicazione che chiameremo "UpdateCentral" costituita
da qualche semplice servlet, la quale si collega ad orari prestabiliti
e chiamando una servlet su un nostro server controlla che la versione
installata dal cliente abbia una release inferiore a quella
disponibile sul server degli aggiornamenti.
Se esiste una versione più recente, questa viene scaricata sotto forma
di war da questo server e messa in una certa directory sotto
l'application server.
Finito di scaricare l'intero pacchetto (e qui dovrei realizzare o
trovare qualche libreria pronta che mi permetta di gestire il download
anche se c'è un interruzione di linea per poi riprenderlo)
l'applicazione/servlet "Update Central" dovrebbe scoppattare il tutto,
segnalare la necessità di interrompere il servizio lanciare qualche
script di allineamento come già succede ora e scambiare i context del
application server.
Non vedo al momento data la struttura dell'applicazione un sistema più
"nobile" (e un pò forse dovrei vergognarmene) ma è così.
Avete qualche consiglio da darmi? personalmente finchè si tratta di un
installazione semplice e controllata presso una nostra serverfarm
posso anche ipotizzare di tirare giù un istanza tomcat e manipolare il
file server.xml ( o rinominare le cartelle "old" con "new" per
capirci". Ma in una installazione complessa di un cliente gestita
autonomamente questo mi da da pensare, ci sono troppe variabili
aleatorie in gioco (e non sono un esperto di application server).
Grazie per i consigli che mi potrete dare (anche se sono del tipo "non esiste!")
A presto.
Massimo
Fabrizio Giudici
> Una considerazione preliminare : non penso si possa fare senza
> "riavviare" il tomcat o websphere di turno (qui sono ignorante,magari
> è banale ma non lo so..), infatti nuovi jar o classi devono essere
> ricaricati.
>
non mi è simpatico), ma credo che si possa dire "invece si può fare".
Solo che al momento sono in grado di darti solo qualche indizio, perché
ci sto lavorando anch'io. Gli indizi te li posso dare per ora in modo
scalcagnato, anche perché in questo momento non mi sento benissimo,
quindi perdonate eventuali cazzate.
Qualche giorno fa ho messo in produzione un'applicazione web, realizzata
con Wicket. Fin qui niente di strano. L'applicazione è in realtà
un'applicazione NetBeans RCP, cioè usa i componenti della Platform e i
meccanismi che li tengono insieme (ok, è scontato: l'applicazione è una
sorta di "blueMarine lato web" che ne riusa integralmente i componenti
di back-end). Per me il vantaggio di tutto ciò non è tanto l'esigenza
dell'aggiornamento via Update Center, quanto il riuso di componenti già
pronti e testati e la possibilità di modularizzare il disegno secondo
una strategia che mi è già nota. Però è chiaro che a questo punto
funzionano/funzionerebbero (devo provarli...) gli Update Center di
NetBeans, previa preparazione di qualche pagina web con le funzionalità
della dialog equivalente della IDE. Ora, in molti casi gli aggiornamenti
di NetBeans _non_ richiedono un riavvio dell'applicazione. Qualora lo
richiedessero, è possibile giocarsela con l'amministrazione di Tomcat
per far si che venga fatta ripartire la sola applicazione corrente
(nota: NON rideployata, ma fatta ripartire, dal momento che è possibile
far gestire i file della piattaforma in modo indipendente da Tomcat).
Come dicevo, si tratta di una cosa allo stadio preliminare, anche se
quello che deve fare per ora funziona (pur con qualche workaround). Ci
lavorerò nelle prossime settimane e mesi (penso che la manderò come
proposta a Jazoon e JavaOne, ho dovuto rinunciare a Devoxx perché sono
un un periodo infernale) e per ora non posso dire niente di più.
Se hai esigenze immediate, non posso esserti di molto aiuto; però,
seguendo questa falsariga, potresti andare a vedere come funziona OSGi
(acc... devo parlare della concorrenza) tenendo conto che Glassfish v3
supporta OSGi e quindi molto probabilmente può fare lo stesso tipo di
trucchetti.
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio...@tidalwave.it - mobile: +39 348.150.6941
Andrea Leoncini
miei 2 cents sull'argomento
per quanto riguarda il ricreare la struttura dei dati tra una installazione ed un'altra, quindi nell'ipotesi di una migrazione, demanderei queste funzionalita' all'uso di un ORM (Object-Relational Mapping tool), ovvero ad un framework del tipo di hibernate, lo so, lo so, anche a me non stanno simpatici i framework, ma quando fanno esattamente quello che serve a te e ti permettono di non riscrivere del codice che gia' e' stato scritto mille volte mi adatto anch'io ad usarli.
per quanto riguarda l'aggiornamento delle applicazioni ormai deployate da quello che ho capito le servlet che avete scritto si basano su un approccio di tipo PULL, ovvero sono loro che vanno a controllare se ci sono aggiornamenti e nel caso scaricano e installano.
premesso che con questa modalita' bisogna comunque pensare a come gestire il processo di deploy, con questo mi riferisco al fatto che probabilmente bisogna comunque gestire un ciclo del tipo testo, rilascio, qualcuno collauda, si approva, si rilascia definitivamente in produzione. Ognuno ha il suo processo ma piu' o meno qualcosa di simile lo fanno un po' tutti. Diamo comunque per scontato che le servlet aggiornano le cose gia' testate e collaudate (tipicamente gli ambienti di esercizio sono molto diffidenti verso questi meccanismi automatici).
il mio consiglio invece e' quello di pensare ad un approccio di tipo PUSH, ovvero a dei server che sono in grado di (per esempio) scaricare il software da un CVS, compilare, deployare sui server target (e qui puoi impostare i vari ambienti: test, collaudo, esercizio, ecc.) lanciare dei cicli di test, lanciare eventuali stress test, fare rolback.
per questo approccio non hai bisogno di scrivere codice, hai a disposizione vari livelli di scripting, dalla shell del sistema operativo, ANT, MAVEN o anche il buon vecchio MAKE.
HTH
ciao
andrea
--
Andrea Leoncini
----------------------------
Esse Quam Videri
Massimo Caliman
uno studio informale, quindi non è una cosa che devo realizzare ora.
I framework sono ok, ma tutto dipende se prima devo fare questo
meccanismo (con l'applicazione nella architettura attuale) o prima
riscrivere la versione "2.0" del applicazione, in tale caso ho già
hibernate che è la mia scelta per quando riscrivo il kernel, ora ho
Torque,Turbine che ormai odio (versione 1.0 per dirla tutta).
Ci sarà modo di tornare sull'argomento, ora mi basta dire che è
possibile (...quindi mi toccherà :-) ma sarà anche affascinante).
Mi avete chiarito molto le idee e dato un riferimento importante al
quale non avevo pensato nel ottica webapplication, cioè di usare i
componenti netbeans.
Il 5 novembre 2008 11.14, Andrea Leoncini <andrea....@gmail.com>
ha scritto:
Fabrizio Giudici
> Grazie mille ad entrambi, aggiungo che al momento si tratta solo di
> uno studio informale, quindi non è una cosa che devo realizzare ora.
> I framework sono ok, ma tutto dipende se prima devo fare questo
> meccanismo (con l'applicazione nella architettura attuale) o prima
> riscrivere la versione "2.0" del applicazione, in tale caso ho già
> hibernate che è la mia scelta per quando riscrivo il kernel, ora ho
> Torque,Turbine che ormai odio (versione 1.0 per dirla tutta).
> Ci sarà modo di tornare sull'argomento, ora mi basta dire che è
> possibile (...quindi mi toccherà :-) ma sarà anche affascinante).
> Mi avete chiarito molto le idee e dato un riferimento importante al
> quale non avevo pensato nel ottica webapplication, cioè di usare i
> componenti netbeans.
>
>
rischi e presume di conoscere bene la piattaforma (e, come nel mio caso,
di poter fare qualche domanda diretta a Praga :-)
L'approccio Glassfish 3 + OSGi, sebbene sia anche lui una cosa nuova e
quindi usata da pochi, è probabilmente più standard (la differenza si
capisce facendo presente che è stata spiegata alla JavaOne, anche in un
keynote speech).
Per completezza, vale la pena ricordare che Hudson ha un meccanismo di
plugin installabili da update center. Però non so come funzionano e
credo che Kohsuke si sia rifatto tutto in casa.
Massimo Caliman
non credo la useremo al momento (4 sviluppatori + io e tempi di
rilascio brevissimi), il discorso cvs nel mio caso è diverso. Mi
spiego meglio, il nostro è un prodotto quindi gli upgrade sono tutto
sommato "poco critici", le nuove features e il bugfix uguali per
tutti, ma avere un meccanismo del genere mi evita di impegnare il
sistemista diverse ore al mese e in alcuni casi di farlo anche
viaggiare.
2008/11/5 Fabrizio Giudici <fabrizio...@tidalwave.it>:
Massimo Musante
dell applicazione puoi controllarlo tramite l'url (ma sicuramente ci
saranno delle API da qualche parte che fanno la stessa cosa).
Solo che ho verificato più volte che anche ad applicazione ferma il
war non si riesce a rimuovere non so di chi sia la 'colpa' (Tomcat,
sistema operativo ...)
(da http://www.jguru.com/faq/view.jsp?EID=455587)
http://localhost:8080/manager/install?path=/xxx&war=yyy -
Install the web application whose WAR file (or directory
containing the unpacked application) is present at URL yyy,
and attach it to context path /xxx. See below for valid syntax
options for the web applcation archive URl. If the URL of an actual
WAR file is specified, the WAR will be automatically expanded
into a directory underneath the application base for this virtual
host.
http://localhost:8080/manager/list - List the context paths of all
currently
installed web applications for this virtual host. Each context will
be
listed with the following format path:status:sessions. Where path is
the context path. Status is either running or stopped. Sessions is
the number of active Sessions.
http://localhost:8080/manager/reload?path=/xxx - Cause the web
application
installed at context path /xxx to reload all its associated Java
classes, even if automatic reloading is disabled.
http://localhost:8080/manager/remove?path=/xxx - Cause the web
application
installed at context path /xxx to be gracefully shutdown and
delete the web application directory and files.
http://localhost:8080/manager/sessions?path=/xxx - List session
information
about the web application attached to context path /xxx for this
virtual host.
http://localhost:8080/manager/start?path=/xxx - Start the web
application
attached to context path /xxx for this virtual host.
http://localhost:8080/manager/stop?path=/xxx - Stop the web
application attached
to context path /xxx for this virtual host.
Fabrizio Giudici
> Ottimo il suggerimento di Hudson, anche se come piattaforma di build
> non credo la useremo al momento (4 sviluppatori + io e tempi di
> rilascio brevissimi), il discorso cvs nel mio caso è diverso. Mi
> spiego meglio, il nostro è un prodotto quindi gli upgrade sono tutto
> sommato "poco critici", le nuove features e il bugfix uguali per
> tutti, ma avere un meccanismo del genere mi evita di impegnare il
> sistemista diverse ore al mese e in alcuni casi di farlo anche
> viaggiare.
>
meccanismo. I miei progetti "diretti" sono molto più piccoli (faccio
tutto io - oppure non sono così piccoli, ma si spiega perché vado verso
l'esaurimento) e quindi non è un deployment semplificato che mi
interessa; quanto piuttosto la capacità di sviluppare nuove features
come "plug-in" e semplificare il ciclo di sviluppo. Mi spiego: seguendo
l'approccio che sto usando per blueMarine, tutte le nuove feature
vengono messe in nuovi moduli in un incubatore. Sia io che il cliente
comunque le possiamo testare in un ambiente di preproduzione, dove al
momento io installo il servizio base e i plugin da provare. Quando
l'utente è soddisfatto delle funzioni e della qualità, vengono promosse
sulla release principale - il che vuol dire che vengono solo copiate da
un albero SVN ad un altro, ma di fatto rimangono sempre plugin.
In questo modo mi pare che sia più facile gestire imprevisti di
percorso, tipo: i moduli X,Y,Z erano previstii per la versione V2,
dovrebbe essere rilasciata la prox. settimana; X,Y sono pronti, Z no.
Bene, andiamo con X,Y e poi Z può seguire a ruota di pochi giorni; ma il
suo rilascio, piuttosto che richiedere un redeployment dell'applicazione
intera, prevederà solo la sua installazione come plugin.
Massimo Caliman
(che richiederà un annetto di sviluppo),ma mi esclude gli
aggiornamenti di core (che poi sono quelli che ci interessano di
più)...tutto può essere un plug-in ma alla fine c'è una qualcosa che
viene pluggato ;-)
Grazie mille a tutti per i consigli.
2008/11/5 Fabrizio Giudici <fabrizio...@tidalwave.it>: