Planear los entornos

Completado

Su propiedad de Azure consta de muchos componentes, como la configuración básica, los recursos y la configuración de toda la organización y las cargas de trabajo de las aplicaciones. Es probable que también haya propagado su propiedad en varios entornos, cada uno con un propósito diferente.

En esta unidad, aprenderá sobre las ventajas de usar código de manera coherente en toda la implementación y configuración. A continuación, considerará los niveles de control y automatización que puede aplicar a cada uno de los entornos. También considerará cómo progresan los cambios en cada fase del proceso de implementación y los controles y tipos de gobernanza que necesita para llevar a cabo la estrategia de implementación elegida.

Definición de la infraestructura como código

La implementación y configuración de Azure van mucho más allá de las aplicaciones, las máquinas virtuales, los servicios de almacenamiento y las redes. Por ejemplo, cada uno de los siguientes elementos es una forma de configuración, con los recursos de Azure correspondientes:

• Creación de grupos de recursos, suscripciones y grupos de administración para organizar los recursos.
• Definición y aplicación de definiciones, iniciativas y asignaciones de Azure Policy para controlar cómo se deben configurar otros recursos.
• Asignación de roles para permitir que usuarios, grupos e identidades de carga de trabajo accedan a los recursos de Azure.
• Configuración de la supervisión, incluidas las alertas, para observar los recursos de Azure y asegurarse de que se comportan del modo esperado.

Cuando empiece a definir la infraestructura como código, es posible que no tenga constancia de que todos los elementos se pueden definir en las plantillas o definiciones. Pero a medida que madura el uso de la automatización, se recomienda definir todos los elementos relacionados con su entorno como código. Al hacerlo, puede usar un proceso coherente, probado y aprobado para toda la configuración de Azure. Además, como el código se versiona y se controla en un repositorio de Git, puede revisar cómo ha cambiado su entorno de Azure con el tiempo. Puede utilizar el repositorio de Git para rastrear el historial de cada cambio.

Por ejemplo, supongamos que necesita configurar las alertas de Azure Monitor. Al principio, es posible que piense que usar la automatización para implementar alertas no tiene sentido. Pero las alertas son una parte importante de la configuración de Azure. Si una alerta no se crea correctamente, es posible que pierda las notificaciones de problemas críticos de producción. Al definir las alertas en el código:

• Los miembros del equipo pueden revisar las alertas y su configuración.
• Puede implementar las alertas en entornos que no son de producción para poder probarlas.
• Tiene trazabilidad completa de los cambios en la configuración de Azure.

Entornos

Cuando planea implementar la infraestructura automáticamente, resulta útil enumerar los entornos que planea usar. Muchas organizaciones tienen una variedad de tipos de entorno, cada uno con características diferentes. Por ejemplo:

• Algunos entornos ejecutan código de producción, mientras que otros ejecutan versiones del mismo código que no son de producción, quizás con configuraciones diferentes.
• Algunos entornos son de larga duración y se han diseñado para no eliminarse nunca. Otros son efímeros: se crean automáticamente y se destruyen cuando ya no se usan.
• El equipo de desarrollo de software o infraestructura podría usar algunos entornos. El equipo de seguridad, o incluso el equipo de ventas, usa otros entornos cuando deba demostrar un producto a clientes potenciales.

Considere qué entornos puede usar su empresa de juguetes para el sitio web:

Al hacer cambios y confirmarlos en la aplicación o en la infraestructura, la canalización implementa los cambios mediante una secuencia de entornos que no son de producción: desarrollo, prueba y ensayo. Es posible que también tenga pasos de aprobación manual en determinados puntos para que los miembros definidos del equipo puedan comprobar la configuración o ver el registro de canalización antes de que la implementación continúe. Por último, la canalización implementa los cambios en el entorno de producción.

Además de estos entornos, el equipo de ventas tiene su propio entorno de demostración que se usa para hablar con los clientes. El equipo de ventas toma una copia del entorno de producción para crear su entorno de demostración. Sus equipos de seguridad y pruebas crean a veces copias temporales del entorno de producción para pruebas de penetración y pruebas de rendimiento, respectivamente.

El equipo de desarrollo también tiene sus propios conjuntos de entornos. Tiene espacios aislados para que los miembros del equipo de desarrollo los usen al explorar nuevas características o experimentar con los servicios de Azure. El equipo de desarrollo también crea entornos de revisión de solicitudes de incorporación de cambios para cada solicitud de incorporación de cambios de GitHub que revisa y combina.

Entornos controlados

En algunos de estos entornos, tiene sentido requerir un proceso formal para revisar y aplicar cambios. Los entornos de este tipo se denominan entornos controlados. El entorno de producción siempre debe controlarse. También es recomendable aplicar controles a algunos de los entornos de no producción. De este modo, puede asegurarse de que todas las restricciones que imponen los controles se comprendan y prueben antes de la implementación de producción.

En cambio, los entornos no controlados no tienen muchos controles formales, o ninguno. Es posible que tengan el mismo código y una configuración similar a los demás entornos, pero permiten llevar a cabo más experimentación y cambios de configuración ad hoc. En un entorno no controlado, es posible que los usuarios puedan modificar la configuración mediante Azure Portal o ejecutando directamente comandos de la CLI de Azure/Azure PowerShell. También es posible que puedan crear recursos sin usar el proceso aprobado de la organización. Los cambios realizados en entornos no controlados deben capturarse en código antes de que puedan empezar a aplicarse en entornos controlados como el entorno de producción.

Nota

A veces, un entorno puede representar realmente varios entornos físicos o implementaciones. Por ejemplo, al crear entornos efímeros para revisiones de solicitudes de incorporación de cambios, varios entornos independientes podrían estar activos al mismo tiempo porque su equipo tiene varias solicitudes abiertas. Sin embargo, para planear los entornos, puede considerarlos equivalentes porque tienen las mismas características y controles.

Después de algunas charlas con su equipo, designa los entornos controlados y no controlados. También puede decidir quién es el propietario de cada entorno.

Nombre del entorno	Descripción	Propietario	Período de duración	Nivel de control
Desarrollo	Integra los cambios de varios desarrolladores en un único entorno.	Equipo de operaciones	Larga duración	Controlado
Prueba	Entorno para ejecutar pruebas manuales y automatizadas con cambios.	Equipo de operaciones	Larga duración	Controlado
Ensayo	El entorno final que no es de producción en el que se implementan los cambios antes de la producción, con una configuración similar al de producción.	Equipo de operaciones	Larga duración	Controlado
Producción	Ejecuta las cargas de trabajo de producción.	Equipo de operaciones	Larga duración	Controlado
Demostración	Lo usa el equipo de ventas para demostrar el producto a los nuevos clientes.	Equipo de ventas	Larga duración	No controlado
Pruebas de rendimiento	Se crea dinámicamente como un duplicado del entorno de producción para ejecutar pruebas de rendimiento y esfuerzo y, a continuación, se elimina cuando se completan las pruebas.	Equipo de prueba	Corta duración	No controlado
Pruebas de penetración	Se crea dinámicamente como un duplicado del entorno de producción para ejecutar pruebas de penetración y seguridad y, a continuación, se elimina cuando se completan las pruebas.	Equipo de seguridad	Corta duración	No controlado
Revisiones de PR	Se crea dinámicamente para cada solicitud de incorporación de cambios que crea un miembro del equipo para cambiar la aplicación o la infraestructura. El entorno se elimina cuando se cierra esta solicitud.	Equipo de desarrollo	Corta duración	No controlado
Espacios aislados de desarrollo	Los crean los miembros del equipo de desarrollo para experimentar o explorar y se eliminan cuando ya no son necesarios.	Equipo de desarrollo	Corta duración	No controlado

La lista anterior de entornos es solo un ejemplo. En su propia organización, necesita decidir qué entornos usa, cuál debe ser su vida útil y qué nivel de control necesita cada entorno.

Sugerencia

Es mucho más fácil aplicar linting, probar y revisar el código de infraestructura cuando se aplican esos procesos al principio de las implementaciones, en lugar de agregarlos más tarde y tener que corregir una gran cantidad de código dañado.

De forma similar, es mucho más fácil trabajar con controles de seguridad cuando están presentes desde el principio y cuando también se aplican a algunos de los entornos de no producción. De esa forma, su equipo se acostumbra a trabajar dentro de un entorno controlado.

A lo largo de las rutas de aprendizaje, hemos introducido algunos de estos conceptos de manera gradual. A menudo, es una buena idea agregar estos elementos al proceso de implementación lo antes posible.

Aislamiento de cada entorno

Es importante separar cada uno de los entornos y hacerlos autónomos siempre que sea posible. El uso de suscripciones de Azure dedicadas para cada entorno puede ser de ayuda, pero procurar mantener separados los entornos.

Evita conectarse de un entorno a otro. Por ejemplo, no empareje la red virtual de un entorno de producción con la red virtual de un entorno que no es de producción. Si lo hace, es fácil que alguien cambie accidentalmente los datos de producción desde un entorno que no es de producción o que filtre datos de producción confidenciales a un entorno que no sea de producción.

Comprobaciones y puertas

A medida que continúe con el proceso de implementación, debería ejecutar una serie de comprobaciones para aumentar la confianza en la implementación. Necesita determinar cuáles son las comprobaciones que tienen sentido para cada uno de los entornos por los que progresan las implementaciones.

Entre las comprobaciones de la infraestructura se suelen incluir:

• Revisiones de código.
• Implementación de su código en proceso de revisión en entornos efímeros y ejecución de pruebas manuales o automatizadas en los entornos.
• Linting.
• Validación preparatoria.
• Pruebas manuales.
• Aprobación manual.
• Pruebas funcionales automatizadas.
• Pruebas de comprobación de la compilación automatizadas.
• Espera de señales del estado de un entorno anterior antes de avanzar al siguiente entorno.

Puede ejecutar algunas de estas comprobaciones varias veces dentro del proceso de implementación, por ejemplo, para cada entorno controlado.

Sugerencia

Al diseñar el proceso de implementación, enumere todos los pasos que necesita realizar, independientemente de lo pequeños u obvios que sean. Sea lo más detallado que pueda. Es posible que no decida automatizar todo al principio, pero seguir esta recomendación le ayudará a crear un plano técnico para sus procesos de implementación automatizados en el futuro.

Una puerta de entrada es una comprobación automática o manual que se debe realizar correctamente para que la implementación continúe.

Intervención manual

Es una buena idea automatizar tantas comprobaciones como sea posible durante los procesos de revisión e implementación de código. Sin embargo, es posible que su organización necesite aprobación manual para la implementación en entornos de producción u otros entornos controlados.

Si usa puertas de aprobación manual para las implementaciones, siga estos procedimientos recomendados:

• Defina claramente quién puede aprobar una implementación. Utilice grupos de Microsoft Entra para definir aprobadores, en lugar de especificar usuarios individuales. Puede cambiar fácilmente la lista de aprobadores en el futuro.
• Configure un proceso para implementaciones de emergencia. Planee quién puede aprobar una implementación si los aprobadores normales no están disponibles. Es posible que una implementación de emergencia tenga lugar en mitad de la noche o durante un período de vacaciones.
• Limite la intervención humana para aprobar o rechazar una implementación. Evite requerir la intervención humana para ejecutar cualquiera de las operaciones de implementación, a menos que haya un paso que no pueda automatizar.

Gobernanza

Azure proporciona herramientas y funciones para ayudarle a gobernar su entorno, entre las que se incluyen:

• Azure Policy, para detectar recursos que se han configurado mediante métodos que no se ajustan a los requisitos de su organización. También puede ayudar a evitar que los recursos se creen o vuelvan a configurar de manera que no cumplan con los requisitos.
• Bloqueos, para evitar cambios o eliminación de recursos importantes.
• Grupos de administración para ayudarle a organizar las suscripciones de Azure y configurar directivas y controles de acceso basados en roles de forma coherente en todos los entornos.
• Azure Monitor, para registrar métricas y registros de los recursos, presentarlos en paneles y enviar alertas automáticas cuando se desvíen de los valores esperados.

Al crear su propiedad de Azure, considere la posibilidad de usar las zonas de aterrizaje de Azure. Al usar una zona de aterrizaje, puede generar gobernanza en su entorno desde el principio. Muchas zonas de aterrizaje incluyen archivos de Bicep y Terraform predefinidos para ayudarle a configurar su entorno. En el resumen se incluyen vínculos a más información.