Preguntas Más Frecuentes de Fedora CoreOS

Fedora CoreOS es un sistema operativo minimalista, monolítico y de actualización automática, centrado en contenedores. Está diseñado para clústeres, pero también es compatible con Kubernetes, aunque también es excelente sin él. Su objetivo es proporcionar el mejor host de contenedores para ejecutar cargas de trabajo en contenedores de forma segura y a escala.

Fedora CoreOS está disponible libremente, distribución de la comunidad que es la base río arriba para RHEL CoreOS. Mientras Fedora CoreOS acoge una variedad de casos de uso contenidos, RHEL CoreOS proporciona un SO enfocado para OpenShit, liberado y ciclo de vida en tándem con la plataforma.

Fedora Bootc es un proyecto de Fedora dirigido en compilación de Fedora y basados en contenedores arrancables de CentOS. El objetivo es llegar a tenere construido Fedora CoreOS en la cima de Fedora Bootc ambos literalmente y en el sentimiento hermano de ser parte del mismo ecosistema. La hoja de ruta se encuentra en GitHub.

Fedora CoreOS añade un modelo de flujo, integración específica de plataforma e imágenes de disco, proporcionando vía Ignition, y más herramientas alrededor de actualizaciones automáticas. El objetivo es también tener integrado Fedora CoreOS más fuertemente con el ecosistema Kubernetes.

Si se encuentra necesario personalizar fuertemente Fedora CoreOS más allá que las extensiones de SO proporcionadas, podría tener más sentido en vez de construir en la cima directamente el Bootc de Fedora. Eventualmente será posible cubrir Ignition y p.e. Zincati en la cima si deseado. Estas herramientas están intentadas ser utilizadas genéricamente y no son atadas estrictamentes a Fedora CoreOS.

Tenemos la siguiente comunicación de canales nuevos alrededor de Fedora CoreOS:

Hay un encuentro de la comunidad que sucede cada semana. Consulte el calendario de Fedora CoreOS para la información del más actual.

Si piensa que ha encontrado un problema con Fedora CoreOS, envíe un problema en nuestro seguimiento de problemas.

Los artefactos de Fedora CoreOS están disponibles en fedoraproject.org.

Sí, Fedora CoreOS viene con actualizaciones automáticas y liberaciones usuales. Se ofrecen múltiples canales de actualización que responden a las necesidades de los distintos usuarios. Fedora CoreOS proporciona un servicio de nodo-actualizado basado en tecnologías de rpm-ostree, con un componente servidor que puede ser auto-hospedado opcionalmente.

Fedora CoreOS está provisto con Ignition. Existiendo configuraciones de nube-init no están admitidas y necesitará ser migrada a su equivalente de Ignition.

Los directorios /etc y /var están montados como lectura-escritura lo cual permite a los usuarios escribir y modificar archivos.

El directorio /etc puede modificarse mediante implementaciones, pero no anulará los cambios realizados por el usuario. Rpm-ostree no modifica el contenido de /var al aplicar actualizaciones o reversiones. Para obtener más información, consulte la sección Sistemas de archivos montados.

Fedora CoreOS incluye Docker y podman por defecto. Basados en reconocimiento de la comunidad y mantiene este listado pudo cambiar a lo largo del tiempo.

Sí. Sin embargo, Fedora CoreOs no incluye un organizador específico contenedor (o versión de Kubernetes) por defecto.

En Fedora CoreOS, los contenedores son la forma de instalar y configurar cualquier software no proporcionado por el sistema operativo base. El mecanismo de capas de paquetes proporcionado por rpm-ostree seguirá existiendo para su uso en la depuración de una máquina Fedora CoreOS, pero desaconsejamos enfáticamente su uso. Para obtener más información sobre esto, consulte documentación.

La imagen FCOS es mantenida mínimal por diseño. No cada herramienta de solución de problemas está incluida por defecto. En su lugar, es recomendado utilizar la herramienta toolbox.

Depuración con Toolbx.

El gesto de actualización Zincati incluye un estrategia de actualizaciones de base bloqueada que admite múltiples backends.

OKD’s Configuración de Máquina Operador (MCO) automáticamente manipula actualizaciones de Fedora CoreOS en racimos OKD. El MCO adicionalmente cubre reconciliación de cambios de configuración de máquina.

Hoy Fedora CoreOS solo es subido a las regiones estándar de AWS. Para regiones en otras particiones AWS como GovCloud y AWS China, debe subir las imágenes usted mismo.

Tenga en cuenta que Fedora CoreOS utiliza una distribución unificada de particiones BIOS/UEFI. Como tal, no es compatible con el API de aws ec2 import-image (para más información, consulte discusiones relacionadas). En su lugar, debe utilizar aws ec2 import-snapshot combinado con aws ec2 register-image.

Para aprender más sobre estas API, consulte la documentación de AWS en importar instantáneas y creación de AMI respaldadas por EBS.

No. Ejecutar contenedores mediante docker y podman simultáneamente puede causar problemas y un comportamiento inesperado. Recomendamos encarecidamente no intentar usarlos simultáneamente.

Cabe destacar que en Fedora CoreOS, docker.service está deshabilitado por defecto, pero se inicia fácilmente si cualquiera se comunica con /var/run/docker.sock, ya que docker.socket está habilitado por defecto. Esto significa que si un usuario ejecuta cualquier comando docker (mediante sudo docker), el demonio será activado.

En coreos/fedora-coreos-tracker#408 fue apuntado fuera que debido a activación de zócalo utiliza quien está utilizando podman para contenedores pudo no intencionalmente iniciar el demonio de docker. Esto pudo debilitar la seguridad del sistema porque debido a la interacción de ambos tiempo de ejecución de ambos contenedores con el cortafuegos en el sistema. Para prevenir hacer esta equivocación puede deshabilitar docker completamente enmascarando la unidad de docker.service de systemd.

Las imágenes x86_64 que proporcionamos pueden utilizarse tanto para el arranque BIOS (heredado) como para el arranque UEFI. Contienen una configuración de partición híbrida BIOS/UEFI que permite usarlas para cualquiera de los dos. La excepción a esto es la imagen metal4k 4k nativa, que está dirigida a discos con sectores de 4k y no tiene una partición de arranque BIOS porque los discos nativos 4k son admitidos solo con UEFI.

La configuración de encendido es una interfaz de bajo nivel que se utiliza para definir todo el conjunto de personalizaciones para una instancia. Está pensado principalmente como una interfaz amigable para máquinas, con contenido codificado como JSON y una estructura fija definida a través del esquema JSON. Cada instancia de FCOS procesa esta configuración JSON durante el primer arranque.

Existen muchas herramientas de alto nivel que pueden producir una configuración de Ignition a partir de sus propios formatos de entrada específicos, tal como terraform, matchbox, openshift-installer, y Butane.

Butane es una de esas herramientas de alto nivel. Su principal objetivo es ofrecer una interfaz intuitiva, por tanto definiendo sus propios apuntes de configuración más completos y utiliza documentos YAML como entrada. Esta configuración YAML nunca es procesada directamente por las instancias de FCOS (solo se procesa la configuración de Ignition resultante).

Aunque similares, las configuraciones de encendido y las de butano no tienen la misma estructura; por lo tanto, la conversión entre ellos no es solo una traducción directa de YAML a JSON, sino que implica lógica adicional. Butane expone varias herramientas de personalización (por ejemplo, entradas específicas de distribución y abstracciones comunes) que no están presentes en Ignition y hacen que los formatos no sean intercambiables. Además, los diferentes formatos (YAML para butano, JSON para encendido) ayudan a evitar mezclar entradas por error.

Este tema se trata en detalle en los documentos de diseño.

En resumen es que Fedora CoreOS utiliza el formato X.Y.Z.A

El esquema de numeración de versiones está sujeto para cambiar y no está pensado para ser interpretado automáticamente.

Hemos descubierto que el binario dnsmasq se puede utilizar para varias aplicaciones de host, incluidas podman y NetworkManager. Por este motivo incluimos el paquete dnsmasq en la capa base OSTree, pero desaconsejamos el uso de dnsmasq.service en el huesped enmascarándolo con systemctl mask dnsmasq.service.

"¿Por qué enmascaran el servicio?"

dnsmasq también es útil para ejecutar un servidor DHCP/DNS/TFTP para clientes externos (es decir, no locales del host), pero es algo que preferiríamos que los usuarios hicieran en un contenedor. Colocar el servicio en un contenedor lo protege de interrupciones causadas por cambios en la capa del host. Por ejemplo, si NetworkManager y podman dejaran de usar dnsmasq, lo eliminaríamos del host y el servicio del que depende dejaría de funcionar.

"Pero, ¡realmente quiero utilizarlo!"

No lo recomendamos, pero si realmente desea utilizarlo puede tan solo desenmascarar y activarlo:

Para otra información consulte la discusión del seguimiento de problemas.

Actualmente, las herramientas OSTree y SELinux entran un poco en conflicto. Si ha aplicado permanentemente modificaciones de política local, las actualizaciones de política proporcionadas por el sistema operativo ya no se aplicarán; su política permanecerá congelada. Esto significa que no se aplicarán las «correcciones» necesarias para habilitar las nuevas funciones. Consulte coreos/fedora-coreos-tracker#701 para más detalles.

Esto significa que puede ver denegaciones como las siguientes, que pueden hacer caer partes críticas de un sistema como en coreos/fedora-coreos-tracker#700:

Para ver si su sistema tiene modificaciones de normativa local actualmente puede ejecutar ostree admin config-diff. El siguiente sistema tiene una normativa modificada:

Para evitar esta incompatibilidad, intente aplicar modificaciones de normativa dinámicamente. Por ejemplo, para un booleano SELinux puede utilizar la unidad del siguiente systemd que ejecuta en cada arranque:

Si la funcionalidad básica de su sistema ha dejado de funcionar debido a denegaciones de SELinux, verifique si su sistema actualmente tiene modificaciones de política local. Puede comprobarlo con ostree admin config-diff:

Si su sistema está dentro de este estado tiene dos opciones:

system-repart es una herramienta para crecer y añadir particiones a una tabla de partición. En Fedora CoreOS, solo admitimos utilizar Ignition para crear particiones, sistemas de archivos y puntos de montado, por tanto systemd-repart está enmascarado por defecto.

Ignition ejecuta en el primer arranque en el initramfs y conoce el diseño de disco específico de Fedora CoreOS. También es capaz de reconfigurar el sistema de archivos raíz (de xfs a ext4 por ejemplo), configurar LUKS, etc…​ Consulte la página Configuración de almacenamiento para ver ejemplos.

Consulte el xref:faq.adoc#_why_is_the_dnsmasq_service_systemd_unit_masked[Por qué está enmascarado el apunte de la unidad systemd de dnsmasq.service para un ejemplo de configuración para desenmascarar esta unidad.

Algunos firmwares Wi-Fi se dividieron en subpaquetes en Fedora 39 y Fedora 40. Fedora CoreOS los mantendrá hasta Fedora 41, pero mostrará un mensaje de advertencia en la consola que indica que NetworkManager-wifi está en capas sin ningún otro paquete de firmware Wi-Fi en capas.

Para solicitar que el firmware Wi-Fi permanezca instalado incluso cuando Fedora CoreOS elimine estos paquetes, siga el procedimiento de pasos para realizar la habilitación Wi-Fi en un sistema existente.

Una vez solicitados los paquetes, ahora puedes desactivar la advertencia para que no se marque en los arranques posteriores.