Modos de implementación de agrupaciones de automatización declarativas

En esta página se describe la sintaxis de los modos de implementación de agrupaciones de Automatización declarativa. Las agrupaciones permiten la administración mediante programación de flujos de trabajo de Azure Databricks. Consulte ¿Qué son los conjuntos de automatización declarativos?

En los flujos de trabajo de CI/CD, los desarrolladores suelen codificar, probar, implementar y ejecutar soluciones en varias fases o modos. Por ejemplo, el conjunto más sencillo de modos incluye un modo de desarrollo para la validación de preproducción, seguido de un modo de producción para entregas validadas. Los conjuntos de automatización declarativos proporcionan una colección opcional de comportamientos predeterminados que corresponden a cada uno de estos modos.

Los modos de implementación son opcionales. Puede implementar agrupaciones sin establecer ni mode ni configurar presets. Los modos de implementación son una comodidad para aplicar un grupo de valores de configuración usados habitualmente a la vez.

Modo de desarrollo

Para desplegar tu paquete en modo de desarrollo, agrega la asignación mode, establecida en development, al destino previsto. Consulte mapeo de destinos de configuración de paquetes. Por ejemplo, este destino denominado dev se trata como destino de desarrollo:

targets:
  dev:
    mode: development

La implementación de un destino en modo de desarrollo mediante la ejecución del comando databricks bundle deploy -t <target-name> implementa los comportamientos siguientes, que se pueden personalizar mediante valores preestablecidos:

• Antepone todos los recursos que no se implementan como archivos o cuadernos con el prefijo [dev ${workspace.current_user.short_name}] y etiqueta cada trabajo implementado y canalización con una etiqueta de dev Azure Databricks.
• Marca las Canalizaciones Declarativas de Lakeflow Spark implementadas relacionadas como development: true.
• Habilita el uso de --cluster-id <cluster-id> en llamadas relacionadas al comando bundle deploy, que invalida todas y cada una de las definiciones de clúster existentes que ya están especificadas en el archivo de configuración de agrupación relacionado. En lugar de usar --cluster-id <cluster-id> en llamadas relacionadas con el comando bundle deploy, puede establecer la asignación de cluster_id aquí, o como asignación secundaria de la asignación de bundle, al identificador del clúster que se va a usar.
• Pausa todas las programaciones y desencadenadores en recursos implementados, como trabajos o monitores de calidad. Reanude las programaciones y los desencadenadores de un trabajo individual estableciendo schedule.pause_status en UNPAUSED.
• Habilite las ejecuciones simultáneas en todos los trabajos implementados para una iteración más rápida. Deshabilite las ejecuciones simultáneas para un trabajo individual estableciendo max_concurrent_runs en 1.
• Deshabilite el bloqueo de implementación para una iteración más rápida. Este bloqueo impide que se produzcan conflictos de implementación que es poco probable que se produzcan en modo de desarrollo. Vuelva a habilitar el bloqueo estableciendo bundle.deployment.lock.enabled en true.

Modo de producción

Para implementar su paquete en modo de producción, agregue la asignación mode, configurada como production, al destino previsto. Consulte asignación de objetivos de configuración del paquete. Por ejemplo, este destino denominado prod se trata como destino de producción:

targets:
  prod:
    mode: production

La implementación de un destino en modo de producción mediante la ejecución del comando databricks bundle deploy -t <target-name> implementa los comportamientos siguientes:

• Valida que todas las canalizaciones declarativas de Spark de Lakeflow implementadas relacionadas se marcan como development: false.

• Valida que la rama de Git actual es igual a la rama de Git especificada en el destino. Especificar una rama de Git en el destino es opcional y se puede realizar con una propiedad adicional git como se indica a continuación:

  git:
    branch: main
  

  Esta validación se puede invalidar especificando --force durante la implementación.

• Databricks recomienda usar entidades de servicio para implementaciones de producción. Puede aplicar esto configurando run_as en un principal de servicio. Consulte Entidades de servicio y Especificación de una identidad de ejecución para un flujo de trabajo de paquetes de Automatización declarativa. Si no usa entidades de servicio, tenga en cuenta los siguientes comportamientos adicionales:

  • Valida que las asignaciones artifact_path, file_pathroot_path, o state_path no se invalidan en un usuario específico.
  • Valida que se especifican las asignaciones de run_as y permissions para aclarar qué identidades tienen permisos específicos para las implementaciones.

• A diferencia del comportamiento anterior para establecer la asignación de mode a development, establecer la asignación de mode a production no permite anular ninguna definición de clúster existente especificada en el archivo de configuración de agrupación relacionado, por ejemplo mediante la opción --compute-id <cluster-id> o la asignación de compute_id.

Ajustes personalizados

Los conjuntos de automatización declarativos admiten valores preestablecidos configurables para destinos, lo que permite personalizar los comportamientos de los destinos. Para ver los valores preestablecidos disponibles, consulte la referencia de configuración.

Nota:

A menos que se especifique una excepción para un valor preestablecido, si se establecen mode y presets, los valores preestablecidos anulan el comportamiento del modo predeterminado, y la configuración de recursos individuales anula los valores preestablecidos. Por ejemplo:

• Si el max_concurrent_runs de un trabajo es 10, pero el valor preestablecido jobs_max_concurrent_runs está fijado en 20, el número máximo de ejecuciones simultáneas del trabajo es 10.
• Si una programación se establece en UNPAUSED, pero el valor preestablecido de trigger_pause_status se ajusta a PAUSED, la programación se reanudará.

En el ejemplo siguiente se muestra una configuración de valores preestablecidos personalizada para el destino denominado dev:

targets:
  dev:
    presets:
      name_prefix: 'testing_' # prefix all resource names with testing_
      pipelines_development: true # set development to true for pipelines
      trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
      jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
      tags:
        department: finance