Řešení 1:
Podělím se o své zkušenosti z práce technologa v několika různých oblastech...
(Pozor:toto je příběh o Red Hat a o tom, jak jsem s ním profesně vyrůstal)
S Linuxem jsem začal profesionálně pracovat v letech 2000-2002. Bylo to během širokého přijetí Red Hat a Red Hat Professional Editions (6.x, 7.x, 8.0). Ty byly k dispozici ke stažení zdarma, stejně jako sady zabalené v krabicích. Lze je snadno najít v maloobchodních prodejnách počítačů.
Pro mě to mělo tu výhodu, že jsem stejným zaujal fandy a domácí uživatele produkt, který se v podniku začal objevovat. Mou prací v této době bylo přesunout zákaznické serverové systémy z komerčních Unices (HP-UX, AIX a SCO) na platformu Red Hat.
Úspora nákladů byla značná! Nahrazení serverů HP9000 PA-RISC v hodnotě 100 000 $ a servery Compaq ProLiant Intel v hodnotě 40 000 $ byla absolutní výhrou z hlediska nákladů a výkonu.
Proč tedy Red Hat?
Red Hat byl první na tomto trhu a získal kritickou obchodní, dodavatelskou a hardwarovou podporu. Vidění velkých dodavatelů aplikací, kteří používají Red Hat jako cílovou platformu, uzavřelo dohodu. Hobbyoví uživatelé, jako jsem já, dokázali snadno přenést dovednosti vypilované doma do našeho pracovního prostředí. Komunita se rozrůstala. Slashdot, Freshmeat a LAMP stacky vládly! Pro Linux to byla dobrá doba.
V tomto okamžiku jsem byl zodpovědný za vývoj a hodnocení linuxových distribucí jako platformy pro proprietární softwarové řešení ERP. Zůstal jsem u Red Hatu. Občas jsem zkoušel jinou distribuci (Mandrake, SuSE, Debian, Gentoo), ale našel jsem problémy s balením, hardwarovou podporou (servery nebo periferie), (velikost) komunita nebo nějaký jiný narušovatel.
Příklad:Používal jsem hardware Compaq/HP ProLiant vybavený rozšiřujícími kartami Digi Serial PCI-X a produkčním faxovým softwarem Esker VSIfax. Poslední dva měly podporu ovladačů pouze pro operační systémy Red Hat. V některých případech byl software dodán pouze v binární nebo RPM formě, což znemožňuje snadné použití na jiných variantách Linuxu.
Ve světě informačních technologií záleží na hybnosti
Nikdo nechce být tím, kdo doporučuje prohru řešení nebo projekt, který nakonec osiřel, takže se budete držet bezpečných možností. Spravoval jsem technologický stack, který potřeboval spolehlivě fungovat a mít několik vrstev podpory. Volba jiné distribuce v tomto bodě by stačila. byl. nezodpovědné.
Líbánky Red Hat pro mě skončily v roce 2003 ukončením profesionálních verzí softwaru. Red Hat Enterprise Linux byl náhradou a přišel s poměrně velkým množstvím zavazadel... Náklady (nákladný model založený na předplatném), dostupnost (zmenšování uživatelské základny a komunity) a obecný zmatek ohledně budoucnosti...
Začal jsem hledat alternativy, přehodnocovat Gentoo, Debian a SuSE. Nemohl jsem získat správnou podporu pro všechny součásti našeho technologického zásobníku. Byl jsem nucen držet se ekosystému Red Hat... Kvůli divokému posunu nákladů souvisejícímu s Red Hat Enterprise Linux jsem nakonec roky provozoval vysoce upravený Red Hat 8.0 po skončení své životnosti. Až když klony RHEL dozrály (Whitebox Linux a později CentOS), připravil jsem skutečný odklon od mého standardu.
Hlavní výhodou derivátů Red Hat byla a je binární kompatibilita s placenými verzemi RHEL. Je dokonce možné provádět na místě konverze mezi RHEL a CentOS a naopak. Pokračoval jsem v práci se systémy podobnými RHEL, dokud jsem neudělal další kariérní krok...
Později jsem se ocitl v odvětví vysokofrekvenčního finančního obchodování, kde jsem byl zodpovědný za výzkum a vývoj a inženýrství Linuxu pro kritické automatizované obchodní systémy. Důraz v tomto světě byl rychlost , pomocí pečlivého testování a ladění. Klíčová byla opět hardwarová podpora. Měl bych specifické síťové karty, specializovaný hardware, serverový hardware nebo knihovny aplikací, které byly certifikovány pouze pro RHEL nebo systémy podobné RHEL. Dokonce i v případech, kdy bylo možné věci zkompilovat pro jiné varianty Linuxu, vyvstal faktor komunity. Když jsem byl v bodě, kdy jsem potřeboval prozkoumat problém, často to byl problém, který bylo možné vysledovat do poznámek nebo komentářů ve zprávách Red Hat Bugzilla, nebo jsem někdy jednoduše poslal opravu nebo požadavek na další vydání. .
Když jsem se začal ponořit do nízkolatenčních sítí a ladění jádra, začal jsem rozebírat základní jádra RHEL a jádra RHEL MRG Realtime. Všiml jsem si, kolik práce při vydání... 200+ patchů pro jádro vanilla kernel.org. Přečtěte si komentáře a poznámky. Můžete mít malé věci jako sysctl parametry vystaveny nebo byly použity rozumnější výchozí hodnoty. Red Hat platí lidem za opravy, testování a opravy těchto problémů. Neviděl jsem stejný závazek u jiných distribucí Linuxu... Přidejte skutečnost, že podniková platforma má zaručeno skutečné zabezpečení, opravy chyb a podporu backportu po let .
Tak jsem se nakonec přestěhoval do jiné finanční firmy, která byla na serveru téměř celá Gentoo a desktop... Byla to pro mě katastrofa. Pocházím ze světa Red Hat a CentOS, setkal jsem se s četnými problémy se stabilitou a správou nastavení Gentoo. Největším problémem byla kontrola verzí, ale obavy byly také ztenčující se podpora komunity a nedostatek skutečného testování. Začal jsem zavádět RHEL do prostředí, protože to vyžadoval některý náš software třetích stran...
Ale vyskytl se problém... Moji vývojáři byli zvyklí na Gentoo a měli relativně snadné cesty pro upgrade základních knihoven a verzí aplikací. Nemohli se přizpůsobit, aby měli pevné hlavní verze, na kterých se Red Hat Enterprise Linux standardizuje. Proces vývoje a vydání byl sužován otázkami, proč GLIBC 2.7 nemohl být naroubován na RHEL 5.x nebo proč určitá verze kompilátoru nebo knihovny nebyla dostupná. Když jim bylo řečeno, že upgrady mezi hlavními verzemi RHEL/CentOS v podstatě vyžadují úplné přestavby, ztratili v řešení velkou důvěru.
V tuto chvíli jsem si uvědomil, že Red Hat se pohybuje příliš pomalu pro vývojáře, kteří chtěli být na pokraji krvácení. RHEL 6.x byl velmi potřebný a vítaný upgrade, ale toto téma se stalo jasnějším, když jsem začal dělat rozhovory se startupy a firmami, které se přihlásily k principům DevOps.
Dnes...
Rostoucí počet vývojářů a uživatelů Linuxu přichází z prostředí jiného než Red Hat, SuSE a podnikového Linuxu.
- Používají Ubuntu nebo Debian...
- Nemuseli řešit starý hardware ani podporu velkých dodavatelů.
- Píšou své vlastní aplikace od základů (samopodporují).
- Virtualizace a cloud computing abstrahují hardwarovou vrstvu, takže starosti s funky ovladači řadičů RAID, periferiemi PCI-X nebo binárně distribuovanými agenty správy nejsou ani na radaru.
- Tito uživatelé chtějí nástroje a uživatelské prostředí, na které jsou zvyklí.
Došlo tedy ke konfliktu... Tito uživatelé nechápou, proč by měli být omezeni na verze aplikací nebo knihoven. Administrátoři ze staré školy se stále přizpůsobují novému paradigmatu. Argumenty, které vypadají zakořenění v náboženství jsou ve skutečnosti jen funkce toho, jak lidé rozvíjeli své příslušné dovednosti.
Dnes jsem viděl pracovní inzerát na pozici velmi zkušeného inženýra DevOps Linux, který zněl:
Musíte být zběhlí v linuxových distribucích založených na Debianu (Ubuntu a varianty jsou v pořádku. Red Hat vhodné , ale ne preferováno)
Takže myslím, že to funguje oběma způsoby... Odešel jsem z pracovních příležitostí, protože 800 serverů CentOS, které bych spravoval, bylo navrženo na převedení na Ubuntu. Jasně, Linux je Linux... ale necítil jsem, že bych byl tak efektivní, jak bych mohl být... Pohrával jsem si s instalacemi Debianu a přál jsem si, aby se používalo distro založené na RPM. Měl jsem vášnivé spory o přednostech různých platforem (obvykle umisťuji Gentoo na konec seznamu).
Co je tedy správné pro VAŠE prostředí? Záleží. Byl jsem ve firmách, kde rozhodují systémoví inženýři, stejně jako v organizacích, kde jsou vývojáři králem. Myslím, že nejlepší uspořádání je, když se vývojáři a lidé podporující systémy dohodnou na platformě. Ale kromě toho přemýšlejte o dlouhodobé podpoře, použitelnosti, komunitě a o tom, co nejlépe vyhovuje vašemu zásobníku aplikací.
Talentovaný vývojář by měl být schopen pracovat v prostředí podobném RHEL nebo Debianu. A dobře, vývojové platformy by měly odrážet produkční prostředí. Jdete odtud...
Řešení 2:
V současné době pracuji v prostředí, které používá Linux již více než deset let. Každý v kanceláři používá různé distribuce na svých počítačích i na serverech. Volby distribuce jako takové mají tendenci se točit kolem řady věcí v žádném konkrétním pořadí:
- Historie - Je zřejmé, že systémy jako RedHat a Debian existují již dlouhou dobu. Jako takové pro ně lze použít pořekadlo „pokud to není rozbité, neopravujte to“. Upgrade je snazší, pokud je software v distribuci dobře podporován.
- Známost - Podobně jako v historii, ale všichni máme své oblíbené. Uřízl jsem si zuby na Debianu a přešel na Ubuntu (tehdy těžké rozhodnutí, protože mám tendenci se zavázat ke komunitě). A naopak je bolestné pamatovat si, jak se věci dělají na tuctu různých distribucí (nemluvě o těch odřených).
- Podpora - Přešel jsem na Ubuntu hlavně proto, že jsem ocenil, co dělají, pokud jde o nabídku placené podpory. To byl prodejní argument, pokud měl klient někdy obavy z dlouhodobého provozu systému. Podobný přístupu RedHatu (ale v té době probíhalo peklo RPM). I z tohoto důvodu máme řadu serverů RedHat.
- Závislosti - Některé programy se v některých distribucích používají snadněji, protože závislé balíčky lze snadněji získat nebo sestavit. Příkladem může být oVirt na RedHat. V některých distribucích nejsou žádné balíčky pro některé programy. A mohli byste to zkompilovat, ale proč byste to dělali, kdyby byl balíček přímo tam v jiném distribuci?
- Granularita - Distribuce jako Gentoo nabízejí jemnější kontrolu nad verzováním a granularitu softwarových přepínačů. Jiná distribuce mají „pinning“ v různých podobách, ale stále to není tak ovladatelné nebo spolehlivé.
- Vazba - I když je u většiny distribucí možné kompilovat ze zdroje, některá distribuce jsou na tom lépe než jiná. To může mít vliv, řekněme, pokud váš projekt opraví stávající knihovny pro rozšířenou funkčnost.
- Krásnost - Některé distribuce prostě vypadají lépe. Každý geek ví, že je to jen chmýří (a dnes by vám to pravděpodobně prošlo jako webová aplikace), ale někteří klienti jsou těmito věcmi ohromeni a všichni to víme.
- Stabilita - Některé distribuce streamují „stabilní“ verze softwaru na rozdíl od „testovacích“, „experimentálních“ atd. To může znamenat hodně, pokud víte, že verze, na které stavíte, nakonec dosáhne konsensu ohledně stability. Můžete se vyvíjet na "experimentální" úrovni s vědomím, že v době, kdy bude váš projekt dokončen, bude "stabilní" a je dobré se na něj spolehnout.
- Správa balíčků – Pokud něco vyvíjíte na denní bázi a bude to fungovat na 1000 počítačích najednou, pak pravděpodobně budete chtít něco, co usnadní vytváření, údržbu a sledování balíčků v těchto systémech.
- Konzistence - Toto je spíše argument pro totéž distro. Méně chyb se udělá (a méně chyb v zabezpečení), když se lidé mohou soustředit na jednu distribuci namísto několika.
- Předvídatelný plán vydání - Pokud si chcete být jisti, že váš software zůstane podporován, plánované upgrady nabízejí určitý typ stability.
- Zabezpečení - Některé distribuce mají aktivní bezpečnostní týmy, jejichž úkolem je okamžitě reagovat na skutečná bezpečnostní rizika v jakémkoli schváleném balíčku.
To je jen pár věcí, které se mi vynořují z hlavy ohledně důvodů, proč byl zvolen každý systém. Nevidím nikoho, kdo by v tomto rozhodnutí řídil světlo nebo preferenci jednoho distra před druhým. Rozmanitost a výběr mohou být skvělé a nabídnout vám opravdu dobré možnosti, jak rychle začít s projektem, ale je to také smyčka, která vás může pověsit. Ujistěte se, že si předem rozmyslíte, co budete potřebovat. Naplánujte si, jaké jsou potřeby systému a kdy bude systém upgradován nebo vyřazen. Nepředpokládejte, že to budete vždy udržovat.