Ejemplos y sintaxis de políticas de implementación de actualizaciones - AWS Organizations

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.

Ejemplos y sintaxis de políticas de implementación de actualizaciones

Una política de implementación de actualizaciones define cómo AWS los servicios aplican las actualizaciones automáticas en todos sus recursos. Comprender la sintaxis de las políticas le ayuda a crear políticas eficaces que se adapten a los requisitos de actualización de su organización.

Consideraciones

Al implementar políticas de implementación de actualizaciones, tenga en cuenta estos factores importantes:

  • Los nombres de las políticas deben ser únicos en su organización y deben ser claros y descriptivos. Elija nombres que reflejen el propósito y el alcance de la política. Para obtener más información, consulte Optimice la eficiencia operativa.

  • Las pruebas son cruciales antes de una implementación amplia. Valide primero las nuevas políticas en entornos que no sean de producción y amplíelas gradualmente para garantizar el comportamiento deseado. Para obtener más información, consulte Comience poco a poco y escale gradualmente.

  • Los cambios en las políticas pueden tardar varias horas en propagarse en toda la organización. Planifique sus implementaciones en consecuencia y asegúrese de que haya una supervisión adecuada. Para obtener más información, consulte Supervise y comunique los cambios.

  • El formato JSON debe ser válido y mantenerse dentro del tamaño máximo de la política, que es de 5.120 bytes. Mantenga las estructuras de políticas tan simples como sea posible y, al mismo tiempo, cumpla con sus requisitos.

  • Las revisiones periódicas de las políticas ayudan a mantener la eficacia. Programa evaluaciones periódicas de tus políticas para asegurarte de que siguen satisfaciendo las necesidades de tu organización. Para obtener más información, consulte Establezca procesos de revisión.

  • Los recursos sin un pedido de actualización asignado se utilizan de forma predeterminada en el «segundo» orden. Considere la posibilidad de establecer órdenes de actualización de forma explícita para los recursos críticos en lugar de confiar en los valores predeterminados. Para obtener más información, consulte Valide los cambios de política de forma eficaz.

  • Las actualizaciones manuales tienen prioridad sobre las órdenes de actualización definidas por la política. Asegúrese de que sus procesos de gestión de cambios tengan en cuenta los escenarios de actualización automática y manual. Para obtener más información, consulte Establezca procesos de revisión.

nota

Al implementar políticas de implementación de actualizaciones basadas en etiquetas desde su cuenta de administración, tenga en cuenta que la cuenta de administración no puede ver ni acceder directamente a las etiquetas a nivel de recursos en las cuentas de los miembros. Recomendamos establecer un proceso en el que las cuentas de los miembros apliquen etiquetas de recursos coherentes y, a continuación, crear políticas a nivel de la organización que hagan referencia a estas etiquetas. Esto garantiza una coordinación adecuada entre el etiquetado a nivel de recursos y la aplicación de las políticas de la organización. También se puede utilizar Políticas de etiquetas para ayudar a mantener la coherencia de las etiquetas cuando se etiquetan los recursos en toda la organización.

Estructura básica de las políticas

Las políticas de implementación de actualizaciones utilizan una estructura JSON que incluye los siguientes elementos principales:

  • Metadatos de políticas (como la información de la versión)

  • Reglas de segmentación de recursos

  • Actualice las especificaciones del pedido

  • Mensajes de excepción opcionales

  • Atributos específicos del servicio

El siguiente ejemplo muestra una estructura básica de políticas de implementación de actualizaciones:

{ "upgrade_rollout":{ "default":{ "patch_order":{ "@@assign":"last" } }, "tags":{ "devtag":{ "tag_values":{ "tag1":{ "patch_order":{ "@@assign":"first" } }, "tag2":{ "patch_order":{ "@@assign":"second" } }, "tag3":{ "patch_order":{ "@@assign":"last" } } } } } } }

Componentes de política

Una política de implementación de actualizaciones consta de dos componentes clave que funcionan juntos para controlar cómo se aplican las actualizaciones en todos los recursos. Estos componentes incluyen opciones de configuración tanto para los comportamientos predeterminados como para las anulaciones basadas en etiquetas. Comprender cómo interactúan estos componentes le ayuda a crear políticas eficaces que se adapten a las necesidades de su organización.

Configuración predeterminada del pedido de parches

Al crear una política de implementación de actualizaciones sin especificar ninguna anulación específica de un recurso, todos los recursos utilizan de forma predeterminada un orden de actualización base. Puede establecer este valor predeterminado mediante el campo «predeterminado» de su política. Los recursos sin asignaciones explícitas de órdenes de actualización mediante etiquetas seguirán este orden predeterminado.

nota

La experiencia de consola actual requiere que se especifique un orden predeterminado.

El siguiente ejemplo muestra cómo configurar todos los recursos para que reciban las actualizaciones al final de forma predeterminada, a menos que las etiquetas las anulen. Este enfoque resulta útil cuando se quiere garantizar que la mayoría de los recursos se actualicen más adelante en el ciclo de actualización:

"upgrade_rollout": { "default": { "patch_order": "last" } }

Anulación del nivel de recursos mediante etiquetas

Puede anular el orden de actualización predeterminado para recursos específicos mediante etiquetas. Esto le permite crear un control detallado sobre qué recursos reciben las actualizaciones y en qué orden. Por ejemplo, puede asignar diferentes órdenes de actualización en función de los tipos de entorno, las etapas de desarrollo o la importancia de la carga de trabajo.

El siguiente ejemplo muestra cómo configurar los recursos de desarrollo para que reciban las actualizaciones primero y los recursos de producción para que las reciban al final. Esta configuración garantiza que sus entornos de desarrollo puedan validar las actualizaciones antes de que lleguen a producción:

"upgrade_rollout": { "tags": { "environment": { "tag_values": { "development": { "patch_order": "first" }, "production": { "patch_order": "last" } } } } }

Ejemplos de políticas de implementación de actualizaciones

Estos son los escenarios más comunes de políticas de implementación de actualizaciones:

Ejemplo 1: Primero el entorno de desarrollo

En este ejemplo, se muestra cómo configurar los recursos del entorno de desarrollo para que reciban primero las actualizaciones. Al asignar a los recursos la etiqueta de entorno de «desarrollo», se asegura de que sus entornos de desarrollo sean los primeros en recibir y validar las nuevas actualizaciones. Este patrón ayuda a identificar posibles problemas antes de que las actualizaciones lleguen a entornos más críticos:

{ "tags": { "environment": { "tag_values": { "development": { "upgrade_order": "first" } } } } }

Ejemplo 2: último entorno de producción

Este ejemplo demuestra cómo garantizar que sus entornos de producción reciban las últimas actualizaciones. Al configurar de forma explícita los recursos etiquetados de producción en el último pedido de actualización, se mantiene la estabilidad del entorno de producción y se permiten realizar las pruebas adecuadas en los entornos de preproducción. Este enfoque resulta especialmente útil para las organizaciones con requisitos estrictos de gestión de cambios:

{ "tags": { "environment": { "tag_values": { "production": { "upgrade_order": "last" } } } } }

Ejemplo 3: Varios pedidos de actualización mediante etiquetas

En el siguiente ejemplo, se muestra cómo utilizar una única clave de etiqueta con valores diferentes para especificar los tres pedidos de mejora. Este enfoque resulta útil cuando se desean gestionar los pedidos de mejora mediante un único esquema de etiquetado:

{ "upgrade_rollout":{ "default":{ "patch_order":{ "@@assign":"last" } }, "tags":{ "devtag":{ "tag_values":{ "tag1":{ "patch_order":{ "@@assign":"first" } }, "tag2":{ "patch_order":{ "@@assign":"second" } }, "tag3":{ "patch_order":{ "@@assign":"last" } } } } } } }