Lightwhale 3: tornando os servidores Linux divertidos novamente

 (lightwhale.asklandd.dk)
4 pontos por GN⁺ 3 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Um sistema operacional de servidor Linux projetado exclusivamente para contêineres Docker; basta inicializar pela ISO para entrar diretamente em um ambiente com Docker Engine
  • Mantém o sistema central em uma estrutura imutável e sem estado, separando /etc, /var, /home e os dados do Docker em áreas de escrita dedicadas, reduzindo bastante o trabalho de instalação e configuração inicial
  • O sistema de arquivos de dados padrão é um armazenamento volátil baseado em tmpfs; ao ativar a persistência, ele detecta automaticamente um dispositivo de armazenamento separado, faz particionamento, formatação e montagem, e pode até ser configurado com Btrfs RAID1 se necessário
  • Usa uma raiz somente leitura baseada em squashfs e componentes mínimos para reduzir a superfície de exposição a malware ou modificações acidentais, além de diminuir o uso de recursos e o consumo de energia
  • Exclusivo para x86-64, funciona em bare metal e máquinas virtuais, permitindo focar imediatamente na execução de contêineres e em operações de self-hosting, em vez da administração do servidor em si

Visão geral

  • É um sistema operacional de servidor Linux projetado exclusivamente para contêineres Docker; ao iniciar a ISO em modo live, você entra diretamente em um ambiente com Docker Engine
  • Para reduzir a carga de instalação e configuração inicial, o sistema central permanece imutável, enquanto dados e personalizações do usuário ficam separados em áreas de armazenamento dedicadas
  • Mira desde homelabs, bare metal, ambientes virtualizados, nós de edge e clusters, mas a arquitetura suportada é limitada a x86-64
  • Prioriza uma composição mínima e facilidade de uso, fazendo com que o foco fique na execução e operação dos contêineres, e não na administração do servidor

Principais características

  • Funciona no estilo plug and play: basta baixar a ISO e inicializar para ter imediatamente um Docker Engine pronto com as ferramentas necessárias
  • Minimiza os componentes para reduzir a curva de aprendizado e permitir entender rapidamente o funcionamento do sistema
  • Usa um núcleo imutável e sem estado para reduzir a superfície de exposição a malware e alterações acidentais, iniciando sempre no mesmo estado
  • Oferece persistência opcional; o sistema de arquivos de dados padrão é o tmpfs volátil em RAM, e ao ativá-la o sistema detecta automaticamente um dispositivo de armazenamento separado, faz particionamento, formatação e montagem
  • Reduz processos desnecessários para diminuir uso de recursos e consumo de energia, ajudando a prolongar a vida útil de hardware antigo ou de baixo desempenho
  • Facilita o self-hosting, ajudando a se desvincular da dependência de Big Tech e a gerenciar diretamente seus dados e sua privacidade

Como começar

  • Basta baixar a ISO mais recente ou uma imagem na seção de downloads, gravá-la em um USB e inicializar
  • Em alguns sistemas, pode ser necessário desativar o safe boot no BIOS antes de iniciar
  • O login padrão usa nome de usuário op e senha opsecret; antes de expor o sistema à internet, o mínimo necessário é trocar a senha
  • O Wi‑Fi pode ser configurado opcionalmente com setup-wifi
  • A execução de contêineres é igual ao uso normal do Docker; o exemplo fornecido é docker run -it --rm busybox ps
  • Ao ativar a persistência, é preciso gravar o magic header em um dispositivo de bloco, não em uma partição; esse processo apaga os dados existentes

Estrutura de boot e execução

  • A ISO pode iniciar em bare metal e máquinas virtuais, com suporte tanto a UEFI quanto a BIOS tradicional
  • O processo de inicialização usa um sistema init semelhante ao sysv para manter um fluxo de boot simples e transparente
  • O bootloader carrega o kernel Linux e o sistema de arquivos raiz na memória, depois o kernel inicializa o hardware e transfere o controle para /init
  • O init lê /etc/inittab, monta tmpfs para /tmp e /run e então executa os scripts em /etc/init.d
  • No início, o data filesystem é montado para fornecer os dados do Docker e a camada superior de escrita do overlay de /etc, /var e /home
  • Depois que todos os sistemas de arquivos e overlays estão prontos, os demais serviços são iniciados, e a partir desse ponto os contêineres já podem ser atendidos

Projeto de imutabilidade

  • O sistema de arquivos raiz é fornecido como uma imagem estática compactada squashfs, com uma estrutura que não pode ser modificada diretamente
  • Graças a isso, o software e as configurações essenciais já vêm incluídos, formando uma imagem autossuficiente e inicializável sem processo de instalação
  • Evita gerenciador de pacotes, gerenciamento de dependências e disputas com atualizações de sistemas convencionais, substituindo o trabalho de reinstalar algo que já funciona por um simples reboot
  • Os arquivos do sistema de arquivos raiz não podem ser apagados acidentalmente nem modificados por vírus, e o sistema não expõe kernel e binários básicos como tradicionalmente mutáveis
  • Por ser uma raiz somente leitura, evita o acúmulo de bagunça que costuma surgir em operações de longo prazo e prejudicar backups, desempenho e organização
  • É possível testar livremente em uma VM local ou em outro computador e desfazer alterações com um reboot
  • O meio de boot não contém informações importantes e, como a imutabilidade preserva esse estado, mesmo que o dispositivo seja danificado ou perdido, é possível recuperar com uma nova cópia

Estrutura de persistência

  • Instalar e executar contêineres, alterar configurações e gravar dados exige um sistema de arquivos gravável; para manter isso após reinicializações, é necessária persistência
  • Um subsistema executado automaticamente no início do boot monta o data filesystem em /mnt/lightwhale-data
  • Os dados gravados pelo Lightwhale ficam em /mnt/lightwhale-data/lightwhale-state, e esse diretório se torna a camada superior gravável do overlayfs
  • O padrão é o tmpfs volátil; ao ativar a persistência, o data filesystem passa a ficar em um dispositivo de armazenamento separado
  • Em vez de sobrepor a raiz inteira, apenas /etc, /var e /home recebem overlay seletivo, preservando o propósito da imutabilidade
    • /etc é usado para personalizações de configuração do sistema, como rede, senha e sshd
    • /var é usado para logs e outros dados de aplicações
    • /home é usado para personalizações do usuário, como chaves SSH autorizadas, clonagem de repositórios Git e gerenciamento de stacks Docker/Swarm
  • O data root do Docker fica diretamente em /mnt/lightwhale-data/lightwhale-state/docker, armazenando o estado de imagens, contêineres, volumes e redes

Ativação da persistência e etapas automáticas

  • A persistência só é ativada explicitamente ao gravar um magic header em um dispositivo de armazenamento, como em echo "lightwhale-please-format-me" | sudo dd conv=notrunc of=/dev/sdx
  • É possível gravar o magic header em vários dispositivos de armazenamento; nesse caso, eles são combinados em um volume Btrfs RAID1
  • No boot seguinte, o sistema detecta os discos mágicos, formata-os e os usa como data filesystem
  • O subsistema de persistência é iniciado em /etc/init.d/S11persistence

  • Detecção do sistema de arquivos de dados

    • Examina todos os discos em busca de partições com o rótulo de sistema de arquivos lightwhale-data
    • Se encontrar, usa esse sistema de arquivos como data filesystem e pula para a etapa de montagem

  • Detecção de magic disks e criação de partições

    • Identifica magic disks procurando a sequência de bytes lightwhale-please-format-me no início do disco
    • Em cada magic disk, cria uma partição swap com rótulo lightwhale-swap e uma partição Linux com rótulo lightwhale-data usando todo o espaço restante

  • Criação do sistema de arquivos

    • As partições swap mágicas são formatadas e recebem o rótulo lightwhale-swap
    • Se houver apenas uma partição de dados mágica, ela é formatada com btrfs --data single --metadata dup
    • Se houver várias, elas são agrupadas em RAID1 e formatadas com btrfs --data raid1 --metadata raid1cn
    • São criados os subvolumes @lightwhale-data, @lightwhale-state e @lightwhale-state-snapshots

  • Montagem e configuração de overlay

    • Se houver data filesystem, @lightwhale-data é montado em /mnt/lightwhale-data; caso contrário, monta-se tmpfs no lugar
    • A camada inferior imutável faz bind mount de /etc em /run/lightwhale/overlay/lower/etc e espelha a árvore de diretórios do sistema de arquivos raiz para preparação
    • A camada superior gravável é preparada em caminhos como /mnt/lightwhale-data/lightwhale-state/overlay/upper/etc
    • Em seguida, o overlayfs combina as duas camadas e as monta em /etc, repetindo o mesmo processo para /var e /home

Restrições e principais pontos do FAQ

  • O hardware suportado é exclusivamente x86-64, com suporte a BIOS e EFI
  • Raspberry Pi ainda não é suportado e está no backlog
  • Apple M-series não tem suporte em bare metal, mas pode rodar virtualizado
  • Pode ser executado em ambientes virtuais como VMWare/ESX/Proxmox/cloud e inclui agentes convidados para QEMU/KVM e VMware ESXi
  • O software só pode ser instalado como contêiner Docker; não é possível instalar diretamente no sistema de arquivos raiz
  • O sistema central é imutável, mas configurações, personalizações e dados dos contêineres são gravados em memória por padrão e só permanecem após reboot quando a persistência é ativada
  • O hostname padrão inclui o machine ID para evitar conflitos de rede, e ao alterá-lo com setup-hostname a mudança entra em vigor imediatamente, exceto no shell atual
  • Não há garantia, e a responsabilidade pelos resultados do uso é do usuário
  • Não segue a direção de adicionar ferramentas preferidas como wget ou nano ao sistema de arquivos raiz, mantendo a proposta de um SO de servidor mínimo e especializado em um objetivo
  • O TL;DR da política de privacidade diz que não coleta dados pessoais e só coleta dados anônimos se você consentir com a telemetria; além disso, é possível revisar exatamente o que é coletado
  • A conformidade com regulamentações relacionadas à idade não é responsabilidade do SO em si, mas dos serviços do usuário implantados sobre ele

Links relacionados

Leituras relacionadas

1 comentários

 
GN⁺ 3 일 전
Comentários do Hacker News

  • É de se comemorar quando alguém realmente lança alguma coisa, mas ainda não está claro por que eu deveria usar isso
    Já existem alternativas com objetivo parecido, como Flatcar Container Linux, Fedora CoreOS, Talos Linux e IncusOS, e elas parecem ter comunidade ou apoio comercial mais sólidos
    Seria preciso explicar com mais clareza o que torna isso diferente para convencer

    • Uso IncusOS no meu homelab, e a experiência de configuração e uso é realmente muito boa
      Migrei do Proxmox e hoje gerencio todas as VMs com ele, usando bastante assistentes de código para automatizar a configuração da CLI do IncusOS, converter imagens Docker-Compose para Incus e escrever scripts bash para subir novos contêineres sem dor de cabeça mesmo usando --dangerously-skip-permissions
      O melhor é que dá para gerenciar tudo com arquivos declarativos, então a configuração de rede e os recursos ficam sempre bem visíveis
      Para um uso parecido, vale dar uma olhada no IncusOS
    • Ferramentas assim normalmente levam horas de configuração, mas a diferença aqui é que você só dá boot e já sai usando

  • Enquanto existir software, não dá para pular a manutenção
    Não existe software sem bugs, e dizer que não há necessidade nenhuma de upgrades, patches ou administração costuma ser o caminho mais curto para um sistema comprometido

    • Não acho que esse OS esteja dizendo que não exige manutenção
      Está mais para reduzir boa parte da manutenção típica de um sistema base tradicional, por dois motivos: 1) quase nada vem instalado e 2) o upgrade da base é simples, então basta reiniciar e subir os contêineres de novo
      Claro que o software que roda por cima ainda precisa de atualização, mas, se for baseado em Docker, essa camada normalmente já é gerenciada em outro lugar, então basta baixar o novo contêiner e reiniciar; o papel do OS é mais garantir que os dados sejam montados sempre no mesmo lugar
      Se você acha aceitável rodar todo o software em Docker, isso parece um passo além de Debian ou Redhat, com menos complexidade procedural do que CoreOS
      Ainda tenho dúvidas sobre o quão agradável é usar isso na prática, especialmente na parte de gerenciamento de armazenamento, mas pelo menos está muito claro o que eles querem vender
    • Venho falando isso há anos
      Self-hosting é possível, mas você acaba assumindo na prática um SLA também no seu tempo livre fora do expediente
      Por isso já faz muito tempo que eliminei tudo que atende mais de 1 usuário
    • Claro, nada é totalmente livre de bugs
      Ainda assim, existe um motivo para projetos como Talos existirem
      Sem terminal, sem SSH, sem gerenciador de pacotes, com sistema de arquivos somente leitura, sem systemd e com o mínimo possível de executáveis, a superfície de ataque realmente diminui
      Não estou falando especificamente do projeto apresentado aqui, mas sistemas mais seguros e que exigem menos manutenção de fato existem
      Como nunca será possível chegar a 100% de segurança, isso não significa que a resposta seja sair aceitando no YOLO um pacote npm alterado 3 minutos atrás

  • É interessante, mas fiquei curioso sobre como funcionam os patches, os upgrades e a construção da própria ISO
    Mesmo olhando o repositório-fonte, quase nada disso fica visível

    The actual repository here hosts the source code for Lightwhale, and is not of any interest for most people.

    https://bitbucket.org/asklandd/lightwhale/src/master/

    • O repositório parece estar desatualizado
      O último commit foi há 2 anos, e aparentemente não há código-fonte da versão 3.0

  • Isso não é um OS, e sim uma distro Linux?

    • Se não for uma distro Linux, então eu gostaria de saber o que seria um OS

  • Sinto que ainda sou quase iniciante nessa área, mas faço self-hosting há mais de 10 anos e por volta de 2019 migrei para Unraid
    Como ele é centrado em portal web, sempre achei fácil de usar e simples de manter
    Fiquei curioso sobre como se interage com esse OS para home server
    Como não há imagens no site, fico pensando se é tudo feito de forma baseada em terminal

  • Acabei de instalar Docker com uma linha no Ubuntu Server e comecei a usar na hora, então ainda não entendi exatamente o que muda aqui nem qual é a proposta de valor
    Também queria entender o que exatamente querem dizer com manutenção, e se é um servidor mais enxuto para rodar em hardware menos potente
    Estou começando agora a montar um home server, então quero sinceramente entender quais seriam as vantagens

    • Eu faço exatamente a mesma coisa
      Dizem que a vantagem da abordagem immutable está nas atualizações: você muda para a nova versão da imagem e, se der problema, pode simplesmente dar boot na versão anterior para reverter
      Mas, funcionalmente, eu também sinto que Ubuntu Server já basta
      Faço apt update e upgrades algumas vezes por ano, e o acesso é apenas local ou via Tailscale
      Esses OSes immutable me parecem mais atraentes para notebooks ou desktops do que para home servers
      Como só o diretório home fica gravável, há a expectativa de que o OS seja mais estável e mais difícil de quebrar

  • Fiquei curioso sobre qual seria a forma recomendada de fazer backup regular dos dados dos contêineres que rodam no Lightwhale

  • Não entendo muito bem
    Se a ideia é só rodar Docker, não vejo por que precisar de algo immutable, nem por que seria necessária uma variação especial de Debian em vez de Debian ou Ubuntu, onde dá para subir Docker em poucos minutos
    Também me parece que a manutenção já é algo resolvido pelo gerenciador de pacotes, usando os repositórios da própria distro ou o repositório oficial do Docker
    Eu realmente gostaria que essa moda do immutable passasse, assim como flatpak e snap
    O Linux já fazia originalmente o que essas soluções dizem resolver
    O usuário não consegue mexer no sistema base sem root, e as aplicações podem instalar dependências em /usr/lib

    • Para mim, uma combinação de Debian stable com podman/Docker já é immutable o suficiente
      E, se alguma coisa der errado, a facilidade de conseguir ajuda também é uma grande segurança
      Talvez dê para deixar ainda menor, mas isso já roda bem até em hardware estranho como BananaPi de baixo custo ou RISC-V baratinho, então quase nunca surge motivo para querer outra coisa

  • Esse tipo de coisa parece combinar bem com um cluster em Swarm mode
    Não sei se o foco é só home server, mas vou continuar acompanhando
    O projeto parece muito bom

    • No momento estamos divulgando mais para o lado de home server porque é onde as pessoas se sentem mais à vontade para experimentar
      Mas o Lightwhale já está rodando em produção e também se encaixa muito bem em clusters Swarm

  • Parece extremamente limpo
    Do ponto de vista de um iniciante, é exatamente o tipo de abordagem que eu preciso para não estragar a configuração, então com certeza vou testar