Domande frequenti su Fedora CoreOS

Fedora CoreOS è un sistema operativo monolitico, minimale e incentrato sui container, che si aggiorna automaticamente, progettato per cluster ma utilizzabile anche in modo autonomo, ottimizzato per Kubernetes ma efficace anche senza di esso. Il suo obiettivo è fornire il miglior host per eseguire workload containerizzati in modo sicuro e su larga scala.

Fedora CoreOS è una distribuzione di comunità liberamente disponibile, che rappresenta la base upstream di RHEL CoreOS. Mentre Fedora CoreOS abbraccia una varietà di casi d’uso containerizzati, RHEL CoreOS fornisce un sistema operativo focalizzato per OpenShift, rilasciato e mantenuto in parallelo con la piattaforma.

Fedora Bootc è un progetto Fedora mirato alla creazione di container avviabili basati su Fedora e CentOS. L’obiettivo è che Fedora CoreOS venga costruito su Fedora Bootc, sia letteralmente che in senso più ampio come parte dello stesso ecosistema. La roadmap per questo si trova su GitHub.

Fedora CoreOS aggiunge un modello di stream, integrazione specifica per piattaforma e immagini disco, provisioning tramite Ignition e ulteriori strumenti per gli aggiornamenti automatici. L’obiettivo è anche che Fedora CoreOS si integri più strettamente con l’ecosistema Kubernetes.

Se ti trovi nella necessità di personalizzare pesantemente Fedora CoreOS oltre quanto offerto dalle estensioni del sistema operativo, potrebbe avere più senso costruire direttamente su Fedora Bootc. Alla fine sarà possibile stratificare Ignition e, ad esempio, Zincati sopra se lo si desidera. Questi strumenti sono pensati per essere utilizzati in modo generico e non sono strettamente vincolati a Fedora CoreOS.

Quali sono i canali di comunicazione di Fedora CoreOS:

C’è una riunione della comunità che si svolge ogni settimana. Consulta il Fedora CoreOS fedocal per le informazioni più aggiornate.

Se pensi di aver trovato un problema con Fedora CoreOS, segnala un issue nel nostro issue tracker.

Gli artefatti di Fedora CoreOS sono disponibili su fedoraproject.org.

Sì, Fedora CoreOS è dotato di aggiornamenti automatici e rilasci regolari. Vengono forniti più canali di aggiornamento per soddisfare le diverse esigenze degli utenti. Fedora CoreOS fornisce un servizio di aggiornamento dei nodi basato sulle tecnologie rpm-ostree, con un componente server che può essere eventualmente self-hosted.

Fedora CoreOS viene approvvigionato con Ignition. Le configurazioni cloud-init esistenti non sono supportate e dovranno essere migrate nella loro equivalente di Ignition.

Le directory /etc e /var sono montate in modalità lettura-scrittura, il che consente agli utenti di scrivere e modificare file.

La directory /etc può essere modificata dalle distribuzioni, ma non sovrascriverà le modifiche apportate dall’utente. Il contenuto di /var non viene toccato da rpm-ostree durante l’applicazione di aggiornamenti o rollback. Per ulteriori informazioni, consultare la sezione Filesystem Montati.

Fedora CoreOS include Docker e podman per impostazione predefinita. Sulla base del coinvolgimento e del supporto della comunità, questo elenco potrebbe cambiare nel tempo.

Sì. Tuttavia, Fedora CoreOS non include per impostazione predefinita uno specifico orchestratore di container (o versione di Kubernetes).

Su Fedora CoreOS, i container sono il modo per installare e configurare qualsiasi software non fornito dal sistema operativo di base. Il meccanismo di stratificazione dei pacchetti fornito da rpm-ostree continuerà a esistere per l’uso nel debug di una macchina Fedora CoreOS, ma ne sconsigliamo vivamente l’utilizzo. Per maggiori informazioni, si prega di fare riferimento alla documentazione.

The FCOS image is kept minimal by design. Not every troubleshooting tool is included by default. Instead, it is recommended to use the toolbox utility.

Debugging with Toolbx.

The Zincati update manager includes a lock-based updates strategy that supports multiple backends.

OKD’s Machine Config Operator (MCO) automatically handles updates of Fedora CoreOS in OKD clusters. The MCO additionally covers reconciliation of machine configuration changes.

Fedora CoreOS today is only uploaded to the standard AWS regions. For regions in other AWS partitions like GovCloud and AWS China, you must upload the images yourself.

Note that Fedora CoreOS uses a unified BIOS/UEFI partition layout. As such, it is not compatible with the aws ec2 import-image API (for more information, see related discussions). Instead, you must use aws ec2 import-snapshot combined with aws ec2 register-image.

To learn more about these APIs, see the AWS documentation for importing snapshots and creating EBS-backed AMIs.

No. Running containers via docker and podman at the same time can cause issues and unexpected behavior. We highly recommend against trying to use them both at the same time.

It is worth noting that in Fedora CoreOS we have docker.service disabled by default but it is easily started if anything communicates with the /var/run/docker.sock because docker.socket is enabled by default. This means that if a user runs any docker command (via sudo docker) then the daemon will be activated.

In coreos/fedora-coreos-tracker#408 it was pointed out that because of socket activation users who are using podman for containers could unintentionally start the docker daemon. This could weaken the security of the system because of the interaction of both container runtimes with the firewall on the system. To prevent making this mistake you can disable docker completely by masking the docker.service systemd unit.

The x86_64 images we provide can be used for either BIOS (legacy) boot or UEFI boot. They contain a hybrid BIOS/UEFI partition setup that allows them to be used for either. The exception to that is the metal4k 4k native image, which is targeted at disks with 4k sectors and does not have a BIOS boot partition because 4k native disks are only supported with UEFI.

Ignition configuration is a low-level interface used to define the whole set of customizations for an instance. It is primarily meant as a machine-friendly interface, with content encoded as JSON and a fixed structure defined via JSON Schema. This JSON configuration is processed by each FCOS instance upon first boot.

Many high-level tools exist that can produce an Ignition configuration starting from their own specific input formats, such as terraform, matchbox, openshift-installer, and Butane.

Butane is one such high-level tool. It is primarily meant as a human-friendly interface, thus defining its own richer configuration entries and using YAML documents as input. This YAML configuration is never directly processed by FCOS instances (only the resulting Ignition configuration is).

Although similar, Ignition configurations and Butane ones do not have the same structure; thus, converting between them is not just a direct YAML-to-JSON translation, but it involves additional logic. Butane exposes several customization helpers (e.g. distribution specific entries and common abstractions) that are not present in Ignition and make the formats not interchangeable. Additionally, the different formats (YAML for Butane, JSON for Ignition) help to avoid mixing up inputs by mistake.

This is covered in detail in the design docs.

The summary is that Fedora CoreOS uses the format X.Y.Z.A

The version numbering scheme is subject to change and is not intended to be parsed by machine.

We have found that the dnsmasq binary can be used for several host applications, including podman and NetworkManager. For this reason we include the dnsmasq package in the base OSTree layer, but we discourage the use of the dnsmasq.service in the host by masking it with systemctl mask dnsmasq.service.

"Why do you mask the service?"

dnsmasq is useful for running a DHCP/DNS/TFTP server for external clients (i.e. not local to the host), too, but that is something we’d prefer users to do in a container. Putting the service in a container insulates the hosted service from breakage as a result of host layer changes. For example, if NetworkManager and podman stopped using dnsmasq, we would remove it from the host and the service you depend on would cease to work.

"But, I really want to use it!"

We don’t recommend it, but if you really want to use it you can just unmask and enable it:

For more information see the tracker issue discussion.

systemd-repart is a tool to grow and add partitions to a partition table. On Fedora CoreOS, we only support using Ignition to create partitions, filesystems and mount points, thus systemd-repart is masked by default.

Ignition runs on first boot in the initramfs and is aware of Fedora CoreOS specific disk layout. It is also capable of reconfiguring the root filesystem (from xfs to ext4 for example), setting up LUKS, etc…​ See the Configuring Storage page for examples.

See the Why is the dnsmasq.service systemd unit masked entry for an example config to unmask this unit.

Some Wi-Fi firmwares were split into subpackages in Fedora 39 and Fedora 40. Fedora CoreOS 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.