Sosna, alpejski linux oparty na OSTree
Wybór czego OS działa na twoich serwerach to kwestia wygody i znajomości. Wygoda oznacza, że chcesz czegoś, co sprawia Ci jak najmniej kłopotów, znajomość oznacza, że wolisz nie nauczyć się dodatkowych rzeczy, jeśli nie musisz.
Moje serwery są zwierzęta domowewięc jestem w porządku, ręcznie wydając kilka poleceń raz na jakiś czas i nie wymagam pełnej automatyzacji.
Po wypróbowaniu CoreOS na rok przerzuciłem się na własne uproszczone dystrybucja na bazie alpejskiej i Ostree.
Ta wersja alpejskiej czerpie wskazówki z platforma oraz projekt-atomowy i ma być zainstalowany jako główny system plików tylko do odczytu z aktualizacjami zachodzącymi niepodzielnie, to znaczy, że albo się powiedzie, albo system wraca do poprzedniego stanu. Aby było to możliwe, system musi zawsze mieć co najmniej dwie migawki wydanej wersji systemu plików, dostępnej w magazynie.
W jakich środowiskach będzie działał system? celowałem OVZ i [KVM], ale ogólnie można powiedzieć pojemniki oraz wirtualne maszyny główną różnicą jest to, że kontenery nie uruchamiają własnego jądra, w szczególności nie mają procesu rozruchu, wywołują bezpośrednio do w tym system (który na przykład w aDockerfile
byłaby zdefiniowana przezCMD
lubENTRYPOINT
instrukcji), który jest odpowiedzialny za zarządzanie drzewem procesów, które podtrzymują działanie kontenera (podobnie jak normalna sesja, jeśli proces inicjacji zginie, kontener się zakończy). Ponadto kontenery nie mogą konfigurować pokręteł systemowych i mogą mieć dodatkowe ograniczenia możliwości.
Jak budowany jest wizerunek?
tenprepare.sh
skrypt obsługuje zależności, z których większość to pakiety oferujące popularne narzędzia CLI, takie jakcoreutils
, util-linux
, binutils
, narzędzia do pracy z urządzeniami blokowymi, takimi jakblkid
, sfdisk
, multipath-tools
i systemy plików zxfsprogs
oraze2fsprogs
. tensquashfs-tools
pakiet jest używany na końcu do skompresowania wbudowanego głównego systemu plików. Aglib
pakiet kompatybilności jest również instalowany domyślnie, ponieważ alpine jest oparty namusl
, pakiet kompatybilności działa poprzez dostarczenie kilku bibliotek zbudowanych przeciwko .
Drzewa plików dla maszyn wirtualnych i kontenerów są budowane odpowiednio zmake.sh
orazmake_ovz.sh
. To jest uproszczony opis kroków
ustawić wersję do zbudowania zgodnie z tagiem repozytorium
utwórz katalog dla nowego drzewa i wyczyść środowisko
tworzyć podstawowe katalogi docelowe i katalogi wymagane przez ostree, np.sysroot
utwórz dowiązania symboliczne, aby były zgodne z standard hierarchii systemu plików
kopiuj niestandardowe usługi i niestandardowe konfiguracje
skonfiguruj chroota z zamontowanymi katalogami systemowymi
załaduj alpine rootfs z pakietami podstawowymi
zastosuj minimalną konfigurację do rootfs, taką jak poświadczenia, strefa czasowa, nazwa hosta.
usługi kopiowania do uruchomienia przez init
skonfiguruj konfigurację startową z określonym obrazem jądra
opcjonalnie dodaj niestandardowe moduły jądra
wykonać porządki
zatwierdź rootfs[1] do repozytorium ostrych
W przypadku kontenerów kolejność jest taka sama, ale konfiguracja zmienia się, ponieważ system nie jest uruchamiany z program rozruchowy ostree ma problemy z weryfikacją środowiska, musimy zastosować trochę obejścia i skonfiguruj niektóre urządzenia, które są zwykle obsługiwane przez initramfs krok. Oto jak OVZ lub LXC szablony są skonfigurowane.
Kiedy już mamy drzewo plików zatwierdzonych przez ostreebuild.sh
lubbuild-update.sh
zajmuje się produkcją artefaktu, który będzie dystrybuowany. Różnica między skryptami polega na tym, że wersja aktualizacji zaczyna się od poprzedniego repozytorium ostree, a także tworzy artefakt delta, który działający system może zastosować na swojej instancji ostree w celu wykonania aktualizacji. To jest uproszczony opis kroków budowania
jeśli nowa kompilacja
tworzyć nowe partycje na nowym obrazie zamontowanym jako urządzenie pętlowe
w przeciwnym razie
zamontuj partycje sysroot i boot z poprzedniej wersji
posprzątaj poprzednie wdrożenia ostree (farmy linków) na zamontowanych kompilacjach
zatwierdź nowe zbudowane drzewo na zamontowanej kompilacji
zweryfikuj integralność i sumy kontrolne
utwórz nową deltę dla uaktualnień
wykonać wdrożenie ostree w celu zregenerowania konfiguracji rozruchu
usuń stare zatwierdzenia ostree
sprawdź integralność partycji rozruchowej
odmontuj nowy zaktualizowany obraz kompilacji
wygeneruj sumę kontrolną obrazu i skompresuj ją (za pomocąsquashfs
dla kontenerów)
Konfiguracja partycji jest stosowana za pomocą fdisklayout.cfg
plik definiujący rozmiary partycji, mamy jedną partycję dla rootfs (~430M
), partycja rozruchowa (~40M
) i partycję wymiany (~40M
). Z kontenerami, w których wystarczy pominąć montowanie poprzedniej wersji nad urządzeniem pętlowym i po prostu przeciągnąć nowe zatwierdzenie ostree na stare (wydobyte) repozytorium ostree.
Co dołączam do tego obrazu (oprócz zainstalowanych pakietów)?
Mała biblioteka wfunctions.sh
do typowych zadań wykonywanych w powłoce
Skrypty aktualizacyjne oparte o ostree z mechanizmem blokującym w oparciu o sklep KV
skrypty monitorujące dla IO zarówno lokalne (iomon
) i sieci (tcpmon
)
skrypty konfiguracyjne dla środowisk wykonawczych kontenera innych niżbubblewrap
: podman
, toolbox
Co było, a czego już nie ma
sup
: Łyk był używany do orkiestracji (rozmieszczania kontenerów) i konfiguracji hosta, ale potem przełączyłem się na ansibl ponieważ w sup były długo utrzymujące się błędy, które nie były naprawione, nie wybrałem ansible od początku, ponieważ nie chciałem, aby zależność python instalowała się na każdym serwerze, ostatecznie ustaliłem z drugorzędnym alpine chroot na maszynach hosta, znajdujących się w/opt/alp
czy instaluję dodatkowe mniej krytyczne oprogramowanie. Dziś jednak ponownie przestawiłbym się z ansibla na pyinfra , ponieważ
jest to python bez boilerplate’u (ansibl ma pseudoDSL
który powoduje więcej bólów głowy niż te, które rozwiązuje)
wykonuje swoje przepisy za pomocą zwykłych poleceń ssh, więc nie ma wymogu zależności od Pythona na docelowych hostach
containerpilot
: Przykładem użycia dla pilota kontenera jest zarządzanie złożonymi zależnościami między kontenerami bez skryptów powłoki ... przestał otrzymywać aktualizacje z radość i został wprowadzony w tryb konserwacji, nie podobało mi się również, że wymagania dotyczące pamięci i zużycie pamięci stale wzrastało przez długi czas bezawaryjnej pracy. Zmieniłem go na proste skrypty powłoki za pomocą konsul , mógłbym poszukać bardziej odpowiednich alternatyw, jeśli skrypty powłoki zaczną się zbytnio rozrastać. Cięższe rozwiązania, takie jak kubernetes, rój lub koczownik zostały odrzucone od samego początku.
beegfs
: Kiedyś wysyłałem moduł jądra niezbędny do beegfs ale po chwili zepsuło się kompatybilność i fakt, że nie było odpowiednio obsługiwanej bezpiecznik został całkowicie usunięty, obecnie nie używam [DFS] na moich serwerach, ale możliwość posiadania gotowego systemu plików do podłączenia do sieci jest nadal atrakcyjna.
Aby zainstalować obraz, możesz albo przesłać go do dostawcy hostingu i zainstalować z VNC, w przypadku maszyn wirtualnych, ale zwykle przechwytuję istniejącą instalację, ponieważ zawsze jest to możliwe, a także od dawna testowałem skrypt instalacyjny z wersją dystrybucja linuksa, zazwyczaj używam debian-8 lub ubuntu-14, nie testowałem innych, ponieważ zawsze uważałem, że są one dostępne. Kroki konfiguracji są następujące
zapewnić obsługę https dla pobierania
pobierz wersję busybox
zainstaluj farmę linków busybox
określić adresy IPv4/ipv6 do konfiguracji sieci
zapewnić możliwości chroot
pobierz obraz sosny i wyodrębnij go
jeśli maszyna wirtualna
migać nad urządzeniem docelowym
zamontować nad urządzeniem pętlowym
zapisz konfigurację sieci lokalnej przez do flashowania rootfs
jeśli pojemnik
skopiuj usługę init (dla kontenerów) przez główny punkt montowania root/sbin/init
jeśli maszyna wirtualna
podziel pozostały dysk za pomocą standardowego (xfs
) partycje
odmontuj
zweryfikować integralność partycji
restart
zrobiłem sosna 5 years from time of writing and I am still using it, and I see no reasons to switch to anything else. Alpine as a linux distro is great, simple, and I have never experienced breakage. I can easily deploy on NATed serwery, które oferują bardzo niskie zasoby, w rzeczywistości mam uruchomione pudełko z zaledwie64M
pamięci RAM i nadal posiadam wszystkie potrzebne funkcje.
[1] | główny system plików |