Dziś rano inżynierowie firmy Red Hat po raz pierwszy publicznie ogłosili swoje prace nad Composefs, nowym systemem plików obrazów, umożliwiającym współdzielenie i weryfikację oportunistyczną.
Red Hat pracuje nad Composefs jako sposobem konstruowania i używania obrazów tylko do odczytu, które są weryfikowalne i mają kilka natychmiastowych zastosowań związanych z udostępnianiem warstw kontenerów Podmana oraz z obsługą weryfikacji do użytku przez OSTree. Inne projekty, takie jak LXC i Snap, mogą być również zainteresowane tą zweryfikowaną i oportunistyczną obsługą udostępniania w porównaniu z istniejącymi montowaniami sprzężenia zwrotnego do obsługi obrazów.
Alexander Larsson z Red Hat ogłosił Composefs na liście mailingowej jądra. Niektóre z głównych atrakcji:
Giuseppe Scrivano i ja ostatnio pracowaliśmy nad nowym projektem, który nazywamy composefs. Po raz pierwszy proponujemy to publicznie i chcielibyśmy poznać opinie na ten temat.
W swej istocie composefs to sposób konstruowania i używania obrazów tylko do odczytu, które są używane podobnie do tego, jak używałbyś np. obrazy squashfs montowane w pętli wstecznej. Oprócz tego composefs ma dwie nowe podstawowe funkcje. Po pierwsze umożliwia udostępnianie danych plików (zarówno na dysku, jak iw pamięci podręcznej strony) między obrazami, a po drugie ma walidację podobną do dm-verity przy odczycie.
…
Tak więc, biorąc pod uwagę zaufany zestaw opcji montowania (powiedzmy odblokowany z TPM), mamy zamontowane w pełni zweryfikowane drzewo systemów plików, z oportunistycznym, precyzyjnym udostępnianiem identycznych plików.
Dlaczego więc tego chcemy? Istnieją dwa początkowe przypadki użytkowników. Przede wszystkim chcemy wykorzystać udostępnianie oportunistyczne dla warstw kontenerów podmana. Chodzi o to, aby użyć montowania composefs jako dolnego katalogu w montowaniu nakładki, z górnym katalogiem będącym katalogiem roboczym kontenera. Umożliwi to automatyczne współdzielenie dysku i pamięci podręcznej stron na poziomie plików między dowolnymi dwoma obrazami, niezależnie od szczegółów, takich jak uprawnienia i znaczniki czasu plików oraz pochodzenie obrazów.
Po drugie jesteśmy zainteresowani wykorzystaniem aspektów weryfikacyjnych composefs w projekcie ostree. Ostree korzysta już z magazynu obiektów adresowanego do treści, ale obecnie odwołują się do niego farmy twardych linków. Składnica obiektów i drzewa, które się do niej odwołują, są podpisywane i weryfikowane w czasie pobierania, ale nie ma weryfikacji w czasie wykonywania. Jeśli zastąpimy farmę hardlink obrazem composefs, który wskazuje na istniejący magazyn obiektów, możemy użyć weryfikacji do wdrożenia weryfikacji w czasie wykonywania.
W rzeczywistości narzędzia do tworzenia obrazów composefs są w pełni odtwarzalne, więc wszystko, czego potrzebujemy, to dodać skrót fs-verity obrazu composefs do metadanych zatwierdzenia ostree. Następnie obraz można zrekonstruować z zatwierdzenia ostree, generując obraz composefs z tym samym skrótem fs-verity.
Oto przypadki użycia, którymi jesteśmy obecnie zainteresowani, ale wydaje się, że istnieje wiele innych możliwych zastosowań. Na przykład wiele systemów używa montowań pętli zwrotnej dla obrazów (takich jak lxc lub snap), a te mogą wykorzystać oportunistyczne udostępnianie. Mówiliśmy również o użyciu fuse do zaimplementowania lokalnej pamięci podręcznej dla plików kopii zapasowych. Tj. miałbyś drugi katalog oparty na systemie plików bezpieczników, a w przypadku niepowodzenia wyszukiwania w pierwszym opartym katalogu bezpiecznik uruchamia pobieranie, które jest również zapisywane w pierwszym katalogu do późniejszych wyszukiwań. Jest tu wiele interesujących możliwości.
Po stronie jądra znajduje się te sześć poprawek RFC właśnie implementuje ten sterownik jądra Composefs. Narzędzia przestrzeni użytkownika wokół Composefs są opracowywane za pośrednictwem containers/composefs w GitHub. Dostępne są również wstępne poprawki do przeglądu dla proponowanej integracji z OSTree.
