Alpaquita Linux – Alpine Linux na sterydach? Alternatywa dla kontenerów i VM

Jeśli budujesz kontenery, uruchamiasz lekkie VM-ki albo po prostu lubisz minimalistyczne dystrybucje, jest spora szansa, że Alpine Linux już dawno trafił na Twój radar. Mały obraz, szybki apk, musl zamiast glibc i bardzo niewielki narzut – trudno się dziwić, że Alpine stał się jednym z fundamentów świata kontenerów.

Ale co, jeśli potrzebujesz tego samego podejścia, a jednocześnie nie chcesz walczyć z ograniczeniami musl? Albo potrzebujesz glibc bez dokładania warstwy kompatybilności? Albo zależy Ci na bardziej przewidywalnym środowisku dla aplikacji produkcyjnych?

Właśnie tutaj pojawia się Alpaquita Linux.

To dystrybucja, która wyrosła z pomysłów stojących za Alpine, ale próbuje pójść krok dalej: zachować niewielki rozmiar i prostotę, a jednocześnie dać programiście większy wybór na poziomie libc, lepszą wydajność oraz opcje istotne w środowiskach produkcyjnych.

Alpaquita Linux w kilku słowach

Alpaquita Linux jest minimalistyczną dystrybucją projektowaną przede wszystkim z myślą o środowiskach cloud-native. Jej korzenie są mocno związane z Alpine Linux, ale projekt rozwija własne komponenty i optymalizacje.

Najważniejsza różnica z punktu widzenia programisty jest bardzo konkretna:

Alpaquita może korzystać zarówno z musl, jak i glibc.

Co więcej, w przypadku musl dostępny jest wariant określany jako musl-perf, czyli zoptymalizowana przez BellSoft implementacja biblioteki. Według dokumentacji projektu zachowuje ona kompatybilność ze standardowym musl, ale poprawia wydajność w określonych obciążeniach.

To ważne, ponieważ wybór libc przestaje być decyzją typu:

„Biorę Alpine i muszę zaakceptować musl”.

Możemy zamiast tego powiedzieć:

„Potrzebuję małego systemu. Najpierw wybieram właściwą libc, a dopiero potem resztę środowiska”.

I to jest chyba najciekawsza cecha Alpaquity.

Dlaczego w ogóle libc ma znaczenie?

Jeżeli korzystasz głównie z Pythona, Go, Node.js czy prostych narzędzi CLI, różnica pomiędzy glibc i musl może przez długi czas pozostać niezauważalna.

Problemy zaczynają się zwykle wtedy, kiedy aplikacja korzysta z natywnych bibliotek albo gotowych binariów.

Typowy przykład:

aplikacja
   │
   ├── biblioteki języka
   │
   ├── biblioteki natywne
   │
   └── libc
        ├── glibc
        └── musl

Binarium skompilowane z założeniem obecności glibc niekoniecznie uruchomi się bezpośrednio w środowisku opartym o musl.

I właśnie dlatego Alpine potrafi być fantastyczne, dopóki nie trafimy na zależność, która mówi:

Error loading shared library ...

albo:

not found

mimo że plik fizycznie znajduje się w systemie.

Można oczywiście stosować warstwy kompatybilności. Istnieją nawet projekty dostarczające glibc jako dodatkowe pakiety dla Alpine. (GitHub)

Tyle że wtedy minimalistyczny obraz zaczyna powoli obrastać wyjątkami.

Alpaquita rozwiązuje ten problem na poziomie samego systemu.

Dwa światy: musl i glibc

To daje ciekawą możliwość budowania obrazów.

Jeżeli aplikacja dobrze działa z musl, możemy wykorzystać wariant musl:

FROM alpaquita-linux:musl

# instalacja aplikacji
# ...

Jeżeli natomiast zależy nam na kompatybilności z oprogramowaniem oczekującym glibc, wybieramy wariant glibc.

To szczególnie interesujące w przypadku ekosystemów, w których gotowe natywne komponenty są częścią aplikacji.

Dobrym przykładem jest Java. BellSoft rozwija Alpaquitę równolegle ze swoim ekosystemem Liberica JDK i dostarcza obrazy runtime wykorzystujące Alpaquita. (GitHub)

Nie oznacza to oczywiście, że Alpaquita jest „dystrybucją tylko dla Javy”. Wręcz przeciwnie. Warto jednak zauważyć, że problemy związane z libc są szczególnie widoczne właśnie w dużych ekosystemach, takich jak Java, gdzie obok samego runtime’u mamy mnóstwo narzędzi i bibliotek natywnych.

A co z apk?

Jeżeli znasz Alpine, tutaj poczujesz się jak w domu.

Alpaquita zachowuje wiele rozwiązań znanych z Alpine, w tym model zarządzania pakietami oparty o apk.

To jedna z rzeczy, które sprawiają, że przejście z Alpine nie przypomina migracji z jednej filozofii systemu do zupełnie innej.

Zamiast:

apt update
apt install ...

nadal możemy myśleć w stylu:

apk add ...

Dla kontenerów ma to spore znaczenie.

Obraz bazowy powinien zawierać możliwie niewiele rzeczy, a dodatkowe komponenty instalujemy tylko wtedy, kiedy są faktycznie potrzebne.

To prowadzi do bardzo prostego Dockerfile:

FROM ...

RUN apk add --no-cache \
    ca-certificates \
    curl

Z punktu widzenia osoby przesiadającej się z Alpine próg wejścia jest więc stosunkowo niski.

Kontenery: tutaj Alpaquita ma najwięcej sensu

Najbardziej naturalnym zastosowaniem Alpaquity są kontenery.

W kontenerach często nie potrzebujemy kompletnej dystrybucji z ogromnym userspace. Potrzebujemy:

• bibliotek wymaganych przez aplikację,
• runtime’u,
• kilku narzędzi,
• certyfikatów,
• użytkownika, pod którym działa proces,
• i możliwie małej powierzchni systemu.

Alpaquita jest projektowana właśnie pod taki model.

Według materiałów BellSoft bazowy obraz Alpaquity może mieć około 3,22 MB, choć oczywiście rzeczywisty rozmiar finalnego obrazu zależy od wybranego wariantu i dołożonych pakietów.

To oznacza, że nie musimy wybierać pomiędzy:

bardzo mały obraz
       vs.
normalne środowisko użytkowe

Alpaquita próbuje zaoferować jedno i drugie.

A może VM?

Tu robi się jeszcze ciekawiej.

Alpaquita nie musi być traktowana wyłącznie jako „system do Dockera”. Projekt posiada również warianty przeznaczone do uruchamiania jako pełny system.

Ma to znaczenie np. wtedy, gdy budujemy:

• małe VM-ki,
• appliance,
• środowiska testowe,
• workloady uruchamiane przez KVM/QEMU,
• lekkie serwery,
• systemy uruchamiane na ARM.

W badaniach wydajnościowych BellSoft testowało Alpaquitę również w VM uruchomionej na KVM/QEMU, a od 2025 roku projekt ma także wsparcie dla AArch64.

To istotna różnica względem myślenia o Alpine wyłącznie jako o „obrazie bazowym dla Dockera”.

Możemy potraktować Alpaquitę jako mały system operacyjny, który po prostu dobrze pasuje również do kontenerów.

OpenRC zamiast systemd

Jeżeli uruchomisz Alpaquitę jako system, natrafisz na kolejną rzecz dobrze znaną użytkownikom Alpine – OpenRC.

OpenRC jest systemem init i menedżerem usług, który bazuje na prostym modelu skryptów i zależności pomiędzy usługami. (GitHub)

Dla VM-ki może to być bardzo atrakcyjne.

Nie każda mała maszyna potrzebuje całego świata systemd. Jeżeli mamy VM przeznaczoną do konkretnego zadania, prosty init może być dokładnie tym, czego potrzebujemy.

W kontenerze natomiast najczęściej w ogóle nie będziemy korzystać z OpenRC – proces aplikacji może być po prostu głównym procesem kontenera.

To dobrze pokazuje różnicę pomiędzy dwoma zastosowaniami:

                 Alpaquita
                     │
          ┌──────────┴──────────┐
          │                     │
      kontener                 VM
          │                     │
   aplikacja jako PID 1      OpenRC

Wydajność: czy to faktycznie coś daje?

Tu warto zachować zdrowy sceptycyzm.

Każdy producent może pokazać benchmark, w którym jego rozwiązanie wygrywa. Dlatego nie traktowałbym liczb publikowanych przez BellSoft jako uniwersalnego dowodu, że „Alpaquita jest szybsza od Alpine”.

Natomiast kierunek optymalizacji jest interesujący.

Alpaquita modyfikuje nie tylko userspace. Projekt zawiera również własne optymalizacje kernela, a jego wariant musl-perf ma eliminować część ograniczeń wydajnościowych klasycznego musl.

W jednym z benchmarków STREAM BellSoft uzyskał dla musl-perf wynik około 21,6 GB/s w operacji Copy, podczas gdy testowany Alpine 3.16 osiągnął około 19,2 GB/s.

Ale najważniejszy wniosek nie brzmi:

„Alpaquita jest o X% szybsza”.

Brzmi raczej:

„Jeżeli wybrałeś Alpine ze względu na musl i mały rozmiar, istnieje alternatywa, która próbuje zoptymalizować właśnie te elementy bez porzucania tej filozofii”.

To dużo bardziej interesująca teza.

Alpaquita vs Alpine – gdzie jest różnica?

Dla programisty najważniejsze różnice można sprowadzić do kilku punktów.

Cecha	Alpine Linux	Alpaquita Linux
Minimalistyczny system	✓	✓
apk	✓	✓
musl	✓	✓
glibc	dodatkowa kompatybilność	✓
zoptymalizowany musl	—	✓
OpenRC	✓	✓
Kontenery	✓	✓
VM	✓	✓
ARM/AArch64	✓	✓
Optymalizacje kernela	standardowy kierunek Alpine	własne optymalizacje
Wsparcie komercyjne	brak w samym projekcie	dostępne od BellSoft

Alpine pozostaje oczywiście bardzo dojrzałym i niezwykle popularnym projektem.

Nie ma powodu wymieniać działających kontenerów tylko dlatego, że pojawiła się alternatywa.

Alpaquita jest interesująca przede wszystkim wtedy, gdy Alpine zaczyna stawiać przed nami konkretne problemy.

Najważniejszy argument: kompatybilność

Wyobraźmy sobie typowy projekt.

Mamy:

Dockerfile
    │
    ├── Alpine
    │
    ├── Python / Node / Java / Go
    │
    └── biblioteka natywna
             │
             └── wymaga glibc

W Alpine zaczynamy kombinować.

Możemy znaleźć alternatywny pakiet. Możemy dodać kompatybilność z glibc. Możemy skompilować bibliotekę samodzielnie.

Ale każda taka decyzja zwiększa złożoność obrazu.

W Alpaquita możemy zacząć od wariantu glibc.

Dockerfile
    │
    ├── Alpaquita glibc
    │
    ├── runtime
    │
    └── biblioteka natywna
             │
             └── glibc ✓

To nie jest spektakularna funkcja.

To jest nudna funkcja, która może oszczędzić programiście bardzo dużo czasu.

A właśnie takie funkcje są często najbardziej wartościowe w produkcji.

Nie tylko glibc – wybór ma znaczenie

Jednocześnie nie należy wyciągać z tego wniosku, że glibc jest zawsze lepszym wyborem.

Jeżeli aplikacja świetnie działa na musl, nie ma potrzeby przechodzenia na glibc.

Możemy wtedy wykorzystać Alpaquitę właśnie jako lekkie środowisko musl.

A jeśli zależy nam na wydajności, warto sprawdzić wariant musl-perf.

W praktyce możemy więc myśleć o Alpaquicie jako o dwóch narzędziach w jednym:

                 Alpaquita
                     │
          ┌──────────┴──────────┐
          │                     │
        musl                  glibc
          │                     │
   minimalistyczne         kompatybilność
   workloady               z ekosystemem
          │                     │
          └──────────┬──────────┘
                     │
                ten sam model
                 lekkiego OS

To właśnie odróżnia ją od klasycznego podejścia „Alpine = musl”.

Dla kogo Alpaquita ma największy sens?

Moim zdaniem przede wszystkim dla trzech grup.

1. Programiści budujący obrazy kontenerowe

Jeżeli regularnie tworzysz:

FROM alpine

warto przetestować:

FROM alpaquita...

szczególnie wtedy, gdy trafiasz na problemy z kompatybilnością natywnych bibliotek.

2. Zespoły używające Javy

Tutaj ekosystem Alpaquity jest szczególnie interesujący dzięki integracji z Liberica JDK i gotowym runtime containers. (GitHub)

Dla aplikacji Java wybór pomiędzy musl i glibc może mieć realne znaczenie, zwłaszcza jeśli w projekcie pojawiają się natywne komponenty.

3. Osoby budujące małe VM-ki

Jeżeli Debian czy Ubuntu są dla Twojej maszyny po prostu zbyt duże, ale Alpine jako system bazowy wydaje Ci się zbyt ograniczony, Alpaquita może być ciekawym kompromisem.

Dostajesz minimalistyczny system, apk, OpenRC i możliwość wyboru libc.

Czy warto migrować z Alpine?

Nie w ciemno.

Jeżeli masz produkcyjne obrazy Alpine, które działają, są małe, szybko się budują i nie sprawiają problemów – zostawiłbym je w spokoju.

Alpaquita nie jest magicznym zamiennikiem, który automatycznie poprawi każdą aplikację.

Natomiast zdecydowanie warto ją przetestować, jeśli:

• trafiasz na problemy z musl,
• potrzebujesz glibc,
• budujesz obrazy dla Javy,
• zależy Ci na małym obrazie bazowym,
• tworzysz lekkie VM,
• chcesz kontrolować wybór libc,
• albo po prostu szukasz alternatywy dla Alpine.

Szczególnie ciekawy jest scenariusz A/B:

Alpine + musl
      vs.
Alpaquita + musl-perf
      vs.
Alpaquita + glibc

Następnie warto zmierzyć dokładnie to, co jest istotne dla naszej aplikacji:

czas budowania obrazu
rozmiar obrazu
czas startu
zużycie RAM
czas odpowiedzi
throughput
czas wykonywania testów

Dopiero taki benchmark powie nam, czy migracja ma sens.

Podsumowanie

Alpaquita Linux nie próbuje być kolejnym Debianem czy Ubuntu.

Jej pomysł jest znacznie bardziej konkretny: wziąć filozofię lekkiego systemu znaną z Alpine, a następnie usunąć część kompromisów, które zaczynają boleć w bardziej wymagających środowiskach.

Najciekawszą zmianą jest możliwość wyboru pomiędzy musl i glibc, bez konieczności dokładania kompatybilności do bazowego systemu.

Do tego dochodzą zoptymalizowany musl, własne optymalizacje kernela, OpenRC, apk, małe obrazy oraz możliwość wykorzystania systemu również poza samym Dockerem.

Dlatego jeśli Alpine Linux jest dla Ciebie trochę jak dobrze znane narzędzie, którego możliwości zaczynają być niewystarczające, Alpaquita jest jednym z ciekawszych projektów, które warto mieć obecnie na radarze.

Nie dlatego, że Alpine jest złe.

Właśnie dlatego, że Alpine pokazało, jak dużo można osiągnąć minimalistycznym Linuksem – a Alpaquita próbuje zrobić następny krok.