Linux Alpine - czy ktoś korzysta?

W tym poście - https://4programmers.net/Forum/1646642 @Adam Boduch się wygadał, że część 4P stoi na linuksie Alpine. Szczerze mówiąc, trochę się zdziwiłem, bo zawsze żyłem w przekonaniu, że to dystrybucja, która jest przeznaczona/nadaje się najlepiej do małych urządzeń o ograniczonych zasobach, a nie do stawiania całkiem niemałych portali z dość dużą bazą danych i konkretną ilością użytkowników.

Żeby była jasność - w żaden sposób nie podważam decyzji Adama, ani nie kwestionuję tego wyboru - na pewno wie, co robi. Ale po prostu mnie ta informacja bardzo zaciekawiła i zdziwiła. Stąd moje pytanie - czy ktoś z Was miał także styczność z tą dystrybucją na serwerach? Stawialiście na tym coś większego? Poszło to na produkcję? Ja zawsze starałem się działać na Debianie (a dawniej na Slackware... gimby nie pamiętajo). Ale może czas poznać coś nowego i zmienić swoje podejście.

Dodam tylko, że chodzi o kontener Dockera z PHP :) Postgres również na Alpine chodzi.

A żeby doprecyzować - ten Alpine jest hostem czy systemem, który jest wsadzony w kontener? I druga sprawa - ja jakim systemie stoi sam docker, też na Alpine?

Nie, na hoście ubuntu. Jeżeli chodzi o obrazy dockerowe, to dość powszechne jest stosowanie okrojonych dystrybucji, aby zmniejszyć rozmiar samego obrazu.

Przy okazji: ktoś wie jak na alpine zainstalować polskie locale? :P

obrazy dockerowe, to dość powszechne jest stosowanie okrojonych dystrybucji, aby zmniejszyć rozmiar samego obrazu

W takim razie poszerzam pytanie z pierwszego posta: czy jest sens/czy coś mogę zyskać, instalując Apline na systemie, w którym mam naprawdę dużo miejsca na dysku oraz RAMu. Czy to taki sport dla sportu, czy są jakieś realne korzyści z tego wynikające?

my na alpine jako docker container mamy kolo 10 roznych api tego samego projektu i wszystko hula, tak jak mowi @Adam Boduch alpine w podstawowej wersji ma chyba ~20mb jesli mnie pamiec nie myli a do tego ma wiekszosc pakietow np dostepnych pod ubuntu.

Akurat u nas nie wiem na czym stoi host na ktorym jest odpalany docker wiem ze cos kombinowali z core-os ale mial jakies problemy z procesorami amd i ostatecznie chyba zostalismy przy ubuntu

cerrato napisał(a):

obrazy dockerowe, to dość powszechne jest stosowanie okrojonych dystrybucji, aby zmniejszyć rozmiar samego obrazu

W takim razie poszerzam pytanie z pierwszego posta: czy jest sens/czy coś mogę zyskać, instalując Apline na systemie, w którym mam naprawdę dużo miejsca na dysku oraz RAMu. Czy to taki sport dla sportu, czy są jakieś realne korzyści z tego wynikające?

Każdy push do mastera czy też wdrożenie powoduje budowanie nowego obrazu Dockera, a następnie przesłanie tego obrazu do huba (https://hub.docker.com/u/4programmers). Następnie serwer produkcyjny musi pobrać ten obraz podczas wdrożenia. Im mniejszy obraz tym szybciej to wszystko trwa :)

@Adam Boduch OK, to ma sens. A co w wypadku, kiedy mamy wersję dość stabilną na produkcji i nie robimy częstych buildów. Czy w takiej sytuacji ten mikro-linux ma też zalety względem takiego np. Debiana?

@marcio: a co to za aplikację/usługę macie na tym postawione?

Im bardziej okrojony linuks to tym mniejszy wektor ataku. Alpine to już prawie standard w świecie kontenerów.

Coś dla fanów Alpine i jego bezpieczeństwa:

Nie specjalnie mi się podoba demonizowanie musl vs glibc. A to, że systemd go nie wspiera musl to wina systemd, które używa wewnętrznych rozszerzeń glibc. Były patche, które oferowały kompatybilność ze wszystkimi libc, które były kompatybilne z POSIX.

@hauleth: patche do czego?

systemd (stara wersja 225, ale było to możliwe, i sądzę, że dalej jest).

Co do samego MUSL, to on jest po prostu równie szybki, mniejszy i lepiej obsługuje część błędów. Dalej paru feature brakuje, ale GLibc też nie jest pod tym względem idealne.

cerrato napisał(a):

obrazy dockerowe, to dość powszechne jest stosowanie okrojonych dystrybucji, aby zmniejszyć rozmiar samego obrazu

W takim razie poszerzam pytanie z pierwszego posta: czy jest sens/czy coś mogę zyskać, instalując Apline na systemie, w którym mam naprawdę dużo miejsca na dysku oraz RAMu. Czy to taki sport dla sportu, czy są jakieś realne korzyści z tego wynikające?

Czy jak kupie sobie elektryczna superlekka hulajnoge to dojade do Wloch? Czy to ma sens?

Ja korzystam pośrednio, bo gitlab pages pozwala na zdeployowanie statycznej stronki na alpinie (możliwe, że na innych też, nie wczytywałem się w docsy, tylko użyłem domyślnego obrazu). Ma to sens, skoro to ultralekka dystrybucja.

hauleth napisał(a):

systemd (stara wersja 225, ale było to możliwe, i sądzę, że dalej jest).

Co do samego MUSL, to on jest po prostu równie szybki, mniejszy i lepiej obsługuje część błędów. Dalej paru feature brakuje, ale GLibc też nie jest pod tym względem idealne.

but as I am the author of musl, that may have influenced my choice of which aspects to compare - no rozumiem...

Systemd to mnie mało interesuje, ale sam się naciąłem w alpine na jakiś segfault czegoś związanego z Go, który automatycznie zniknął na obrazie z Ubuntu. Ponieważ jestem z natury leniwy, to nie rozstrząsałem tematu, ale skłoniło mnie to do małego zbadania alpine.

Z czymś takim jak taka biblioteka jest jeden poważny problem produkcyjny: masz sprawdzone glibc, niedoskonałe, ale sprawdzone. Miliony firm to testuje w tej sekundzie, w której Ty to czytasz. Teraz masz taki musl, sypnie się apka z niewiadomego powodu i dojdzie ekstra rozkmina, jak ktoś w ogóle ogarnia coś ze swojej apki, czy aby to nie przez core lib tym razem, a założę się, że pewnie będzie ekstra banalne do diagnozowania, wręcz idealne na piątek wieczór.

I problemem musl jest to, że ciężko znaleźć jakiegoś wiarygodnego bug trackera, gnu glibc ma takiego (pomnę jak on wygląda). Ma co prawda listę błędów, chyba według autorów zasadną, bo nie można tam nic dopisać (aż mi to pewien projekt przypomniał - qmail, tam autor w podobny sposób "uznawał" błędy), ma listę mailingową na openwallu, na której aktywnie udziela się 2 developerów. Patche latają jak przy kernelu - na listę. Taki "nowoczesny" devops, tylko, że w przypadku np. linuksa czy glibc, ewentualny błąd w main release i masz ddosa na kilkudziesięciu popularnych bugtrackerach, a tu? Jesteś na środku Sahary, możesz wołać.

I w sumie nie liczę tu gitlaba do alpine czy innych distro na tym bazujących - ale tam też widzę lądują rozkminy dot. musl

To nie jest jakiś ekstra lib do podrzędnej apki, to jest core lib. Dwóch, nawet majganych developerów i patche na liście mailingowej nie wzbudzają zbytniego zaufania. Dodajmy, że to napędza alpine, które faktycznie nie publikuje swoich biuletynów bezpieczeństwa no i język C, który jak wiadomo słynie z tego, że aplikacje w nim napisane są memory safe, no i mamy dyskretne urozmaicenie na wszelkie nudne projekty.

Dodajmy, że to napędza alpine, które faktycznie nie publikuje swoich biuletynów bezpieczeństwa no i język C, który jak wiadomo słynie z tego, że aplikacje w nim napisane są memory safe, no i mamy dyskretne urozmaicenie na wszelkie nudne projekty.

Bardzo istotne rzeczy:

• Nie tylko Alpine, ale również, np. Gentoo
• MUSL, w przeciwieństwie do GLibc najczęściej jest kompilowany statycznie, więc można to porównać do kompilacji większości projektów w Go (które samo implementuje syscalle, ma nawet własnego assemblera)
• Masz całe kompilatory wspierające MUSL

Ogólnie co do łatek do systemd, to one zwyczajnie robiły kod bardziej kompatybilny z POSIX, a jakby "przy okazji" również kompatybilnym z innymi libc. Niestety jak dla mnie Linux-centryzm i GLibc-centryzm w systemd to dość znaczące wady.