Stack di lampada multi-sviluppo ideale?

Question

Mi piacerebbe costruire uno stack di sviluppo della lampada "ideale".

• doppio Server (virtualizzata, ESX)
  • Apache/PHP su uno, database (MySQL, PgSQL, etc) dall'altra.
• Utente (sviluppatore) Mini ambienti gestibili o istanza.
  • Ogni istanza sviluppatore condivide il livello di configurazione superiore (moduli disponibili e di configurazione di default, ecc)
  • Uno sviluppatore dovrebbe avere il controllo sul loro versione apache e php per ogni progetto.
  • Uno sviluppatore potrebbe essere in grado di modificare le impostazioni secondarie, ad esempio i magicquotes per il codice legacy.
  • Ogni progetto sarebbe determinare il suo provider di database nel suo codice

L'idea è che si tratta di un server amministrare-grado che posso controllare, e di fornire le cose configurati a livello globale come APC, Memcached, XDebug ecc Quindi spostandomi in sottoinsiemi per ciascun progetto, posso consentire ai miei utenti di controllare rapidamente i loro ambienti per vari progetti.

In sostanza sto proponendo il tipico sistema di uno sviluppatore che esegue il proprio stack sulla propria macchina, ma centralizzato. In questo modo, spero di evitare problemi come problemi di codice Cross OS, incongruenze di database, installazioni leggermente diverse che producono bug ecc.

Sono felice di gestirlo in versioni personalizzate dalla fonte, ma se possibile sarebbe essere bravi a gestirne una parte consistente con una sorta di gestione dei pacchetti. Usiamo tipicamente CentOS, quindi yum?

Qualcuno ha mai costruito qualcosa di simile prima? C'è qualcosa di "chiavi in ​​mano" che è simile a quello che ho descritto? Ci sono delle guide utili che dovrei leggere per costruire qualcosa del genere?

Answer 1

La mia opinione sulla questione, non credo che copre tutte le vostre esigenze, ma è abbastanza vicino:

• dispone di un server CentOS con stack LAMP (yum install apache2 mysql php ecc) - o 2 server uno httpd e uno mysqld
• per n sviluppatori hanno n cartelle con n host virtuali www.developer-n.com sull'host che runst il server Apache
• Ogni sviluppatore monti il ​​suo cartella del server (diciamo //192.168 .0.1/home/developer-n/www) sul computer locale tramite CIFS nel file/etc/fstab della stazione locale e modifica i file da locale macchina ancora li esegue sul (unico) del server
• Ogni mini-ambiente di sviluppo è ottimizzato tramite .htaccess

Answer 2

OK, il modo in cui correvamo configurazione LAMP sviluppo al mio lavoro precedente, era come questo. Un singolo server che esegue sia MySQL che Apache.A ogni sviluppatore viene assegnato un indirizzo IP sul server (la macchina sta eseguendo più IP sulla stessa interfaccia, tutti gli IP si trovano sulla stessa sottorete), quindi ogni sviluppatore può avere almeno un host virtuale basato su IP e tanti nomi basati come vogliono (il nostro sito web ha usato SSL, quindi avevamo bisogno di IP separati, wigthout SSL, si può farla franca con un singolo IP e nomi basati su vhosts). Avevamo un server DNS locale che pubblicava i record wildcard A per ogni sviluppatore in questo modo * .john.dev.company IN A 10.1.1.123, dove 10.1.1.123 era l'indirizzo IP assegnato a John. In questo modo, John ha potuto definire quanti vhosts basati sul nome desidera e verrebbero risolti correttamente finché finiscono tutti in john.dev.company (come project1.john.dev.company). Ogni sviluppatore aveva il proprio file di configurazione apache con i propri host virtuali al suo interno e abbiamo usato la direttiva Include per estrarre tutti questi file nella configurazione principale di Apache. Le autorizzazioni sono state impostate, quindi questi file di configurazione sarebbero stati modificabili dai rispettivi sviluppatori e ogni sviluppatore aveva un link soft alla propria configurazione nella propria home directory. Inoltre, ogni sviluppatore è stato autorizzato a utilizzare sudo per riavviare Apache. Lo svantaggio di questa configurazione era che una volta ogni tanto un particolare dev avrebbe fatto crashare l'intero server rovinando il loro file di configurazione. Abbiamo usato un database comune, dato che tutti lavoravano su un singolo progetto, ma non dovrebbe essere difficile impostare più database individuali.