Perguntas frequentes sobre o Fedora CoreOS

Se você tiver outras perguntas além das mencionadas aqui ou quiser discutir mais, junte-se a nós em nossa sala Matrix #coreos:fedoraproject.org, ou em nosso fórum de discussão. Consulte aqui, pois algumas perguntas e respostas provavelmente serão atualizadas.

O que é 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.

Qual a relação do Fedora CoreOS com o RHEL CoreOS?

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.

Quais são os canais de comunicação sobre o 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.

Onde eu posso baixar o Fedora CoreOS?

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

O Fedora CoreOS se atualiza automaticamente?

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.

Como os nós do Fedora CoreOS são provisionados? Posso reutilizar configurações existentes de cloud-init?

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.

Quais dados persistem entre atualizações e reinicializações?

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.

Quais tempos de execução de contêiner estão disponíveis no Fedora CoreOS?

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.

Posso executar o Kubernetes no Fedora CoreOS?

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

Como executo aplicativos personalizados no Fedora CoreOS?

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.

Onde está minha ferramenta predileta para solução de problemas?

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.

Como coordeno atualizações do sistema operacional em todo o cluster?

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.

Como carrego o Fedora CoreOS em regiões privadas do AWS EC2?

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.

Posso executar contêineres via docker e podman ao mesmo tempo?

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.

Exemplo de configuração Butane para desabilitar o docker.service
variant: fcos
version: 1.5.0
systemd:
  units:
    - name: docker.service
      mask: true

As imagens de disco do Fedora CoreOS x86_64 híbrido BIOS+UEFI são inicializáveis?

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.

Qual a diferença entre as configurações do Ignition e do Butane?

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.

Qual é o formato do número da versão?

Isso é coberto em detalhes nos documentos de design.

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

  • X é a versão maior do Fedora (i.e 32)

  • Y é a data em que o pacote escolhido teve um snapshot no Fedora (i.e. 20200715)

  • Z é um código numérico utilizado por builds oficiais

    • 1 para o novo stream next

    • 2 para o fluxo testing

    • 3 para o fluxo stable

  • A é um número de revisão que é incrementado para cada nova build com os mesmos parâmetros X.Y.Z

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.

Por que a unidade systemd dnsmasq.service está mascarada?

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:

Exemplo de configuração Butane para desmascarar o dnsmasq.service
variant: fcos
version: 1.5.0
systemd:
  units:
    - name: dnsmasq.service
      mask: false
      enabled: true

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

Por que recebo negações do SELinux após as atualizações se tenho modificações na política local?

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:

Exemplo de negação do SELinux
systemd-resolved[755]: Failed to symlink /run/systemd/resolve/stub-resolv.conf: Permission denied
audit[755]: AVC avc:  denied  { create } for  pid=755 comm="systemd-resolve" name=".#stub-resolv.confc418434d59d7d93a" scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:systemd_resolved_var_run_t:s0 tclass=lnk_file permissive=0

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:

Exemplo de sistema com uma política modificada de SELinux
$ sudo ostree admin config-diff | grep selinux/targeted/policy
M    selinux/targeted/policy/policy.32

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:

Exemplo de configuração Butane para dinamicamente aplicar booleano SELinux
variant: fcos
version: 1.5.0
systemd:
  units:
    - name: setsebool.service
      enabled: true
      contents: |
        [Service]
        Type=oneshot
        ExecStart=setsebool container_manage_cgroup true
        RemainAfterExit=yes
        [Install]
        WantedBy=multi-user.target

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:

Exemplo de sistema com uma política modificada de SELinux
$ sudo ostree admin config-diff | grep selinux/targeted/policy
M    selinux/targeted/policy/policy.32

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

  • Reimplantar começando com os artefatos de imagem mais recentes.

    • Isso significa que você começa com a política mais recente.

  • Seguir a solução alternativa em coreos/fedora-coreos-tracker#701 para restaurar a política básica.

Por que a unidade systemd-repart.service systemd está mascarada?

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.