Come dovrebbe un dipartimento IT scegliere una distribuzione Linux standard?

C'è molta sensibilità della comunità riguardo a quali distribuzioni Linux sono appropriate per gli ambienti dei server di produzione e che non sono, tuttavia, molte di queste sensazioni sembrano religiosamente basate e raramente presentate con prove a sostegno.

Supponendo che stessimo cercando di selezionare una distribuzione Linux su cui standardizzare (perché abbiamo interesse a mantenere i nostri ambienti il ​​più omogenei possibile), quali criteri sono importanti e come si determinano in che misura le diverse distribuzioni soddisfano tali criteri?

Attualmente lavoro in un ambiente che utilizza Linux da oltre un decennio. Tutti in ufficio usano diverse distribuzioni sui loro desktop e sui server. Come tale, le scelte di distribuzione tendono a ruotare attorno a una serie di cose in nessun ordine particolare:

1. Storia - Ovviamente sistemi come RedHat e Debian sono in circolazione da molto tempo. Come tale, l'adagio "se non è rotto, non aggiustarlo" può essere usato per questi. L'aggiornamento diventa più semplice se il software è supportato bene su una distribuzione.
2. Familiarità - Simile alla storia, tuttavia tutti abbiamo i nostri preferiti. Ho tagliato i denti su Debian e sono migrato su Ubuntu (una decisione difficile all'epoca perché tendo a impegnarmi in una comunità). Al contrario, è un dolore dover ricordare come fare le cose su una dozzina di distro diverse (per non parlare di quelle costruite con i graffi).
3. Supporto : sono migrato su Ubuntu principalmente perché ho apprezzato ciò che stavano facendo per offrire supporto a pagamento. Questo è stato un punto di forza se mai un cliente ha avuto preoccupazioni sull'esecuzione di un sistema a lungo termine. Simile all'approccio di RedHat (ma all'epoca l'inferno di RPM stava succedendo). Anche per questo motivo disponiamo di numerosi server RedHat.
4. Dipendenze - Alcuni software sono più facili da usare su alcune distribuzioni semplicemente perché i pacchetti dipendenti sono più facilmente ottenibili o costruibili. Come esempio di questo sarebbe oVirt su RedHat. Non ci sono pacchetti per alcuni software in alcune distribuzioni. E potresti compilarlo, ma perché dovresti se il pacchetto fosse proprio lì su un'altra distribuzione?
5. Granularità : le distribuzioni come Gentoo offrono un controllo più preciso sul controllo delle versioni e sulla granularità del cambio software. Altre distro hanno "appuntamenti" in varie forme, ma non sono ancora così controllabili o affidabili.
6. Rilegatura - Sebbene sia possibile compilare dalla fonte sulla maggior parte delle distribuzioni, alcune distribuzioni sono migliori di altre. Ciò può avere un effetto, ad esempio, se il progetto modifica le librerie esistenti per funzionalità estese.
7. Prettiness - Alcune distro sono solo più belle. Ogni smanettone sa che è solo una lanugine (e probabilmente potresti cavartela come un'app Web in questi giorni) ma alcuni clienti sono entusiasti di questa roba, e lo sappiamo tutti.
8. Stabilità - Alcune distribuzioni trasmettono versioni "stabili" del software anziché "test", "sperimentali", ecc. Ciò può significare molto se si sa che la versione su cui si sta costruendo raggiungerà un consenso sulla stabilità. Puoi sviluppare "sperimentale" sapendo che una volta terminato il tuo progetto avrà raggiunto "stabilità" e su cui fare affidamento.
9. Gestione dei pacchetti - Se stai sviluppando qualcosa su base giornaliera e uscirà con migliaia di macchine in un colpo solo, allora probabilmente vorrai qualcosa che semplifichi la costruzione, la manutenzione e il monitoraggio dei pacchetti su quei sistemi.
10. Coerenza - Questo è più un argomento per la stessa distribuzione. Meno errori vengono commessi (e meno errori nella sicurezza) quando le persone possono concentrarsi su una distribuzione anziché su diverse.
11. Programma di rilascio prevedibile : se si desidera essere certi che il software rimanga supportato, gli aggiornamenti pianificati offrono un certo tipo di stabilità.
12. Sicurezza - Alcune distro hanno team di sicurezza attivi il cui compito è quello di rispondere immediatamente ai rischi di sicurezza reali in qualsiasi pacchetto approvato.

Queste sono solo alcune delle cose che mi vengono in mente per quanto riguarda i motivi per cui è stato scelto ciascun sistema. In questa decisione non vedo alcuna luce guida o preferenza di una distro sull'altra. La diversità e la scelta possono essere eccezionali e offrirti alcune opzioni davvero valide per avviare rapidamente un progetto, ma è anche il cappio che ti può appendere. Assicurati di pensare prima di cosa avrai bisogno. Pianificare quali sono le esigenze del sistema e quando il sistema verrà aggiornato o ritirato. Non dare per scontato che sarai sempre tu a mantenerlo.

Condividerò le mie esperienze lavorando come tecnologo in alcuni campi diversi ...

(Attenzione: questa è una storia su Red Hat e su come sono cresciuto professionalmente con esso)

Ho iniziato a lavorare con Linux professionalmente nel 2000-2002. Ciò avvenne durante l'ampia adozione di Red Hat e Red Hat Professional Editions (6.x, 7.x, 8.0) . Questi erano disponibili per il download gratuito e set confezionati in scatola. Potrebbero essere facilmente trovati nei negozi al dettaglio di computer.

Per me, questo ha avuto il vantaggio di coinvolgere hobbisti e utenti domestici con lo stesso prodotto che stava iniziando a emergere nell'azienda. Il mio lavoro in quel momento era di spostare i sistemi server dei clienti da Unices commerciali (HP-UX, AIX e SCO) alla piattaforma Red Hat.

Il risparmio sui costi è stato notevole! Sostituire i server PA-RISC da $ 100k + HP9000 con i server Intel Compaq ProLiant da $ 40k è stata una vittoria assoluta in termini di costi e prestazioni.

Quindi, perché Red Hat?

Red Hat è stato il primo a questo mercato, ottenendo supporto per attività commerciali, fornitori e hardware. Vedere grandi fornitori di applicazioni utilizzare Red Hat come piattaforma di destinazione ha concluso l'affare. Gli utenti di hobbisti come me sono stati in grado di trasferire facilmente le competenze perfezionate a casa nei nostri ambienti di lavoro. La comunità stava crescendo. Le pile di Slashdot , Freshmeat e LAMP hanno dominato! È stato un buon momento per Linux.

A questo punto, ero responsabile dello sviluppo e della valutazione delle distribuzioni Linux come piattaforma per una soluzione software ERP proprietaria. Mi sono bloccato con Red Hat. Ogni tanto provavo un'altra distro ( Mandrake , SuSE , Debian , Gentoo ), ma trovavo problemi con il packaging, il supporto hardware (server o periferiche), la (dimensione della) comunità o qualche altro affare.

Un esempio: stavo usando l'hardware Compaq / HP ProLiant dotato di schede PCI-X di espansione seriale Digi e software fax di produzione Esker VSIfax . Gli ultimi due avevano solo il supporto del driver per i sistemi operativi Red Hat. In alcuni casi, il software è stato consegnato solo in formato binario o RPM, impedendo un facile utilizzo su altre varianti di Linux.

Il momento conta nel mondo dell'Information Technology
Nessuno vuole essere uno che raccomanda la soluzione o il progetto perdente che alla fine rimane orfano, quindi ti attieni a scelte sicure. Gestivo uno stack tecnologico che doveva funzionare in modo affidabile e con diversi livelli di supporto. Scegliere una distribuzione diversa a quel punto sarebbe giusto. stato. irresponsabile.

La luna di miele di Red Hat si è conclusa per me nel 2003 con la sospensione delle edizioni professionali del software. Red Hat Enterprise Linux è stato il sostituto ed è arrivato con un bel po 'di bagaglio ... Costo (modello basato su abbonamento costoso), accessibilità (riduzione della base di utenti e della comunità) e confusione generale sul futuro ...

Ho iniziato a cercare alternative, rivalutando Gentoo, Debian e SuSE. Non sono riuscito a ottenere il giusto supporto su tutti i componenti del nostro stack tecnologico. Sono stato costretto a rimanere fedele all'ecosistema Red Hat ... A causa del selvaggio spostamento dei costi associato a Red Hat Enterprise Linux, ho finito per eseguire un Red Hat 8.0 altamente modificato per anni dopo la fine della sua vita. Fu solo quando i cloni di RHEL maturarono ( Whitebox Linux e, successivamente, CentOS ) che preparai un vero allontanamento dal mio standard.

Il vantaggio principale dei derivati ​​Red Hat era ed è la compatibilità binaria con le versioni RHEL a pagamento. È anche possibile eseguire conversioni sul posto tra RHEL e CentOS e viceversa. Ho continuato a lavorare con sistemi simili a RHEL fino a quando ho fatto la prossima mossa di carriera ...

In seguito mi sono trovato nel settore del trading finanziario ad alta frequenza , dove ero responsabile dell'ingegneria di ricerca e sviluppo e Linux per i sistemi di trading automatizzati fondamentali. L'enfasi in questo mondo era la velocità , attraverso accurati test e messa a punto. Ancora una volta, il supporto hardware era la chiave. Avrei specifiche schede di rete , hardware specializzato, hardware del server o librerie di applicazioni certificate solo per sistemi simili a RHEL o RHEL. Anche nei casi in cui le cose potrebbero essere compilate per altre varianti di Linux, è emerso il fattore comunità. Quando ero nel punto in cui avevo bisogno di ricercare un problema, spesso era un problema che poteva essere ricondotto a note o commenti nei report di Red Hat Bugzilla o, a volte, avrei semplicemente inviato una patch o una richiesta per la prossima versione .

Quando ho iniziato ad approfondire le reti a bassa latenza e l'ottimizzazione del kernel, ho iniziato a dissezionare i kernel RHEL stock e i kernel RHEL MRG Realtime . Ho notato quanto lavoro nelle versioni ... oltre 200 patch per un kernel kernel.org vanilla. Leggi i commenti e invia note. Potresti avere piccole cose come sysctlparametri esposti o impostazioni predefinite più sane applicate. Red Hat paga le persone per patchare, testare e risolvere questi problemi. Non ho visto lo stesso impegno da altre distribuzioni Linux ... Aggiungo il fatto che la piattaforma aziendale garantirà sicurezza reale, bugfix e supporto backport per anni .

Quindi alla fine mi sono trasferito in un'altra società finanziaria che era quasi completamente Gentoo sul server e sul desktop ... È stato un disastro per me. Provenendo dal mondo Red Hat e CentOS, ho riscontrato numerosi problemi di stabilità e gestione con l'installazione di Gentoo. Il controllo della versione era il problema più grande, ma anche il calo del supporto della comunità e la mancanza di test reali erano preoccupanti. Ho iniziato a introdurre RHEL nell'ambiente perché alcuni dei nostri software di terze parti lo richiedevano ...

Ma c'era un problema ... I miei sviluppatori erano abituati a Gentoo e avevano percorsi di aggiornamento relativamente facili per le librerie core e le versioni dell'applicazione. Non potevano adattarsi alle versioni principali fisse su cui Red Hat Enterprise Linux standardizza. Il processo di sviluppo e rilascio è stato afflitto da domande sul perché GLIBC 2.7 non potesse essere innestato su RHEL 5.x o perché una determinata versione di compilatore o libreria non fosse disponibile. Quando è stato detto che gli aggiornamenti tra le principali versioni di RHEL / CentOS richiedevano essenzialmente ricostruzioni complete , hanno perso molta fiducia nella soluzione.

A questo punto, mi sono reso conto che Red Hat si stava muovendo troppo lentamente per gli sviluppatori che volevano essere all'avanguardia. RHEL 6.x è stato un aggiornamento molto necessario e gradito, ma questo tema è diventato più evidente quando ho iniziato a intervistare startup e aziende che aderivano ai principi DevOps .

Oggi ...
Un numero crescente di sviluppatori e utenti Linux proviene da ambienti Linux non Red Hat, non SuSE, non aziendali.

• Stanno usando Ubuntu o Debian ...
• Non hanno avuto a che fare con l'hardware della vecchia scuola o il supporto di grandi fornitori.
• Stanno scrivendo le proprie applicazioni da zero (autoportanti).
• La virtualizzazione e il cloud computing astraggono il livello hardware, quindi le preoccupazioni per i driver di controller RAID funky, le periferiche PCI-X o gli agenti di gestione distribuiti binari non sono nemmeno sul radar.
• Questi utenti desiderano gli strumenti e l'area utente a cui sono abituati.

Quindi c'è un conflitto ... Questi utenti non capiscono perché dovrebbero essere limitati alle versioni dell'applicazione o della libreria. Gli amministratori della vecchia scuola si stanno ancora adeguando al nuovo paradigma . Gli argomenti che sembrano essere radicati nella religione sono in realtà solo funzioni di come le persone hanno sviluppato le loro rispettive competenze.

Oggi ho visto un annuncio di lavoro per una posizione di ingegnere DevOps Linux molto senior che diceva:

Deve essere esperto in distribuzioni Linux basate su Debian (Ubuntu e varianti ok. Red Hat accettabile , ma non preferito)

Quindi immagino che funzioni in entrambi i modi ... Mi sono allontanato dalle opportunità di lavoro perché i server 800 CentOS che avrei gestito sarebbero stati convertiti in Ubuntu. Certo, Linux è Linux ... ma non pensavo che sarei stato il più efficace possibile ... Mi sono imbattuto nelle installazioni di Debian e ho desiderato che fosse in uso una distribuzione basata su RPM. Ho avuto le accese discussioni sui meriti di varie piattaforme (di solito mettendo Gentoo in fondo alla lista).

Allora, cosa è giusto per il TUO ambiente? Dipende. Sono stato in aziende in cui gli ingegneri di sistema guidano le decisioni, così come le organizzazioni in cui gli sviluppatori sono i re. Penso che l'accordo migliore sia quando gli sviluppatori e le persone che supportano i sistemi concordano sulla piattaforma. Ma a parte questo, pensa al supporto a lungo termine, all'usabilità, alla comunità e a ciò che ospita lo stack di applicazioni nel modo più appropriato.

Uno sviluppatore di talento dovrebbe essere in grado di lavorare in un ambiente simile a RHEL o simile a Debian. E bene, le piattaforme di sviluppo dovrebbero rispecchiare l'ambiente di produzione. Vai da lì ...