Esta publicación es parte de una serie de publicaciones de blog sobre mi beca Garden Linux.
Ver el publicación introductoria para el contexto.

Mi beca está llegando a su fin y me gustaría utilizar esta publicación de blog para resumir mis aprendizajes y discutir el potencial futuro.

Ya expliqué lo que hace OSTree en la primera publicación de esta serie, pero como mi comprensión ha mejorado durante los últimos meses, me gustaría abordarlo de otra manera.

Los sistemas operativos basados ​​en OSTree tienen un local repositorio. Por diseño, esto es bastante similar a un repositorio de git. El repositorio contiene nuestras confirmaciones, archivos, directorios y metadatos. Normalmente esto se encuentra en /ostree/repo.

Nuestro repositorio se ve más o menos así:

Los archivos que forman parte de nuestra imagen (es decir, nuestro sistema de archivos raíz de Linux) se almacenan dentro del objects directorio, direccionado por su suma sha256. Suponiendo que tenemos tres confirmaciones/implementaciones en nuestra máquina local y todas ellas contienen la misma versión de bashsólo tendremos una única copia del bash binario en nuestro sistema, identificado por su suma sha. Al arrancar, dependiendo de la implementación que seleccionemos, el sistema de archivos raíz representado por una confirmación se montará como sistema de archivos raíz. En este ejemplo, para bash Obtendremos exactamente el mismo binario, pero para otros archivos habrá versiones diferentes.

Suponiendo que obtengamos un nuevo compromiso/implementación __3__ que contiene una versión actualizada de bash, esto dará como resultado un nuevo archivo binario con una suma sha diferente. Cuando nos inician en el __3__ implementación, obtendremos la versión más nueva de bash, si por alguna razón necesitamos iniciar una confirmación anterior, también obtendremos la versión anterior de bash nuevamente.

Al igual que git, OSTree tiene el concepto de controles remotos. A diferencia de git, normalmente no redactaremos nuevas confirmaciones en nuestra máquina local, sino que serán creadas mediante un trabajo de CI. Las nuevas confirmaciones normalmente incluirán una versión actualizada de nuestro sistema de archivos raíz que nos proporcionará actualizaciones de seguridad y otras correcciones. Nuestros repositorios locales se actualizarán desde ese control remoto. Las nuevas confirmaciones estarán pendientes hasta que nuestros clientes se reinicien la próxima vez, que es cuando las nuevas confirmaciones se iniciarán automáticamente y nuestro sistema se actualizará.

Así es como se ve realizar una actualización en la línea de comando. Puedes ver que nuestro sistema comienza con un solo compromiso. 9e4e. Nuestro control remoto tiene un nuevo compromiso. 85f8 disponible. La confirmación más reciente se está descargando e implementando.

Podemos ver la relación padre/hijo entre esas confirmaciones cuando miramos el registro.

Y podemos inspeccionar qué archivos se han cambiado, agregado o eliminado entre ambas confirmaciones. Esto puede resultar útil cuando necesitamos una lista de materiales de software (SBOM) para nuestros nodos, por ejemplo, si se hace público un nuevo problema de seguridad y queremos asegurarnos de que todos nuestros nodos en ejecución tengan la versión parcheada de algún componente en uso.

En el próximo reinicio, el nuevo compromiso 85f8 Se iniciará de forma predeterminada y nuestro sistema se actualizará.

Recursos recomendados

Los siguientes recursos me parecieron útiles para explicar esto y algunos de mis dibujos se inspiraron en las diapositivas:

Los sistemas basados ​​en imágenes están (naturalmente) limitados en cuanto a su personalización. Por ejemplo, si estaba interesado en utilizar las imágenes que he creado como parte de este proyecto, está limitado por la selección que he incluido en las imágenes. Esto podría funcionar para su caso de uso, pero lo más probable es que tenga otros requisitos.

Para resolver esto, puede crear su propio repositorio OStree e imagen de disco con configuraciones personalizadas. Esto le permite alojar un repositorio remoto personalizado y ser independiente del repositorio proporcionado por Garden Linux.

Para hacerlo, deberá configurar las siguientes variables antes de crear su repositorio y su imagen de disco:

El proceso completo para construir tu propio sistema está documentado en GitHub.

Mi objetivo para el curso de la beca era ver cómo se puede construir un sistema Garden Linux basado en OSTree y qué beneficios podría proporcionar. Este objetivo se logra y el resultado está disponible como software de código abierto. en GitHub y estoy muy feliz con el resultado.

Como ocurre con cada proyecto, existen múltiples extensiones posibles del alcance. Estas son las que me parecen plausibles:

Siéntase libre de comentar sobre cualquiera de esos temas, o tal vez incluso contribuir con un PR que aborde cualquiera de ellos si lo desea.

Esta es la última publicación de esta serie ya que mi beca está llegando a su fin. Me gustaría agradecer a todos los que me apoyaron para hacer esto, ha sido una gran experiencia y estoy muy agradecido de haber tenido la oportunidad de hacerlo.

Continuaré trabajando en Garden Linux y escribiré publicaciones de blog cuando haya temas interesantes.

Si está interesado en el tema, no dude en comentar esta publicación de blog o comunicarse conmigo en LinkedIn.