Implementación de entornos efímeros para revisiones
El linting del código de Bicep te ayuda a saber si la implementación de Azure tendrá éxito. También le puede resultar útil implementar el código de Bicep en algún lugar para ver cómo se verá el entorno después de que se combine la solicitud de incorporación de cambios y se complete la implementación.
En esta unidad, aprenderá a implementar el código en un entorno temporal desde dentro de una solicitud de incorporación de cambios.
¿Por qué implementar el código desde una solicitud de incorporación de cambios?
Al revisar una solicitud de incorporación de cambios que incluye código Bicep, es un procedimiento recomendado implementar el código Bicep en un entorno real de Azure. Al hacerlo, ayudará a crear confianza en que los cambios funcionarán cuando lleguen a su entorno de producción. Si hay algún problema, querrá descubrirlo rápidamente. Las solicitudes de incorporación de cambios ofrecen una gran oportunidad para detectar y resaltar problemas, ya que recibe comentarios inmediatos de los revisores.
Ya está acostumbrado a la idea de implementar los cambios en uno o varios entornos que no son de producción, como Prueba, Control de calidad y Almacenamiento provisional, antes de implementarlos en los entornos de producción. En muchas organizaciones, estos entornos son de larga duración, lo que significa que se actualizan cuando se implantan los cambios y los entornos no suelen eliminarse.
Por el contrario, un entorno efímero es aquel que se crea dinámicamente y que se puede eliminar cuando ya no es útil. Los entornos efímeros están diseñados para existir solo durante un breve período de tiempo (por ejemplo, tan solo un tiempo suficiente para que se revisen los cambios).
Los entornos efímeros son una buena opción al implementar entornos para solicitudes de incorporación de cambios, ya que es posible que tenga muchas solicitudes independientes abiertas a la vez. Esto puede representar distintos tipos de cambios. Si tiene abiertas varias solicitudes de cambios, compartir sus entornos de no producción de larga duración significa que solo puede previsualizar un cambio cada vez.
Creación de entornos efímeros
Como está tan acostumbrado a crear su infraestructura de Azure como código y ha invertido en crear sus archivos Bicep para implementar sus recursos, puede reutilizar esos mismos recursos para implementar un entorno efímero. Incluso puedes implementar varios entornos efímeros a la vez, si es necesario. Solo tiene que asegurarse de que sus implementaciones estén suficientemente parametrizadas y generalizadas para que pueda crear entornos independientes con facilidad. Por ejemplo, debes asegurarte de que algunos recursos de Azure reciben nombres únicos globales que no pueden ser los mismos que los nombres de recursos en cualquier otro entorno efímero o de larga duración.
Los entornos efímeros ofrecen muchas ventajas:
- Puede probar de forma segura nuevas características y funcionalidades en un entorno aislado que no afecta a las demás cargas de trabajo de producción o que no sean de producción.
- Puede mostrar los cambios en su propia rama, lo que le permite mostrar fácilmente su trabajo a sus compañeros o proporcionar acceso a los revisores.
- Puede hacer que varios miembros del equipo prueben sus cambios por separado a la vez, incluso si los cambios son incompatibles.
- Dado que implican ejecutar periódicamente los archivos de Bicep, los entornos efímeros le ayudan a probar continuamente la precisión y la integridad del código de Bicep y otros scripts. Como resultado, puede estar más seguro de que el código se ejecutará perfectamente en el entorno de producción.
En este módulo, crearás entornos efímeros para ayudarte a aumentar la confianza sobre los cambios en las solicitudes de incorporación de cambios. Cualquier persona que revise la solicitud de incorporación de cambios puede acceder al entorno efímero, incluidas las nuevas incorporaciones y actualizaciones, antes de aprobar y combinar la solicitud de incorporación de cambios.
Implementación
Cuando se trabaja con entornos efímeros, es recomendable crear un grupo de recursos de Azure independiente para cada solicitud de incorporación de cambios que cree el equipo. Si un creador tiene dos solicitudes de incorporación de cambios independientes abiertas, cada uno tendrá su propio entorno efímero. Esto ayuda a mantener cada cambio separado de los demás y puede ayudar a evitar confusiones o sobrescribir accidentalmente los recursos.
Para que este enfoque funcione, el flujo de trabajo de validación de solicitud de incorporación de cambios debe crear grupos de recursos de forma dinámica. Los grupos de recursos requieren nombres únicos y también debes poder encontrar fácilmente el grupo de recursos para probar los recursos y eliminarlos cuando se cierre la solicitud de incorporación de cambios. Para manipular los nombres de grupo de recursos de manera eficaz, puedes usar el número de solicitud de incorporación de cambios dentro del nombre del grupo de recursos. Verá cómo hacerlo en el ejercicio siguiente.
Cuando llegue el momento de eliminar el entorno efímero, es fácil para el flujo de trabajo buscar y eliminar todo el grupo de recursos. Todos los recursos utilizados en el entorno efímero se eliminan al mismo tiempo.
Permisos
La creación de grupos de recursos requiere permisos de nivel de suscripción y normalmente requiere que el rol de Colaborador se asigne a la identidad de carga de trabajo del flujo de trabajo.
Es un procedimiento recomendado usar una suscripción dedicada a Azure para los entornos efímeros. Siguiendo este enfoque, puedes conceder acceso a la identidad de carga de trabajo del flujo de trabajo y a los miembros del equipo sin dar acceso accidentalmente a los demás entornos.
Importante
Los colaboradores con ámbito de suscripción son eficaces, por lo que debe asegurarse de que tiene una gobernanza adecuada en torno a la identidad de carga de trabajo del flujo de trabajo y los cambios que puede implementar. Al usar una suscripción dedicada para entornos efímeros, se reduce el riesgo en los demás entornos.
Identidad del flujo de trabajo
El flujo de trabajo de implementación usa una identidad de carga de trabajo y una credencial federada para autenticarse en Azure. Al usar flujos de trabajo de validación de solicitudes de incorporación de cambios, debe configurar la credencial federada para que funcione con las solicitudes de incorporación de cambios.
En un ejercicio anterior de este módulo, ejecutó un comando para crear una credencial federada. La cadena de directiva era similar a la siguiente:
repo:my-github-user/my-repo:pull_request
El pull_request cerca del final de la cadena especifica que la credencial federada funciona con flujos de trabajo de validación de solicitudes de incorporación de cambios.
Administración de costos
Al crear entornos efímeros dinámicamente, existe el riesgo de que los gastos de Azure aumenten. Si el equipo tiene un gran número de solicitudes de incorporación de cambios abiertas, podrías implementar un gran número de recursos costosos en Azure.
Sugerencia
Aunque el equipo cierre las solicitudes de incorporación de cambios rápido, el aumento del coste no supondrá un problema porque se eliminará un entorno efímero cuando se cierre la solicitud correspondiente.
También puedes supervisar fácilmente los costes de los entornos efímeros con el uso de una suscripción dedicada a Azure. Además, puede aplicar directivas para toda la suscripción que limiten las SKU de los recursos efímeros, lo que puede ayudarle a evitar sobrecostes.
Por otro lado, Azure ofrece muchas formas de ayudarle a controlar los costes de los entornos efímeros, entre las que se incluyen las siguientes:
- Microsoft Cost Management permite establecer presupuestos para una suscripción. Los presupuestos desencadenan notificaciones para que el equipo sea consciente de que el coste se acerca al umbral que ha especificado.
- Muchos tipos de recursos de Azure ofrecen niveles más baratos, o incluso gratuitos, para las cargas de trabajo que no son de producción. Considera si puedes usar estos planes de tarifa y SKU.
- Los precios de desarrollo y pruebas de Azure están disponibles para que algunos clientes los utilicen para las suscripciones que no son de producción.
- Las etiquetas de recursos pueden ayudarle a identificar los recursos asociados a cada entorno efímero y a calcular el coste de cada uno.
- Puede crear scripts de automatización para eliminar los recursos efímeros después de un período de tiempo definido, o incluso cada noche después del horario comercial.
También puedes considerar la posibilidad de compartir determinados recursos entre entornos efímeros. Por ejemplo, el código de Bicep podría definir muchos recursos, algunos de los cuales son costosos o que pueden tardar mucho tiempo en ser aprovisionados. Puede crear un grupo de recursos compartido de larga duración para todas las solicitudes de incorporación de cambios a fin de compartir los costosos recursos y crear grupos de recursos efímeros independientes para los demás recursos. Sin embargo, este enfoque dificulta la administración de los entornos efímeros y hace que sea propensa a errores, además de mantenerlos lo suficientemente separados para que sean útiles para su proceso de revisión del código. Es mejor evitar este enfoque a menos que el coste de los entornos efímeros sea demasiado alto.