Introducción a la arquitectura de Azure DevOps Server

Azure DevOps Server |Azure DevOps Server |Azure DevOps Server 2022 | Azure DevOps Server 2020

Para planear y administrar la implementación, primero debe comprender la arquitectura subyacente de Azure DevOps Server. Comprender la arquitectura puede ayudarle a mantener el estado general de la implementación y ayudar a garantizar la disponibilidad general de los servidores y servicios que requieren los equipos de desarrollo.

Puede implementar Azure DevOps Server de varias maneras: en un servidor; en muchos servidores; o en un dominio o grupo de trabajo o entre dominios. Como alternativa, puede optar por usar Azure DevOps Services, donde Microsoft hospeda todos los elementos de servidor de la implementación. Comprender la arquitectura puede ayudarle a decidir qué topología es más probable que satisfaga sus necesidades empresariales. Independientemente de su elección de topología, si entiende la arquitectura subyacente de Azure DevOps Server, puede administrar mejor los requisitos físicos y lógicos. En este artículo se proporciona información general sencilla de las distintas arquitecturas, con vínculos a más información sobre implementaciones de ejemplo. También proporciona información técnica sobre los servicios, las bases de datos, la información de configuración y los puertos de red y los protocolos de implementaciones locales.

Para comprender la arquitectura de Azure DevOps Server y cómo afecta a la implementación, debe tener en cuenta lo siguiente:

  • La aplicación lógica, los datos y los niveles de cliente de Azure DevOps, y si desea usar uno o varios servidores para la aplicación y los niveles de datos, o si desea que la aplicación y los niveles de datos se hospede en la nube mediante Azure DevOps Services.
  • Ubicación de los servidores físicos o virtuales que hospedan esos niveles
  • Team Foundation Build y el número y la ubicación de los equipos de compilación que se ejecutan en su entorno, incluido cuántos podría necesitar para soportar sus prácticas de desarrollo, o si va a usar los servicios en la nube de Azure Pipelines para compilar y desplegar sus aplicaciones de software.
  • La posible necesidad de servidor proxy de Azure DevOps

Además, debe tener en cuenta las interacciones entre estas entidades. Por ejemplo, si decide usar el servicio Azure DevOps Server hospedado, debe asegurarse de que los clientes puedan acceder al servicio en el puerto 443. Si decide implementar Azure DevOps Server localmente, debe saber qué servicios web, bases de datos y modelos de objetos usa Azure DevOps Server. Además, debe saber qué puertos de red y protocolos usa Azure DevOps Server de forma predeterminada y qué puertos de red puede personalizar. Por último, debe comprender qué permisos debe establecer en Azure DevOps Server y los componentes y programas en los que depende la implementación.

Además de sus propios servicios, Azure DevOps Server depende de otros servicios para funcionar. Para más información sobre estos servicios, consulte Conceptos y componentes de Azure DevOps Serverdel almacenamiento de datos de Azure DevOps Server. Para más información sobre los requisitos y dependencias para la instalación, consulte la guía de instalación de Azure DevOps Server.

Importante

No debe modificar manualmente ninguna de las bases de datos de Azure DevOps Server a menos que se le indique que lo haga el Soporte técnico de Microsoft o siga los procedimientos descritos para realizar copias de seguridad manualmente de las bases de datos. Cualquier otra modificación puede invalidar el contrato de servicio.

Azure DevOps Services

Azure DevOps Services

Microsoft ofrece la opción de usar Azure DevOps Services, que puede hospedar todos los aspectos del lado servidor de Azure DevOps Server automáticamente. El código fuente, los elementos de trabajo, las configuraciones de compilación y las características del equipo se hospedan en la nube. Desde un punto de vista arquitectónico, esto simplifica considerablemente el uso de Azure DevOps Server, ya que los únicos aspectos de la arquitectura que debe tener en cuenta son los componentes del cliente y su acceso a Internet.

Al usar Azure DevOps Services, se usa un explorador web para conectarse al servicio mediante su cuenta Microsoft. Puede crear proyectos, agregar miembros al equipo y trabajar como lo haría con una instancia de Azure DevOps Server instalada localmente, sin la sobrecarga de administrar los servidores. Azure DevOps Services hospeda el nivel de aplicación, el nivel de datos y los servidores de compilación en la nube.

Para más información sobre los servicios en la nube frente a las implementaciones locales, consulte Azure DevOps Services frente a Azure DevOps Server.

El modelo de objetos

Con la arquitectura hospedada o implementada localmente, puede ampliar las características y la funcionalidad de Azure DevOps escribiendo una aplicación basada en su modelo de objetos de cliente o servidor. En todos los tipos de implementación, puede escribir aplicaciones que amplíen las funcionalidades de cliente. Sin embargo, si desea ampliar las funcionalidades del servidor, la aplicación debe ejecutarse en el servidor de nivel de aplicación. Para ampliar las funcionalidades de cliente, debe ejecutar la aplicación en el mismo equipo que Team Explorer.

Modelo de objetos de Azure DevOps Server

Servicios web y bases de datos para implementaciones locales

Azure DevOps Server incluye un conjunto de servicios web y bases de datos que se instalan y configuran por separado en el servidor o los servidores que hospedan la aplicación lógica, los datos y los niveles de cliente para Azure DevOps. Algunas características, como el tablero de tareas y las características de equipo basadas en backlog, son completamente web y se acceden únicamente a través de un portal web, un servicio web del lado del cliente. Otros, como las características de control de versiones, se pueden acceder a ellos a través de un portal web o a través de una aplicación cliente. Las siguientes ilustraciones proporcionan una vista general de los servicios web, las aplicaciones y las bases de datos para las implementaciones locales de Azure DevOps Server.

Niveles de servicio principales de Azure DevOps Server

Servicios opcionales de Azure DevOps Server

Clientes de Azure DevOps Server

Servicios a nivel de colección

Los servicios de nivel de colección proporcionan la funcionalidad de las operaciones en el nivel de la colección de proyectos. Puede crear aplicaciones que extiendan Azure DevOps Server mediante algunos de estos servicios. Para más información sobre cómo crear aplicaciones para Azure DevOps Server, consulte Desarrollo de extensiones.

Nota:

Algunos servicios aparecen en más de un nivel. Por ejemplo, el servicio de Registro funciona tanto a nivel de colección como a nivel de servidor y aparece en ambas listas.

Servicios de marco:

  • Servicio de registro
  • Servicio de registro (por compatibilidad con versiones anteriores de Azure DevOps Server)
  • Servicio de propiedades
  • Servicio de eventos
  • Servicio de seguridad
  • Servicio de ubicación
  • Servicio De administración de identidades
  • Servicio web control de versiones
  • Servicio web de seguimiento de elementos de trabajo
  • Servicio Web de Team Foundation Build
  • Servicio web de administración de laboratorio
  • Servicio web de administración de VMM
  • Servicio web de controlador de agente de prueba

Servicios de nivel de servidor

Los servicios de nivel de servidor (también conocidos como servicios de nivel de aplicación) proporcionan la funcionalidad de las operaciones para Azure DevOps Server como una aplicación de software. Puede crear aplicaciones que extiendan Azure DevOps Server mediante algunos de estos servicios.

Servicios de marco:

  • Servicio de registro
  • Servicio de eventos
  • Servicio de recopilación de proyectos
  • Servicio de propiedades
  • Servicio de seguridad
  • Servicio de ubicación
  • Servicio De administración de identidades
  • Servicio de administración
  • Servicio de administración de recopilación
  • Servicio de catálogo

Capa de datos

El nivel de datos incluye datos, procedimientos almacenados y otra lógica asociada. Cuando se usa Azure DevOps Services, el nivel de datos se hospeda para usted mediante SQL Server Azure. En una implementación local de Azure DevOps Server, el nivel de datos lógico consta de los siguientes almacenes operativos dentro de SQL Server. Estos almacenes pueden encontrarse en un servidor físico o distribuirse entre muchos servidores. Puede crear aplicaciones que extiendan Azure DevOps Server mediante algunos de estos almacenes operativos.

  • Base de datos de configuración (TFS_Configuration)
  • Almacenamiento de aplicaciones (TFS_Warehouse)
  • Base de datos de Analysis Services (TFS_Analysis)
  • Bases de datos para colecciones de proyectos (TFS_CollectionName)

En la tabla siguiente se proporciona una lista de las bases de datos que Azure DevOps Server usa en implementaciones locales. A menos que se indique lo contrario, puede mover todas las bases de datos de esta lista desde el servidor original y la instancia donde están instaladas y restaurarlas en otro servidor o instancia.

Nombre de la base de datos Descripción Servidor
TFS_Configuration Esta base de datos almacena el catálogo de recursos y la información de configuración de Azure DevOps Server. Esta base de datos contiene los almacenes operativos de Azure DevOps Server. Instancia de SQL Server que se usa cuando Azure DevOps Server está instalado y configurado.
TFS_Warehouse Esta base de datos almacena los datos de los informes. Instancia de SQL Server que se usa cuando Azure DevOps Server está instalado y configurado.
TFS_Analysis Esta base de datos multidimensional almacena los datos agregados de colecciones de proyectos. Instancia de SQL Server que se usa cuando SQL Server Analysis Services está instalado y configurado.
Bases de datos para colecciones de proyectos Una base de datos para cada colección de proyectos, que contiene datos de todos los proyectos de esa colección. Instancia de SQL Server compatible con Azure DevOps Server.

Nivel de cliente

El nivel de cliente se comunica con el nivel de aplicación a través del modelo de objetos de servidor y usa los mismos servicios web que se enumeran para ese nivel. Esto es cierto tanto si implementa Azure DevOps Server localmente como si usa Azure DevOps Services. Además de ese modelo, el nivel de cliente consta de componentes de Visual Studio Industry Partners (VSIP), la integración con Microsoft Office, interfaces de línea de comandos y un marco para directivas de registro.

Configuración

El servicio hospedado depende de los servicios cliente, implementados localmente y una conexión a Internet a la aplicación y a los niveles de datos hospedados en la nube. Una implementación local de Azure DevOps Server depende de SQL Server, Internet Information Services (IIS) y del sistema operativo Windows. En función de la topología elegida, Azure DevOps Server también puede depender de SQL Server Reporting Services o productos de SharePoint. Por lo tanto, la información de configuración de Azure DevOps Server se puede almacenar en cualquiera de las siguientes ubicaciones:

  • Almacenes de datos de IIS.
  • Archivos de configuración de Azure DevOps Server.
  • Orígenes de datos para Reporting Services (por ejemplo, datos TFSREPORTS).
  • Base de datos de configuración para Azure DevOps Server. El registro de Azure DevOps Server forma parte de la base de datos de configuración.
  • Registro de Windows.

Para obtener ejemplos de diferentes topologías de implementación local y dónde se almacenan estos recursos, vea Ejemplos de topología simple, Ejemplos de topología moderada y Ejemplos de topología compleja. A medida que mantiene una implementación local de Azure DevOps Server, debe tener en cuenta estos orígenes de configuración. Para cambiar la configuración de cualquier manera, es posible que tenga que modificar la información almacenada en varias ubicaciones. También es posible que tenga que cambiar la información de configuración de los datos y los niveles de cliente. Azure DevOps Server incluye una consola de administración y varias utilidades de línea de comandos para ayudarle a realizar estos cambios. Para obtener más información, consulte Referencia rápida de tareas administrativas.

Active Directory y sincronización de identidades de grupo

En implementaciones locales en las que Azure DevOps se ejecuta en un dominio de Active Directory, la información de grupo e identidad se sincroniza cuando se produce cualquiera de los eventos siguientes:

  • Se inicia el servidor de nivel de aplicación.
  • Se agrega un grupo de Active Directory a un grupo de Azure DevOps.

El período de tiempo especificado en el trabajo programado transcurre. El valor predeterminado es una hora y todos los grupos de Azure DevOps Server se actualizan cada 24 horas.

Identity Management Services (IMS) se sincroniza con Active Directory y las identidades modificadas se propagan del servidor a los clientes. De forma predeterminada, todos los grupos se actualizan en un plazo de 24 horas, pero puede personalizarlo para adaptarlo mejor a las necesidades de la implementación. Para más información, consulte Consideraciones sobre confianzas y bosques para Azure DevOps Server. Para las implementaciones locales que no usan Active Directory, consulte Administración de Azure DevOps Server en un grupo de trabajo.

Grupos y permisos

En una implementación local, Azure DevOps Server tiene su propio conjunto de grupos y permisos predeterminados que puede establecer en el nivel de proyecto, colección o servidor. Puede crear grupos personalizados y personalizar permisos en los niveles de grupo y individuales. Sin embargo, los usuarios o grupos que agregue a Azure DevOps Server no se agregan automáticamente a dos componentes en los que las implementaciones locales de Azure DevOps Server pueden depender de: Productos de SharePoint y Reporting Services. Si la implementación usa estos programas, debe agregar usuarios y grupos a ellos y conceder los permisos adecuados para que esos usuarios o grupos funcionen correctamente en todas las operaciones de Azure DevOps Server. Para más información, consulte Administración de usuarios o grupos en Azure DevOps Server.

En el caso de las implementaciones hospedadas, el acceso se controla mediante una combinación de cuentas de Microsoft y pertenencia al equipo. Para más información, consulte Introducción a Azure DevOps Services.

Puertos y protocolos de red

De forma predeterminada, se configura una implementación local de Azure DevOps Server para usar protocolos y puertos de red específicos. En la ilustración siguiente se muestra el tráfico de red para Azure DevOps Server en una implementación sencilla.

Instalación local sencilla

Del mismo modo, el servicio hospedado para Azure DevOps Server está configurado para usar protocolos y puertos de red específicos. En la ilustración siguiente se muestra el tráfico de red en una implementación hospedada.

Servidor de Azure DevOps hospedado

 

En la ilustración siguiente se muestra el tráfico de red en una implementación más compleja que incluye los componentes de Visual Studio Lab Management. (Tenga en cuenta que Lab Management ha quedado en desuso para TFS 2017 y versiones posteriores).

Nivel de aplicación

Entornos virtuales

máquinas virtuales

Las máquinas virtuales usan el puerto 80 para comunicarse con cualquier controlador de pruebas sobre la descarga de un agente de administración de laboratorio. Compruebe que este puerto está habilitado si tiene algún problema de comunicación.

Configuración de red predeterminada

De forma predeterminada, la comunicación entre los equipos de una implementación de Azure DevOps usa los protocolos y puertos que se muestran en la tabla siguiente. Si un asterisco (*) sigue el número de puerto, puede personalizar ese puerto.

Nivel y servicio Protocolo Puerto
Nivel de aplicación: servicios web HTTP/HTTPS 8080/443*
Nivel de aplicación: Administración de productos de SharePoint HTTP 17012* si Productos de SharePoint se instaló con Azure DevOps Server; de lo contrario, se genera aleatoriamente
Nivel de aplicación: Productos de SharePoint y Reporting Services HTTP
Servicio de Instrumentación de administración de Windows (WMI) (necesario durante la instalación para especificar y comprobar las direcciones URL de los servicios de informes)
80* Puerto dinámico
Capa de datos MS-SQL TCP 1433*
Capa de datos (SQL Server Analysis Services) MS-AS valor predeterminado (2382 o 2383)*
El puerto predeterminado varía según la versión de SQL Server que haya instalado y el tipo de instancia. Use el Administrador de configuración de SQL Server para determinar los puertos usados por la implementación.
Servidor proxy de Azure DevOps: cliente a proxy HTTP 8081*
Servidor proxy de Azure DevOps: proxy al nivel de aplicación HTTP/HTTPS 8080/443*
Nivel de cliente: Reporting Services HTTP 80*
Nivel de cliente: servicios web HTTP/HTTPS 8080/443*
Controlador de compilación en el nivel de aplicación HTTP/HTTPS 8080/443
Compilación del agente en el nivel de aplicación HTTP/HTTPS 8080/443
Servidor de Gestión de Lanzamientos HTTP o HTTPS 1000*
Release Management Client HTTP o HTTPS 1000*
Agente de administración de versiones HTTP o HTTPS 1000*
Controlador de pruebas al nivel de aplicación HTTP/HTTPS 8080/443*
Nivel de aplicación para probar el controlador Comunicación remota de .NET 6901*
Nivel de aplicación al sistema de nombres de dominio (DNS) Actualización dinámica de DNS 53
Nivel de aplicación: Virtual Machine Manager HTTP 8100
Controlador de pruebas para el agente de pruebas Comunicación remota de .NET 6910*
Agente de prueba para probar el controlador Comunicación remota de .NET 6901*
Controlador de compilación para compilar el agente SOAP a través de HTTP 9191
De agente de laboratorio a agente de laboratorio en un entorno aislado Sockets TCP 9050
Agente de compilación para compilar el controlador SOAP a través de HTTP 9191
Consola de administrador de Virtual Machine Manager: Virtual Machine Manager HTTP 8100
Administrador de Máquinas Virtuales: anfitriones de Virtual Machine Manager Administración remota de Windows (WinRM) para realizar acciones
Servicio de transferencia inteligente en segundo plano (BITS) para transferir datos
80 para realizar acciones
443 para transferir datos
Virtual Machine Manager: servidor de biblioteca de Virtual Machine Manager WinRM para realizar acciones
BITS para transferir datos
80 para realizar acciones
443 para transferir datos
Nivel de aplicación: hosts de Virtual Machine Manager Modelo de objetos de componente distribuido/Interfaz de administración de Windows (DCOM/WMI) para transferir datos 135
Asignado dinámicamente en el intervalo de 49152 a 65535
Nivel de cliente: hosts de Virtual Machine Manager Conexión basada en host a la máquina virtual. 2179 para realizar conexiones basadas en host
Servicios hospedados HTTPS 443

Configuración de red personalizable

Como se muestra en la tabla anterior, puede cambiar la comunicación entre la aplicación, los datos y los niveles de cliente en las implementaciones locales modificando Azure DevOps Server para usar puertos personalizados. En la tabla siguiente se describen los cambios de ejemplo en los puertos de HTTP a HTTPS.

Nota:

Para configurar Azure DevOps Server para que use https y capa de sockets seguros, no solo debe habilitar puertos para el tráfico de red HTTPS, sino también realizar muchas otras tareas. Para más información, consulte Configuración de HTTPS con capa de sockets seguros (SSL) para Azure DevOps Server.

Servicio Protocolo Puerto
Servicios web con SSL HTTPS Configurado por el administrador
Administración central de SharePoint HTTPS Configurado por el administrador
Productos de SharePoint HTTPS 443
Servicios de Generación de Informes HTTPS 443
Servicios web cliente HTTPS Configurado por el administrador
Administración de versiones HTTPS Configurado por el administrador