Não é possível recriar o aplicativo: driver de armazenamento docker não suportado (btrfs)

Instalação
1

Vamos migrar nosso servidor e a instalação do Discourse.
Estamos usando um novo servidor com o sistema de arquivos btrfs.

Estou fazendo alguns testes em uma máquina de teste, copiei todos os arquivos e instalei todas as partes necessárias (nginx, docker, o próprio discourse).

Tentei com um sistema de arquivos ext4 e funcionou bem.
Mas agora, quando faço o mesmo com um sistema de arquivos formatado em btrfs, recebo este erro ao tentar ‘launcher rebuild app’:

Sua instalação do Docker não está usando um driver de armazenamento compatível. Se prosseguirmos, você pode ter uma instalação corrompida.
overlay2 é o driver de armazenamento recomendado, embora zfs e aufs também possam funcionar.
Outros drivers de armazenamento são conhecidos por serem problemáticos.
Você pode saber qual sistema de arquivos está usando executando "docker info" e olhando a linha 'Storage Driver'.

Se você deseja continuar mesmo assim usando seu driver de armazenamento não suportado existente,
leia o código fonte do launcher e descubra como contornar esta verificação.

Obviamente, o docker info indica que está usando btrfs.
Li neste fórum que o discourse tem problemas com alguns drivers de armazenamento do docker e é por isso que ele se recusa a reconstruir.

Existe uma maneira de alterá-lo para ‘overlay’ ou outro driver compatível com o discourse e capaz de recuperar os arquivos do sistema de arquivos btrfs?

Como devo configurar o docker?
É possível fazer isso apenas para o contêiner do discourse e deixar o restante da configuração do docker como padrão?

Obrigado.

2

Observação

Tanto overlay quanto overlay2 não são suportados atualmente em btrfs ou em qualquer sistema de arquivos Copy on Write e só devem ser usados sobre partições ext4.

Como o Docker não suporta o uso do driver overlay2 sobre btrfs, parece que a recomendação da ferramenta de inicialização é o limite de suas opções aqui. Ou seja, continuar executando o Discourse em um sistema onde o Docker é suportado por ext4 ou modificar o launcher para ignorar o driver de armazenamento e torcer pelo melhor.

Comentar (adicionar # no início) a linha exit 1 nas seguintes linhas do script launcher com seu editor de texto preferido alcançará o último se você quiser seguir esse caminho:

Considerando que “Outros drivers de armazenamento são conhecidos por serem problemáticos”, eu não recomendaria fazer isso.

1 curtida
3

Obrigado pela sua rápida resposta.

Então, se entendi corretamente, o docker não é capaz de usar outro driver de armazenamento alternativo para acessar os arquivos do sistema subjacentes, se você estiver usando um sistema de arquivos COW como o btrfs.

Portanto, não há uma boa solução, pois o discourse pode ter problemas ao usar o driver de armazenamento btrfs do docker.

Reverter para ext4 não é uma opção, pois toda a migração foi para garantir que os arquivos de dados fossem mantidos sob o sistema de arquivos COW btrfs e sua capacidade de tirar snapshots e manter os dados limpos.

Não há sentido em usar btrfs em outras partes do sistema, pois seu principal objetivo é fornecer acesso ao fórum discourse.

É uma pena, pois seria ótimo tê-lo funcionando com a proteção de um sistema de arquivos COW.

É mais fácil usar a flag --skip-prereqs. Mas usá-la no sistema de produção pode ser arriscado.
Eu tentei na máquina de teste e está funcionando bem por enquanto, mas o problema parece ser a longo prazo.

4

Usar --skip-prereqs pula muitos outros testes que, como você mencionou, introduzem vários riscos ao realizar uma reconstrução. Comentar essa única linha não é mais ou menos arriscado do que rodar em btrfs e deve fazer um auto-merge quando o launcher se atualizar, o que significa que você provavelmente pode fazer a alteração uma vez e, na maior parte, esquecer dela.

1 curtida
5

OK; obrigado, eu não tinha percebido isso.

6

Para ser honesto, essa mensagem foi direcionada ao antigo devicemapper, que era um problema conhecido de confiabilidade.

Ao longo dos anos, usamos aufs e, mais recentemente, usamos o driver overlay2, sem problemas. Se você quiser usar brtfs para experimentar, por favor, faça um relatório aqui após alguns meses.

2 curtidas
7

Obrigado.
No servidor de produção, tenho receio de fazer isso.
Se houver problemas com o driver do Docker e ele gravar dados corrompidos, ter snapshots, backups ou qualquer outra coisa não ajudará se houver uma falha.
Se houver alguma maneira segura de manter os dados em um backup, eu poderia tentar…
que tipo de problemas aconteceram no passado?

Mas hoje em dia, esses sistemas de arquivos COW são muito úteis. Você pode tirar snapshots, os dados são protegidos contra corrupções durante a gravação ou outras falhas, é fácil adicionar espaço ou mover dispositivos…

Seria ótimo se pudéssemos ver isso no Discourse no futuro.
Talvez eu possa ajudar a testar. Eu o tenho rodando em uma máquina de teste.

8

O problema é que, se eu editar o arquivo do lançador para adicionar btrfs à lista de drivers de armazenamento do Docker suportados, quando eu executar o script, ele reclama que o script foi alterado localmente e será substituído pela versão remota (do github).
Como eu resolvo isso?

9

Qual é a mensagem exata que você está vendo e em que ponto da reconstrução ela ocorre?

Eu acabei de iniciar uma VM que uso para testes e modifiquei a linha, depois reconstruí. No ponto em que o launcher se atualiza, ele fez o git pull e uma mesclagem fast-forward como eu esperava, deixando a modificação intacta.

A versão da qual eu estava atualizando não incluía uma alteração no próprio launcher, mas eu esperaria que funcionasse da mesma forma, desde que não haja um conflito, ou seja, desde que essa linha exit 1 ou linhas muito próximas a ela não sejam alteradas no repositório.

1 curtida
10

Obrigado pela sua resposta e interesse.
Deixe-me tentar esclarecer.

Alterei o script do lançador para incluir o btrfs como um dos formatos aceitos.
Na função check_prereqs alterei:

if ! $docker_path info 2> /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then

Quando tentei pela primeira vez fazer uma reconstrução do lançador, recebi uma mensagem dizendo que o lançador havia sido modificado localmente e se eu queria continuar baixando arquivos da origem.

Então tive que deixá-lo como estava, fazer a reconstrução e alterá-lo depois para iniciar o aplicativo.

Mas tentei hoje fazer uma reconstrução novamente, e parece que ele detecta a mudança, mas não reclama e a mudança é preservada.

Não sei se algo foi alterado recentemente no lançador e eu poderia ter originalmente um lançador antigo que não fazia a reconstrução e agora faz (depois de atualizá-lo ontem).

Estou testando com btrfs e tudo parece funcionar bem, você pode iniciar e parar aplicativos, fazer backups, tudo funciona bem por enquanto.

O Docker parece criar subvolumes btrfs para os dados de armazenamento dos contêineres quando detecta que está rodando em um sistema de arquivos btrfs e usa o driver de armazenamento btrfs.
Portanto, parece que ele faz algumas otimizações ao clonar contêineres ou tirar snapshots por meio de comandos do Docker.

Mas não sei se o driver pode estar com defeito de alguma forma (não parece ser um driver experimental no Docker, não há avisos sobre seu uso em btrfs ou não consegui encontrá-los) e se seria melhor (se possível) alterar as informações do Docker para executá-lo usando o driver overlay2 como se estivesse rodando em um sistema de arquivos padrão.
Em teoria, seria possível para o Docker gravar seus arquivos e fazer operações em um sistema de arquivos btrfs sem levar em conta suas capacidades (já que o btrfs não é diferente de outros sistemas de arquivos no nível do usuário, para E/S de arquivos).

Quaisquer opiniões ou experiências usando o driver de armazenamento btrfs do Docker ou configurando o driver overlay2 para ser usado ao usar o Docker em um sistema de arquivos btrfs seriam bem-vindas.

11

Não tenho experiência direta para oferecer, mas eu desaconselharia fortemente forçar o Docker a permitir que o driver overlay2 seja usado sobre o btrfs. É explicitamente não suportado e o driver overlay2 pode estar fazendo suposições sobre o sistema de arquivos que podem ou não ser verdadeiras para o btrfs, levando plausivelmente a vários resultados inesperados. Você realmente não quer resultados inesperados no nível do sistema de arquivos.

As operações de baixo nível do sistema de arquivos serão tratadas pelo Docker e pelo driver de armazenamento btrfs. Se essa for uma combinação madura e bem mantida, que não seja conhecida por ter bugs como o devicemapper, há uma boa chance de que funcione bem.

A razão pela qual o btrfs não é suportado no Discourse, pelo que entendo, não é por alguma expectativa de que ele falhará, é simplesmente porque eles não têm informações suficientes para dizer às pessoas que ele funcionará.

Eles não têm (ou não têm o suficiente) incentivo para executar seus próprios servidores em btrfs, então a única maneira de obter essas informações é através de pessoas na comunidade experimentando em produção e relatando após longos períodos de tempo. Isso ainda não aconteceu, então permanece não suportado.

Se você se encontrar nesta situação no futuro, sempre poderá reverter a alteração, atualizar e, em seguida, aplicar a alteração novamente antes de executar o launcher:

cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app
1 curtida
12

Muito obrigado.

Então, não tentarei usar o driver de armazenamento overlay2 do Docker sobre o sistema de arquivos btrfs, deixarei o Docker usar o driver btrfs esperando que funcione corretamente e sem problemas.
Aqui Docker Storage Drivers | Learn the Different Storage drivers of Docker eles dizem que é a abordagem recomendada e oficialmente suportada para SLE Linux, mas recomendada no Ubuntu.
Debian 10 e 11 suportam btrfs no kernel sem modificações e suportam boot a partir de uma partição btrfs (apenas a partição UEFI deve ser de outro tipo).

Então, presumo que seja bem testado.

A resposta de Rafael parece indicar que não há razão especial para não usá-lo. Os problemas eram com devicemapper e eles fizeram a solicitação para usar sistemas de arquivos conhecidos, provavelmente em um momento em que não havia tanta atenção ao btrfs ou outros sistemas COW.

Vou tentar.
Relatarei minha experiência (boa ou ruim) em seu uso.
Por enquanto, funciona perfeitamente e me permite alterar facilmente o tamanho do sistema de arquivos, adicionar dispositivos, removê-los, etc., e me dá a confiança de que os dados subjacentes estão corretos e permanecerão sem erros.
A única precaução é com o driver de armazenamento do Docker se ele não for testado o suficiente, mas parece que tem sido amplamente utilizado no SLE (que implementa btrfs como sistema de arquivos de armazenamento padrão há muito tempo).

1 curtida
13

Tenho que dizer que estamos com o servidor de produção rodando há 9 dias em um sistema de arquivos BTRFS sem nenhum problema.

Eu já havia testado anteriormente em um servidor de teste.
E eu movi o fórum de um local para um subvolume, adicionei e removi discos e espaço do sistema de arquivos, sem problemas.

Relatarei após mais tempo de uso.

Sou bastante novo no BTRFS e não o conheço profundamente, mas não é tão difícil e funciona como esperado.

2 curtidas
14

Bem, tenho que dizer que estamos executando o Discourse no sistema de arquivos btrfs há quase um mês sem nenhum problema.

Funciona perfeitamente.
Os drivers btrfs do Docker parecem funcionar perfeitamente.
Seria ótimo se outras pessoas testassem o Discourse rodando em btrfs e o suporte a btrfs pudesse ser integrado à distribuição do Discourse.

Paramos o fórum por um momento, tiramos o snapshot usando btrfs (alguns segundos) e o executamos novamente.
Em seguida, fazemos um backup externo do snapshot tirado.

Parece funcionar perfeitamente.

Restaurei o backup em outra máquina para testar e funcionou.

O

2 curtidas
15

Que ótimo saber! Você pode enviar um PR que o adicione a

16

Eu vou tentar. Não sou muito proficiente com o github, espero fazer isso bem.

Feito, fiz o PR, espero ter feito tudo certo.

1 curtida
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.