Descripción de los trabajos
Un trabajo es una acción que Autonomous Linux realiza en una o más instancias, como la instalación de actualizaciones o la asociación de orígenes de software. Cuando se ejecuta un trabajo, se crea una solicitud de trabajo que realiza las tareas necesarias para satisfacer el trabajo, distribuye el trabajo a las instancias e informa los resultados al servicio.
Un trabajo se puede ejecutar inmediatamente o puede definirlo para que se ejecute en una fecha y hora futuras, o como un evento recurrente. Se trata de un trabajo programado. Puede optar por reintentar automáticamente un trabajo programado en caso de fallo. Cuando se selecciona el reintento automático, si el trabajo programado falla en su primera ejecución, el servicio reintenta el trabajo programado hasta tres veces, cada cinco minutos de diferencia. Los trabajos programados también se pueden etiquetar.
Estado de trabajo programado
Los trabajos programados se encuentran en uno de los siguientes estados:
- Siguiente ejecución: fecha y hora en las que el trabajo está programado para su ejecución.
- Frecuencia: indica si el trabajo se ha definido para ejecutarse en un programa recurrente o si solo se ejecuta una vez.
- Destinos: identifica el número de instancias de destino para el trabajo.
Estado de Solicitud de Trabajo
Después de ser despachado como una solicitud de trabajo, un trabajo está en curso o finalizado.
- Las solicitudes de trabajo en curso informan de los siguientes valores de estado posibles:
- Aceptado: el servicio ha aceptado el trabajo y tiene el trabajo listo para las instancias. Si un agente no selecciona un trabajo y permanece en el estado aceptado durante 24 horas, el servicio marca el trabajo como fallido.
- En curso: un agente ha seleccionado el trabajo aceptado y lo está ejecutando en una instancia.
- Cancelando: el trabajo se está cancelando.
- Las solicitudes de trabajo finalizadas informan de los siguientes valores de estado posibles:
- Correcto: el trabajo se ha terminado sin errores.
- Con fallos: el trabajo presenta fallos.
- Cancelado: el trabajo se canceló.
Para ver los resultados detallados de un trabajo, vea el log del trabajo y los mensajes de error. Cuando un trabajo tiene una jerarquía, si falla algún trabajo secundario, el servicio marca el trabajo principal como fallido.
Nueva Ejecución de un Trabajo Fallido
Si un trabajo falla, puede volver a ejecutar el trabajo fallido en lugar de crear manualmente un nuevo trabajo para volver a intentar la acción fallida. Puede volver a ejecutar un trabajo fallido inmediatamente o programarlo para que se ejecute en una fecha y hora futuras. Al volver a ejecutar el trabajo, se crea una nueva solicitud de trabajo para la misma acción (como la aplicación de actualizaciones o la asociación de orígenes de software). El trabajo original y su estado permanecen sin cambios para fines de auditoría e históricos.
Para los trabajos de una jerarquía, puede volver a ejecutar el trabajo principal para volver a ejecutar todos los trabajos de la jerarquía o volver a ejecutar los trabajos secundarios individualmente. Cuando se vuelve a ejecutar un principal con fallos, el servicio sólo tiene como destino los trabajos secundarios con fallos. Por ejemplo, supongamos que tiene un grupo de diez instancias y un trabajo de actualización falla en tres de las instancias. Después de revisar el log de trabajo y los mensajes de error y abordar los problemas informados, puede volver a ejecutar el trabajo fallido para el grupo. La nueva ejecución solo tiene como destino las tres instancias que han experimentado el fallo original.
Trabajo programado restringido
Cada instancia de Autonomous Linux tiene un trabajo programado restringido con el tipo de actualización "Todo" que se ejecuta diariamente para mantener la instancia actualizada. Esto se denomina trabajo de actualizaciones autónomas. Puede editar la hora del día que se ejecuta el trabajo, pero no puede cambiar su frecuencia ni suprimir el trabajo.
Jerarquía de trabajos
Algunos trabajos se dividen en tareas más pequeñas. El servicio crea una jerarquía de puestos en la que el puesto inicial es el "principal" y las tareas más pequeñas son "secundarios". Para trabajos más grandes o trabajos que afectan a varias instancias, puede averiguar fácilmente qué tareas de un trabajo se han realizado correctamente o han fallado. Puede ver los trabajos secundarios en el separador Solicitudes de trabajo de la página de detalles del trabajo principal.
Por ejemplo, un trabajo de actualización 'Todo' crea trabajos secundarios para cada tipo de actualización: seguridad, corrección de bugs, mejora, otros.
--Update All (parent)
|--Update Security (child)
|--Update Bug fix (child)
|--Update Enhancement (child)
|--Update Other (child)Un trabajo reside en el mismo compartimento que su recurso asociado. Para los trabajos asociados a un grupo, esto puede significar que los trabajos principales y secundarios están en diferentes compartimentos. El trabajo principal reside en el compartimento asociado al grupo, mientras que los trabajos secundarios residen en el compartimento asociado a cada instancia. Consulte Consideraciones de compartimentos para conocer las mejores prácticas.
Por ejemplo, agregar un origen de software a un grupo con tres miembros produce un único trabajo principal con tres trabajos secundarios, uno para cada instancia.--Set software sources for dev group (parent in dev compartment)
|--Set software source Instance 1 (child in dev compartment)
|--Set software source Instance 2 (child in test compartment)
|--Set software source Instance 3 (child in preview compartment)