Come gestisci e distribuisci le porte di FreeBSD in un ambiente di grandi dimensioni?

19

Sono curioso di sapere come le persone stiano implementando le porte di FreeBSD nel loro ambiente. Presumo che la maggior parte delle persone che usano FreeBSD stiano effettivamente usando Ports (e spesso portupgrade per l'aggiornamento con i binari). Sono comunque interessato a come hai questa configurazione, poiché non sono soddisfatto di come funzionano le cose nelle versioni recenti. Ora eseguo FreeBSD 9.0 e sto riscontrando problemi.

Ho impostato le cose come segue:

/ usr / doors è condiviso tramite NFS da un nodo (con 'aggiornamento portnap fetch' notturno).
Ogni nodo monta / usr / porte con lettura-scrittura
Ho impostato "WRKDIRPREFIX = / usr / tmp" in /etc/make.conf su tutti i nodi
Ho configurato Portsnap per utilizzare un indice locale aggiungendo quanto segue a /usr/local/etc/pkgtools.conf:

ENV['LOCALINDICES'] ||= '/var/db'

ENV['PORTS_INDEX'] ||= ENV['LOCALINDICES'] + '/INDEX.local'

Posso eseguire con successo portupgrade -p packageper creare un pacchetto e quindi portupgrade -P packageinstallare il binario sugli altri nodi.

Tuttavia, a volte ricevo il seguente problema: /var/db/INDEX.local:23265:dbm_store failed

Non riesco a pensare ad altre ottimizzazioni che posso fare al sistema, poiché l'indice ora risiede localmente e l'unica cosa realmente esportata è l'albero dei porti e nulla viene mai scritto lì dai nodi.

freebsd

— vpetersson
fonte

Un'opzione sarebbe quella di avere un albero di porte locale completo su ogni nodo (e forse semplicemente montare "distfile" e "pacchetti"), ma questo sembra un enorme spreco di spazio (e per non parlare di molti aggiornamenti inutili).

— vpetersson,

vpeterson: Questa è una domanda che deve essere posta (in questo momento sono bloccato. E +5 voti e 3 stelle suggeriscono che non siamo soli). Forse ripulisci questa domanda e indica alcuni problemi specifici che stai cercando di risolvere. (FWIW, qualcuno ha votato per chiudere la tua domanda. Personalmente mi piacerebbe molto vedere questa, o una domanda simile, salvata).

— Stefan Lasiewski

Non sono sicuro di come chiarire la domanda. Inoltre, non penso che @ voretaq7 risponda effettivamente alle domande, ma piuttosto suggerisce un metodo alternativo. La domanda riguarda davvero ciò che l'argomento suggerisce: come stanno le persone che distribuiscono le porte di FreeBSD in un ambiente multi-nodo.

— vpetersson

13

Non sono mai stato pienamente soddisfatto del sistema di porte in un ambiente di grandi dimensioni: sembra sempre che sia necessario applicare una gestione esterna per farlo funzionare bene.

I miei migliori consigli (in ordine di preferenza crescente, soluzione "peggiore" a soluzione "migliore"):

Se stai costruendo su ogni host, non farlo .
Se è necessario, non farlo su NFS con supporti di lettura / scrittura come descritto: Di solito puoi fidarti delle porte per fare la cosa giusta e non calpestare l'albero delle porte se fornisci directory di lavoro alternative, ma è sempre meglio sii sicuro che dispiaciuto: esegui un mirror CVS / csup locale e csup tutti i tuoi host da quella casella, quindi costruisci localmente come faresti se fossero macchine singole.
Sì, lo so che significa avere più spazio su disco sugli host e un ulteriore passaggio. Inoltre è quasi garantito per essere senza problemi.
Avvertimento: Probabilmente si desidera sincronizzare i file di configurazione del pacchetto (rsync o simili) da un "host di configurazione" designato per garantire coerenza su ogni macchina (se si desidera, è anche possibile risincronizzare l'intero albero delle porte, anziché utilizzare csup su ciascun nodo).

Utilizzare un host di build, creare pacchetti e installarli.
Una soluzione molto migliore rispetto alla creazione su ogni singolo computer: utilizzare un host di build per creare pacchetti e indirizzare gli strumenti su tali pacchetti.
Ciò significa mantenere un host di build in giro per ogni architettura eseguita (o cross-compilazione), ma alla fine è più bello per le macchine target (nessun lavoro di compilazione di grandi dimensioni, una garanzia di coerenza)

Utilizzare uno strumento di configurazione / gestione del sistema.
Questa è la soluzione che mi è venuta in mente: creo un'immagine server standard e la utilizzo nel mio ambiente radmind. Puoi fare cose simili con Puppet o Chef . Ciò ha tutti i vantaggi dell'utilizzo di un host di build (coerenza, meno carico sui singoli server) e aggiunge il vantaggio della gestione della configurazione.

Avvertenza: funziona davvero bene solo se le tue macchine sono "identiche" - Cioè puoi installare lo stesso set di porte su tutte. Esso può funzionare se a diversi gruppi di porte, ma che aumenta sostanzialmente il carico amministrativo.

Disclaimer: sono il manutentore della porta per sysutils/radmind. Sì, mi piace così tanto che l'ho adottato.

Tutto questo si basa sulla mia esperienza nella gestione di ambienti FreeBSD di varie dimensioni (che vanno da 1-2 macchine a oltre 100). Gli strumenti di configurazione / gestione del sistema che spingono e mantengono un'immagine standardizzata sono davvero il modo migliore per gestirlo nella mia esperienza.

— voretaq7
fonte

Buoni suggerimenti. Ho giocato con Puppet un po 'in passato e lo adoro su Ubuntu. Tuttavia, non sono sicuro di come funzioni con FreeBSD. Devo ancora provarlo. Indipendentemente da ciò, anche con Puppet, penso che faccia appello a Portupgrade, che ci riporta al punto di partenza. Non vedo nessun altro modo in cui potrebbe funzionare, dato che dovrebbe quindi fare pkg_delete / pkg_add o 'pkg_add -f' che non sarebbe una buona idea. Per quanto riguarda l'hardware, sono tutti identici poiché funzionano in un cloud pubblico (KVM / Qemu).

— vpetersson,

Se le configurazioni hardware e software di base sono identiche, suggerirei qualcosa come radmind, che gestisce l'intera immagine del sistema. Puppet e Chef sono ottimi strumenti, tuttavia, come hai sottolineato, chiamano i binari del sistema operativo sottostante, il che ti lascia indietro usando un host di build e distribuendo pacchetti. radmind evita questo assumendo la gestione a livello di filesystem ("Se non è quello che dovrebbe essere qui, sostituiscilo o rimuovilo") piuttosto che cercare di essere un amministratore di sistema surrogato ("Esegui questi comandi / cambia questi file per me per configurare il scatola").

— voretaq7,

Bene, i sistemi hanno hardware identico, ma non configurazioni identiche. Dovrò esaminare Radmind ma non sono sicuro che sia l'approccio migliore. L'uso degli strumenti integrati dovrebbe funzionare con IMHO, motivo per cui sto contattando la community per vedere se ho perso qualcosa di ovvio. Difficilmente posso essere l'unico a provare a farlo.

— vpetersson,

Il built-in strumenti sicuramente DO lavoro, hanno solo richiedono un sacco di aiuto (server di build, la distribuzione locale di pacchetti, ecc) - Sono davvero orientati verso la gestione di una macchina, e non scala, così come potevano. Nota che ho lasciato fuori l'opzione di far girare il tuo server freebsd-update - non l'ho mai provato per qualcosa di più del semplice sistema di base, ma teoricamente è possibile. Mi sono appena attaccato alle cose che so funzionare :)

— voretaq7,

Sì, questa è un'idea interessante in realtà. Non sono sicuro che funzionerebbe con la distribuzione di port-pacchetti senza molte modifiche. Sono davvero curioso di sapere come lo fanno i amministratori di sistema di grandi dimensioni, dato che ci sono molte grandi distribuzioni di FreeBSD. Ognuno di loro lancia la propria soluzione? Se è così, sembra piuttosto strano e non molto open source.

— vpetersson,

6

Strano che nessuno abbia menzionato porti-mgmt / tinderbox :

Tinderbox è un sistema di creazione di pacchetti per le porte di FreeBSD, basato su script Portbuild ufficiali usati nel cluster di costruzione. Tinderbox è stato scritto da Joe Marcus Clarke.

È possibile definire più jail (versioni del sistema di base) e più porte. La combinazione di jail e doorstree si chiama build. Una prigione di Tinderbox non è ciò che viene inteso come una prigione in FreeBSD, è in realtà un dato mondo in un chroot. Tinderbox supporta il rilevamento automatico delle dipendenze e ricostruisce solo i pacchetti modificati dall'ultima esecuzione. Tinderbox ha il supporto per la notifica via email di build fallite. Tinderbox si integra bene anche con ccache.

Tinderbox è progettato per fornire facilmente pacchetti di porte di cui hai bisogno, per piattaforme e architetture di cui hai bisogno. Tinderbox è anche uno strumento eccellente per testare nuove porte e aggiornamenti delle porte, in particolare per testare dipendenze e liste di imballaggio. È anche utile per testare le porte su varie versioni di FreeBSD, dato che puoi eseguire il mondo FreeBSD 6.X come jail sull'host FreeBSD 7.X / 8.X.

Anche il passaggio a pkgng semplifica notevolmente le distribuzioni dei pacchetti.
Dai un'occhiata su github: https://github.com/pkgng/pkgng

— SaveTheRbtz
fonte

1

Sebbene ciò possa certamente essere utile per creare i pacchetti effettivi in un ambiente diversificato (versioni multiple, architetture ecc.), Non risolve davvero il problema della distribuzione dei pacchetti.

— vpetersson

Tinderbox rende i pacchetti disponibili su HTTP, quindi puoi combinarli con i commenti sulla risposta di voretaq7 per ottenere la tua soluzione di distribuzione (ad esempio set PACKAGEROOT/ PACKAGESITEe usa radmind o Puppet / Chef).

— James O'Gorman,

Sì, ma la creazione e la distribuzione di pacchetti non è il problema. Posso usare portupgrade (-p) per creare il pacchetto e distribuirli tramite NFS (con o senza un albero delle porte). Il problema è che questo modello richiede ancora a) un albero di porte completo localmente oppure b) un albero di porte esportato tramite NFS, il che ci riporta al problema attuale.

— vpetersson,

2

Portupgrade farà esattamente quello che dovresti fare se stavi costruendo dal sorgente o usando pacchetti binari - pkg_deletedeve essere eseguito prima e quindi installare la nuova versione. OpenBSD lo ha gestito meglio includendo un'opzione di aggiornamento in pkg_add. Non sono sicuro di Portupgrade, ma portmaster può funzionare solo usando INDEX e non un albero di porte completo.

— James O'Gorman,

1

Giusto, ma pkg_delete non è certo un approccio ragionevole. Supponiamo che tu voglia aggiornare Ruby, Python o qualsiasi altro pacchetto che è un prerequisito per un gran numero di altri pacchetti. pkg_delete richiederebbe quindi di eliminare tutte le dipendenze, che difficilmente è un'opzione per un sistema di produzione. Portupgrade fa un lavoro molto migliore con questo, ma ancora una volta, non sembra ridimensionare.

— vpetersson,

3

Ho gestito oltre 100 server FreeBSD semplicemente condividendo / usr in sola lettura su NFS ottimizzato, spostando i database dei pacchetti da / var a / usr e collegandoli a loro (non strettamente necessari ma abilita pkg_info e simili). Potrebbero esserci stati uno o due altri file che dovevano essere spostati in una direzione o nell'altra e collegati in modo simbolico, ma l'intera configurazione mi ha impiegato circa un'ora per capire. Ha funzionato molto, molto bene. Se avessi incontrato problemi di ridimensionamento avrei aggiunto altri server NFS e diviso il carico di lavoro, ma non si è mai verificato. Le prestazioni non sono mai state un problema per me (in realtà è stato grandioso) ma suppongo che potresti mettere il server / usr (o una sua copia) su un md.

— lanugine
fonte

Condividere i file dei pacchetti creati su NFS (che sembra di cosa stai parlando?) È sicuramente un altro approccio ragionevole: puoi quindi usare qualcosa come Puppet (o persino script SSH e shell fatti in casa) per installare / aggiornare i pacchetti dalla condivisione NFS.

— voretaq7,

1

Sembra che nessuno abbia avuto una buona soluzione a questo purtroppo. Molto probabilmente ciò è dovuto alle limitazioni degli strumenti di base.

Ecco cosa mi è venuto in mente: ho scartato l'idea di esportare l'intero albero delle porte. Invece, mi sono arreso e ho inserito un albero di porte completo su ciascun nodo. Ho quindi montato "pacchetti" su NFS (per consentire la distribuzione di pacchetti).

Ho anche intenzione di utilizzare un proxy di memorizzazione nella cache (probabilmente Squid) per accelerare il processo portnap. Ho scritto un breve post su come impostare questo sul mio blog.

Riferimenti:

— vpetersson
fonte