Dlaczego gentoo to nie jest dobry pomysł na serwer ?

Zanim rozpocząłem pracę w banku, przez kilka lat moją ulubioną i podstawową dystrybucją było gentoo. Przesiadłem się na nią z mojego pierwszego Linuksa z jakim miałem kontakt - Slackware. Z racji, że drugim uniksowym systemem z którym miałem kilkuletni romans było freebsd, czułem się z tą dystrybucją bardzo dobrze.


Na tamte czasy, bardzo podobał mi się system portów - bardzo przemyślane flagi USE, system który pakiet po pakiecie budował się tak jak chciałem, zawsze w najnowszych wersjach i bez niepotrzepanych dodatków.

Imponująca jest też społeczność zgromadzona wokół tej dystrybucji, strony związane z gentoo zawierają na prawdę dużą ilość solucji i rozwiązań zebranych przez lata przez użytkowników. Są tam nie tylko solucje dotyczące konfiguracji systemu, ale też szczegółowe rozwiązania dotyczące usług - których wartość edukacyjna jest na prawdę spora.

Wszystko było dobrze, do momentu kiedy serwer był jeden, a drobne przerwy w działaniu usług nie stanowiły problemu. Niestety, gdy zmieniła się skala - moje ulubione gentoo, przestało spełniać oczekiwania, a część jego zalet zmieniła się w wady, które w oczywisty sposób wykluczają użycie gentoo w dużych środowiskach serwerowych.

Rzeczy, które z czasem zaczęły być przeszkodą:

1. Czas instalacji systemu - od momentu powstania gentoo komputery wielokrotnie zwiekszały swoją moc obliczeniową - dalej jednak czas budowy systemu wraz z usługami jest nieproporcjonalnie wyższy, w stosunku do budowy systemu z pakietów - różnica w wydajności zaś, jest zupełnie pomijalna. Wiem, ze w czasach wirtualizacji, możemy sobie przygotować gotowy image systemu, który rozklonowujemy w zależności od zapotrzebowania - czy jednak taki klon nie bedzie mimo wszystko wymagał przebudowania? Praktyka uczy, że jednak często trzeba go modyfikować, lub pogodzić się z dość dużym systemem - który nie zawsze jest wskazany.

2. Czas potrzebny na aktualizacje - i moc obliczeniowa z nią związana. Wszystko jest dobrze do momentu, kiedy pracujace usługi nie zajmują praktycznie całej mocy obliczeniowej - gdy jednak tak sie dzieje, chodzące w tle GCC potrafi zabrać sporą część zasobów - gdy dodatkowo przemnożymy to przez ilość nodów na hoscie - potrafimy stanąć w obliczu realnego problemu aktualizacji systemu

3. Taktyka aktualizacji - tu również robi się nieciekawie. Z jednej strony zyskujemy zawsze świeże wersje naszego środowiska, z drugiej strony niejednokrotnie po kompilacji okazywało się, że plik konfiguracyjny usługi wymaga sporego przebudowania, bądz też czegoś brakuje. Oczywiscie można dopieszczać wszystko do skutku - tu jednak po raz kolejny tracimy cenny czas. Zamykanie systemu w profilu, również nie zawsze dawalo oczekiwany rezultat i niejednokrotnie zmuszani byliśmy do jego zmiany.

Byłem zatwardziałym zwolennikiem trzymania systemu w wersji current - przestałem być gdy odkryłem jak wiele problemów w świecie linuksowym to za sobą niesie. Teraz zdecydowanie wolę zostawać w obrębie raz postawionej wersji środowiska, a ingerencje w ten system ograniczać do patchowania - pozostając jak najdłużej w jednej wersji i mieć pewność, że system po aktualizacji zadziała dokładnie tak samo jak przed nią. To zdecydowanie pozwala zaoszczedzić czas, nawet jeśli dana wersja OS bedzie wymagała za jakiś czas migracji, to i tak jest szybsza metoda.. Wartym uwagi jest fakt, że obecnie serwerowe dystrybucje linuksa, są już obięte długoterminowym wsparciem i zwykle szybciej system wypada z produkcji niż musi zostać zmigrowany.

Podsumowując, gentoo okazało się dla mnie zbyt czasochłonne i zbyt ryzykowne jako system serwerowy. Dalej używam go w domu, na jednej z maszyn nie mających komercyjnego zastosowania, jednakże komercyjnie preferuję systemy na bazie RHEL. Szybkość pracy z RedHatem, jest nieporównywalnie wieksza, a sam system wyposażony jest w kilka fajnych i unikalnych rozwiązań, zarówno w samym systemie, jak i do zarządzania i kontroli wersji w systemach, gdzie maszyn nie jest już kilkanaście, a kilkaset, ale to już temat na zupełnie inny wpis. Nie twiedzę, że gentoo to zły system - na pewno niesie za sobą spore wartości edukacyjne i może być rajem dla developera, czy też świetnym poligonem testowym, jednak tam gdzie chcemy mieć duże stabline środowisko - moim zdaniem po prostu się nie sprawdza.