Jak dział IT powinien wybrać standardową dystrybucję Linuksa?

Istnieje wiele odczuć społeczności na temat tego, które dystrybucje Linuksa są odpowiednie dla środowisk serwerów produkcyjnych, a które nie są jednak zbyt duże, wydaje się, że są oparte na religii i rzadko przedstawiane są dowody potwierdzające.

Zakładając, że próbowaliśmy wybrać dystrybucję Linuksa do standaryzacji (ponieważ zależy nam na tym, aby nasze środowiska były jak najbardziej jednorodne), jakie kryteria są ważne i jak podejmujesz ustalenia, w jakim stopniu różne dystrybucje spełniają te kryteria?

Obecnie pracuję w środowisku, które używa Linuksa od ponad dekady. Wszyscy w biurze używają różnych dystrybucji na swoich komputerach stacjonarnych i serwerach. W związku z tym wybory dotyczące dystrybucji mają tendencję do obracania się wokół szeregu rzeczy w określonej kolejności:

1. Historia - Oczywiście systemy takie jak RedHat i Debian istnieją już od dawna. W związku z tym można użyć do tego powiedzenia „jeśli się nie zepsuło, nie naprawiaj”. Aktualizacja staje się łatwiejsza, jeśli oprogramowanie jest dobrze obsługiwane w dystrybucji.
2. Znajomość - podobna do historii, jednak wszyscy mamy swoich ulubionych. Obciąłem zęby na Debianie i przeprowadziłem migrację do Ubuntu (trudna decyzja w tym czasie, ponieważ mam skłonność do angażowania się w społeczność). I odwrotnie, trudno jest pamiętać, jak robić rzeczy na kilkunastu różnych dystrybucjach (nie wspominając o tych zbudowanych na zera).
3. Wsparcie - migrowałem do Ubuntu głównie dlatego, że doceniam to, co robili, oferując płatne wsparcie. To był punkt sprzedaży, jeśli kiedykolwiek klient miał obawy dotyczące długoterminowego działania systemu. Podobne do podejścia RedHata (ale wtedy działo się piekło RPM). Z tego powodu mamy również wiele serwerów RedHat.
4. Zależności - Niektóre programy są łatwiejsze w użyciu na niektórych dystrybucjach po prostu dlatego, że zależne pakiety można łatwiej uzyskać lub zbudować. Przykładem może być oVirt na RedHat. W niektórych dystrybucjach nie ma pakietów dla niektórych programów. Mógłbyś go skompilować, ale dlaczego miałbyś, gdyby paczka znajdowała się na innej dystrybucji?
5. Ziarnistość - dystrybucje jak Gentoo oferują lepszą kontrolę nad wersjami oprogramowania przełącznika i ziarnistości. Inne dystrybucje mają „przypinanie” w różnych formach, ale nadal nie jest to tak kontrolowane ani niezawodne.
6. Wiązanie - Chociaż w większości dystrybucji można skompilować ze źródła, niektóre dystrybucje są w tym lepsze niż inne. Może to mieć efekt, powiedzmy, jeśli twój projekt załatuje istniejące biblioteki dla rozszerzonej funkcjonalności.
7. Piękność - niektóre dystrybucje wyglądają po prostu lepiej. Każdy maniak wie, że to tylko puch (i prawdopodobnie mógłbyś teraz zrobić to jako aplikacja internetowa), ale niektórzy klienci są zachwyceni tymi rzeczami i wszyscy o tym wiemy.
8. Stabilność - niektóre dystrybucje przesyłają strumieniowo „stabilne” wersje oprogramowania w przeciwieństwie do „testowania”, „eksperymentalnego” itp. Może to oznaczać wiele, jeśli wiesz, że wersja, na której budujesz, ostatecznie osiągnie konsensus w sprawie stabilności. Możesz rozwijać się na zasadzie „eksperymentalnej”, wiedząc, że do czasu ukończenia projektu osiągnie on „stabilność” i będzie można na nim polegać.
9. Zarządzanie pakietami - jeśli projektujesz coś na co dzień, a za jednym razem trafi on do tysiąca maszyn, prawdopodobnie potrzebujesz czegoś, co ułatwi budowanie, utrzymywanie i śledzenie pakietów w tych systemach.
10. Spójność - jest to raczej argument za tym samym dystrybucją. Mniej błędów jest popełnianych (i mniej błędów w zabezpieczeniach), gdy ludzie mogą skupić się na jednej dystrybucji, a nie na kilku.
11. Przewidywalny harmonogram wydań - jeśli chcesz mieć pewność, że Twoje oprogramowanie będzie nadal obsługiwane, planowane aktualizacje oferują pewien rodzaj stabilności.
12. Bezpieczeństwo - niektóre dystrybucje mają aktywne zespoły bezpieczeństwa, których zadaniem jest natychmiastowe reagowanie na prawdziwe zagrożenia bezpieczeństwa w każdym zatwierdzonym pakiecie.

To tylko kilka rzeczy, które wychodzą mi z głowy, jeśli chodzi o powody, dla których każdy system został wybrany. W tej decyzji nie widzę nikogo, kto kierowałby się światłem lub preferencją jednej dystrybucji względem drugiej. Różnorodność i wybór mogą być świetne i oferują naprawdę dobre opcje szybkiego rozpoczęcia projektu, ale także pętla, która może Cię zawiesić. Upewnij się, że myślisz przed tym, czego będziesz potrzebować. Zaplanuj, jakie są potrzeby systemu, a także kiedy system będzie aktualizowany lub wycofywany. Nie zakładaj, że zawsze będziesz tym, który go utrzymuje.

Podzielę się swoimi doświadczeniami pracując jako technolog w kilku różnych dziedzinach ...

(Uwaga: to historia o Red Hacie i tym, jak dorastałam z nim zawodowo)

Pracę z Linuksem zacząłem profesjonalnie w latach 2000-2002. Było to podczas szerokiej adopcji Red Hat i Red Hat Professional Editions (6.x, 7.x, 8.0) . Były one dostępne do pobrania za darmo, a także w zestawach w pudełkach. Można je łatwo znaleźć w komputerowych sklepach detalicznych.

Dla mnie miało to zaletę polegającą na zaangażowaniu hobbystów i użytkowników domowych w ten sam produkt, który zaczął pojawiać się w przedsiębiorstwie. Moja praca w tym czasie polegała na przeniesieniu systemów serwerów klienta z komercyjnych Unices (HP-UX, AIX i SCO) na platformę Red Hat.

Oszczędności były znaczne! Zastąpienie serwerów PA-RISC o wartości 100 000 USD + HP9000 serwerami Compaq ProLiant Intel o wartości 40 000 USD było absolutną wygraną pod względem kosztów i wydajności.

Dlaczego więc Red Hat?

Red Hat był pierwszym na tym rynku, zyskując krytyczne wsparcie biznesowe, dostawców i sprzętu. Dostawcy dużych aplikacji używają Red Hata jako platformy docelowej, która zawarła umowę. Użytkownicy hobbystów tacy jak ja byli w stanie z łatwością przenieść umiejętności wyuczone w domu do naszego środowiska pracy. Społeczność rosła. Rządy stosów Slashdot , Freshmeat i LAMP ! To był dobry czas na Linuksa.

W tym momencie byłem odpowiedzialny za rozwój i ocenę dystrybucji Linuksa jako platformy zastrzeżonego oprogramowania ERP. Utknąłem z Red Hat. Co jakiś czas próbowałem innej dystrybucji ( Mandrake , SuSE , Debian , Gentoo ), ale znajdowałem problemy z pakowaniem, wsparciem sprzętowym (serwery lub urządzenia peryferyjne), społecznością (rozmiarem) lub innym przełomem.

Przykład: korzystałem ze sprzętu Compaq / HP ProLiant wyposażonego w karty rozszerzeń Digi Serial PCI-X i produkcyjnego oprogramowania faksu Esker VSIfax . Dwa ostatnie miały tylko obsługę sterowników dla systemów operacyjnych Red Hat. W niektórych przypadkach oprogramowanie było dostarczane tylko w formie binarnej lub RPM, co wyklucza łatwą obsługę w innych wariantach systemu Linux.

Momentum ma znaczenie w świecie technologii informatycznych
Nikt nie chce być tym, który poleca przegrane rozwiązanie lub projekt, który ostatecznie zostaje osierocony, więc trzymaj się bezpiecznych wyborów. Zarządzałem stosem technologii, który musiał działać niezawodnie i mieć kilka warstw wsparcia. Wybór innej dystrybucji w tym momencie miałby właśnie. być. nieodpowiedzialny.

Miesiąc miodowy Red Hat zakończył się dla mnie w 2003 r. Wraz z wycofaniem profesjonalnych edycji oprogramowania. Red Hat Enterprise Linux był zamiennikiem i przyniósł sporo bagażu ... Koszt (drogi model oparty na subskrypcji), dostępność (zmniejszenie bazy użytkowników i społeczności) i ogólne zamieszanie związane z przyszłością ...

Zacząłem szukać alternatyw, ponownie oceniając Gentoo, Debian i SuSE. Nie udało mi się uzyskać odpowiedniego wsparcia dla wszystkich składników naszego stosu technologii. Byłem zmuszony trzymać się ekosystemu Red Hat ... Z powodu gwałtownej zmiany kosztów związanej z Red Hat Enterprise Linux, skończyłem z wysoce zmodyfikowanym Red Hat 8.0 przez wiele lat po jego zakończeniu. Dopiero dojrzewanie klonów RHEL ( Whitebox Linux , a później CentOS ) przygotowałem prawdziwy odejście od mojego standardu.

Główną zaletą instrumentów pochodnych Red Hat była i jest zgodność binarna z płatnymi wersjami RHEL. Możliwe jest nawet przeprowadzanie konwersji w miejscu między RHEL i CentOS i odwrotnie. Kontynuowałem pracę z systemami podobnymi do RHEL, dopóki nie wykonałem kolejnego kroku kariery ...

Później znalazłem się w branży handlu finansowego o wysokiej częstotliwości , gdzie byłem odpowiedzialny za badania i rozwój oraz inżynierię Linux dla krytycznych automatycznych systemów transakcyjnych. W tym świecie nacisk położono na szybkość , poprzez staranne testowanie i dostrajanie. Ponownie kluczowa była obsługa sprzętu. Miałem określone karty sieciowe , specjalistyczny sprzęt, sprzętowe lub bibliotek aplikacji serwera, które zostały certyfikowane tylko dla systemów RHEL lub RHEL. Nawet w przypadkach, w których można skompilować rzeczy dla innych wariantów Linuksa, pojawił się czynnik społeczności. Kiedy znajdowałem się w punkcie, w którym musiałem zbadać problem, często zdarzało się, że problem można przypisać notatkom lub komentarzom w raportach Bugzilli Red Hat, lub czasami po prostu przesłałem łatkę lub prośbę o następne wydanie .

Kiedy zacząłem zagłębiać się w sieci o niskim opóźnieniu i dostrajanie jądra, zacząłem analizować podstawowe jądra RHEL i jądra RHEL MRG Realtime . Zauważyłem, ile pracy zajmuje wydanie ... ponad 200 łatek do waniliowego jądra kernel.org. Przeczytaj komentarze i zatwierdź notatki. Możesz mieć małe rzeczy, takie jak sysctlparametry odsłonięte lub zastosować bardziej rozsądne wartości domyślne. Red Hat płaci ludziom za łatanie, testowanie i naprawianie tych problemów. Nie widziałem takiego samego zaangażowania w innych dystrybucjach Linuksa ... Dodaj fakt, że platforma korporacyjna ma zagwarantowane przez lata prawdziwe bezpieczeństwo, poprawki błędów i wsparcie dla backportu .

W końcu przeniosłem się do innej firmy finansowej, która była prawie w całości Gentoo na serwerze i komputerze ... To była dla mnie katastrofa. Pochodząc ze świata Red Hat i CentOS, napotkałem wiele problemów ze stabilnością i zarządzaniem w konfiguracji Gentoo. Kontrola wersji była największym problemem, ale niepokojące było także wsparcie społeczności i brak prawdziwych testów. Zacząłem wprowadzać RHEL do środowiska, ponieważ wymagało tego niektóre nasze oprogramowanie innych firm ...

Ale pojawił się problem ... Moi programiści byli przyzwyczajeni do Gentoo i mieli stosunkowo łatwe ścieżki aktualizacji dla bibliotek podstawowych i wersji aplikacji. Nie mogli się dostosować do ustalonych głównych wersji, w których Red Hat Enterprise Linux standaryzuje. Proces rozwoju i wydania był nękany pytaniami o to, dlaczego GLIBC 2.7 nie może zostać zaszczepiony na RHEL 5.x lub dlaczego pewien kompilator lub wersja biblioteki nie była dostępna. Kiedy powiedziano, że aktualizacje między głównymi wersjami RHEL / CentOS zasadniczo wymagały pełnych przebudów , straciły duże zaufanie do rozwiązania.

W tym momencie zdałem sobie sprawę, że Red Hat porusza się zbyt wolno dla deweloperów, którzy chcą być na czele. RHEL 6.x był bardzo potrzebną i mile widzianą aktualizacją, ale ten temat stał się bardziej widoczny, kiedy zacząłem rozmawiać ze startupami i firmami, które podpisały się pod zasadami DevOps .

Dzisiaj ...
Coraz więcej programistów i użytkowników Linuksa pochodzi ze środowisk Linuksa innych niż Red Hat, nie-SuSE i innych niż korporacyjne.

• Używają Ubuntu lub Debiana ...
• Nie musieli zajmować się sprzętem oldschoolowym ani wsparciem dużych dostawców.
• Piszą własne aplikacje od podstaw (samowystarczalne).
• Wirtualizacja i przetwarzanie w chmurze wyodrębniają warstwę sprzętową, więc obawy o funkcjonalne sterowniki kontrolerów RAID, urządzenia peryferyjne PCI-X lub agentów zarządzania rozproszonych binarnie nie są nawet na radarze.
• Ci użytkownicy chcą narzędzi i przestrzeni użytkownika, do których są przyzwyczajeni.

Występuje więc konflikt ... Ci użytkownicy nie rozumieją, dlaczego byliby ograniczeni do wersji aplikacji lub biblioteki. Administratorzy starej szkoły wciąż dostosowują się do nowego paradygmatu . Argumenty, które wydają się być zakorzenione w religii, są tak naprawdę tylko funkcjami tego, jak ludzie rozwijali swoje umiejętności.

Zobaczyłem dzisiaj ogłoszenie o pracę dla bardzo wysokiego stanowiska inżyniera DevOps Linux, które brzmiało:

Musi być biegłym ekspertem w dystrybucjach Linuksa opartych na Debianie (Ubuntu i warianty w porządku. Red Hat przejezdny , ale nie preferowany)

Sądzę więc, że działa to w obie strony ... Odszedłem od możliwości pracy, ponieważ 800 serwerów, którymi zarządzałem, miało zostać przekonwertowanych na Ubuntu. Jasne, Linux to Linux ... ale nie czułem, że będę tak skuteczny, jak mógłbym być ... Pogrzebałem przy instalacjach Debiana i żałowałem, że nie korzystam z dystrybucji opartej na RPM. Miałem gorącą dyskusję na temat zalet różnych platform (zazwyczaj umieszczając Gentoo na dole listy).

Co jest odpowiednie dla twojego środowiska? To zależy. Byłem w firmach, w których inżynierowie systemów podejmują decyzje, a także w organizacjach, w których programiści są królem. Myślę, że najlepszym rozwiązaniem jest, gdy programiści i osoby obsługujące systemy uzgodnią platformę. Ale poza tym pomyśl o długoterminowym wsparciu, użyteczności, społeczności i o tym, co dostosowuje stos aplikacji w najbardziej odpowiedni sposób.

Utalentowany programista powinien być w stanie pracować w środowisku RHEL lub Debian. Platformy programistyczne powinny odzwierciedlać środowisko produkcyjne. Idziesz stamtąd ...