Mi chiedevo se esiste un modo "agevole" di ridistribuire un WAR Java a un server di produzione (nessun cluster, nessun OSGi)?Ridistribuzione regolare di WAR in produzione?
Tutto ciò che posso inventare è arrestare il server, aggiornare il file, riavviare il server. E 10 minuti prima ho bisogno di visualizzare un avviso di manutenzione sul sito.
Qual è il tuo approccio?
In primo luogo, la distribuzione a caldo non funziona sempre. Abbiamo speso così tanto tempo per assicurarci che ogni nuovo modulo sia caricato e abbiamo deciso che non ne vale la pena. Quindi quello che stai facendo può sembrare brutto, ma è il modo più affidabile per distribuire una nuova GUERRA.
Il nostro approccio attuale consiste nell'utilizzare uno switch con bilanciamento del carico di fronte a tutti i server. Eseguiamo almeno 2 istanze dei server delle applicazioni. Quando chiudiamo un server per la manutenzione, il traffico passa automaticamente all'altro.
Alcuni degli switch sono davvero economici. Se non si dispone di un carico sufficiente per giustificare una nuova casella e le 2 istanze possono essere eseguite sulla stessa casella.
In alcune circostanze, gli switch possono effettivamente risparmiare denaro. Ad esempio, abbiamo una pagina SSL che usava 6 caselle e ora funziona bene su 2 caselle con l'accelerazione SSL nello switch.
sembra molto intelligente - eppure mi chiedo: come gestisci lo stato? Quando ne prendi uno, lo stato deve ovviamente essere disponibile su un'altra risorsa (DB, cache, seconda app?). E in secondo luogo, come funziona? -basato sulle mie umili esperienze di framework java (jsf, cucitura, wicket), mi aspetterei che dovresti saltare un bel po 'di cerchi quando non usi' sessioni appiccicose 'in un cluster. – stephanos
Buona domanda. Il server stateless è un requisito qui per così tanto tempo che lo do per scontato. Se hai uno stato nel server, devi fare qualche trucco nel load-balancer, come il routing appiccicoso basato sull'IP di origine o sui cookie. –
Si potrebbe dare un'occhiata a JRebel, anche se non lo userei in produzione. In produzione facciamo praticamente la stessa cosa, anche se il nostro capo continua a sognare hot redeploys. Sfortunatamente sono supportati principalmente su carta - nelle applicazioni più complesse qualcosa va sempre storto con hot redeploys. Lo stesso è ancora più vero per i redeploys incrementali caldi ...
Di solito, mv old.war new.war e lasciare che l'AS prenda da lì, anche se con servizi 24/7 molto occupati, immagino che questa non sarebbe un'opzione.
hm, l'ho provato una volta con Jetty, forse l'ho fatto sth. sbagliato, ma non è successo niente dopo pochi minuti; probabilmente ogni AS lo gestisce diversamente. Su quale AS hai fatto effettivamente questo? – stephanos
È configurabile: puoi far funzionare Tomcat e JBoss in questo modo. Sarei sorpreso di apprendere che Jetty non ti consente di configurarlo in modo simile. Proprio come una questione terminologica, Tomcat e Jetty sono contenitori servlet, JBoss (e Glassfish, JOnAS, ecc.) Sono application severs. –
Alcuni server applicazioni supportano la ridistribuzione senza interruzione del servizio. Questo è almeno vero per WebLogic, vedere Using Production Redeployment to Update Applications. Si noti che questa è la distribuzione hot non (e NON utilizzerei MAI la distribuzione a caldo con i server di produzione).
Senza il supporto del server delle applicazioni, temo che non sarà possibile effettuare ridistribuzioni "regolari". Se si desidera ridurre al minimo i tempi di inattività, un approccio consiste nel distribuire la nuova applicazione in parallelo (sullo stesso server o in un altro) e modificare le regole di routing al termine. Ma i clienti perdono la sessione.
Di solito è possibile ottimizzare i tempi di avvio. La nostra applicazione web inizia con Jetty in 5-7 secondi. Altri server Web Java sono peggiori, perché iniziano molto lentamente.
Inoltre, come sono a conoscenza (non l'ho fatto), il server Web front-end (come apache, usiamo lighttpd) potrebbe essere configurato per contenere una richiesta di un certo periodo di tempo (fino a 30 secondi sul nostro) mentre il Jetty non è pronto. Quindi, riavviamo facilmente il Jetty durante la distribuzione, e gli utenti hanno solo alcuni secondi di ritardo nel peggiore dei casi, che di solito sembra solo un problema di connessione a Internet.
buona idea con il timeout! grazie – stephanos
Come ZZ Coder ha già menzionato il bilanciamento del carico è una buona soluzione soprattutto per le grandi implementazioni. Per il mio progetto, utilizzo la funzionalità reverse proxy HTTP del server Web nginx. Reindirizza tutti i pacchetti http da un determinato contesto web (visto da Internet) a un server all'interno della mia rete.La configurazione è molto semplice:
location /best-app-ever/ { proxy_pass host-address:8080/some-app-1.1 root /home/www/some-app-1.1 }
versione di commutazione dovrebbe essere regolare pure. Supponendo che è già stato distribuito nuova versione dell'applicazione è sufficiente modificare il file di configurazione nginx e applicare le modifiche:
location /best-app-ever/ { proxy_pass host-address:8080/some-app-1.2 root /home/www/some-app-1.2 }
sudo nginx -t
sudo service nginx restart
essere avvertito che nel caso in cui l'applicazione web è stateful e/o contiene alcuni processi in esecuzione o pianificati, la distribuzione e l'annullamento della distribuzione potrebbero non essere altrettanto fluidi.
perché interrompere il server, aggiornare il file, riavviare il server e non solo annullare la distribuzione/distribuzione? Abbiamo diverse app web .war sui nostri server di produzione e tipicamente non distribuiamo/ridistribuiamo: non c'è bisogno di prendere l'intero server con tutte le webapp verso il basso !? – NoozNooz42
@nooz: beh, eseguo solo 1 app sul server. Non sono stato in grado di trovare tutorial/guide su come eseguire nuovamente la distribuzione con Jetty, tutto quello che trovo è come farlo per uno sviluppo rapido – stephanos
oh, vedo ... Non so di Jetty (forse altri commenteranno) . Ma con Tomcat ci sono diversi modi per annullare la distribuzione/ridistribuzione di un singolo .war (ero solito farlo da un'attività Ant ma ora sto usando l'app manager). Ciò consente di risparmiare il tempo necessario per arrestare/riavviare Tomcat. – NoozNooz42