Crear definiciones de trabajos mediante ECSProperties - AWS Batch

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Crear definiciones de trabajos mediante ECSProperties

Si utiliza las definiciones de trabajo de AWS Batch con EcsProperties, puede modelar el hardware, los sensores, los entornos 3D y otras simulaciones en contenedores separados. Puede utilizar esta característica para organizar de forma lógica los componentes de la carga de trabajo y separarlos de la aplicación principal. Esta característica se puede usar en AWS Batch con Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) y AWS Fargate.

ContainerProperties frente a las definiciones de trabajo de EcsProperties

Puede utilizar las definiciones de trabajo ContainerProperties o EcsProperties según lo requiera su caso de uso. A un nivel superior, ejecutar trabajos de AWS Batch con EcsProperties es similar a ejecutar trabajos con ContainerProperties.

La estructura de definición de trabajos heredada, que utiliza ContainerProperties, sigue siendo compatible. Si actualmente tiene flujos de trabajo que utilizan esta estructura, puede seguir ejecutándolos.

La principal diferencia es que se ha añadido un objeto nuevo a la definición del trabajo para dar cabida a las definiciones basadas en EcsProperties.

Por ejemplo, una definición de trabajo que usa ContainerProperties en Amazon ECS y Fargate tiene la siguiente estructura:

{ "containerProperties": { ... "image": "my_ecr_image1", ... }, ... }

Una definición de trabajo que usa EcsProperties en Amazon ECS y Fargate tiene la siguiente estructura:

{ "ecsProperties": { "taskProperties": [{ "containers": [ { ... "image": "my_ecr_image1", ... }, { ... "image": "my_ecr_image2", ... },

Cambios generales en las API de AWS Batch

A continuación, se describen más detalladamente algunas de las principales diferencias entre el uso de EcsProperties y los tipos de datos de la API de EcsProperties:

Definiciones de trabajo en varios contenedores para Amazon ECS

Para adaptarse a la estructura de varios contenedores de Amazon ECS, algunos de los tipos de datos de API son diferentes. Por ejemplo:

  • ecsProperties tiene el mismo nivel que containerProperties en la definición de contenedor único. Para obtener más información, consulte EcsProperties en la Referencia de la API de AWS Batch.

  • taskProperties contiene las propiedades definidas para la tarea de Amazon ECS. Para obtener más información, consulte EcsProperties en la Referencia de la API de AWS Batch.

  • containers incluye información similar a la de containerProperties en la definición de contenedor único. La principal diferencia es que containers permite definir hasta diez contenedores. Para obtener más información, consulta ECSTaskProperties:containers en la Guía de referencia de la API de AWS Batch.

  • El parámetro essential indica cómo afecta el contenedor al trabajo. Todos los contenedores esenciales deben completarse correctamente (salir como 0) para que el trabajo progrese. Si un contenedor marcado como esencial falla (sale con un valor distinto de 0), el trabajo fallará.

    El valor predeterminado es true, y al menos un contenedor debe estar marcado como essential. Para obtener más información, consulte essential en la Guía de referencia de la API de AWS Batch.

  • Con el parámetro dependsOn, puede definir una lista de dependencias de contenedores. Para obtener más información, consulte dependsOn en la Guía de referencia de la API de AWS Batch.

    nota

    La complejidad de la lista de dependsOn y el tiempo de ejecución del contenedor asociado pueden afectar a la hora de inicio del trabajo. Si las dependencias tardan mucho en ejecutarse, el trabajo permanecerá en el estado STARTING hasta que se complete.

Para obtener más información sobre ecsProperties y la estructura, consulte la sintaxis de solicitud RegisterJobDefinition para ecsProperties.

Definiciones de trabajos con varios contenedores para Amazon EKS

Para adaptarse a la estructura de varios contenedores de Amazon EKS, algunos de los tipos de datos de API son diferentes. Por ejemplo:

  • name es un único identificador para el contenedor. Este objeto no es necesario para un único contenedor, pero sí para definir varios contenedores en un pod. Si name no está definido para contenedores individuales, se aplica el nombre predeterminado, default.

  • initContainers se definen en el tipo de datos eksPodProperties. Se ejecutan antes que los contenedores de aplicaciones, siempre hasta completarse, y deben completarse correctamente antes de que se inicie el siguiente contenedor.

    Estos contenedores están registrados en el agente Amazon EKS Connector y conservan la información de registro en el almacén de datos de backend de Amazon Elastic Kubernetes Service. El objeto initContainers puede aceptar hasta diez elementos. Para obtener más información, consulte Contenedores init en la documentación de Kubernetes.

    nota

    El objeto initContainers puede afectar a la hora de inicio del trabajo. Si los initContainers tardan mucho en ejecutarse, el trabajo mantendrá el estado STARTING hasta que se complete.

  • shareProcessNamespace indica si los contenedores del pod pueden compartir el mismo espacio de nombres del proceso. El valor predeterminado es false. Configúrelo en true para permitir que los contenedores vean y señalen los procesos de otros contenedores que se encuentran en el mismo pod.

  • Todos los contenedores son importantes. Todos los contenedores deben completarse correctamente (salir como 0) para que el trabajo se complete correctamente. Si un contenedor falla (sale con un valor distinto de 0), se produce un error en el trabajo.

Para obtener más información sobre eksProperties y la estructura, consulte la sintaxis de solicitud RegisterJobDefinition para eksProperties.