Resolución de errores de tamaño de trabajo superado

En este artículo se describe cómo resolver los errores JobSizeExceededException y DeploymentJobSizeExceededException. Los errores de tamaño de trabajo excedido pueden producirse al implementar un archivo Bicep o una plantilla de Azure Resource Manager (plantilla de ARM).

Síntoma

Al implementar una plantilla, recibe un error que indica que la implementación ha superado los límites.

Causa

Este error se produce cuando la implementación supera los límites de tamaño permitidos. Normalmente aparece cuando la plantilla o el trabajo de implementación son demasiado grandes. Tenga en cuenta que las plantillas se comprimen antes de comprobar sus tamaños para la implementación, por lo que los límites efectivos pueden ser mayores que el tamaño real de la plantilla.

El límite de tamaño del trabajo de implementación es de 1 MB después de la compresión, incluidos los metadatos sobre la solicitud. En el caso de las plantillas grandes, el tamaño combinado de los metadatos y la plantilla puede superar este límite.

El propio tamaño de plantilla comprimido no puede ser superior a 4 MB y cada definición de recurso individual no puede ser superior a 1 MB después de la compresión. Estos límites se aplican al estado final de la plantilla después de la expansión de las definiciones de recursos que usan bucles para crear varias instancias, lo cual incluye valores resueltos para todas las variables y parámetros.

Otros límites de la plantilla son los siguientes:

• 256 parámetros
• 256 variables
• 800 recursos (incluido el recuento de copia)
• 64 valores de salida
• 24 576 caracteres en una expresión de plantilla

Solución 1: Reducir el tamaño de los nombres

Bicep

Intente acortar la longitud de los nombres que utiliza para parámetros, variables y salidas. Cuando estos valores se repiten en bucles, un nombre largo se multiplica muchas veces.

JSON

Intente acortar la longitud de los nombres que utiliza para parámetros, variables y salidas. Cuando estos valores se repiten a través de bucles de copia, un nombre largo se multiplica muchas veces.

Solución 2: simplificar la plantilla

Bicep

Cuando el archivo implementa muchos tipos de recursos diferentes, considere la posibilidad de dividirlo en módulos. Divida los tipos de recursos en grupos lógicos y agregue un módulo para cada grupo. Por ejemplo, si necesita implementar una gran cantidad de recursos de red, puede trasladar esos recursos a un módulo.

Puede establecer otros recursos como dependencias implícitas y obtener valores de la salida de los módulos.

Use especificaciones de plantilla en lugar de módulos de Bicep. Los módulos de Bicep se convierten en una sola plantilla de ARM con plantillas anidadas.

JSON

Cuando la plantilla implementa muchos tipos de recursos diferentes, considere la posibilidad de dividirla en plantillas vinculadas. Divida los tipos de recursos en grupos lógicos y agregue una plantilla vinculada para cada grupo. Por ejemplo, si necesita implementar una gran cantidad de recursos de red, puede trasladar esos recursos a una plantilla vinculada.

Puede establecer otros recursos como dependientes de la plantilla vinculada y obtener valores de la salida de la plantilla vinculada.

Use especificaciones de plantilla en lugar de plantillas anidadas.

Solución 3: Usar las dependencias con cuidado

Bicep

Use una dependencia implícita que se crea cuando un recurso hace referencia a otro recurso por su nombre simbólico. Para la mayoría de las implementaciones, no es necesario usar dependsOn y crear una dependencia explícita.

JSON

Al usar bucles de copia para implementar recursos, no use el nombre del bucle como una dependencia:

JSON

dependsOn: [ "nicLoop" ]

En su lugar, use la instancia del recurso del bucle del que depende. Por ejemplo:

JSON

dependsOn: [
    "[resourceId('Microsoft.Network/networkInterfaces', concat('nic-', copyIndex()))]"
]

Las dependencias complejas pueden consumir rápidamente los límites de datos. Por ejemplo, si un bucle de n recursos depende de otro bucle de n recursos, el resultado es almacenar O(n²) datos. Por el contrario, si cada recurso de un bucle solo depende de su homólogo en el otro bucle, da como resultado O(n) datos. Esta diferencia puede parecer sutil, pero el impacto en el almacenamiento crece muy rápidamente.

Solución 4: Reducir los datos que no pueden comprimirse

La inclusión de grandes cantidades de datos que no pueden comprimirse, como certificados o archivos binarios, o datos con una relación de compresión baja en una plantilla o parámetros, hará que se consuma rápidamente el límite de tamaño.