Come gestire in modo efficiente più installazioni di un'applicazione Web?

StackOverflow https://stackoverflow.com/questions/502774

Domanda

Dalla mia esperienza, uno dei maggiori problemi che incontriamo durante il nostro processo di sviluppo web è mantenere diverse configurazioni aggiornate e sicure su server diversi.

La mia azienda ha il proprio CMS che è attualmente installato su oltre 100 server. Al momento, utilizziamo un approccio basato su FTP hack-ish, combinato con script di aggiornamento in posizioni specifiche per aggiornare tutte le nostre configurazioni CMS. La gestione efficiente di queste configurazioni diventa sempre più difficile e rischiosa quando sono coinvolti diversi moduli personalizzati.

  • Qual è il modo migliore per mantenere sicure e aggiornate più configurazioni di un'applicazione Web?
  • Come lo fai tu ?
  • Esistono suggerimenti specifici per quanto riguarda la modularità nelle applicazioni, al fine di mantenere la flessibilità nei confronti dei nostri clienti, pur essendo in grado di gestire in modo efficiente più " filiali " di un'applicazione?

Alcune informazioni contestuali: sviluppiamo principalmente sullo stack LAMP. Uno dei principali fattori che ci aiutano a vendere il nostro CMS è che possiamo plug-in praticamente tutto ciò che il nostro cliente desidera. Questo può variare da 10 a 10.000 righe di codice personalizzato.

Un sacco di lavoro personalizzato consiste in pezzi di codice molto piccoli; la gestione di tutti questi piccoli pezzi di codice in Subversion mi sembra abbastanza noiosa e inefficiente (poiché consegniamo circa 2 siti Web ogni settimana, ciò comporterebbe un lotto di filiali).

Se c'è qualcosa che sto trascurando, mi piacerebbe sentirlo da te.

Grazie in anticipo.

Roundup: prima di tutto, grazie per tutte le tue risposte. Tutti questi sono davvero utili.

Molto probabilmente userò un approccio basato su SVN, che rende la soluzione di benlumley più vicina a quella che userò . Dal momento che la risposta a questa domanda potrebbe differire in altri casi d'uso, accetterò la risposta con il maggior numero di voti alla fine della corsa.

Esamina le risposte e vota per quelle che ritieni abbiano il maggior valore aggiunto.

È stato utile?

Soluzione

Penso che usando un sistema di controllo versione e " branching " la parte dei codici che devi modificare potrebbe rivelarsi l'approccio migliore in termini di robustezza ed efficienza.

Un sistema a versione distribuita potrebbe essere più adatto alle tue esigenze, poiché ti permetterebbe di aggiornare il tuo " core " funzioni perfettamente su diversi " rami " mantenendo alcune modifiche locali se necessario.

Modifica: sono abbastanza sicuro che tenere tutto aggiornato con un sistema di versioni distribuite sarebbe molto meno noioso di quello che sembra aspettarsi: puoi mantenere le modifiche di cui sei sicuro non avrai mai bisogno di altrove a livello locale e l'aspetto distribuito significa che ciascuna delle tue applicazioni distribuite è effettivamente indipendente dalle altre e solo la correzione che intendi propagare si propagherà.

Altri suggerimenti

Se la personalizzazione della tua applicazione comporta la modifica di molti piccoli pezzi di codice, questo potrebbe indicare che il design della tua applicazione è difettoso. La tua applicazione dovrebbe avere un set di codice core stabile, punti di estensibilità per le librerie personalizzate a cui collegarsi, la possibilità di cambiare aspetto usando i modelli e la capacità di cambiare comportamento e installare plugin usando i file di configurazione. In questo modo, non è necessario un ramo SVN separato per ogni client. Piuttosto, mantieni il codice principale e le librerie dei plugin di estensione nel controllo del codice sorgente come al solito. In un altro repository, crea una cartella per ciascun client e conserva lì tutti i loro modelli e file di configurazione.

Per ora, la creazione di filiali SVN potrebbe essere l'unica soluzione che ti aiuta a mantenere la sanità mentale. Nel tuo stato attuale, è quasi inevitabile che tu commetta un errore e rovini il sito di un cliente. Almeno con le filiali è garantito un codice base stabile per ogni client. L'unico gotcha con i rami SVN è se sposti o rinomini un file in un ramo, è impossibile unire quella modifica al tronco (dovresti farlo manualmente).

Buona fortuna!

MODIFICA: per un esempio di un'applicazione ben progettata che utilizza tutti i principi che ho descritto sopra, vedi Magento E-Commerce . Magento è l'applicazione web più potente, estensibile e facile da personalizzare con cui ho lavorato finora.

Potrei sbagliarmi, ma mi sembra che Aron sia il controllo della versione non . Il controllo delle versioni è eccezionale e sono sicuro che lo stiano già utilizzando, ma per gestire gli aggiornamenti su centinaia di installazioni personalizzate, hai bisogno di qualcos'altro.

Sto pensando a qualcosa di simile a un sistema di pacchetti appositamente costruito . Desidererai che ogni versione di un modulo tenga traccia delle sue dipendenze individuali e delle "compatibilità garantite" e utilizzi queste informazioni per aggiornare automaticamente solo i moduli "sicuri".

es. diciamo che hai creato una nuova versione 3 del tuo modulo "Wiki". Vuoi propagare la nuova versione a tutti i server che eseguono la tua applicazione, ma hai apportato modifiche a una delle interfacce all'interno del modulo Wiki dalla versione 2. Ora, per tutte le installazioni predefinite, questo non è un problema, ma si spezzerebbe installazioni con estensioni personalizzate nella parte superiore della vecchia interfaccia. Un sistema di pacchetti ben pianificato se ne occuperebbe.

Per rispondere alla domanda di sicurezza, dovresti cercare di usare le firme digitali sulle tue patch. Ci sono molte buone librerie disponibili per le firme basate su chiave pubblica, quindi basta andare con qualsiasi cosa sembri essere lo standard per la tua piattaforma scelta.

Non sono sicuro che qualcuno l'abbia detto, ci sono molte risposte lunghe qui e non le ho lette tutte.

Penso che un approccio migliore al controllo della tua versione sarebbe quello di far sedere il tuo CMS da solo nel suo repository e ogni progetto nel suo. (o, tutti questi potrebbero essere sottocartelle all'interno di un repository credo)

Puoi quindi usare il suo trunk (o un ramo / tag specifico se preferisci) come svn: esterno in ogni progetto che lo richiede. In questo modo, tutti gli aggiornamenti apportati al CMS possono essere ripristinati nel suo repository e verranno inseriti in altri progetti come e quando vengono aggiornati svn (o l'esterno è svn: switch 'ed).

Per semplificare tutto ciò, dovrai assicurarti che il CMS e la funzionalità personalizzata si trovino in cartelle diverse, in modo che svn externals funzioni correttamente.

IE: 

project
 project/cms <-- cms here, via svn external
 project/lib <-- custom bits here
 project/www <-- folder to point apache/iis at

(potresti avere cms e lib nella cartella www se necessario)

Questo ti permetterà di ramificare / taggare ogni progetto come desideri. Puoi anche cambiare svn: posizione esterna in base al ramo / tag.

Per quanto riguarda le modifiche in tempo reale, ti suggerirei di eliminare immediatamente ftp e utilizzare rsync o svn checkout / export. Entrambi funzionano bene, la scelta spetta a te.

Ho molta esperienza con il percorso rsync, rsyncing un'esportazione svn sul server. Se segui questa strada, scrivi alcuni script di shell e puoi creare uno script di shell di prova per mostrarti i file che caricherà senza caricarli, usando il flag -n. In genere utilizzo un paio di script per ciascun ambiente: uno di prova e uno per farlo effettivamente.

L'autenticazione con chiave condivisa, quindi non è necessaria una password per inviare i caricamenti, può essere utile, a seconda della sicurezza del server a cui è concesso l'accesso.

Potresti anche mantenere un altro script di shell per eseguire aggiornamenti di massa, che chiama semplicemente lo script di shell pertinente per ogni progetto che desideri aggiornare.

Hai visto Drupal? No, non per distribuire e sostituire ciò che hai, ma per vedere come gestiscono le personalizzazioni e i moduli specifici del sito?

Fondamentalmente, c'è un " siti " cartella che ha una directory per ogni sito che stai ospitando. All'interno di ogni cartella è presente un settings.php separato che consente di specificare un database diverso. Infine, puoi (facoltativamente) avere & Quot; temi & Quot; e " moduli " cartelle all'interno dei siti.

Ciò consente di eseguire personalizzazioni specifiche del sito di determinati moduli e di limitare determinati moduli a tali siti. Di conseguenza, si finisce con un sito in cui la stragrande maggioranza di tutto è perfettamente identica e solo le differenze vengono duplicate. Combinalo con il modo in cui gestisce gli aggiornamenti e potresti avere un modello praticabile.

Compilare nel codice un processo di autoaggiornamento.
Controllerà la presenza di aggiornamenti e li eseguirà quando / dove / come lo hai configurato per il client.

Dovrai creare una sorta di elenco di moduli (personalizzati o meno) che devono essere testati con la nuova build prima del lancio. Quando si distribuisce un aggiornamento, è necessario assicurarsi che siano testati e integrati correttamente. Spero che il tuo design possa gestirlo.

Gli aggiornamenti sono idealmente alcuni passaggi chiave.

  1. a) Backup in modo da poter uscire. Dovresti essere in grado di uscire l'intero aggiornamento in qualsiasi momento. Così, ciò significa creare un archivio locale dell'applicazione e del database prima.

    b) Processo di monitoraggio degli aggiornamenti - Porta il telefono di sistema CMS a casa per cercare una nuova build.

    c) Pianifica aggiornamento sulla disponibilità : è probabile che non desideri che l'aggiornamento venga eseguito nel momento in cui è disponibile. Ciò significa che dovrai creare un cron / agent di qualche tipo per eseguire automaticamente l'aggiornamento del sistema nel cuore della notte. Puoi anche considerare i requisiti del cliente da aggiornare nei fine settimana o in giorni specifici. Puoi anche scaglionare l'implementazione degli aggiornamenti in modo da non aggiornare 1000 client in 1 giorno e ottenere l'inferno dell'assistenza tecnica. Un lancio sfalsato di qualche tipo potrebbe essere utile per te.

    d) Aggiungi modalità di manutenzione per aggiornare il sito - Attiva il sito in modalità di manutenzione.

    e) Checkout SVN o pacchetti scaricabili - idealmente è possibile distribuire tramite checkout svn e, in caso contrario, configurare il server per consegnare i pacchetti generati svn in un archivio che può essere distribuito sui siti client.

    f) Distribuisci script DB - Esegui il backup dei database, aggiornali, popolali

    g) Aggiorna codice sito : tutto questo funziona in un solo passaggio.

    h) Esegui alcuni test su di esso. Se il tuo codice ha degli autotest integrati, sarebbe l'ideale.

Ecco cosa faccio ...

Percorso di inclusione specifico del client

  • Il codice comune condiviso è in condiviso / versione_versione/lib/
  • Il codice specifico del sito è in client / foo.com/lib
  • Il percorso di inclusione è impostato per includere da client / foo.com / lib , quindi condividi/lib
  • Il tutto è in un sistema di controllo della versione

Questo assicura che il codice utilizzi i file condivisi ove possibile, ma se per qualche motivo devo sovrascrivere una determinata classe o file, posso scrivere una versione specifica del client nella loro cartella.

File comuni alias

La mia configurazione dell'host virtuale conterrà una linea come 

Alias /common <path>/shared/current_version/public_html/common

Che consente di condividere elementi dell'interfaccia utente, icone, ecc. comuni tra progetti

Contrassegna il codice comune con ogni versione del sito

Dopo ogni versione del sito, taggo il codice comune creando un ramo per bloccare efficacemente quel momento. Questo mi permette di distribuire / shared / version_xyz / sul server live. Quindi posso fare in modo che un host virtuale utilizzi una versione particolare dei file comuni o lasciarlo puntare a current_version se voglio che raccolga gli ultimi aggiornamenti.

Hai esaminato strumenti come Puppet (per l'amministrazione del sistema inclusa la distribuzione di app) o < a href = "http://www.capify.org/" rel = "nofollow noreferrer"> Capistrano (distribuzione di app in RubyOnRails ma non limitato a questi)?

Un'opzione sarebbe quella di impostare un sistema di controllo della versione di sola lettura (Subversion). È possibile integrare l'accesso al repository nel CMS e richiamare gli aggiornamenti tramite un menu o automaticamente se non si desidera che l'utente abbia una scelta su un aggiornamento (potrebbe essere critico). L'uso di un sistema di controllo della versione ti consentirebbe anche di mantenere facilmente rami diversi

Come la gente ha già detto che usare il controllo versione (preferisco Subversion per funzionalità) e la ramificazione sarebbe l'opzione migliore. Un altro software open source disponibile su sourceforge chiamato cruisecontrol. È incredibile, configuri cruisecontrol con sovversione in un modo che qualsiasi modifica di codice o nuovo codice aggiunto in server, il controllo automatico della velocità saprà automaticamente e costruirà per te. Ti farà risparmiare il tuo inferno di tempo.

Ho fatto lo stesso nella mia compagnia. abbiamo quattro progetti e dobbiamo distribuire quel progetto su server diversi. Ho installato cruiseconrol in modo tale che qualsiasi modifica nella base di codice inneschi la generazione automatica. e un altro script distribuirà tale build sul server. sei a posto.

Se usi uno stack LAMP, trasformerei sicuramente i file delle soluzioni in un pacchetto della tua distribuzione e lo userei per propagare le modifiche. Raccomando per questo Redhat / Fedora a causa degli RPM ed è ciò su cui ho esperienza. Comunque puoi usare anche qualsiasi distribuzione basata su Debian.

Qualche tempo fa ho realizzato una soluzione LAMP per la gestione di un server di hosting ISP. Avevano più server per occuparsi dell'hosting web e avevo bisogno di un modo per implementare le modifiche del mio manager, perché ogni macchina era autonoma e aveva un gestore online. Ho creato un pacchetto RPM contenente i file della soluzione (principalmente php) e alcuni script di distribuzione eseguiti con RPM.

Per l'aggiornamento automatico avevamo il nostro repository RPM impostato su ogni server in yum.conf. Ho impostato un processo crontab per aggiornare quotidianamente i server con gli ultimi RPM da quel repository di fiducia.

La fiducia può essere raggiunta anche perché puoi usare le impostazioni di fiducia nei pacchetti RPM, come firmarli con il tuo file di chiave pubblica e accettare solo i pacchetti firmati.

Hm potrebbe essere un'idea aggiungere file di configurazione? Hai scritto che molti piccoli script stanno facendo qualcosa. Ora se li costruissi nei sorgenti e li guidassi con i file di configurazione non dovrebbe essere & Quot; facilità & Quot; quello?

D'altra parte, avere filiali per ogni cliente mi sembra una crescita esponenziale. E come vorresti & Quot; conoscere & Quot; quali aree hai fatto qualcosa e non dimenticare di " make " cambiamenti anche in tutti gli altri settori. Mi sembra abbastanza brutto.

Sembra una combinazione di controlli di revisione, opzioni di configurazione e / o ricevute di distribuzione sembra essere un " buon " idea .....

Con così tante varianti sul tuo software principale, penso che tu abbia davvero bisogno di un sistema di controllo della versione per rimanere aggiornato sulla spinta degli aggiornamenti dal trunk ai singoli siti client.

Quindi se pensi che Subversion sia noioso, hai un buon senso per quali saranno i punti dolenti ... Personalmente, non consiglierei Subversion per questo, dal momento che non è poi così bravo a gestire amp; rami di tracciamento. Sebbene il suggerimento di Benlumley di utilizzare gli esterni per il tuo software principale sia valido, questo si interrompe se devi modificare il codice principale per i tuoi siti client.

Cerca in Git il controllo della versione, è progettato per la ramificazione ed è veloce.

Scopri Capistrano per la gestione delle tue implementazioni. È uno script ruby, spesso utilizzato con Rails, ma può essere utilizzato per tutti i tipi di gestione dei file su server remoti, anche su siti non ruby. Può portare il contenuto alla fine remota attraverso varie stragegie tra cui ftp, scp, rsync, oltre a controllare automaticamente l'ultima versione dal tuo repository. Le simpatiche funzionalità fornite includono hook di callback per ogni fase del processo di distribuzione (ad esempio, in modo da poter copiare i file di configurazione specifici del sito che potrebbero non essere nel controllo della versione) e un sistema di registro delle versioni, eseguito tramite collegamenti simbolici, in modo da può tornare rapidamente a una versione precedente in caso di problemi.

Consiglierei un file di configurazione con l'elenco dei rami e la loro posizione ospitata, quindi eseguo quello con uno script che controlla a turno ogni ramo e carica le ultime modifiche. Questo potrebbe essere fatto per eseguire automaticamente aggiornamenti notturni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top