Puppet: gestione (molti) Apache VirtualHosts

Sto imparando la mia strada attraverso la gestione della configurazione in generale e usando il pupazzo per implementarlo in particolare. Ho già fatto alcune ricerche generiche ( anche su SF ) e in questo momento sto prendendo in considerazione Apache VirtualHosts.

Ospitiamo molti siti Web LAMP (attualmente è nella gamma di centinaia) su due sistemi: uno Apache2 / mod_php e uno MySQL - praticamente l'opposto di un'altra domanda già su SF in cui gestisce molti server con pochi host ciascuno (se in realtà non uno, non lo so). Non ho ancora messo insieme una configurazione funzionante in burattino ma non dovrebbe essere un problema, ci sono molti esempi e ricette là fuori.

Oltre agli ovvi file di configurazione di apache (nessun problema qui immagino) ogni vhost dovrebbe avere alcune directory create e le autorizzazioni controllate (ad es. Una directory root per ogni vhost contenente un documentroot, una directory tmp dedicata, un dedicato dir di file di sessione php, possibilmente certificati SSL e così via) sul server web e un utente + uno o più database sul server MySQL.

L'aggiunta di un nuovo vhost richiederebbe il pupazzo per crearli, la rimozione di uno richiederebbe al burattino di eseguire uno script che eseguirà il backup dei dati dell'utente e quindi rimuoverà i dati in tempo reale dai due server, ma anche ogni esecuzione di ogni agente fantoccio verificherebbe l'esistenza di le directory, il db, le autorizzazioni, ecc.

Sto chiedendo problemi quando salgo a centinaia di virtualhost con tutti quei controlli in esecuzione ad ogni esecuzione di marionette, in particolare quelli del filesystem (sul server web), e specialmente quando in futuro i sistemi verranno caricati di più? (supponiamo di scegliere come target il range di siti Web 1000 ~ 2000 come massimo ragionevole per server).

C'è qualche esperienza nel farlo là fuori in rete? Ho cercato su Google ma non ho trovato nulla, anche perché c'è un basso rapporto segnale / rumore durante la ricerca di "pupazzo" e "apache" ...

Ho il sospetto che la gestione di molti host virtuali di Apache non sarà un problema, ma non posso dirlo con certezza. Le prestazioni accettabili sono definite dalle esigenze aziendali. Solo tu puoi decidere se è abbastanza veloce. Ecco una discussione decente sulla riduzione del carico della CPU: https://groups.google.com/forum/?fromgroups#!topic/puppet-users/sxtMvCnKnys[1-25]

Per riassumere il thread:

• Aumenta il ritardo tra le esecuzioni dell'agente fantoccio
• non programmare le marionette e usare solo il calcio delle marionette o mcollective per attivare le corse
• pianificare le modifiche di Apache in modo che avvengano solo in determinati momenti.
• utilizzare due ambienti diversi (manutenzione e produzione) per gestire le cose. Mantieni la produzione leggera e usa la manutenzione per apportare modifiche.

Ecco un esempio di gestione di un host virtuale apache dal sito Web PuppetLabs: http://docs.puppetlabs.com/learning/definedtypes.html#an-example-apache-vhosts

L'impostazione e la rimozione della configurazione non dovrebbero essere un problema. Il problema maggiore sarebbe la rimozione dei file di dati per le applicazioni / i siti Web. Per questo, consiglierei l'archiviazione condivisa, come NFS / AFS. Se non stai utilizzando l'archiviazione condivisa, assicurati che i dati generati dall'utente vengano lasciati intatti, sottoposti a backup o migrati sul nuovo server.

Ho il sospetto che tu sia in una situazione di hosting di massa, come una società di web hosting, quindi raccomando che i nomi dei singoli siti non vengano codificati nel tuo manifest fantoccio. Per questo, ti consiglio di usare Hiera < http://puppetlabs.com/blog/first-look-installing-and-using-hiera/ . Hiera ti consente di utilizzare un modo separato per memorizzare l'elenco di host virtuali su mappature di server reali. Puoi usare file flat o un database con Hiera. Purtroppo, non conosco Hiera abbastanza per guidarti su come impostare la struttura di dati Hiera multilivello di cui potresti aver bisogno, ma posso almeno indirizzarti nella direzione generale di Hiera.