Gobernanza de la infraestructura de Azure DevTest Labs

Este artículo aborda la alineación y la administración de recursos de DevTest Labs dentro de su organización.

Recursos

Alineación de recursos de DevTest Labs dentro de una suscripción de Azure

Antes de que una organización empiece a usar Azure para desarrollo de aplicaciones generales, los planificadores de TI deben revisar cómo introducir la funcionalidad como parte de su cartera de servicios global. Las áreas de revisión deben resolver las siguientes cuestiones:

• ¿Cómo medir el costo asociado con el ciclo de vida de desarrollo de las aplicaciones?
• ¿Cómo alinea la organización la oferta de servicio propuesta con la directiva de seguridad corporativa?
• ¿La segmentación es necesaria para separar los entornos de producción y desarrollo?
• ¿Qué controles se introducen para facilitar la administración, la estabilidad y el crecimiento a largo plazo?

La primera práctica recomendada consiste en revisar la taxonomía de Azure de las organizaciones donde se describen las divisiones entre las suscripciones de desarrollo y producción. En el diagrama siguiente, la taxonomía sugerida permite una separación lógica de los entornos de desarrollo y pruebas y producción. Con este enfoque, una organización puede introducir códigos de facturación para realizar un seguimiento de los costos asociados con cada entorno por separado. Para más información, vea Gobernanza de suscripción prescriptiva. Además, puede usar etiquetas de Azure para organizar recursos para fines de facturación y seguimiento.

La segunda práctica recomendada consiste en habilitar la suscripción a DevTest dentro del portal de Azure Enterprise. Permite que una organización ejecute sistemas operativos cliente que normalmente no están disponibles en una suscripción de Azure Enterprise. A continuación, use software empresarial donde solo paga por el proceso sin tener que preocuparse por las licencias. Esto garantiza que la facturación por servicios designados, incluidas las imágenes de la galería en IaaS, como Microsoft SQL Server, se base solo en el consumo. Puede encontrar detalles sobre la suscripción de Azure DevTest aquí para los clientes con Contrato Enterprise (EA) y aquí para los clientes de pago por uso.

Este modelo proporciona a una organización la flexibilidad para implementar Azure DevTest Labs a escala. Una organización puede admitir cientos de laboratorios para diversas unidades de negocio con la ejecución en paralelo de 100 a 1000 máquinas virtuales. Promociona la noción de una solución de laboratorio empresarial centralizada que puede compartir los mismos principios de administración de configuración y controles de seguridad.

Este modelo también garantiza que la organización no agote sus límites de recursos asociados con su suscripción de Azure. Para obtener información detallada sobre suscripciones y límites de servicio, vea Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure. El proceso de aprovisionamiento de DevTest Labs puede consumir una gran cantidad de grupos de recursos. Puede solicitar un aumento de los límites con una solicitud de soporte técnico en la suscripción de Azure DevTest. El aumento del uso de la suscripción de desarrollo no afecta a los recursos incluidos en la suscripción de producción. Para más información sobre el escalado de DevTest Labs, vea Escalado de cuotas y límites en DevTest Labs.

Un límite a nivel de suscripción común que debe tenerse en cuenta es cómo se realizan las asignaciones de intervalos IP de red para que admitan suscripciones de desarrollo y producción. Deben tenerse en cuenta estas asignaciones para el crecimiento a lo largo del tiempo (suponiendo la conectividad local u otra topología de red que requiere la empresa para administrar su pila de red en lugar de usar como opción predeterminada la implementación de Azure). La práctica recomendada es tener algunas redes virtuales que tengan un prefijo de dirección IP grande asignado y dividido con muchas subredes grandes, en lugar de disponer de varias redes virtuales con subredes pequeñas. Por ejemplo, con 10 suscripciones, puede definir 10 redes virtuales (una para cada suscripción). Todos los laboratorios que no necesiten aislamiento pueden compartir la misma subred en la red virtual de la suscripción.

Número de usuarios por laboratorio y laboratorios por organización

Las unidades de negocio y los grupos de desarrollo que están asociados con el mismo proyecto de desarrollo se deben asociar con el mismo laboratorio. Esto permite aplicar a ambos grupos los mismos tipos de directivas, imágenes y directivas de cierre.

También debe tener en cuenta los límites geográficos. Por ejemplo, los desarrolladores del Nordeste de Estados Unidos (EE. UU.) pueden usar un laboratorio aprovisionado en el Este de EE. UU. 2. Además, los desarrolladores de Dallas (Texas) y Denver (Colorado) pueden ser remitidos a usar un recurso en Centro y Sur de EE. UU. Si existe algún trabajo de colaboración con un tercero externo, se les podría asignar a un laboratorio que los desarrolladores internos no usen.

También puede usar un laboratorio para un proyecto específico en los proyectos de Azure DevOps. A continuación, aplique seguridad en un grupo específico de Microsoft Entra, lo que permite acceder a ambos conjuntos de recursos. La red virtual asignada al laboratorio puede ser otro límite para consolidar a los usuarios.

Impedir la eliminación de recursos

Establezca permisos en el nivel de laboratorio para que solo los usuarios autorizados puedan eliminar los recursos o cambiar las directivas del laboratorio. Los desarrolladores deben incorporarse al grupo de usuarios de DevTest Labs. El jefe de desarrollo o el responsable de la infraestructura debe ser el propietario de DevTest Labs. Se recomienda que haya solo dos propietarios del laboratorio. Esta directiva se extiende al repositorio de código para evitar daños. Los usuarios del laboratorio tienen derechos para usar los recursos, pero no pueden actualizar las directivas del laboratorio. Consulte el artículo siguiente en el que se enumeran los roles y derechos que cada grupo integrado tiene dentro de un laboratorio: Adición de propietarios y usuarios en Azure DevTest Labs.

Administración de costos y propiedad

El costo y la propiedad son las principales preocupaciones cuando considere la posibilidad de crear los entornos de desarrollo y pruebas. En esta sección, encontrará información que le ayudará a optimizar el costo y alinear la propiedad en su entorno.

Optimizar el costo

Ha varias características integradas de DevTest Labs que ayudan a optimizar el costo. Consulte los artículos sobre administración de costos, umbralesy directivas para limitar las actividades de los usuarios.

Si usa DevTest Labs con cargas de trabajo de desarrollo y pruebas, puede considerar la posibilidad de usar la ventaja de la suscripción Desarrollo/pruebas - Enterprise, que forma parte del Contrato Enterprise. O bien, si es cliente de Pago por uso, es posible que le interese la oferta de Pago por uso de Desarrollo/pruebas.

Este enfoque proporciona varias ventajas:

• Tarifas especiales de Desarrollo/pruebas más económicas en instancias de máquinas virtuales con Windows, Cloud Services, HDInsight, App Service y Logic Apps
• Tarifas geniales del Contrato Enterprise (EA) en otros servicios de Azure
• Acceso a imágenes exclusivas de Desarrollo y pruebas de la galería, que incluye Windows 8.1 y Windows 10

Solo los suscriptores activos de Visual Studio (suscripciones estándar, suscripciones de nube anuales y mensuales) pueden usar los recursos de Azure que se ejecutan en una suscripción Desarrollo/pruebas - Enterprise. Pero los usuarios finales pueden acceder a la aplicación para aportar comentarios o hacer pruebas de aceptación. Puede usar recursos de esta suscripción solo para desarrollar y probar aplicaciones. No hay ninguna garantía de tiempo de actividad.

Si decide usar la oferta de Desarrollo/pruebas, emplee esta ventaja únicamente para el desarrollo y las pruebas de las aplicaciones. El uso conforme a la suscripción no conlleva ningún Acuerdo de Nivel de Servicio con respaldo financiero, salvo para el uso de Azure DevOps y HockeyApp.

Definición de acceso basado en rol en la organización

El departamento de TI central debe poseer solo lo que sea necesario y permitir que los equipos de proyectos y aplicaciones tengan el nivel necesario de control. Normalmente, esto significa que esa departamento de TI central posee la suscripción y las controla las funciones de TI básicas, como las configuraciones de redes. El conjunto de propietarios para una suscripción debe ser pequeño. Estos propietarios pueden designar a otros propietarios cuando sea necesario, o aplicar directivas de nivel de suscripción, por ejemplo, “sin dirección IP pública”.

Puede haber un subconjunto de usuarios que necesiten acceso en una suscripción, como la compatibilidad con Tier1 o Tier2. En este caso, se recomienda dar a dichos usuarios acceso de colaborador para que puedan administrar los recursos, pero no puedan proporcionar acceso de usuario o ajustar las directivas.

Los propietarios de recursos de DevTest Labs deben estar cercanos al equipo del proyecto o la aplicación. Estos propietarios comprenden los requisitos de máquina y software. En la mayoría de las organizaciones, el propietario del recurso de DevTest Labs es el responsable de desarrollo o del proyecto. Este propietario puede administrar usuarios y directivas en el entorno de laboratorio, además de todas las máquinas virtuales del entorno de DevTest Labs.

Agregue miembros del equipo de proyecto y aplicación al rol Usuarios de DevTest Labs. Estos usuarios pueden crear máquinas virtuales de conformidad con las directivas de nivel de suscripción y de laboratorio. Los usuarios también pueden administrar sus propias máquinas virtuales, pero no las que pertenecen a otros usuarios.

Para obtener más información, vea Scaffolding empresarial de Azure: gobernanza de suscripción prescriptiva.

Directiva de seguridad y cumplimiento

En esta sección se proporcionan instrucciones sobre la directiva de la empresa y el cumplimiento para la infraestructura de Azure DevTest Labs.

Repositorio de artefactos público frente a privado

El repositorio de artefactos público proporciona un conjunto inicial de paquetes de software que se utilizan con mayor frecuencia. Ayuda a una rápida implementación sin tener que invertir tiempo en reproducir herramientas y complementos comunes para desarrolladores. Puede elegir implementar su propio repositorio privado. Puede utilizar un repositorio público y uno privado en paralelo. También puede elegir deshabilitar el repositorio público. Los criterios para implementar un repositorio privado deben estar guiados por las siguientes preguntas y consideraciones:

• ¿Tiene la organización el requisito de tener un software corporativo con licencia como parte de su oferta de DevTest Labs? Si la respuesta es afirmativa, entonces se debe crear un repositorio privado.
• ¿Desarrolla la organización software personalizado que proporciona una operación específica, que se requiere como parte del proceso general de aprovisionamiento? Si la respuesta es afirmativa, se debe implementar un repositorio privado.
• Si la directiva de gobernanza de la organización requiere aislamiento y los repositorios externos no están bajo la administración directa de la configuración por parte de la organización, se debe implementar un repositorio de artefactos privado. Como parte de este proceso, una copia inicial del repositorio público se puede copiar e integrar con el repositorio privado. Después, el repositorio público se puede deshabilitar para que nadie dentro de la organización pueda acceder a él. Este enfoque obliga a todos los usuarios dentro de la organización a tener un único repositorio aprobado por ella y minimizar la deriva de la configuración.

Repositorio único o varios repositorios

Como parte de la estrategia general de gobernanza y administración de configuración de la organización, le recomendamos que utilice un repositorio centralizado. Cuando utiliza varios repositorios, pueden convertirse en silos de software no administrado con el tiempo. Con un repositorio central, múltiples equipos pueden consumir artefactos de este repositorio para sus proyectos. Impone la estandarización, la seguridad, la facilidad de administración y elimina la duplicación de esfuerzos. Como parte de la centralización, las siguientes acciones son procedimientos recomendados para la administración a largo plazo y la sostenibilidad:

• Asocie los servicios de Azure Repos con el mismo inquilino de Microsoft Entra que la suscripción de Azure está utilizando para la autenticación y autorización.
• Cree un grupo llamado Todos los desarrolladores de DevTest Labs en Microsoft Entra ID que se administre de forma centralizada. Cualquier desarrollador que contribuya al desarrollo de artefacto debe colocarse en este grupo.
• El mismo grupo de Microsoft Entra puede usarse para proporcionar acceso al repositorio de Azure Repos y al laboratorio.
• En Azure Repos, las ramificaciones o bifurcaciones deben utilizarse para separar un repositorio en desarrollo del repositorio de producción principal. El contenido solo se agrega a la rama principal con una solicitud de incorporación de cambios después de una revisión apropiada del código. Una vez que el revisor de código aprueba el cambio, un desarrollador jefe, que es responsable del mantenimiento de la rama principal, combina el código actualizado.

Directivas de seguridad corporativas

Una organización puede aplicar directivas de seguridad corporativas mediante lo siguiente:

• Desarrollar y publicar una directiva de seguridad integral. La directiva articula las reglas de uso aceptable asociadas con el uso de recursos de nube y software. También define lo que claramente infringe la directiva.
• El desarrollo de una imagen personalizada, artefactos personalizados y un proceso de implementación que permita la orquestación dentro del ámbito de la seguridad que se define con el directorio activo. Este enfoque refuerza los límites corporativos y establece un conjunto común de controles ambientales. Estos controles contra el entorno que un desarrollador puede considerar al desarrollar y seguir un ciclo de vida de desarrollo seguro como parte de su proceso general. El objetivo también es proporcionar un entorno que no sea excesivamente restrictivo y que pueda obstaculizar el desarrollo, sino un conjunto razonable de controles. Las directivas de grupo en la unidad organizativa que contiene máquinas virtuales de laboratorio podrían ser un subconjunto del total de directivas de grupo que se encuentran en producción. Además, pueden ser un conjunto adicional para mitigar adecuadamente cualquier riesgo identificado.

Integridad de datos

Una organización puede garantizar la integridad de los datos para asegurarse de que los desarrolladores remotos no puedan quitar código ni introducir malware o software no aprobado. Hay varias capas de control para mitigar la amenaza de consultores externos, contratistas o empleados remotos para colaborar en DevTest Labs.

Como se dijo anteriormente, el primer paso debe tener una directiva de uso aceptable redactada y definida que describa claramente las consecuencias cuando alguien infringe la directiva.

La primera capa de controles para el acceso remoto es aplicar una directiva de acceso remoto mediante una conexión VPN que no esté conectada directamente al laboratorio.

La segunda capa de controles consiste en aplicar un conjunto de objetos de directiva de grupo que impiden copiar y pegar mediante el escritorio remoto. Se podría implementar una directiva de red para no permitir que los servicios salientes del entorno, como los servicios FTP y RDP, queden fuera del entorno. El enrutamiento definido por el usuario podría obligar a todo el tráfico de red de Azure de nuevo a un entorno local, pero el enrutamiento no podría dar cuenta de todas las direcciones URL que podrían permitir la carga de datos a menos que se controlen mediante un proxy para escanear el contenido y las sesiones. Las direcciones IP públicas podrían restringirse dentro de la red virtual que admite DevTest Labs para no permitir el protocolo de puente de un recurso de red externo.

En última instancia, es necesario aplicar el mismo tipo de restricciones en toda la organización, lo que también tendría que tener en cuenta todos los métodos posibles de medios extraíbles o direcciones URL externas que podrían aceptar un mensaje de contenido. Consulte con el profesional de seguridad para revisar e implementar una directiva de seguridad. Para más recomendaciones, consulte Ciberseguridad de Microsoft.

Integración y migración de aplicaciones

Una vez establecido el entorno de laboratorio de desarrollo y pruebas, necesita pensar en las siguientes preguntas:

• ¿Cómo se usa el entorno en el equipo del proyecto?
• ¿Cómo se garantiza el cumplimiento de las directivas organizativas necesarias y el mantenimiento de la agilidad para aportar valor a la aplicación?

Imágenes de Azure Marketplace frente a imágenes personalizadas

Azure Marketplace se debe usar de forma predeterminada a menos que tenga requisitos organizativos o preocupaciones específicos. Algunos ejemplos frecuentes son:

• Instalación compleja del software que requiere que una aplicación se incluya como parte de la imagen base.
• La instalación y configuración de una aplicación podrían tardar muchas horas, lo que no constituye un uso eficaz del tiempo de proceso que se agregará a una imagen de Azure Marketplace.
• Los desarrolladores y evaluadores necesitan tener acceso a una máquina virtual rápidamente y desean minimizar el tiempo de configuración de una nueva máquina virtual.
• Existencia de condiciones de cumplimiento o normativas (por ejemplo, las directivas de seguridad) para todas las máquinas.

Considere detenidamente la posibilidad de usar imágenes personalizadas. Las imágenes personalizadas añaden complejidad, ya que ahora hay que administrar archivos de VHD de esas imágenes base subyacentes. También debe revisar periódicamente esas imágenes base con las actualizaciones de software. Estas actualizaciones incluyen nuevas actualizaciones del sistema operativo (SO) y las actualizaciones o los cambios de configuración necesarios para el paquete de software.

Fórmula frente imágenes personalizadas

Normalmente, los factores decisivos en este escenario son el costo y la reutilización.

Puede reducir el costo si crea una imagen personalizada si:

• Muchos usuarios o laboratorios necesitan la imagen.
• La imagen necesaria tiene una gran cantidad de software sobre la imagen base.

Esta solución significa que la imagen se crea una vez. Una imagen personalizada reduce el tiempo de configuración de la máquina virtual. No se incurre en costos al ejecutar la máquina virtual durante la configuración.

Otro factor es la frecuencia de cambios en el paquete de software. Si ejecuta compilaciones diarias y necesita que el software se encuentre en las máquinas virtuales de los usuarios, considere la posibilidad de usar una fórmula en lugar de una imagen personalizada.

Patrones para configurar la red

Al asegurarse de que las máquinas virtuales de desarrollo y prueba no pueden acceder a la red pública de Internet hay dos aspectos que se deben tener en cuenta: el tráfico entrante y el saliente.

Tráfico entrante: si la máquina virtual no tiene una dirección IP pública, Internet no llega a ella. Un enfoque común es establecer una directiva de nivel de suscripción que consista en que ningún usuario pueda crear una dirección IP pública.

Tráfico saliente: si quiere evitar que las máquinas virtuales vayan directamente a la red pública de Internet y forzar el tráfico a través de un firewall corporativo, puede enrutar el tráfico local a través de Azure ExpressRoute o VPN, mediante el enrutamiento forzado.

Nota

Si tiene un servidor proxy que bloquea el tráfico sin configuración del proxy, no olvide agregar excepciones a la cuenta de almacenamiento de artefactos del laboratorio.

También puede usar grupos de seguridad de red para máquinas virtuales o subredes. Este paso agrega otra capa de protección para permitir o bloquear el tráfico.

Red virtual nueva frente a una existente

Si las máquinas virtuales necesitan interactuar con la infraestructura existente, debe considerar la posibilidad de usar una red virtual existente dentro del entorno de DevTest Labs. Si usa ExpressRoute, minimice el número de redes virtuales y subredes para no fragmentar el espacio de direcciones IP asignado a las suscripciones. Además, considere la posibilidad de usar aquí el patrón de emparejamiento de red virtual (modelo en estrella tipo hub-and-spoke). Este enfoque permite la comunicación de red virtual y subred entre suscripciones de una región determinada.

Cada entorno de DevTest Labs podría tener su propia red virtual, aunque hay límites en cuanto al número de redes virtuales por suscripción. La cantidad predeterminada es 50, aunque este límite puede aumentarse a 100.

Dirección IP compartida, pública o privada

Si usa una VPN de sitio a sitio o ExpressRoute, considere la posibilidad de usar direcciones IP privadas para que se pueda acceder a las máquinas a través de la red interna, pero no a través de Internet.

Nota

Los propietarios de laboratorios pueden cambiar esta directiva de subred para asegurarse de que nadie puede crear accidentalmente direcciones IP públicas para sus máquinas virtuales. El propietario de la suscripción debe crear una directiva de suscripción que impida la creación de direcciones IP públicas.

Si se usan direcciones IP compartidas, las máquinas virtuales del laboratorio comparten una dirección IP pública. Este enfoque puede resultar útil si necesita impedir que se traspasen los límites de las direcciones IP públicas de una suscripción concreta.

Límites del laboratorio

Hay varios límites de laboratorio que debe tener en cuenta. Estos límites se describen en las secciones siguientes.

Límites de laboratorios por suscripción

No hay ningún límite específico en el número de laboratorios que se pueden crear por cada suscripción. Sin embargo, la cantidad de recursos que se usan para cada suscripción está limitada. Puede leer sobre los límites y las cuotas de las suscripciones de Azure y cómo aumentar estos límites.

Límites de máquinas virtuales por laboratorio

No hay ningún límite específico del número de máquinas virtuales que se pueden crear por cada laboratorio. Sin embargo, los recursos (los núcleos de máquinas virtuales, las direcciones IP públicas, etc) están limitados para cada suscripción. Puede leer sobre los límites y las cuotas de las suscripciones de Azure y cómo aumentar estos límites.

Límites del número de máquinas virtuales por usuario o laboratorio

Al considerar el número de máquinas virtuales por usuario o laboratorio, existen tres inquietudes principales:

• El costo total en que el equipo puede incurrir por los recursos del laboratorio. Es fácil poner en marcha varias máquinas. Para controlar los costos, un mecanismo es limitar el número de máquinas virtuales por usuario o laboratorio.
• Las cuotas a nivel de suscripción disponibles repercuten en el número total de máquinas virtuales de un laboratorio. Uno de los límites máximos es 800 grupos de recursos por suscripción. DevTest Labs actualmente crea un grupo de recursos para cada máquina virtual (a menos que se usen direcciones IP públicas compartidas). Si hay 10 laboratorios en una suscripción, los laboratorios podrían incluir aproximadamente 79 máquinas en cada laboratorio (Límite máximo de 800 – 10 grupos de recursos para los 10 laboratorios) = 79 máquinas virtuales por laboratorio.
• Si el laboratorio está conectado a un entorno local a través de ExpressRoute, por ejemplo, hay espacios de direcciones IP definidos disponibles para la red virtual o subred. Para garantizar que no se produzcan errores al crear máquinas virtuales en el laboratorio (error: no se puede obtener la dirección IP), los propietarios del laboratorio pueden especificar el número máximo de máquinas virtuales por laboratorio de tal forma que esté en consonancia con el espacio de direcciones IP disponible.

Uso de plantillas de Resource Manager

Implemente las plantillas de Resource Manager mediante los pasos de Usar Azure DevTest Labs para entornos de prueba. Básicamente, se guardan las plantillas de Resource Manager en un repositorio Git de Azure Repos o GitHub y se agrega un repositorio privado para las plantillas al laboratorio.

Este escenario puede no ser útil si usa DevTest Labs para hospedar máquinas de desarrollo. Use este escenario para compilar un entorno de ensayo que sea representativo de producción.

La opción de número de máquinas virtuales por laboratorio o usuario solo limita el número de máquinas creadas de forma nativa en el propio laboratorio. Esta opción no limita la creación por parte de cualquier entorno con plantillas de Resource Manager.