Arquitectura de referencia empresarial para DevTest Labs

Este artículo proporciona una arquitectura de referencia para implementar Azure DevTest Labs en una empresa. La arquitectura incluye los siguientes elementos clave:

• Conectividad local mediante Azure ExpressRoute
• Una puerta de enlace de escritorio remoto para iniciar sesión remotamente en máquinas virtuales
• Conectividad a un repositorio de artefactos privado
• Otros componentes de plataforma como servicio (PaaS) que usan los laboratorios

Arquitectura

En el diagrama siguiente se muestra una implementación empresarial típica de DevTest Labs. Esta arquitectura conecta varios laboratorios de distintas suscripciones de Azure a la red local de una empresa.

Componentes de DevTest Labs

DevTest Labs permite a las empresas proporcionar acceso a los recursos de Azure de manera fácil y rápida. Cada laboratorio contiene recursos de software como servicio (SaaS), infraestructura como servicio (IaaS) y plataforma como servicio (PaaS). Los usuarios del laboratorio pueden crear y configurar máquinas virtuales, entornos de PaaS y artefactos de máquina virtual.

En el diagrama anterior, Team Lab 1 en la suscripción de Azure 1 muestra un ejemplo de los componentes de Azure a los que los laboratorios pueden acceder y usar. Para más información, consulte Acerca de DevTest Labs.

Componentes de conectividad

Necesita conectividad local si los laboratorios deben acceder a los recursos corporativos locales. Los escenarios comunes son:

• Algunos datos locales no se pueden mover a la nube.
• Quiere unir máquinas virtuales de laboratorio a un dominio local.
• Quiere forzar todo el tráfico de red en la nube a través de un firewall local por motivos de seguridad o cumplimiento.

Esta arquitectura usa ExpressRoute para la conectividad a la red local. También puede usar una VPN de sitio a sitio.

En el entorno local, una puerta de enlace de Escritorio remoto permite conexiones de protocolo de escritorio remoto (RDP) salientes a DevTest Labs. Los firewalls empresariales corporativos suelen bloquear las conexiones salientes en el firewall corporativo. Para habilitar la conectividad, puede usar una de las siguientes opciones:

• Use una puerta de enlace de Escritorio remoto y permita la dirección IP estática del equilibrador de carga de la puerta de enlace.
• Use la tunelización forzada para redirigir todo el tráfico RDP a ExpressRoute o la conexión VPN de sitio a sitio. La tunelización forzada es una funcionalidad común para las implementaciones de DevTest Labs a escala empresarial.

Componentes de red

En esta arquitectura, Microsoft Entra ID proporciona administración de identidades y acceso en todas las redes. Las máquinas virtuales de laboratorio normalmente tienen una cuenta administrativa local para el acceso. Si hay una instancia de Microsoft Entra ID, un entorno local o un dominio de Microsoft Entra Domain Services disponible, puede unir máquinas virtuales de laboratorio al dominio. Los usuarios pueden usar entonces sus identidades basadas en dominio para conectarse a las máquinas virtuales.

La topología de red de Azure controla el acceso y la comunicación de los recursos de laboratorio con las redes locales e Internet. Esta arquitectura muestra una manera común en que las empresas usan DevTest Labs para sus conexiones en red. Los laboratorios se conectan con redes virtuales emparejadas en una configuración de topología en estrella, a través de ExpressRoute o una conexión VPN de sitio a sitio, a la red local.

Dado que DevTest Labs usa directamente Azure Virtual Network, no hay restricciones sobre cómo configurar la infraestructura de red. Puede configurar un grupo de seguridad de red para restringir el tráfico en la nube en función de las direcciones IP de origen y destino. Por ejemplo, puede permitir únicamente el tráfico que se origina en la red corporativa en las redes del laboratorio.

Consideraciones sobre escalabilidad

DevTest Labs no tiene cuotas ni límites integrados, pero otros recursos de Azure que usan los laboratorios tienen cuotas de nivel de suscripción. En una implementación empresarial típica, necesita varias suscripciones de Azure para cubrir una gran implementación de DevTest Labs. Las empresas normalmente alcanzan las cuotas siguientes:

• Grupos de recursos. DevTest Labs crea un grupo de recursos para cada nueva máquina virtual y los usuarios del laboratorio crean entornos en grupos de recursos. Las suscripciones pueden contener hasta 980 grupos de recursos, de modo que ese es el límite de máquinas virtuales y entornos de una suscripción.

  Dos estrategias pueden ayudarle a mantenerse por debajo de los límites de grupos de recursos:

  • Todas las máquinas virtuales van al mismo grupo de recursos. Esta estrategia le ayuda a cumplir el límite de grupos de recursos, pero incide en el límite de tipo de recurso por grupo de recursos.
  • Uso de direcciones IP públicas compartidas. Si las máquinas virtuales pueden tener direcciones IP públicas, coloque todas las máquinas virtuales del mismo tamaño y región en el mismo grupo de recursos. Esta configuración ayuda a cumplir las cuotas de grupos de recursos y las cuotas de tipo de recurso por grupo de recursos.

• Recursos por grupo de recursos por tipo de recurso. El límite predeterminado de recursos por grupo de recursos por tipo de recurso es 800. Al colocar todas las máquinas virtuales en el mismo grupo de recursos, este límite se alcanza mucho antes, especialmente si las máquinas virtuales tienen varios discos adicionales.

• Cuentas de almacenamiento. Cada instancia de DevTest Labs viene con una cuenta de almacenamiento. La cuota de Azure para el número de cuentas de almacenamiento por suscripción y región es 250 de manera predeterminada. Por tanto, el número máximo de instancias de DevTest Labs en una región también es 250. Con un aumento de cuota, podría crear hasta 500 cuentas de almacenamiento por región. Para obtener más información, consulte Aumento de las cuotas de la cuenta de Azure Storage.

• Asignaciones de roles. Una asignación de roles proporciona a un usuario o entidad de seguridad acceso a un recurso. Azure tiene un límite de 2000 asignaciones de roles por suscripción.

  De forma predeterminada, DevTest Labs crea un grupo de recursos para cada máquina virtual de laboratorio. Al creador de la máquina virtual se le concede el permiso de propietario para la máquina virtual y el permiso de lector para el grupo de recursos. Por lo tanto, cada máquina virtual de laboratorio usa dos asignaciones de roles. La concesión de permisos de usuario al laboratorio también usa asignaciones de roles.

• Lecturas y escrituras de API. Puede automatizar Azure y DevTest Labs mediante las API REST, PowerShell, la CLI de Azure y el SDK de Azure. Cada suscripción de Azure permite hasta 12 000 solicitudes de lectura y 1200 solicitudes de escritura por hora. Al automatizar DevTest Labs, es posible que alcance el límite de solicitudes de API.

Consideraciones sobre la manejabilidad

Puede usar Azure Portal para administrar una única instancia de DevTest Labs a la vez, pero es posible que las empresas tengan varias suscripciones de Azure y muchos laboratorios que administrar. Para realizar cambios de forma coherente en todos los laboratorios se necesita automatización de scripting.

Estos son algunos ejemplos del uso de scripting en implementaciones de DevTest Labs:

• Cambiar la configuración del laboratorio. Actualice una configuración de laboratorio específica en todos los laboratorios mediante scripts de PowerShell, la CLI de Azure o API REST. Por ejemplo, actualice todos los laboratorios para permitir un nuevo tamaño de instancia de máquina virtual.

• Actualizar los tokens de acceso personal del repositorio de artefactos. Los tokens de acceso personal para repositorios de Git suelen expirar en 90 días, un año o dos años. Para garantizar la continuidad, es importante extender el token de acceso personal. También puede crear un nuevo token de acceso personal y usar automatización para aplicarlo a todos los laboratorios.

• Restringir los cambios en la configuración del laboratorio. Para restringir determinadas configuraciones, como permitir el uso de imágenes de Marketplace, puede usar Azure Policy para evitar cambios en un tipo de recurso. También puede crear un rol personalizado y otorgar a los usuarios ese rol en lugar del rol de laboratorio integrado. Puede restringir los cambios para la mayoría de la configuración de laboratorio, como la compatibilidad interna, los anuncios de laboratorio y los tamaños de máquina virtual permitidos.

• Aplicar una convención de nomenclatura para máquinas virtuales. Puede usar Azure Policy para especificar un patrón de nomenclatura que ayude a identificar las máquinas virtuales en entornos basados en la nube.

Los recursos de Azure para DevTest Labs se administran de la misma manera que para otros fines. Por ejemplo, Azure Policy se aplica a las máquinas virtuales que se crean en un laboratorio. Microsoft Defender for Cloud puede informar sobre el cumplimiento de máquinas virtuales de laboratorio. Azure Backup puede proporcionar copias de seguridad periódicas para las máquinas virtuales de laboratorio.

Consideraciones sobre la seguridad

DevTest Labs se beneficia automáticamente de las características de seguridad de Azure integradas. Para requerir que las conexiones entrantes de Escritorio remoto se originen solo desde la red corporativa, puede agregar un grupo de seguridad de red a la red virtual en la puerta de enlace del escritorio remoto.

Otra consideración de seguridad es el nivel de permiso que conceder a los usuarios del laboratorio. Los propietarios del laboratorio usan el control de acceso basado en roles de Azure (RBAC de Azure) para asignar roles a los usuarios y establecer permisos de nivel de acceso y recursos. Los permisos más comunes de DevTest Labs son Propietario, Colaborador y Usuario. También puede crear y asignar roles personalizados. Para más información, consulte Adición de propietarios y usuarios en Azure DevTest Labs.

Pasos siguientes

Consulte el siguiente artículo de esta serie: Entrega de una prueba de concepto.