Os engenheiros da Red Hat anunciaram publicamente pela primeira vez nesta manhã seu trabalho no Composefs, um novo sistema de arquivos de imagens verificadas e de compartilhamento oportunista.
A Red Hat está trabalhando no Composefs como uma forma de construir e usar imagens somente leitura que são verificáveis e têm alguns casos de uso imediatos em relação ao compartilhamento de camadas de contêiner Podman e com o suporte de verificação para uso pelo OSTree. Outros projetos como LXC e Snap também podem estar interessados neste suporte de compartilhamento verificado e oportunista em comparação com suas montagens de loopback existentes para manipulação de imagens.
Alexander Larsson da Red Hat anunciou o Composefs na lista de discussão do kernel. Alguns dos principais destaques:
Giuseppe Scrivano e eu recentemente trabalhamos em um novo projeto que chamamos de composefs. Esta é a primeira vez que propomos isso publicamente e gostaríamos de algum feedback sobre isso.
Em sua essência, composefs é uma maneira de construir e usar imagens somente leitura que são usadas de maneira semelhante a como você usaria, por exemplo, imagens squashfs montadas em loopback. Além disso, o composefs tem dois novos recursos fundamentais. Primeiro, ele permite o compartilhamento de dados de arquivo (tanto no disco quanto no cache da página) entre as imagens e, em segundo lugar, possui dm-verity como validação na leitura.
…
Portanto, dado um conjunto confiável de opções de montagem (digamos, desbloqueado do TPM), temos uma árvore de sistema de arquivos totalmente verificada montada, com compartilhamento oportunista de granularidade fina de arquivos idênticos.
Então, por que queremos isso? Existem dois casos de usuário iniciais. Em primeiro lugar, queremos usar o compartilhamento oportunista para as camadas do contêiner podman. A ideia é usar uma montagem composefs como o diretório inferior em uma montagem de sobreposição, com o diretório superior sendo o diretório de trabalho do contêiner. Isso permitirá o compartilhamento automático de disco em nível de arquivo e cache de página entre quaisquer duas imagens, independentemente de detalhes como permissões e carimbos de data/hora dos arquivos e a origem das imagens.
Em segundo lugar, estamos interessados em usar os aspectos de verificação de composefs no projeto ostree. Ostree já usa um armazenamento de objeto endereçado ao conteúdo, mas atualmente é referenciado por farms de hardlink. O armazenamento de objetos e as árvores que fazem referência a ele são assinados e verificados no momento do download, mas não há verificação em tempo de execução. Se substituirmos o hardlink farm por uma imagem composefs que aponte para o armazenamento de objeto existente, podemos usar a verificação para implementar a verificação de tempo de execução.
Na verdade, as ferramentas para criar imagens composefs são totalmente reproduzíveis, então tudo o que precisamos é adicionar o resumo fs-verity da imagem composefs nos metadados de confirmação ostree. Em seguida, a imagem pode ser reconstruída a partir do ostree commit, gerando uma imagem composefs com o mesmo resumo fs-verity.
Esses são os casos de uso nos quais estamos interessados atualmente, mas parece haver uma variedade de outros usos possíveis. Por exemplo, muitos sistemas usam montagens de loopback para imagens (como lxc ou snap) e podem aproveitar o compartilhamento oportunista. Também falamos sobre usar o fuse para implementar um cache local para os arquivos de backup. ou seja você teria um segundo basedir como um sistema de arquivos fuse e, em caso de falha de pesquisa no primeiro basedir, o fuse aciona um download que também é salvo no primeiro diretório para pesquisas posteriores. Existem muitas possibilidades interessantes aqui.
No lado do kernel existe estes seis patches RFC agora implementando este driver do kernel Composefs. Para as ferramentas de espaço do usuário em torno do Composefs, elas estão sendo trabalhadas por meio de containers/composefs no GitHub. Também existem patches iniciais disponíveis para revisão para a integração OSTree proposta.
