Perguntas frequentes sobre o Fedora CoreOS

O Fedora CoreOS é um sistema operacional com atualização automática, mínimo, monolítico e focado em contêiner, projetado para clusters, mas também operável de forma independente, otimizado para o Kubernetes, mas também excelente sem ele. Seu objetivo é fornecer o melhor host de contêiner para executar cargas de trabalho em contêiner com segurança e em escala.

O Fedora CoreOS é uma distribuição comunitária disponível livremente, que é a base de upstream do RHEL CoreOS. Enquanto o Fedora CoreOS abraça uma variedade de casos de uso em contêiner, o RHEL CoreOS fornece um sistema operacional focado para o OpenShift, lançado e com ciclo de vida em conjunto com a plataforma.

Fedora Bootc is a Fedora project aimed at building Fedora and CentOS-based bootable containers. The goal is to eventually have Fedora CoreOS build on top of Fedora Bootc both literally and in the broader sense of being part of the same ecosystem. The roadmap for this can be found on GitHub.

Fedora CoreOS adds a stream model, platform-specific integration and disk images, provisioning via Ignition, and more tooling around automatic updates. The goal is also to have Fedora CoreOS integrate more strongly with the Kubernetes ecosystem.

If you find yourself needing to heavily customize Fedora CoreOS beyond what OS extensions provide, it might make more sense to instead build on top of Fedora Bootc directly. It will eventually be possible to layer Ignition and e.g. Zincati on top if desired. These tools are intended to be used generically and are not strictly tied to Fedora CoreOS.

Temos os seguintes novos canais de comunicação sobre o Fedora CoreOS:

Esse é um encontro da comunidade que acontece toda semana. Veja o fedocal do Fedora CoreOS para informações mais atualizadas.

Se você acredita que encontrou um problema com o Fedora CoreOS, preencha um relatório em nosso rastreador de problemas.

Artefatos do Fedora CoreOS estão disponíveis em fedoraproject.org.

Sim, o Fedora CoreOS vem com atualizações automáticas e lançamentos regulares. Vários canais de atualização são fornecidos, atendendo às necessidades de diferentes usuários. Fedora CoreOS fornece um serviço de atualização de nó baseado nas tecnologias rpm-ostree, com um componente de servidor que pode ser opcionalmente hospedado em seu próprio servidor.

O Fedora CoreOS é fornecido com o Ignition. As configurações existentes de cloud-init não são suportadas e precisam ser migradas para o equivalente no Ignition.

Os diretórios /etc e /var são montados como leitura-escrita, o que permite que usuários escrevam e modifiquem os arquivos.

O diretório /etc pode ser alterado por implantações, mas não vai sobrescrever alterações feitas pelos usuários. O conteúdo em /var é deixado intocado por rpm-ostree ao aplicar atualizações ou reversões. Para mais informações, confira a seção Sistemas de arquivos montados.

O Fedora CoreOS inclui Docker e podman por padrão. Com base no envolvimento e no apoio da comunidade, esta lista pode mudar com o tempo.

Sim. No entanto, o Fedora CoreOS não inclui um orquestrador de contêiner específico (ou versão do Kubernetes) por padrão.

No Fedora CoreOS, os contêineres são o caminho para instalar e configurar qualquer software não fornecido pelo sistema operacional básico. O mecanismo de divisão em camadas de pacotes fornecido pelo rpm-ostree continuará a existir para uso na depuração de uma máquina Fedora CoreOS, mas desencorajamos fortemente seu uso. Para mais informações, consulte a documentação.

A imagem FCOS é mantida mínima por design. Nem todas as ferramentas de solução de problemas são incluídas por padrão. Ao invés disso, é recomendado o uso da ferramenta toolbox.

Depurando com Toolbx.

O gerenciador de atualizações Zincati inclui uma estratégia de travamento de atualizações que oferece suporte para múltiplos backends.

O Machine Config Operator (MCO) do OKD cuida automaticamente de atualizações do Fedora CoreOS em clustes OKD. O MCO cobre (adicionalmente) a reconciliação com mudanças na configuração da máquina.

Hoje, o Fedora CoreOS é carregado apenas nas regiões padrão da AWS. Para regiões em outras partições da AWS, como GovCloud e AWS China, você deve fazer o upload das imagens.

Note que o Fedora CoreOS usa um layout de partição BIOS/UEFI unificado. Como tal, não é compatível com a API aws ec2 import-image (para obter mais informações, consulte discussões relacionadas). Em vez disso, você deve usar o aws ec2 import-snapshot combinado com o aws ec2 register-image.

Para saber mais sobre estas APIs, veja a documentação da AWS para importação de snapshots e criação de AMIs por EBS.

Não. A execução de contêineres através de docker e podman ao mesmo tempo pode causar problemas e comportamento inesperado. É altamente recomendável não tentar usá-los ao mesmo tempo.

Vale ressaltar que no Fedora CoreOS temos o docker.service desativado por padrão, mas é facilmente iniciado se algo se comunica com o`/var/run/docker.sock` porque o docker.socket está ativado por padrão. Isso significa que se um usuário executar qualquer comando docker (via sudo docker), o daemon será ativado.

Em coreos/fedora-coreos-tracker#408, foi apontado que, devido à ativação de soquetes, os usuários que estão usando o podman para contêineres podem, involuntariamente, iniciar o daemon do docker. Isso pode enfraquecer a segurança do sistema devido à interação dos dois tempos de execução do contêiner com o firewall no sistema. Para evitar este erro, você pode desativar completamente o docker mascarando a unidade systemd do docker.service.

As imagens x86_64 que fornecemos podem ser usadas para inicialização BIOS (legado) ou inicialização UEFI. Eles contêm uma configuração de partição híbrida BIOS/UEFI que permite que sejam usados para ambos. A exceção é a imagem nativa 4k metal4k, que é direcionada a discos com setores de 4k e não tem uma partição de inicialização de BIOS porque os discos nativos de 4k são compatível apenas com UEFI.

A configuração do Ignition é uma interface de baixo nível usada para definir todo o conjunto de personalizações para uma instância. Ele foi criado principalmente como uma interface amigável à máquina, com conteúdo codificado como JSON e uma estrutura fixa definida via JSON Schema. Esta configuração JSON é processada por cada instância FCOS na primeira inicialização.

Existem muitas ferramentas de alto nível que podem produzir uma configuração do Ignition a partir de seus próprios formatos de entrada específicos, como terraform, matchbox, openshift-installer e Butane.

O Butane é uma dessas ferramentas de alto nível. Ele foi criado principalmente como uma interface amigável, definindo assim suas próprias entradas de configuração mais ricas e usando documentos YAML como entrada. Esta configuração YAML nunca é processada diretamente por instâncias FCOS (apenas a configuração Ignition resultante é).

Embora semelhantes, as configurações do Ignition e as do Butane não têm a mesma estrutura; portanto, a conversão entre eles não é apenas uma tradução direta de YAML para JSON, mas envolve lógica adicional. O Butane expõe vários auxiliares de personalização (por exemplo, entradas específicas da distribuição e abstrações comuns) que não estão presentes no Ignition e tornam os formatos não intercambiáveis. Além disso, os diferentes formatos (YAML para Butane, JSON para Ignition) ajudam a evitar misturar entradas por engano.

Isso é coberto em detalhes nos documentos de design.

O resumo é que o Fedora CoreOS usa o formato X.Y.Z.A

O esquema de numeração de versões é algo a ser alterado e não tem a intenção de ser analisado pela máquina.

Descobrimos que o binário dnsmasq pode ser usado para vários aplicativos host, incluindo podman e NetworkManager. Por esta razão, incluímos o pacote dnsmasq na camada OSTree base, mas desencorajamos o uso do dnsmasq.service no host mascarando-o com systemctl mask dnsmasq.service.

"Por que você mascara o serviço?"

O dnsmasq também é útil para executar um servidor DHCP/DNS/TFTP para clientes externos (ou seja, não local para o host), mas isso é algo que preferimos que os usuários façam em um contêiner. Colocar o serviço em um contêiner isola o serviço hospedado de falhas como resultado de mudanças na camada do host. Por exemplo, se o NetworkManager e o podman parassem de usar o dnsmasq, nós o removeríamos do host e o serviço do qual você depende deixaria de funcionar.

"Mas eu realmente quero usá-lo!"

Não o recomendamos, mas se você realmente deseja usá-lo, basta desmascará-lo e habilitá-lo:

Para mais informações, veja a discussão no rastreador de problemas.

Atualmente, as ferramentas OSTree e SELinux entram em conflito um pouco. Se você aplicou modificações de política local permanentemente, as atualizações de política fornecidas pelo sistema operacional não serão mais aplicáveis; sua política permanece congelada. Isso significa que quaisquer "correções" de política necessárias para habilitar a nova funcionalidade não serão aplicadas. Veja coreos/fedora-coreos-tracker#701 para mais detalhes.

Isso significa que você pode ver negações como as seguintes, que podem derrubar partes críticas de um sistema como em coreos/fedora-coreos-tracker#700:

Para ver se seu sistema atualmente tem modificações de política local, você pode executar ostree admin config-diff. O sistema a seguir tem uma política modificada:

Para contornar essa incompatibilidade, tente aplicar as modificações de política dinamicamente. Por exemplo, para um booleano SELinux, você pode usar a seguinte unidade systemd que é executada a cada inicialização:

Se a funcionalidade básica do seu sistema parou de funcionar devido às negações do SELinux, verifique se o seu sistema atualmente tem modificações de política local. Você pode verificar com ostree admin config-diff:

Se o seu sistema estiver neste estado, você tem duas opções:

system-repart é uma ferramenta para aumentar e adicionar partições a uma tabela de partição. No Fedora CoreOS, só suportamos o uso do Ignition para criar partições, sistemas de arquivos e pontos de montagem, portanto, o systemd-repart é mascarado por padrão.

O Ignition é executado na primeira inicialização no initramfs e está ciente do layout de disco específico do Fedora CoreOS. Ele também é capaz de reconfigurar o sistema de arquivos raiz (de xfs para ext4, por exemplo), configurar LUKS, etc …​ Veja a página Configurando o armazenamento para exemplos.

Consulte a entrada Por que a unidade systemd dnsmasq.service está mascarada? para obter um exemplo de configuração para desmascarar esta unidade.

Some Wi-Fi firmwares were split into subpackages in Fedora 39 and Fedora 40. Fedora CoresOS will keep them in until Fedora 41, but display a warning message in the console if NetworkManager-wifi is layered without any other Wi-Fi firmware packages layered.

To request the Wi-Fi firmware stay installed even when Fedora CoreOS drops these packages please follow the steps to perform Wi-Fi enablement on an existing system.

Once the packages are requested you can now disable the warning so it won’t be checked on subsequent boots.