Compartir vía

Ciclo de vida de la aplicación de Service Fabric

  • Artículo

Al igual que sucede con otras plataformas, una aplicación en Azure Service Fabric normalmente pasa las siguientes fases: diseño, desarrollo, prueba, implementación, actualización, mantenimiento y eliminación. Service Fabric ofrece compatibilidad de primera clase para todo el ciclo de vida de aplicación de las aplicaciones de nube: desde el desarrollo hasta la implementación, la administración diaria, el mantenimiento y, finalmente, la retirada. El modelo de servicio habilita varios roles distintos para participar de manera independiente en el ciclo de vida de la aplicación. Este artículo proporciona información general de las API y cómo son usadas por los distintos roles durante todas las fases del ciclo de vida de aplicación de Service Fabric.

Puede ver un vídeo de entrenamiento en el que se describe cómo administrar el ciclo de vida de la aplicación en esta página:

Importante

Hay dos utilidades de la CLI que interactúan con Service Fabric. La CLI de Azure se utiliza para administrar los recursos de Azure, como un clúster de Service Fabric hospedado en Azure. La CLI de Service Fabric se utiliza para conectarse directamente al clúster de Service Fabric (independientemente de dónde esté hospedado) y administrar el clúster, las aplicaciones y los servicios.

Roles del modelo de servicio

Los roles del modelo de servicio son:

  • Desarrollador del servicio: desarrolla servicios modulares y genéricos que se pueden volver a definir y usar en varias aplicaciones del mismo tipo o de tipos distintos. Por ejemplo, un servicio de cola puede usarse para crear una aplicación de incidencias (departamento de soporte técnico) y una aplicación de comercio electrónico (carro de la compra).
  • Desarrollador de aplicaciones: crea aplicaciones mediante la integración de una recopilación de servicios para satisfacer ciertos escenarios o requisitos específicos. Por ejemplo, un sitio web de comercio electrónico podría integrar "Servicio front-end sin estado JSON", "Servicio con estado de subasta" y "Servicio con estado de cola" para crear una solución de subasta.
  • Administrador de aplicaciones: toma decisiones sobre la configuración de las aplicaciones (relleno de los parámetros de la plantilla de configuración), implementación (asignación a recursos disponibles) y calidad de servicio. Por ejemplo, un administrador de aplicaciones decide la configuración regional de idioma (por ejemplo, inglés para Estados Unidos o japonés para Japón) de la aplicación. Una aplicación implementada diferente puede tener configuraciones distintas.
  • Operador: implementa aplicaciones basadas en la configuración de la aplicación y los requisitos especificados por el administrador de aplicaciones. Por ejemplo, un operador aprovisiona e implementa la aplicación y garantiza que se ejecuta en Azure. Los operadores supervisan la información de rendimiento y estado de la aplicación y mantiene la infraestructura física, según corresponda.

Desarrollar

  1. Un desarrollador de servicios desarrolla los distintos tipos de servicios con el modelo de programación Reliable Actors o Reliable Services.
  2. Un desarrollar de servicio describe, mediante declaración, los tipos de servicio desarrollados en un archivo de manifiesto de servicio que consta de uno o más paquetes de código, configuración y datos.
  3. Un desarrollador de aplicaciones luego crea una aplicación con distintos tipos de servicio.
  4. Un desarrollador de aplicaciones describe, mediante declaración, el tipo de aplicación en un manifiesto de aplicación a través de la referencia a los manifiestos de servicio de los servicios constituyentes y anulan y parametrizan de manera adecuada las distintas configuraciones de ajuste e implementación de los servicios constituyentes.

Consulte Introducción a Reliable Actors e Introducción a Reliable Services para ver ejemplos.

Implementación

  1. Un administrador de aplicaciones adapta el tipo de aplicación a una aplicación específica para su implementación en un clúster de Service Fabric mediante la especificación de los parámetros adecuados del elemento ApplicationType en el manifiesto de aplicación.
  2. Un operador carga el paquete de aplicación en el almacén de imágenes del clúster mediante el método CopyApplicationPackage o el cmdlet Copy-ServiceFabricApplicationPackage. El paquete de aplicación contiene el manifiesto de aplicación y la recopilación de los paquetes de servicio. Service Fabric implementa aplicaciones desde el paquete de aplicación almacenado en ImageStore, que puede ser un almacenamiento de blobs de Azure o el servicio de sistema de Service Fabric.
  3. Luego el operador aprovisiona el tipo de aplicación en el clúster de destino desde el paquete de aplicación cargado mediante el método ProvisionApplicationAsync, el cmdlet Register-ServiceFabricApplicationType o la operación de REST Aprovisionar una aplicación.
  4. Después de realizar el aprovisionamiento de la aplicación, un operador inicia la aplicación con los parámetros que suministra el administrador de aplicaciones mediante el método CreateApplicationAsync, el cmdlet New-ServiceFabricApplicationo la operación de REST Crear aplicación.
  5. Una vez implementada la aplicación, un operador usa el método CreateServiceAsync, el cmdlet New-ServiceFabricService o la operación de REST Crear servicio para crear nuevas instancias de servicio de la aplicación basándose en tipos de servicio disponibles.
  6. La aplicación ahora se ejecuta en el clúster de Service Fabric.

Consulte Implementación de una aplicación para ver ejemplos.

Prueba

  1. Después de realizar la implementación en el clúster de desarrollo local o en un clúster de prueba, un desarrollador de servicio ejecuta el escenario de prueba de conmutación por error integrado mediante las clases FailoverTestScenarioParameters y FailoverTestScenario o el cmdlet Invoke-ServiceFabricFailoverTestScenario. El escenario de prueba de conmutación por error ejecuta un servicio especificado a través de importantes transiciones y conmutadores por error para asegurarse de que sigue disponible y en funcionamiento.
  2. El desarrollador de servicio luego ejecuta el escenario de prueba de caos integrado mediante el uso de las clases ChaosTestScenarioParameters y ChaosTestScenario o el cmdlet Invoke-ServiceFabricChaosTestScenario. El escenario de prueba de caos induce de manera aleatoria varios errores de nodo, paquete de código y réplica en el clúster.
  3. El desarrollador del servicio comprueba la comunicación del servicio a servicio mediante la creación de escenarios de prueba que mueven las réplicas principales en torno al clúster.

Consulte Introducción al servicio de análisis de errores para obtener más información.

Actualizar

  1. Un desarrollador de servicio actualiza los servicios constituyentes de la aplicación con instancias y/o corrige errores y proporciona una versión nueva del manifiesto de servicio.
  2. Un desarrollador de aplicaciones anula y parametrizan las configuraciones de ajuste e implementación de los servicios constituyentes y proporciona una versión nueva del manifiesto de aplicación. A continuación, el desarrollador de aplicaciones incorpora las versiones nuevas de los manifiestos de servicio a la aplicación y proporciona una versión nueva del tipo de aplicación en un paquete de aplicación actualizado.
  3. Un administrador de aplicaciones incorpora la versión nueva del tipo de aplicación a la aplicación de destino mediante la actualización de los parámetros adecuados.
  4. Un operador carga el paquete de aplicación actualizado en el almacén de imágenes del clúster mediante el método CopyApplicationPackage o el cmdlet Copy-ServiceFabricApplicationPackage. El paquete de aplicación contiene el manifiesto de aplicación y la recopilación de los paquetes de servicio.
  5. Un operador aprovisiona la versión nueva de la aplicación en el clúster de destino mediante el método ProvisionApplicationAsync, el cmdlet Register-ServiceFabricApplicationType o la operación de REST Aprovisionar una aplicación.
  6. Un operador actualiza la aplicación de destino a la versión nueva mediante el método UpgradeApplicationAsync, el cmdlet Start-ServiceFabricApplicationUpgrade o la operación de REST Actualizar una aplicación.
  7. Un operador controla el progreso de la actualización mediante el método GetApplicationUpgradeProgressAsync, el cmdlet Get-ServiceFabricApplicationUpgrade o la operación de REST Obtener progreso de la actualización de la aplicación.
  8. En caso de ser necesario, el operador modifica y vuelve a aplicar los parámetros de la actualización de la aplicación actual mediante el método UpdateApplicationUpgradeAsync, el cmdlet Update-ServiceFabricApplicationUpgrade o la operación de REST Actualizar la actualización de la aplicación.
  9. En caso de ser necesario, el operador revierte la actualización de la aplicación actual mediante el método RollbackApplicationUpgradeAsync, el cmdlet Start-ServiceFabricApplicationRollback o la operación de REST Revertir actualización de la aplicación.
  10. Service Fabric actualiza la aplicación de destino que se ejecuta en el clúster sin perder la disponibilidad de ninguno de sus servicios constituyentes.

Consulte Tutorial de actualización de la aplicación para obtener ejemplos.

Mantenimiento

  1. Para obtener actualizaciones y revisiones del sistema operativo, Service Fabric interactúa con la infraestructura de Azure para garantizar la disponibilidad de todas las aplicaciones que se ejecutan en el clúster.
  2. En el caso de las actualizaciones y revisiones de la plataforma de Service Fabric, Service Fabric realiza actualizaciones sin perder la disponibilidad de ninguna de las aplicaciones que se ejecutan en el clúster.
  3. Un administrador de aplicaciones aprueba la adición o eliminación de nodos de un clúster después de analizar los datos históricos de utilización de capacidad y la demanda futura prevista.
  4. Un operador agrega y quita nodos especificados por el administrador de aplicaciones.
  5. Cuando se agregan nodos nuevos al clúster o se quitan nodos existentes, Service Fabric equilibra automáticamente la carga de las aplicaciones en ejecución en todos los nodos del clúster para lograr un rendimiento óptimo.

Remove

  1. Un operador puede eliminar una instancia específica de un servicio en ejecución en el clúster sin quitar la aplicación completa mediante el método DeleteServiceAsync, el cmdlet Remove-ServiceFabricService o la operación de REST Eliminar servicio.
  2. Un operador también puede eliminar una instancia de aplicación y todos sus servicios mediante el método DeleteApplicationAsync, el cmdlet Remove-ServiceFabricApplication o la operación de REST Eliminar aplicación.
  3. Una vez detenidos los servicios y la aplicación, el operador puede deshacer el aprovisionamiento del tipo de aplicación mediante el método UnprovisionApplicationAsync, el cmdlet Unregister-ServiceFabricApplicationType o la operación de REST Deshacer aprovisionamiento de una aplicación. Deshacer el aprovisionamiento del tipo de aplicación no quita el paquete de aplicación del ImageStore.
  4. Un operador quita el paquete de aplicación de ImageStore mediante el método RemoveApplicationPackage o el cmdlet Remove-ServiceFabricApplicationPackage.

Consulte Implementación de una aplicación para ver ejemplos.

Conservación del espacio en disco en el almacén de imágenes del clúster

ImageStoreService mantiene los paquetes copiados y aprovisionados, lo que puede provocar la acumulación de archivos. La acumulación de archivos puede hacer que ImageStoreService (fabric:/System/ImageStoreService) rellene el disco y pueda aumentar el tiempo de compilación de las réplicas de ImageStoreService.

Para evitar la acumulación de archivos, use la siguiente secuencia de aprovisionamiento:

  1. Copie el paquete en ImageStore y use la opción comprimir.

  2. Aprovisionamiento del paquete

  3. Eliminación del paquete en el almacén de imágenes

  4. Actualización de la aplicación o el clúster

  5. Anulación del aprovisionamiento de la versión anterior

Los pasos 3 y 5 del procedimiento anterior impiden la acumulación de archivos en el almacén de imágenes.

Configuración para la limpieza automática

Puede automatizar el paso 3 anterior mediante PowerShell o XML. Esto hará que el paquete de aplicación se elimine automáticamente después del registro correcto del tipo de aplicación.

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

Puede automatizar el paso 5 anterior mediante XML. Esto hará que los tipos de aplicación sin usar se anulen automáticamente el registro.

<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

Limpieza de archivos y datos de los nodos

La replicación de archivos de aplicación distribuirá finalmente los archivos a todos los nodos en función de las acciones de equilibrio. Esta situación puede crear presión sobre el disco en función del número de aplicaciones y su tamaño de archivo. Incluso cuando no se ejecuta ninguna instancia activa en un nodo, se conservarán los archivos de una instancia anterior. Lo mismo sucede con los datos de colecciones de confianza que usan los servicios con estado. Esto sirve para lograr una mayor disponibilidad. En el caso de una nueva instancia de aplicación en el mismo nodo, no se deben copiar archivos. Si las colecciones son de confianza, solo se debe replicar la diferencia.

Para quitar completamente los archivos binarios de la aplicación, debe anular el registro del tipo de aplicación.

Recomendaciones para reducir la presión del disco:

  1. Remove-ServiceFabricApplicationPackage quita el paquete de la ubicación de carga temporal.
  2. Unregister-ServiceFabricApplicationType libera espacio de almacenamiento al quitar los archivos de tipo de aplicación del servicio de almacén de imágenes y de todos los nodos. El administrador de eliminación se ejecuta cada hora por valor predeterminado.
  3. CleanupUnusedApplicationTypes limpia automáticamente las versiones antiguas de la aplicación sin usar. 
    {
  "name": "Management",
  "parameters": [
    {
      "name": "CleanupUnusedApplicationTypes",
      "value": true
    },
    {
      "name": "MaxUnusedAppTypeVersionsToKeep",
      "value": "3"
    }
  ]
}
  4. Remove-ServiceFabricClusterPackage quita los archivos binarios de instalación de tiempo de ejecución antiguos sin usar.

Nota

Hay una característica en proceso de desarrollo que permite a Service Fabric eliminar las carpetas de aplicación una vez que la aplicación se evacúe del nodo.

Pasos siguientes

Para obtener más información sobre cómo desarrollar, probar y administrar aplicaciones y servicios de Service Fabric, consulte: