Alpine Linux – dlaczego należy dobrze przemyśleć korzystanie z niego? Artykuł o tym narzędziu był opublikowany na blogu już 3 lata temu. Jednak temat nadal jest aktualny, dlatego postanowiliśmy go odświeżyć.
Na początku, gdy zaczęto używać kontenerów, większość z nas traktowała je jako bardziej wydajne VM-ki. Jeżeli spojrzymy na obrazy na Docker Hubie, publikowane przez dostawców systemów operacyjnych, możemy dostrzec, że w większości przypadków kopiują oni do obrazów to, co do tej pory dostarczali jako cały system operacyjny. Zwykle, obrazy są okrajane tylko o niektóre, niepotrzebne ich zdaniem paczki / binarki.
Pomimo tego, obrazy nadal są za ciężkie, zajmując na dysku setki megabajtów. To spowodowało wzrost popularności dystrybucji takich jak Alpine. Czy kiedykolwiek wcześniej wykorzystywałeś Alpine, zanim zaczęto go używać w obrazach dockerowych? Ja nie.
Dlaczego zaczęto stosować Alpine Linux do obrazów bazowych?
Głównym powodem, dla którego zaczęto na potęgę wykorzystywać Alpine, jest oczywiście jego rozmiar. 5 MB — tyle waży obraz Alpine. W porównaniu do np. Debiana (125 MB) lub Ubuntu (188MB) jest to spora różnica. W pewnym momencie, z uwagi na rozmiar obrazów, Docker Hub zaczął mieć problemy wydajnościowe. Te problemy z czasem zostały zażegnane, lecz popularność Alpine nadal rosła.
Pojawia się zatem pytanie. Co jest złego w stosowaniu Alpine Linux?
Wady Alpine Linux
Pomimo że Alpine Linux jest ultralekki, nadal jego zachowanie może być porównane do wirtualnej maszyny. Dlaczego?
Stosując obraz Alpine, nadal możemy korzystać z shell’a a nawet z managera pakietów. No właśnie, manager pakietów…
1. Brakujące pakiety
Zdarzały się przypadki, w których brakowało podstawowych pakietów. Coś, co innych dystrybucjach takich jak Debian mamy pewne. Przykład – brakująca paczka MySQL.
2. Różnice w repozytoriach dla różnych wersji Alpine
Każda wersja Alpine Linux posiada własny manager pakietów i niestety nie przechowuje archiwalnych wersji. Przykładowo w wersji Alpine 3.5, dostępna paczka Node.js może być w wersji 2.0, w Alpine 3.4 będzie już w wersji 1.9. Chcąc używać Node.js w wersji 1.9, musimy opierać się o starszą wersje Alpine.
3. Brak glibc
Jeśli cokolwiek w życiu kompilowałeś (np. na studiach) to zakładam, że w 90% przypadków korzystałeś z glibc. Alpine zastąpił glibc własnym stworem o nazwie musl. Osobiście, natknąłem się na ten problem w momencie, w którym aplikacja webowa uruchomiona w kontenerze na bazie Debiana działała poprawnie, a wewnątrz kontenera na bazie Alpine, już nie
Jeżeli chcesz by Twoja aplikacja działała poprawnie, musisz skompilować ją w środowisku wykorzystującym musl.
4. Stabilność
Obecnie obraz dockerowy Alpine Linux jest rozwijany jako projekt open-source.
Poszperałem nieco tu i ówdzie i co znalazłem?
Okazuje się, że aktywnie rozwija go zaledwie kilka osób. A do zatwierdzenia zmiany w repozytorium wystarczą dwie (!), powtarzam, dwie osoby (na dzień pisania tego artykułu). Przykład pull requesta — TUTAJ
Czy w swoich obrazach, chcesz bazować na czymś, czego jakość sprawdza dwie osoby?
Zauważyłem też, że repozytorium z powyższego linka, w którym widnieją osoby rozwijające, zostało przeniesione do https://github.com/alpinelinux/docker-alpine, gdzie kontrybutorem jest tylko jedna osoba. Na Docker Hubie widnieje już adres nowego repozytorium Githuba. Dlaczego?
5. Wydajność
Szukając informacji o wydajności Alpine, natrafiłem na post na Reddicie, w którym mowa o aplikacji Node.js. Jeden z użytkowników twierdzi, że jego aplikacja działała 15% wolniej używając Alpine jako obraz bazowy w porównaniu do Debiana.
Inny przykład to aplikacja w Pythonie. Bardzo ciekawy artykuł opisujący wady Alpine Linux w porównaniu do Ubuntu.
6. Bezpieczeństwo
Nie wiele narzędzi do skanowania obrazów “radzi” sobie z obrazami bazującymi na Alpine. Jeżeli skanowałeś obrazy narzędziami takimi jak Anchore czy Clair, które nie wykryły żadnych podatności – polecałbym porównać wyniki skanowania z wynikami uzyskanymi narzędziem trivy.
Przykładowe problemy, na jakie możesz się natknąć korzystając z Alpine Linux
Problemów z Alpine jest wiele, jak zauważa autor tego artykułu.
Problemy z DNS
Wiele problemów z Alpine Linux wynika z tego jak musl obsługuje DNS, a właściwie to nie obsługuje DNS-over-TCP. Jest dobrze, póki pojedynczy pakiet UDP (512 bajtów) jest wystarczający do rozwiązywania nazw hostów. Jednak jeśli to się zmieni, aplikacja wcześniej działająca dobrze, zaczyna wyrzucać “Unknown Host”. Często też zdarza się to losowo.
Używając Alpine, piszesz się na inżynierię chaosu dla klastra
Jeśli uruchomisz wiele mikroserwisów/aplikacji opartych o Alpine, a one wszystkie nagle przestaną działać i jedyną możliwością w tym przypadku jest przejście na inną dystrybucję Linuksa, wymaga to przebudowy wszystkich aplikacji i ponownego ich rozmieszczenia. Nie trzeba dodawać, jak długi i żmudny jest to proces.
Brak informacji o możliwych problemach
Problem z DNS nie ujawnia się w kontenerze Docker. Jeśli przetestujesz go lokalnie i wszystko będzie działać dobrze, może się okazać, że o nienaprawialnym problemie dowiesz się dopiero po wdrożeniu aplikacji do klastra. Trochę późno.
Problemy z językami opartymi na bibliotekach C
Każdy język programowania lub jego biblioteka, które opierają się na standardowej bibliotece C, są dotknięte przez wszelkie różnice między musl a glibc. Często wymagać to będzie skompilowania ich samemu, co jest dość czasochłonne. A nawet jeśli zrobisz to poprawnie, i tak możesz natknąć się na problemy z Alpine.
Co więc wybrać?
Chociaż Alpine może być świetnym bazowy systemem operacyjnym dla obrazów kontenerów, wiele osób straciło do niego zaufanie przez opisane wyżej problemy. Wybierając Alpine należy być świadomym możliwych trudności. Apline ma kilka wartych uwagi zamienników, takich jak Wolfi czy UBI (Universal Base Image). Dlatego nie wybieraj tylko po rozmiarze. Zapoznaj się z wadami i zaletami każdego z rozwiązań i wtedy wybierz najlepsze narzędzie dla siebie.
