Actualizaciones Automáticas y Reversiones Manuales

Fedora CoreOS provides atomic updates and rollbacks via OSTree deployments.

De forma predeterminada, el SO lleva a cabo auto actualizaciones continuas por medio de dos componentes:

  • rpm-ostree maneja múltiples despliegues OSTree sobre el disco y puede conmutar entre ellos en el momento del arranque.

  • Zincati comprueba continuamente las actualizaciones de SO y las aplica por medio de rpm-ostree.

Cautela ante las actualizaciones

El agente local Zincati comprueba periódicamente el servicio remoto para ver cuando están disponibles las actualizaciones. Un valor personalizado de "rollout wariness" (vea documentación) se puede proporcionar para que el servidor sepa qué tan ansioso o averso al riesgo está el nodo para recibir actualizaciones.

El parámetro rollout_wariness se puede establecer con un valor de punto flotante entre 0.0 (más ansioso) y 1.0 (más conservador). Para recibir actualizaciones muy pronto en el ciclo de implementación por fases, se puede configurar un nodo con un valor bajo (e.g. 0.001). Esto se puede hacer durante el aprovisionamiento mediante el fragmento de configuración Butane que se muestra abajo:

Ejemplo: configurar la cautela de implementación de Zincati
variant: fcos
version: 1.5.0
storage:
  files:
    - path: /etc/zincati/config.d/51-rollout-wariness.toml
      contents:
        inline: |
          [identity]
          rollout_wariness = 0.001

Finalización de la actualización de SO

Para finalizar la actualización de un SO se debe reiniciar la máquina. Como esta es una acción invasiva que puede originar problemas en el servicio, Zincati permite al administrador del cluster controlar que nodos tienen permitido el reinicio para terminar la actualización.

Estas disponibles las siguiente estrategias de finalización:

  • As soon as the update is downloaded and staged locally, immediately reboot to apply an update.

  • Use an external lock-manager to coordinate the reboot of a fleet of machines.

  • Allow reboots only within configured maintenance windows, defined on a weekly UTC schedule.

A specific finalization strategy can be configured on each node.

The Butane snippet below shows how to define two maintenance windows during weekend days, starting at 22:30 UTC and lasting one hour each:

Example: configuring Zincati updates strategy
variant: fcos
version: 1.5.0
storage:
  files:
    - path: /etc/zincati/config.d/55-updates-strategy.toml
      contents:
        inline: |
          [updates]
          strategy = "periodic"
          [[updates.periodic.window]]
          days = [ "Sat", "Sun" ]
          start_time = "22:30"
          length_minutes = 60

For further details on updates finalization, check the Zincati documentation.

Retrocesos Manuales

Cuando una actualización está completa el anterior despliegue de SO permanece en el disco. Si una actualización causa problema usted puede utilizar el anterior como respaldo. Esta es una operación manual que requiere intervención humana y una consola de acceso.

Vuelta atrás temporal

Para arrancar temporalmente el anterior despliegue del sistema operativo pulse la tecla Mayús durante el proceso de arranque del sistema operativo. Cuando el menú del gestor de arranque aparezca, seleccione la entrada del SO en el menú.

Vuelta atrás permanente

Para volver permanentemente al anterior SO, acceda en el nodo objetivo y ejecute los siguientes comandos:

# Parar el servicio que lleva a cabo las actualizaciones automáticas
sudo systemctl stop zincati.service

# Marcar el anterior sistema operativo como el predeterminado e inmediatamente reiniciar en él
sudo rpm-ostree rollback -r

Tenga en cuenta que Zincati se mantendrá buscando actualizaciones y mejoras en cualquier nuevo SO disponible, distinto al que usted ha vuelto.

Si lo prefiere, puede apagar temporalmente las actualizaciones automáticas. Más tarde, las puede volver a poner en marcha para permitir que la máquina vuelva con el flujo usual de actualizaciones:

# Deshabilitar Zincati para optar por no recibir actualizaciones automáticas en el futuro
sudo systemctl disable --now zincati.service

[...]

# En un punto posterior, volver a habilitarlo para que se alinee con el flujo de actualziaciones
sudo systemctl enable --now zincati.service