Implementación de DevOps para flujos de trabajo de aplicaciones lógicas estándar en Azure Logic Apps

Se aplica a: Azure Logic Apps (Estándar)

A medida que las cargas de trabajo de integración crecen en entornos de desarrollo, prueba y producción, la implementación manual y las actualizaciones de los flujos de trabajo de aplicaciones lógicas estándar se vuelven lentos, propensos a errores y son difíciles de mantener coherentes. Con la tendencia hacia las aplicaciones en la nube distribuidas y nativas, los equipos deben administrar componentes más distribuidos en más entornos. El equipo necesita una manera de compilar, probar y liberar cambios de flujo de trabajo de forma confiable mediante las mismas prácticas de DevOps que se aplican al código de aplicación.

Los flujos de trabajo de aplicaciones lógicas estándar en Azure Logic Apps de inquilino único admiten la integración continua y la implementación continua (CI/CD) con las herramientas de DevOps que ya usa. A diferencia del modelo multiinquilino, Azure Logic Apps separa el código de la aplicación de la infraestructura, por lo que puede crear e implementar los flujos de trabajo de forma independiente, localmente, en contenedores o a través de canalizaciones automatizadas.

En este artículo se proporciona una introducción e información general sobre la experiencia actual de integración continua e implementación continua (CI/CD) para flujos de trabajo de aplicaciones lógicas estándar en Azure Logic Apps de inquilino único.

Inquilino único frente a multiinquilino

En multitenant Azure Logic Apps, la implementación de recursos se basa en plantillas de Azure Resource Manager (plantillas de ARM). Estas plantillas combinan y controlan el aprovisionamiento de recursos tanto para los recursos de la aplicación lógica de consumo como para la infraestructura. En single-tenant Azure Logic Apps, la implementación es más fácil porque puede separar el aprovisionamiento de recursos entre los recursos de aplicación lógica estándar y la infraestructura.

Al crear un recurso de aplicación lógica estándar, los flujos de trabajo funcionan con el entorno de ejecución de Azure Logic Apps de un solo inquilino rediseñado. Este runtime usa el Modelo de extensibilidad de Azure Functions y se hospeda como una extensión en el runtime de Azure Functions. Este diseño proporciona portabilidad, flexibilidad y más rendimiento para las aplicaciones lógicas estándar, además de otras funcionalidades y ventajas heredadas de la plataforma de Azure Functions y del ecosistema de Azure App Service.

Por ejemplo, puede empaquetar el entorno de ejecución en contenedores rediseñado y los flujos de trabajo juntos como parte de la aplicación lógica estándar. Puede usar pasos genéricos o tareas que compilan, ensamblan y comprimen los recursos de la aplicación lógica en artefactos listos para implementarse. Para implementar aplicaciones lógicas estándar, copie los artefactos en el entorno de host y, a continuación, inicie las aplicaciones para ejecutar los flujos de trabajo. O bien, integre los artefactos en canalizaciones de implementación mediante las herramientas y los procesos que ya conoce y usa. Por ejemplo, si el escenario requiere contenedores, puede incluir aplicaciones lógicas estándar en contenedores e integrarlas en las canalizaciones existentes.

Para configurar e implementar los recursos de infraestructura, como redes virtuales y conectividad, puede seguir usando plantillas de ARM y aprovisionar por separado esos recursos junto con otros procesos y canalizaciones que use para esos fines.

Mediante el uso de las opciones de compilación e implementación estándar, puede centrarse en el desarrollo de aplicaciones por separado de la implementación de infraestructura. Como resultado, obtiene un modelo de proyecto más genérico en el que se pueden aplicar muchas opciones de implementación similares o las mismas que se usan para una aplicación genérica. También se beneficia de una experiencia más coherente para crear canalizaciones de implementación en torno a los proyectos de aplicación y para ejecutar las pruebas y validaciones necesarias antes de publicar en producción. Independientemente de la pila de tecnología que use, puede implementar aplicaciones lógicas mediante sus propias herramientas elegidas.

Funcionalidades de implementación de DevOps

La plataforma Azure Logic Apps de inquilino único hereda muchas funcionalidades y ventajas de la plataforma Azure Functions y el ecosistema Azure App Service. Estas actualizaciones incluyen todo un nuevo modelo de implementación y más formas de usar DevOps para los flujos de trabajo de la aplicación lógica.

Desarrollo y pruebas locales

Cuando se usa Visual Studio Code con la extensión Azure Logic Apps (Estándar) puede desarrollar, compilar y ejecutar localmente flujos de trabajo de aplicaciones lógicas estándar en el entorno de desarrollo sin tener que realizar la implementación en Azure. Si su escenario requiere una implementación local mediante la infraestructura que controla, consulte Creación de flujos de trabajo de aplicaciones lógicas estándar para la implementación híbrida en su propia infraestructura.

Esta funcionalidad es una mejora importante y proporciona una ventaja considerable en comparación con el modelo multiinquilino, lo que requiere que se desarrolle con un recurso existente y en ejecución en Azure.

Separación de las preocupaciones

El modelo de inquilino único ofrece la capacidad de separar los problemas entre la aplicación lógica y la infraestructura subyacente. Por ejemplo, puede desarrollar, compilar, comprimir e implementar la aplicación por separado como un artefacto inmutable en diferentes entornos. Normalmente, los flujos de trabajo de aplicación lógica tienen "código de aplicación" que se actualiza con más frecuencia que la infraestructura subyacente. Al separar estas capas, puede centrarse más en la creación del flujo de trabajo de la aplicación lógica y dedicar menos esfuerzo a implementar los recursos necesarios en varios entornos.

Estructura de recursos de la aplicación lógica

En el modelo multiinquilino de Azure Logic Apps, la estructura de recursos de la aplicación lógica de consumo solo puede incluir un único flujo de trabajo. Debido a esta relación uno a uno, tanto la aplicación lógica como el flujo de trabajo suelen considerarse y se hace referencia a ellos como sinónimos. Sin embargo, en el modelo de Azure Logic Apps de inquilino único, la estructura de recursos de la aplicación lógica estándar puede incluir varios flujos de trabajo. Esta relación uno a varios significa que, en la misma aplicación lógica, los flujos de trabajo pueden compartir y reutilizar otros recursos. Los flujos de trabajo de la misma aplicación lógica e inquilino también ofrecen un rendimiento mejorado debido a este inquilinato compartido y la proximidad entre sí. Esta estructura de recursos tiene un aspecto y funciona de forma similar a Azure Functions, donde una aplicación de funciones puede hospedar muchas funciones.

Para más información y conocer los procedimientos recomendados sobre la organización de flujos de trabajo, el rendimiento y el escalado en la aplicación lógica, revise las instrucciones similares para Azure Functions que normalmente se pueden aplicar a las aplicaciones de Azure Logic Apps de inquilino único.

Estructura de proyecto de la aplicación lógica

En Visual Studio Code, el proyecto de aplicación lógica tiene uno de los siguientes tipos:

• Basado en paquete de extensiones (Node.js), que es el tipo predeterminado.
• Basado en paquetes NuGet (.NET), que se puede convertir desde el tipo predeterminado.

En función de estos tipos, el proyecto puede incluir carpetas o archivos ligeramente diferentes. Por ejemplo, un proyecto basado en paquetes Nuget tiene una carpeta .bin que contiene paquetes y otros archivos de biblioteca. Un proyecto basado en agrupación de extensiones no incluye esta carpeta .bin .

Algunos escenarios requieren un proyecto basado en paquetes NuGet para que la aplicación se ejecute, por ejemplo, cuando quiera desarrollar y ejecutar operaciones integradas personalizadas. Para obtener más información sobre cómo convertir el proyecto para que use NuGet, consulte Habilitación de la creación de conectores integrados.

El proyecto basado en agrupación de extensiones predeterminado tiene una estructura de carpetas y archivos similar al ejemplo siguiente:

MyWorkspaceName
| MyBundleBasedLogicAppProjectName
  || .vscode
  || Artifacts
     ||| Maps 
         |||| MapName1
         |||| ...
     ||| Rules
     ||| Schemas
         |||| SchemaName1
         |||| ...
  || lib
     ||| builtinOperationSdks
         |||| JAR
         |||| net472
     ||| custom
  || WorkflowName1
     ||| workflow.json
     ||| ...
  || WorkflowName2
     ||| workflow.json
     ||| ...
  || workflow-designtime
     ||| host.json
     ||| local.settings.json
  || .funcignore
  || connections.json
  || host.json
  || local.settings.json

En el nivel raíz del proyecto, puede encontrar las siguientes carpetas y archivos junto con otros elementos:

Implementación de contenedores

El Azure Logic Apps de inquilino único admite la implementación en contenedores. Puede incluir en contenedores los flujos de trabajo de sus aplicaciones lógicas y ejecutarlos donde los contenedores pueden ejecutarse. Después de incluir la aplicación lógica en un contenedor, la implementación funciona principalmente igual que cualquier otro contenedor que implemente y administre.

Para obtener ejemplos que incluyen Azure DevOps, consulte CI/CD for Containers.

Configuración y parámetros de la aplicación

En Azure Logic Apps multiinquilino, las plantillas de ARM suponen un desafío cuando es necesario mantener variables de entorno para aplicaciones lógicas en varios entornos de desarrollo, pruebas y producción. Se define todo en una plantilla de ARM en la implementación. Si necesita cambiar solo una variable, debe volver a implementar todo.

En el entorno de Azure Logic Apps de inquilino único, puede llamar a las variables de entorno en el entorno de ejecución y hacer referencia a estas mediante la configuración y los parámetros de la aplicación, por lo que no tiene que volver a implementar con tanta frecuencia.

Conectores administrados y operaciones integradas

El ecosistema de Azure Logic Apps proporciona más de 1000 conectores administrados por Microsoft y hospedados en Azure y operaciones integradas como parte de una colección que puede usar en Azure Logic Apps de inquilino único. La forma en que Microsoft mantiene los conectores administrados es prácticamente la misma tanto en las aplicaciones Azure Logic Apps de un solo inquilino como en las de múltiples inquilinos.

La mejora más significativa es que el servicio de un solo inquilino hace que los conectores administrados más populares estén disponibles como operaciones integradas. Por ejemplo, puede usar operaciones integradas para Azure Service Bus, Azure Event Hubs, SQL y muchos otros. Mientras tanto, las versiones del conector administrado siguen estando disponibles y siguen funcionando.

Las conexiones que cree mediante operaciones integradas basadas en servicios de Azure se denominan conexiones integradas o conexiones basadas en proveedores de servicios. Las operaciones integradas y sus conexiones se ejecutan localmente en el mismo proceso que ejecuta los flujos de trabajo. Ambos se hospedan en el runtime de Azure Logic Apps rediseñado. Por el contrario, las conexiones administradas o las conexiones de API se crean y se ejecutan por separado como recursos Azure, que se implementan mediante plantillas de ARM. Como resultado, las operaciones integradas y sus conexiones proporcionan un mejor rendimiento debido a su proximidad a los flujos de trabajo. Este diseño también funciona bien con las canalizaciones de implementación porque las conexiones del proveedor de servicios se empaquetan en el mismo artefacto de compilación.

En Visual Studio Code, cuando se usa el diseñador para desarrollar o realizar cambios en los flujos de trabajo, el motor de Azure Logic Apps de un solo inquilino genera automáticamente los metadatos de conexión necesarios en el archivo connections.json del proyecto. En las secciones siguientes se describen los tres tipos de conexiones que puede crear en los flujos de trabajo. Cada tipo de conexión tiene una estructura JSON diferente, que es importante comprender porque los puntos de conexión cambian al moverse entre entornos.

Conexiones del proveedor de servicios

Cuando se usa una operación integrada para un servicio como Azure Service Bus o Azure Event Hubs en aplicaciones Azure Logic Apps de inquilino único, se crea una conexión de proveedor de servicios que se ejecuta en el mismo proceso que el flujo de trabajo. Esta infraestructura de conexión se hospeda y administra como parte del recurso de aplicación lógica, y la configuración de la aplicación almacena las cadenas de conexión de cualquier operación integrada basada en el proveedor de servicios que usen los flujos de trabajo.

En el proyecto de aplicación lógica Estándar, cada flujo de trabajo tiene un archivo workflow.json que contiene la definición JSON subyacente del flujo de trabajo. Esta definición de flujo de trabajo hace referencia a las cadenas de conexión necesarias en el archivo connections.json del proyecto.

En el ejemplo siguiente se muestra cómo aparece la conexión del proveedor de servicios para una operación integrada de Azure Service Bus en el archivo connections.json del proyecto:

"serviceProviderConnections": {
   "{service-bus-connection-name}": {
      "parameterValues": {
         "connectionString": "@appsetting('servicebus_connectionString')"
      },
      "serviceProvider": {
         "id": "/serviceProviders/serviceBus"
      },
      "displayName": "{service-bus-connection-name}"
   },
   <...>
}

Conexiones administradas

Cuando use un conector administrado por primera vez en el flujo de trabajo, se le pedirá que cree una conexión de API administrada para el servicio o sistema de destino y autentique su identidad. El ecosistema de conectores compartidos de Azure administra estos conectores. Las conexiones de API existen y se ejecutan como recursos independientes en Azure.

En Visual Studio Code, mientras sigues creando y desarrollando tu flujo de trabajo mediante el diseñador, el motor de Azure Logic Apps en un entorno de un solo inquilino crea automáticamente los recursos necesarios en Azure para los conectores gestionados de tu flujo de trabajo. El motor agrega automáticamente estos recursos de conexión al grupo de recursos de Azure que ha diseñado para contener la aplicación lógica.

En el ejemplo siguiente se muestra cómo aparece una conexión de API para el conector administrado de Azure Service Bus en el archivo connections.json del proyecto:

"managedApiConnections": {
   "{service-bus-connection-name}": { 
      "api": {
         "id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
      },
      "connection": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
      }, 
      "connectionRuntimeUrl": "{connection-runtime-URL}",
      "authentication": { 
         "type": "Raw",
         "scheme": "Key",
         "parameter": "@appsetting('servicebus_1-connectionKey')"
      },
   },
   <...>
}

Conexiones de Azure Functions

Para llamar a funciones creadas y hospedadas en Azure Functions, use la operación integrada Azure Functions. Los metadatos de conexión para las llamadas Azure Functions son diferentes de otras conexiones integradas. Estos metadatos se almacenan en el archivo connections.json del proyecto de aplicación lógica, pero tiene un aspecto diferente:

"functionConnections": {
   "{function-operation-name}": {
      "function": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
      },
      "triggerUrl": "{function-url}",
      "authentication": {
        "type": "QueryString",
         "name": "Code",
         "value": "@appsetting('azureFunctionOperation_functionAppKey')"
      }, 
      "displayName": "{functions-connection-display-name}"
   },
   <...>
}

Authentication

En Azure Logic Apps de un solo inquilino, el modelo de hospedaje para los flujos de trabajo de las aplicaciones lógicas es un único inquilino de Microsoft Entra en el que sus cargas de trabajo se benefician de un mayor aislamiento que en el modelo multiinquilino. Además, el entorno de ejecución de Azure Logic Apps de un solo inquilino es portátil, lo que significa que puede ejecutar los flujos de trabajo en otros entornos, como la Visual Studio Code local. Aun así, este diseño requiere una manera de que las aplicaciones lógicas autentiquen su identidad para que puedan acceder al ecosistema de conectores administrados en Azure. Las aplicaciones también necesitan los permisos correctos para ejecutar operaciones cuando se usan conexiones administradas.

De forma predeterminada, cada aplicación lógica basada en un inquilino único tiene una identidad administrada asignada por el sistema habilitada automáticamente. Esta identidad se diferencia de las credenciales de autenticación o de la cadena de conexión que se usan al crear una conexión. En el entorno de ejecución, la aplicación lógica usa esta identidad para autenticar sus conexiones a través de directivas de acceso de Azure. Si deshabilita esta identidad, las conexiones no funcionan en tiempo de ejecución.

En las secciones siguientes se proporciona más información sobre los tipos de autenticación que puede usar para autenticar las conexiones administradas, en función de dónde se ejecuta la aplicación lógica. Para cada conexión administrada, el archivo connections.json del proyecto de aplicación lógica tiene un objeto authentication que especifica el tipo de autenticación que la aplicación lógica puede usar para autenticar esa conexión administrada.

Identidad administrada

En el caso de una aplicación lógica hospedada y ejecutada en Azure, una identidad administrada es el tipo de autenticación predeterminado y recomendado que se usará para autenticar las conexiones administradas hospedadas y ejecutadas en Azure. En el archivo connections.json del proyecto de aplicación lógica, la conexión administrada tiene un objeto authentication que especifica ManagedServiceIdentity como tipo de autenticación:

"authentication": {
   "type": "ManagedServiceIdentity"
}

Raw

En el caso de las aplicaciones lógicas que se ejecutan en el entorno de desarrollo local mediante Visual Studio Code, las claves de autenticación sin procesar autentican las conexiones administradas hospedadas y se ejecutan en Azure. Use estas claves solo para el desarrollo, no para producción, ya que expiran después de siete días. En el archivo connections.json del proyecto de aplicación lógica, la conexión administrada incluye un authentication objeto que especifica la siguiente información de autenticación:

"authentication": {
   "type": "Raw", 
   "scheme": "Key", 
   "parameter": "@appsetting('connectionKey')"
 }

Contenido relacionado

• Configuración de la implementación de DevOps para Azure Logic Apps de inquilino único