Introducción a Fedora Atomic Workstation
BastiánTraducción libre al español del artículo "An Introduction to Fedora Atomic Workstation" escrito por Jonathan Lebon el 6-febrero-2018.
Para los últimos lanzamientos de Fedora, el grupo de investigación para la estación de trabajo (Workstation WG) ha estado ocupado en combinar lo mejor del modelo del Proyecto Atomic con la Edición Fedora Workstation en una "Fedora Atomic Workstation". En Fedora 27, hemos llegado a un punto en el que nos sentimos cómodos invitando a otros desarrolladores y entusiastas a probarlo e incluso hacerlo su estación de uso diario.
Siga leyendo para descubrir qué es Fedora Atomic Workstation, cuáles son sus beneficios y cómo puede comenzar hoy!
Nota: esta entrada del blog se basa en una charla que di en DevConf.cz 2018. Dirígete a YouTube si prefieres escucharlo.
¿Qué es Atomic Workstation?
Al igual que Atomic Host, Atomic Workstation utiliza RPM-OSTree como su gestor de actualizaciones. Sin embargo, Atomic Workstation está orientada a todos los mismos casos de uso que la edición Workstation regular debe cumplir. Aunque hay algunas diferencias entre los dos, más allá del modelo de actualización.
En una Atomic Workstation, las aplicaciones de escritorio se distribuyen y ejecutan como flatpaks, y el desarrollo ocurre principalmente dentro de contenedores. Por ejemplo, puede tener un contenedor preformateado con su entorno de desarrollo configurado, así como un oc cluster up para OpenShift en el desarrollo de aplicaciones para servidor.
¿Porqué debería usar Atomic Workstation?
¿Cuáles son las ventajas de esta estrategia? Muchas de las siguientes razones son compartidas con Atomic Host. Aunque intentaré dar un punto de vista más centrado en la estación de trabajo.
1- Actualizaciones Transaccionales
La razón principal para utilizar Atomic Workstation, por supuesto, son las actualizaciones transaccionales. Esto es tan relevante en el caso del servidor como para el escritorio. La mayoría de la gente consideraría sus estaciones de trabajo como el sistema estereotipo: instalación y personalización tal como lo quieren, y un enorme obstáculo a la productividad si algo le sucede. Por lo tanto, el uso de un modelo de actualización que reduzca en gran medida los riesgos de fallos está bien justificado.
No me quedaré en este tema más tiempo ya que asumo que los lectores de este blog están familiarizados con los beneficios y las trampas que el modelo Atomic nos ayuda a evitar. Si no está familiarizado con estas ideas, consulte definitivamente los documentos de OSTree y los documentos de actualización del Proyecto Atomic si desea obtener más información.
2- Inmutabilidad y Aislamiento
Como se discutió en una entrada de blog anterior, todas las grandes características de un sistema basado en OSTree requieren inmutabilidad del sistema operativo base. Por ejemplo, /usr está protegido para escritura por defecto. Esto es igualmente cierto tanto para Atomic Workstation como en Atomic Host. Esto es bueno, porque (1)te protege de daños accidentales y (2)fomenta un flujo de trabajo más saludable.
Por ejemplo, en sistemas gestionados por yum/dnf, los scriptlets de RPM se ejecutan sin restricciones como root durante las transacciones de actualización, lo que abre la puerta a la corrupción accidental (o intencionada). En los sistemas administrados por rpm-ostree, todos los scriptlets se ejecutan en el servidor al componer la actualización. (Como se menciona más abajo, también soportamos capas adicionales de RPMs; sus scriptlets se ejecutan en un contenedor bloqueado y no pueden afectar al sistema en ejecución).
Al ejecutar sus aplicaciones como flatpaks y desarrollar a través de contenedores, no sólo ayuda a proteger su sistema operativo base de daños, sino que también minimiza el número de paquetes que se interponen entre usted y un arranque exitoso.
Basar su flujo de trabajo al desarrollar en contenedores preformateados, podría garantizar un blog propio. En DevConf.cz se han llevado a cabo grandes conversaciones en esta área este año (enlace al final).
3- Seguimiento de cambios sin esfuerzo
Ahora, parte de la personalización de su estación de trabajo requerirá sin duda la instalación de paquetes que no son parte de la base OSTree y que no son adecuados para la contenedorización (p. ej. controladores, paquetes de virtualización, $EDITOR_FAVORITO). Debido a que RPM-OSTree es un modelo híbrido, entiende tanto las RPM como los OSTrees. Podemos, por ejemplo, hacer rpm-ostree install vim-enhanced libvirt-client para añadir paquetes adicionales. Así rpm-ostree se mostrará entonces:
$ rpm-ostree status State: idle Deployments: ● faw27:fedora/27/x86_64/workstation Version: 27.62 (2018-01-31 21:39:54) BaseCommit: a052d7482a186f1979f8bba90cfe1a1d0c13e75a43a416b580d2f2a83c18fe5a GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4 LayeredPackages: libvirt-client vim-enhanced
A diferencia de los sistemas gestionados por yum/dnf, que proporcionan un enfoque de "conjunto de paquetes", rpm-ostree status permite saber exactamente lo que hemos cambiado desde la confirmación de OSTree base, y cómo volver al estado inicial (en este caso, rpm-ostree uninstall libvirt-client vim-enhanced).
Para complementar, mencionaré que RPM-OSTree no sólo soporta adiciones puras, sino que también reemplaza y elimina paquetes base. Todos estos cambios pueden ser rastreados igualmente en rpm-ostree status y revertirse fácilmente.
Adicionalmente, debido a que en el modelo OSTree los valores por defecto de configuración se almacenan en /usr/etc, también se puede realizar una simple comparación para saber qué valores por defecto se han cambiado (por ejemplo diff /usr/etc /etc | less).
4- Pruebas de flujo ascendente (upstream)
El hecho de que las actualizaciones se entreguen como unidades concretas permite al proveedor de contenido probarlas más fácilmente, lo que se traduce en un sistema operativo más estable para los usuarios finales. En contraste, es efectivamente imposible en el enfoque de "conjunto de paquetes" probar sanamente todas las combinaciones posibles. Esto significa sobre todo que las pruebas se limitan a nivel de paquete.
En el modelo OSTree, sin embargo, es posible acceder a actualizaciones sobre pruebas de integración de alto nivel como las que hemos estado haciendo en las versiones de dos semanas de Fedora Atomic Host. Tenga en cuenta, sin embargo, que las actualizaciones de Atomic Workstation no están siendo puestas al día actualmente por estar en pruebas; todavía estamos en el inicio de estas discusiones.
5- Actualizaciones Automáticas
En RPM-OSTree, estamos trabajando en añadir una función de actualización automática. Funcionalidad similar en sistemas con dnf que ya existe. La diferencia es que el modelo OSTree nos permite eliminar o minimizar muchos de los problemas involucrados en tal esquema. Por ejemplo, la capacidad de revertir las actualizaciones es crítica aquí, y esto es algo que RPM-OSTree hace con facilidad.
En el futuro, nos gustaría llegar a un punto en el que (si está habilitado) el sistema prepare automáticamente las actualizaciones en segundo plano y "actualizar" simplemente implica reiniciar el equipo para reducir al mínimo el tiempo de inactividad.
¿Cómo puedo empezar con Atomic Workstation?
Puede descargar la ISO y volver a instalar desde cero, o puede convertir su sistema existente basado en dnf usando los pasos de este documento. Este último también le permite cambiar entre los dos modelos si aún no está listo para sumergirse.
Una vez iniciado en Atomic Workstation, vea la sección "Usando el sistema" aquí. Para obtener más información sobre cómo administrar las actualizaciones, consulte los documentos del proyecto Atomic y los documentos RPM-OSTree.
Si necesitas ayuda, puedes entrar en el canal freenode/#atomic, o enviar un email a la lista de correo atomic-devel.