Perguntas frequentes sobre o Fedora CoreOS

If you have other questions than are mentioned here or want to discuss further, join us in our Libera.Chat IRC channel, #fedora-coreos, or on our discussion board. Please refer back here as some questions and answers will likely get updated.

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. O objetivo é combinar o melhor do CoreOS Container Linux e do Fedora Atomic Host, integrando tecnologia como Ignition do Container Linux com rpm-ostree e proteção SELinux do Project Atomic. 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 Red Hat CoreOS?

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

O Fedora CoreOS substitui o Container Linux? O que acontece com o CL?

O Fedora CoreOS é o sucessor oficial do CoreOS Container Linux, mas não é um substituto imediato. O CoreOS Container Linux alcançará seu fim de vida em 26 de maio de 2020 e não receberá mais atualizações após essa data. Para notas sobre a migração do Container Linux para o Fedora CoreOS, consulte o guia de migração.

O Fedora CoreOS substitui o Fedora Atomic Host? O que acontece com o Fedora Atomic Host e o CentOS Atomic Host?

O Fedora CoreOS é o sucessor oficial do Fedora Atomic Host. O último lançamento do Fedora Atomic Host foi a versão 29, que chegou ao fim de vida.

O CentOS Atomic Host continuará produzindo recompilações de downstream do RHEL Atomic Host e se alinhará com o final de vida. O projeto Fedora CoreOS será o ponto de consolidação das distribuições da comunidade. Os usuários são incentivados a se mudar para lá no futuro.

O que acontece com o Project Atomic?

O Project Atomic é um projeto abrangente que consiste em dois tipos de Atomic Host (Fedora e CentOS), além de vários outros projetos relacionados a contêineres. O projeto Atomic como nome do projeto será desativado até o final de 2018, com um foco individual mais forte em projetos bem-sucedidos, como Buildah e Cockpit. Isso mescla o lado da comunidade do sistema operacional de forma mais eficaz com o Fedora e permite uma comunicação mais clara para outros projetos apoiados pela comunidade, especificamente a bem adotada abordagem #nobigfatdaemons do Buildah e o versátil gerenciador gráfico de servidores Cockpit.

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.

FAQ técnico

Onde eu posso baixar o Fedora CoreOS?

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

O Fedora CoreOS adota a filosofia de atualização do Container Linux?

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. Ele apresenta um novo 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. Falhas que impedem a inicialização de uma atualização serão revertidas automaticamente.

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. No entanto, as configurações existentes do Ignition exigirão alterações, pois a configuração do sistema operacional será diferente do Container Linux. 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.

Como faço para migrar do Container Linux para o Fedora CoreOS?

As migrações podem ser realizadas provisionando novamente a máquina com o Fedora CoreOS. Para notas sobre a migração do Container Linux para o Fedora CoreOS, consulte o guia de migração.

Como migrar do Fedora Atomic Host para o Fedora CoreOS?

Como no Container Linux, a melhor prática é provisionar novamente o nó, pelo menos devido à transição cloud-init/Ignition. Como o Fedora CoreOS usa a tecnologia rpm-ostree, pode ser possível fazer uma nova conversão do Fedora Atomic Host para o Fedora CoreOS, mas isso não é recomendado. É preferível ganhar experiência na implantação de sistemas usando o Ignition, para que eles possam ser provisionados novamente facilmente, se necessário. Para notas sobre a migração do Atomic Host para o Fedora CoreOS, consulte o guia de migração.

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.

Quais plataformas têm suporte ao Fedora CoreOS?

Fedora CoreOS funciona em pelo menos

  • Alibaba Cloud,

  • AWS,

  • Azure,

  • GCP,

  • OpenStack,

  • QEMU,

  • VMware,

  • e sistemas diretamente no hardware, se instalados em disco ou inicializados em rede.

Posso executar o Kubernetes no Fedora CoreOS?

Sim. No entanto, visualizamos o Fedora CoreOS como não incluindo um orquestrador de contêineres específico (ou versão do Kubernetes) por padrão – assim como o Container Linux e o Atomic Host. Trabalharemos com a comunidade upstream do Kubernetes em ferramentas (por exemplo, kubeadm) e práticas recomendadas para instalar o Kubernetes no Fedora CoreOS.

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 coordenar atualizações de sistema operacional em todo o cluster? O locksmith ou o Container Linux Update Operator está disponível para o Fedora CoreOS?

O recurso etcd-lock de locksmith foi diretamente portado para o Zincati, como uma estratégia de travamento de atualizações. Também foi melhorada para suportar múltiplos backends, não sendo mais restrito ao etcd2.

As capacidades do Container Linux Update Operator (CLUO) foram embarcadas dentro do Machine Config Operator (MCO), que é um componente vital do 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. Fizemos isso para facilitar a transição para os usuários do Container Linux.

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.4.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?

This is covered in detail in the design docs.

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.4.0
systemd:
  units:
    - name: dnsmasq.service
      mask: false
      enabled: true

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

Por que o SSH para de funcionar após a atualização para o Fedora 33?

No Fedora 33, houve uma mudança para implementar padrões de criptografia mais fortes. Parte disso incluiu seguir o conselho of OpenSSH upstream e desabilitar o uso do algoritmo de assinatura de chave pública ssh-rsa.

Você pode ter problemas se usar chaves RSA e:

  • usar uma versão antiga do cliente SSH

  • usar bibliotecas de ferramentas/software que não oferecem suporte ao uso de assinaturas de chave pública RSA SHA2

Por exemplo, Go tem um relatório de problema aberto para resolver esse problema em sua implementação SSH, mas ainda não resolveu. Isso foi alcançado e contornado pela comunidade FCOS em nossas ferramentas de construção e também em nossos projetos de nível superior:

Se você se deparar com esse problema e precisar contorná-lo, você tem algumas opções:

  • Mudar para um tipo de chave não RSA mais recente.

  • Fornecer uma configuração para sua máquina que reative as assinaturas de chave inseguras:

Exemplo de configuração Butane para habilitar novamente assinaturas RSA SHA1 de chaves SSH
variant: fcos
version: 1.4.0
storage:
  files:
    - path: /etc/ssh/sshd_config.d/10-insecure-rsa-keysig.conf
      mode: 0600
      contents:
        inline: |
          PubkeyAcceptedKeyTypes=+ssh-rsa

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.4.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.