Vraag Hoe moet een IT-afdeling een standaard Linux-distributie kiezen?


Er heerst veel gemeenschapsgevoel over wat Linux-distributies geschikt maken voor omgevingen met productieservers en die echter niet veel van dit gevoel religieus lijken te zijn en zelden worden gepresenteerd met ondersteunend bewijs.

Ervan uitgaande dat we een Linux-distributie probeerden te standaardiseren (omdat we er belang bij hebben om onze omgevingen zo homogeen mogelijk te houden), welke criteria zijn belangrijk, en hoe bepaal je hoe goed verschillende distributies aan die criteria voldoen?


70
2017-12-27 21:05


oorsprong


Ik zou graag willen dat anderen het uitleggen hoe ze gaan over het kiezen van een enkele Linux-distributie voor hun organisatie naar mij. Ik zit in die situatie, en "algemene kennis" zou me vertellen om RHEL of CentOS te kiezen, maar behalve commerciële steun, heb ik niet veel feitelijke beweringen gehoord waarom een ​​van die dingen beter is dan de andere. - wfaulk
serverfault.com/questions/53954/centos-vs-ubuntu - Iain


antwoorden:


Ik werk momenteel in een omgeving die al meer dan een decennium Linux gebruikt. Iedereen op kantoor gebruikt verschillende distro's op hun desktops en op de servers. Als zodanig hebben de distributiekeuzes de neiging om in een bepaalde volgorde rond een aantal dingen te draaien:

  1. Geschiedenis - Uiteraard bestaan ​​systemen als RedHat en Debian al heel lang. Als zodanig kan het adagium "als het niet kapot is, repareer het niet" hiervoor worden gebruikt. Upgraden wordt eenvoudiger als de software goed wordt ondersteund op een distro.
  2. vertrouwdheid - Vergelijkbaar met de geschiedenis, maar we hebben allemaal onze favorieten. Ik knipte mijn tanden op Debian en migreerde naar Ubuntu (een moeilijke beslissing op dat moment omdat ik de neiging heb om me aan een gemeenschap te binden). Omgekeerd is het lastig om te onthouden hoe je dingen moet doen op een tiental verschillende distro's (om nog maar te zwijgen van de scratch-built versies).
  3. Ondersteuning - Ik migreerde vooral naar Ubuntu omdat ik op prijs stelde wat ze deden, voor zover ik betaalde ondersteuning bood. Dat was een verkoopargument als ooit een klant zich zorgen maakte over het langdurig uitvoeren van een systeem. Vergelijkbaar met de aanpak van RedHat (maar de RPM-hel was op dat moment aan de gang). We hebben om deze reden ook een aantal RedHat-servers.
  4. afhankelijkheden - Sommige software is gemakkelijker te gebruiken op sommige distributies, simpelweg omdat de afhankelijke pakketten gemakkelijker verkrijgbaar of te bouwen zijn. Als voorbeeld hiervan zou OVirt on RedHat. Er zijn geen pakketten voor sommige software op sommige distributies. En je zou het kunnen compileren, maar waarom zou je het pakket daar op een andere distro hebben?
  5. granularity - Distros zoals Gentoo bieden fijnere controle over versiebeheer en softwarematig geschakelde granulariteit. Andere distro's hebben "pinning" in verschillende vormen, maar dat is nog steeds niet zo controleerbaar of betrouwbaar.
  6. Verbindend - Hoewel het mogelijk is om te compileren vanaf de bron op de meeste distro's, zijn sommige distro's beter dan andere. Dit kan bijvoorbeeld effect hebben als uw project bestaande bibliotheken patcht voor uitgebreide functionaliteit.
  7. prettiness - Sommige distro's zien er alleen maar beter uit. Elke geek weet dat het gewoon pluis is (en je zou er waarschijnlijk van af kunnen komen door het tegenwoordig als een web-app te doen), maar sommige klanten zijn versteld van dit spul en dat weten we allemaal.
  8. Stabiliteit - Sommige distro's streamen "stabiele" versies van software in tegenstelling tot "testen", "experimenteel", enz. Dit kan veel betekenen als je weet dat de versie waarop je bouwt uiteindelijk een consensus over stabiliteit zal bereiken. U kunt zich ontwikkelen op "experimenteel" wetende dat tegen de tijd dat uw project is voltooid, het "stabiel" is en goed is om op te vertrouwen.
  9. Pakketbeheer - Als u dagelijks iets aan het ontwikkelen bent, en het gaat uit naar duizenden machines in één hit, dan wilt u waarschijnlijk iets dat het gemakkelijk maakt om pakketten op die systemen te bouwen, te onderhouden en bij te houden.
  10. Consistentie - Dit is meer een argument voor de dezelfde distro. Er worden minder fouten gemaakt (en minder fouten in de beveiliging) wanneer mensen zich kunnen richten op één distributie in plaats van meerdere.
  11. Voorspelbaar releaseschema - Als u zeker wilt weten dat uw software ondersteund blijft, bieden geplande upgrades een bepaald type stabiliteit.
  12. Veiligheid - Sommige distributeurs hebben actieve beveiligingsteams wiens taak het is om onmiddellijk te reageren op echte veiligheidsrisico's in een goedgekeurd pakket.

Dat zijn maar een paar dingen die uit de hoogte raken met betrekking tot de redenen waarom elk systeem is gekozen. Ik zie niet één leidend licht of voorkeur van een distro over een ander in deze beslissing. Diversiteit en keuzemogelijkheden kunnen geweldig zijn en je een aantal echt goede opties bieden om een ​​project snel op gang te krijgen, maar het is ook de strop die je kan ophangen. Zorg ervoor dat je vooruitdenkt wat je nodig hebt. Plan wat de behoeften van het systeem zijn en wanneer het systeem wordt geüpgraded of met pensioen gaat. Ga er niet vanuit dat je altijd degene bent die het handhaaft.


59
2017-12-28 02:45



En de # 7 Prettiness is inderdaad meer een factor voor die installaties die Linux op het bureaublad gebruiken voor de algemene gebruikersgemeenschap. - Magellan
Ik zou ook toevoegen Voorspelbaar releaseschema. U wilt het multi-serverimplementatieproject niet starten om erachter te komen dat de nieuwe versie van distro de volgende week uitkomt. Of loop jarenlang dezelfde oude distro met oude pakketten (hoest * rhel5 / centos5) zonder een bekende upgrade-datum. Bijvoorbeeld: Ubuntu brengt elke 6 maanden en LTS-versie om de 2 jaar in april nieuwe versies uit. Als u dat weet, kunt u uw projecten en middelen beter indelen. - Mxx


Ik zal mijn ervaringen delen als een technoloog op een paar verschillende gebieden ...

(Let op: dit is een verhaal over Red Hat en hoe ik er professioneel mee ben opgegroeid)

Ik ben in 2000-2002 professioneel met Linux gaan werken. Dit was tijdens de brede adoptie van Red Hat en de Red Hat Professional Editions (6.x, 7.x, 8.0). Deze waren beschikbaar als gratis download en in dozen verpakte sets. Ze zijn gemakkelijk te vinden in computerwinkels.

Voor mij had dit het voordeel dat ik hobbyisten en thuisgebruikers bij de dezelfde product dat zich in de onderneming begon te ontwikkelen. Mijn werk was op dit moment om klantenserversystemen te verplaatsen van commerciële Unices (HP-UX, AIX en SCO) naar het Red Hat-platform.

De kostenbesparingen waren aanzienlijk! Het vervangen van $ 100k + HP9000 PA-RISC-servers met $ 40k Compaq ProLiant Intel-servers was een absolute overwinning op de kosten en prestaties.

Dus, waarom Red Hat?

Red Hat was de eerste op deze markt die kritieke bedrijfs-, leverancier- en hardware-ondersteuning verkreeg. Het zien van grote applicatie-leveranciers gebruiken Red Hat als een doelplatform verzegelde de deal. Hobbyistische gebruikers zoals ik waren in staat om de vaardigheden die thuis in onze werkomgevingen werden gedaan met gemak over te dragen. De gemeenschap groeide. Slashdot, Vers vlees en LAMP-stapels geregeerd! Het was een goede tijd voor Linux.

Op dit punt was ik verantwoordelijk voor de ontwikkeling en evaluatie van Linux-distributies als een platform voor een eigen ERP-softwareoplossing. Ik bleef bij Red Hat. Af en toe zou ik een andere distro proberen (alruin, SuSE, Debian, Gentoo), maar zou problemen met de verpakking, hardware-ondersteuning (servers of randapparatuur), de (grootte van de) community of een andere deal-breaker.

Een voorbeeld: ik gebruikte Compaq / HP ProLiant hardware uitgerust met Digi Seriële uitbreiding PCI-X-kaarten en Esker VSIfax productie faxsoftware. De laatste twee hadden alleen stuurprogramma-ondersteuning voor Red Hat-besturingssystemen. In sommige gevallen werd software alleen in binaire of RPM-vorm afgeleverd, zodat eenvoudig gebruik op andere Linux-varianten onmogelijk was.

Momentum doet er in de wereld van de informatietechnologie toe
Niemand wil iemand zijn die het aanbeveelt verliezen oplossing of project dat uiteindelijk verweesd raakt, dus blijf je bij veilige keuzes. Ik beheerde een technologiestack die betrouwbaar moest werken en meerdere lagen van ondersteuning had. Het kiezen van een andere verdeling op dat moment zou juist zijn. geweest. onverantwoordelijk.


De Red Hat-huwelijksreis eindigde voor mij in 2003 met de stopzetting van de professionele edities van de software. Red Hat Enterprise Linux was de vervanger en kwam met heel wat bagage ... Kosten (duur op abonnement gebaseerd model), toegankelijkheid (het gebruikersbestand en de gemeenschap doen slinken) en algemene verwarring over de toekomst ...

Ik ging op zoek naar alternatieven en evalueerde Gentoo, Debian en SuSE opnieuw. Ik kon niet de juiste ondersteuning krijgen voor alle componenten van onze technologiestack. Ik moest me vasthouden aan het Red Hat-ecosysteem ... Vanwege de wilde kostenverschuiving die verband hield met Red Hat Enterprise Linux, had ik uiteindelijk een sterk gewijzigde Red Hat 8.0 voor jaar voorbij het einde van zijn levensduur. Pas toen de RHEL-klonen volgroeiden (Whitebox Linux, en later, CentOS) dat ik een echte stap van mijn standaard voorbereidde.

Het grote voordeel van Red Hat-derivaten was en is binaire compatibiliteit met de betaalde RHEL-versies. Het is zelfs mogelijk om interne conversies tussen RHEL en CentOS uit te voeren en omgekeerd. Ik bleef werken met RHEL-achtige systemen totdat ik de volgende carrièrestap maakte ...


Ik vond mezelf later in de hoogfrequente financiële handel industrie, waar ik verantwoordelijk was voor R & D en Linux-engineering voor kritieke geautomatiseerde handelssystemen. De nadruk in deze wereld was snelheid, door middel van zorgvuldig testen en tunen. Nogmaals, hardware-ondersteuning was de sleutel. Ik zou specifiek hebben netwerkkaarten, gespecialiseerde hardware, serverhardware of toepassingsbibliotheken die alleen zijn gecertificeerd voor RHEL- of RHEL-achtige systemen. Zelfs in gevallen waarin dingen gecompileerd konden worden voor andere Linux-varianten, ontstond de gemeenschapsfactor. Toen ik op het punt stond dat ik een probleem moest onderzoeken, was het vaak een probleem dat kon worden herleid tot notities of opmerkingen in Red Hat Bugzilla-rapporten, of soms diende ik gewoon een patch of verzoek in voor de volgende release .

Toen ik me ging verdiepen in low-latency-netwerken en kernel-tuning, begon ik de RHEL-kernels van het bestand te ontleden en RHEL MRG Realtime kernels. Ik merkte hoeveel werk wanneer in de releases ... 200+ patches naar een vanilla kernel.org kernel. Lees de opmerkingen en maak aantekeningen. Je hebt misschien kleine dingen sysctl parameters blootgesteld of meer gezonde standaardwaarden toegepast. Red Hat betaalt mensen om deze problemen op te lossen, te testen en op te lossen. Ik zag niet dezelfde toewijding van andere Linux-distributies ... Voeg daarbij het feit dat het enterprise-platform gegarandeerd echte beveiliging, bugfix en backport-ondersteuning biedt voor jaar.


Dus uiteindelijk ben ik verhuisd naar een ander financieel bedrijf dat bijna helemaal Gentoo was op de server en bureaublad ... Het was een ramp voor mij. Vanuit de Red Hat- en CentOS-wereld kwam ik veel stabiliteits- en beheerproblemen tegen met de Gentoo-installatie. Versiebeheer was het grootste probleem, maar afnemende gemeenschapsondersteuning en gebrek aan echte tests waren ook zorgen. Ik begon RHEL in de omgeving te introduceren omdat sommige van onze software van derden dit vereisten ...

Maar er was een probleem ... Mijn ontwikkelaars waren gewend aan Gentoo en hadden relatief eenvoudige upgradespaden voor kernbibliotheken en applicatieversies. Ze konden zich niet aanpassen aan het hebben van de vaste hoofdversies waarop Red Hat Enterprise Linux standaardiseert. Het ontwikkelings- en releaseproces werd geplaagd door vragen over waarom GLIBC 2.7 niet kon worden geënt op RHEL 5.x of waarom een ​​bepaalde compiler- of bibliotheekversie niet beschikbaar was. Wanneer verteld dat upgrades tussen belangrijke versies van RHEL / CentOS essentieel vereiste volledige herbouwingen, ze verloren veel vertrouwen in de oplossing.

Op dit moment besefte ik dat Red Hat veel te traag ging met ontwikkelaars die op de vlucht wilden komen. RHEL 6.x was een broodnodige en welkome upgrade, maar dit thema werd duidelijker toen ik begon te interviewen met startups en bedrijven die zich op DevOps-principes.


Vandaag...
Een toenemend aantal ontwikkelaars en Linux-gebruikers komt uit niet-Red Hat, non-SuSE, niet-enterprise Linux-omgevingen.

  • Ze gebruiken Ubuntu of Debian ...
  • Ze hadden geen te maken met old-school hardware of grote leveranciersondersteuning.
  • Ze schrijven hun eigen applicaties vanaf het begin (self-supported).
  • Virtualisatie en cloud computing abstraheren de hardwarelaag, dus zorgen over funky RAID-controllerstuurprogramma's, PCI-X-randapparatuur of binair verdeelde beheeragenten zijn niet eens op de radar.
  • Deze gebruikers willen de tools en het gebruikersland waar ze aan gewend zijn.

Er is dus een conflict ... Deze gebruikers begrijpen niet waarom ze zouden worden beperkt in applicatie- of bibliotheekversies. Old-school beheerders zijn nog steeds aan het aanpassen nieuw paradigma. Argumenten dat lijken wortelen in religie zijn eigenlijk gewoon functies van hoe mensen hun respectievelijke vaardigheden hebben ontwikkeld.

Ik zag vandaag een vacature voor een zeer senior DevOps Linux-ingenieurspositie die luidde:

Moet bekwaam-tot-expert zijn in Debian-gebaseerde Linux-distributies   (Ubuntu en varianten oke. Red Hat begaanbaar, maar niet voorkeur)

Dus ik denk dat het in beide richtingen werkt ... Ik ben weggegaan van vacatures omdat de 800 CentOS-servers die ik zou beheren, naar verwachting zouden worden geconverteerd naar Ubuntu. Natuurlijk, Linux is Linux ... maar ik had niet het gevoel dat ik zo effectief zou zijn als ik zou kunnen zijn ... Ik heb gedompeld met Debian-installaties en wilde dat er een RPM-gebaseerde distro in gebruik was. Ik heb de verhitte discussies gehad over de verdiensten van verschillende platforms (meestal plaatste ik Gentoo onderaan de lijst).

Dus wat is goed voor UW omgeving? Het hangt er van af. Ik heb gewerkt in bedrijven waar systeemingenieurs beslissingen nemen, evenals organisaties waar de ontwikkelaars koning zijn. Ik denk dat de beste overeenkomst is wanneer ontwikkelaars en de mensen die de systemen ondersteunen, het eens zijn over het platform. Maar denk daar buiten ook aan op lange termijn ondersteuning, bruikbaarheid, gemeenschap en wat uw applicatie op de meest geschikte manier onderbrengt.

Een getalenteerde ontwikkelaar moet kunnen werken in een RHEL-achtige of Debian-achtige omgeving. En ja, ontwikkelingsplatforms moeten de productieomgeving weerspiegelen. Ga jij vanaf daar ...


69
2017-12-28 03:21



@dyasny Het zou interessant zijn om het Debian-standpunt te horen. - ewwhite
@ewwhite zou je waarschijnlijk een beheerder van sourceforge willen laten pitchen. Weet je wat? - dyasny
@dyasny Geen reactie :) - ewwhite
Deze heer, is de beste post die ik tot nu toe heb ontmoet in serverfault. Ik denk dat ik hier een fysieke kopie van zou maken en op mijn plank zou zetten en in mijn werkkubus. Je hebt de verklaring van systeemingenieurs gedurende een tijdperk herhaald. Geweldig, geweldig bericht. - Soham Chakraborty
@SohamChakraborty Oh, ik voel me gewoon oud ... maar vandaag, na het lezen van een vacature op deze site, drong het tot me door dat mijn redenen om Red Hat terug te gebruiken dezelfde reden is waarom mensen Ubuntu, etc. op hun systemen vandaag. Het is waar ze bekend mee zijn op de desktop! - ewwhite