Implementación de DevOps para Azure Logic Apps de inquilino único
Se aplica a: Azure Logic Apps (estándar)
Con la tendencia hacia las aplicaciones en la nube distribuidas y nativas, las organizaciones están tratando con componentes más distribuidos en más entornos. Para mantener el control y la coherencia, puede automatizar los entornos e implementar más componentes de forma más rápida y segura mediante herramientas y procesos de DevOps.
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 aplicaciones de Azure Logic Apps de inquilino único.
Inquilino único frente a multiinquilino
En Azure Logic Apps multiinquilino, la implementación de recursos se basa en las plantillas de Azure Resource Manager (plantillas de ARM), que combinan y controlan el aprovisionamiento de recursos para las aplicaciones lógicas y la infraestructura. En Azure Logic Apps de inquilino único, la implementación es más fácil porque puede separar el aprovisionamiento de recursos entre las aplicaciones y la infraestructura.
Cuando se crean aplicaciones lógicas con el tipo de recurso Logic App (estándar) , los flujos de trabajo tienen la tecnología del entorno de ejecución de Azure Logic Apps de inquilino único rediseñado. El entorno de ejecución usa el modelo de extensibilidad de Azure Functions y se hospeda como una extensión en el entorno de ejecución de Azure Functions. Este diseño proporciona portabilidad, flexibilidad y más rendimiento para las aplicaciones lógicas, además de otras funcionalidades y ventajas heredadas de la plataforma Azure Functions y el ecosistema Azure App Service.
Por ejemplo, puede empaquetar el entorno de ejecución y los flujos de trabajo en contenedores rediseñados juntos como parte de la aplicación lógica. 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 las aplicaciones, copie los artefactos en el entorno 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 crear incluir en contenedores las aplicaciones lógicas 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 con 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
Al usar Visual Studio Code con la extensión Azure Logic Apps (Estándar), puede desarrollar, compilar y ejecutar localmente flujos de trabajo de aplicación lógica basados en un solo inquilino en el entorno de desarrollo sin tener que implementar en Azure. Si el escenario requiere contenedores, puede crear e implementar mediante Logic Apps habilitado para Azure Arc.
Esta funcionalidad es una mejora importante y proporciona una ventaja considerable en comparación con el modelo multiinquilino, 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 las preocupaciones entre la aplicación 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 incluye carpetas y archivos ligeramente diferentes. Un proyecto basado en NuGet incluye una carpeta .bin que contiene paquetes y otros archivos de biblioteca. Un proyecto basado en paquetes no incluye la carpeta .bin ni otros archivos. Algunos escenarios requieren un proyecto basado en NuGet para que la aplicación se ejecute, por ejemplo, si quiere 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.
Para el proyecto basado en paquetes predeterminado, el proyecto tiene una estructura de carpetas y archivos similar a la del ejemplo siguiente:
MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
|| Maps
||| MapName1
||| ...
|| Schemas
||| SchemaName1
||| ...
| WorkflowName1
|| workflow.json
|| ...
| WorkflowName2
|| workflow.json
|| ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json
En el nivel raíz del proyecto, puede encontrar los siguientes archivos y carpetas con otros elementos:
| Nombre | Archivo o carpeta | Descripción |
|---|---|---|
| .vscode | Carpeta | Contiene archivos de configuración relacionados con Visual Studio Code, como extensions.json, launch.json, settings.json y tasks.json. |
| Artefactos | Carpeta | Contiene artefactos de la cuenta de integración que se definen y usan en los flujos de trabajo que admiten escenarios de negocio a negocio (B2B). Por ejemplo, la estructura de ejemplo incluye mapas y esquemas para operaciones de transformación y validación de XML. |
| <WorkflowName> | Carpeta | En cada flujo de trabajo, la carpeta <WorkflowName> incluye un archivo workflow.json, que contiene la definición JSON subyacente de ese flujo de trabajo. |
| workflow-designtime | Carpeta | Contiene archivos de configuración relacionados con el entorno de desarrollo. |
| .funcignore | Archivo | Contiene información relacionada con la instancia de Azure Functions Core Tools instalada. |
| connections.json | Archivo | Contiene los metadatos, los puntos de conexión y las claves de las conexiones administradas y de Azure Functions que se usan en los flujos de trabajo. Importante: Para usar diferentes conexiones y funciones en cada entorno, asegúrese de parametrizar este archivo connections.json y de actualizar los puntos de conexión. |
| host.json | Archivo | Contiene valores y opciones de configuración específicos del runtime, como, por ejemplo, los límites predeterminados para la plataforma de Azure Logic Apps de un solo inquilino, las aplicaciones lógicas, los flujos de trabajo, los desencadenadores y las acciones. En el nivel raíz del proyecto de aplicación lógica, el archivo de metadatos host.json contiene los valores y las opciones de configuración predeterminados que todos los flujos de trabajo de la misma aplicación lógica usan mientras se ejecutan, ya sea localmente o en Azure. Nota: Al crear la aplicación lógica, Visual Studio Code crea un archivo host.snapshot.*.json de copia de seguridad en el contenedor de almacenamiento. Si elimina la aplicación lógica, este archivo de copia de seguridad no se elimina. Si crea otra aplicación lógica con el mismo nombre, se crea otro archivo de instantánea. Solo puede tener 10 instantáneas para la misma aplicación lógica. Si se supera este número, verá el siguiente error: Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host)) Para resolver este error, elimine los archivos de instantáneas adicionales del contenedor de almacenamiento. |
| local.settings.json | Archivo | Contiene la configuración de la aplicación, las cadenas de conexión y otras configuraciones que los flujos de trabajo usan mientras se ejecutan localmente. En otras palabras, esta configuración y estos valores solo se aplican cuando se ejecutan los proyectos en el entorno de desarrollo local. Durante la implementación en Azure, el archivo y la configuración se omiten y no se incluyen con la implementación. Este archivo almacena valores y opciones de configuración como variables de entorno local que las herramientas de desarrollo local usan como valores appSettings. Puede llamar a estas variables de entorno y hacer referencia a ellas tanto en tiempo de ejecución como en tiempo de implementación mediante la configuración de la aplicación y los parámetros. Importante: el archivo local.settings.json puede contener secretos, por lo que debe asegurarse de excluir también este archivo del control de código fuente del proyecto. |
Implementación de contenedor
Las instancias de Azure Logic Apps de inquilino único admiten la implementación en contenedores, lo que significa que puede incluir en contenedores los flujos de trabajo de aplicación lógica y ejecutarlos donde se puedan ejecutar los contenedores. 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, revise CI/CD para contenedores.
Configuración y parámetros de la aplicación
En Azure Logic Apps multiinquilino, las plantillas de ARM suponen un desafío cuando hay que mantener variables de entorno para aplicaciones lógicas en distintos entornos de desarrollo, pruebas y producción. Todo lo que hay en una plantilla de ARM se define en la implementación. Si necesita cambiar solo una variable, tendrá que volver a implementarlo 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 Azure Logic Apps proporciona cientos de conectores administrados por Microsoft y operaciones integradas como parte de una colección en constante crecimiento que se puede usar en aplicaciones Azure Logic Apps de inquilino único. La forma en que Microsoft mantiene estos conectores y operaciones integradas permanece principalmente igual en el caso de las aplicaciones Azure Logic Apps de inquilino único.
La mejora más significativa es que el servicio de inquilino único hace que los conectores administrados más populares también estén disponibles como operaciones integradas. Por ejemplo, puede usar operaciones integradas para Azure Service Bus, Azure Event Hubs y otros. Mientras tanto, las versiones del conector administrado siguen estando disponibles y siguen funcionando.
Las conexiones que se crean mediante operaciones integradas se denominan conexiones integradas, o conexiones de proveedor 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 entorno de ejecución de Logic Apps rediseñado. Por el contrario, las conexiones administradas, o las conexiones de API, se crean y ejecutan por separado como recursos de 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 Logic Apps 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, cada flujo de trabajo tiene un archivo workflow.json que contiene la definición JSON subyacente del flujo de trabajo. A continuación, 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 de Service Bus integrada 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. Estos conectores se administran por el ecosistema de conectores compartidos en Azure. Las conexiones de API existen y se ejecutan como recursos independientes en Azure.
En Visual Studio Code, mientras continúa creando y desarrollando el flujo de trabajo mediante el diseñador, el motor de Logic Apps crea automáticamente los recursos necesarios en Azure para los conectores administrados del 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 de Service Bus administrado 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 de Azure Functions integrada. Los metadatos de conexión para las llamadas de Azure Functions son diferentes a los de otras conexiones integradas. Estos metadatos se almacenan en el archivo connections.json del proyecto de aplicación lógica, pero tienen 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 inquilino único, el modelo de hospedaje para los flujos de trabajo de las aplicaciones lógicas es un único inquilino 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 inquilino único es portátil, lo que significa que puede ejecutar los flujos de trabajo en otros entornos, por ejemplo, localmente en Visual Studio Code. 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 funcionarán en runtime.
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 formato se usan para autenticar las conexiones administradas hospedadas y ejecutadas en Azure. Estas claves están diseñadas solo para el desarrollo, no para producción, y expiran en 7 días. En el archivo connections.json del proyecto de aplicación lógica, la conexión administrada tiene un objeto authentication que especifica la siguiente información de autenticación:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}