Migración al motor de implementación directa

Los paquetes declarativos de automatización se construyeron originalmente sobre el proveedor de Terraform de Databricks para gestionar las implementaciones. Sin embargo, las versiones 0.279.0 y posteriores de la CLI de Databricks admiten dos motores de implementación diferentes: terraform y direct. El motor de implementación directa proporciona ventajas significativas y no depende de Terraform.

Los nuevos conjuntos creados con la CLI de Databricks versión 1.3.0 y versiones posteriores usan el motor de implementación directa de forma predeterminada. Los bundles que aún usan el motor de despliegue de Terraform se migran automáticamente al motor directo, por lo que no se requiere configuración. Consulta Primeros pasos con el despliegue directo.

Para evitar la migración automática, configure bundle.engine: terraform o DATABRICKS_BUNDLE_ENGINE=terraform. Esto evita la migración automática en todas las versiones de Databricks CLI. En las versiones de la CLI de Databricks hasta la 1.19, el motor Terraform sigue utilizándose. En la CLI de Databricks versión 1.20.0 y superior, se produce un error. Consulte Cómo implementar directamente un nuevo paquete.

Ventajas de implementación directa

El nuevo motor de implementación directa usa el SDK de Databricks Go y tiene las siguientes ventajas:

• Implementaciones más rápidas: las implementaciones de agrupación son de hasta 40% más rápidas.
• Validación y planificación más potentes y detalladas: comparativas detalladas de los cambios mediante bundle plan -o json informes con detalles por campo que explican qué ha desencadenado una acción determinada.
• Planes reproducibles: bundle deploy --plan plan.json ejecuta un plan creado anteriormente, lo que garantiza que solo las acciones aprobadas alcancen la producción y las implementaciones más rápidas porque se omite el cálculo del plan.
• Configuración sencilla: se evitan problemas con firewalls, servidores proxy y registros de proveedor personalizados.
• Más recursos: se admiten recursos adicionales, como catálogos, ubicaciones externas, puntos de conexión de AI Search y espacios de Genie.
• Carpetas inmutables: los recursos se pueden implementar opcionalmente en una carpeta inmutable de solo lectura para la protección contra alteraciones y la coherencia de la implementación. Consulte immutable_folder.

Empieza a usar el despliegue directo

El motor de despliegue directo es el predeterminado para los nuevos paquetes creados con la CLI de Databricks versión 1.3.0 y superiores. En la versión 1.14 de la CLI de Databricks en adelante, los bundles que utilizan el motor Terraform se migran automáticamente al motor directo al desplegarse.

En las versiones 1.8 y superiores de la CLI de Databrick, puedes migrar un paquete al motor directo configurando engine: direct. Consulte Cómo implementar directamente un nuevo paquete.

Implementar directamente un nuevo paquete

Para configurar explícitamente el motor de despliegue directo, haz una de las siguientes acciones:

• Establezca bundle.engine en su archivo "databricks.yml".

  bundle:
    engine: direct
  

• Establezca la variable de DATABRICKS_BUNDLE_ENGINE entorno e implemente:

  DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target
  

Si se establecen la configuración y la variable de entorno, la configuración tiene prioridad.

Comparación del motor de implementación

El nuevo motor de implementación directa se comporta principalmente igual que el motor de implementación terrform, pero hay algunas diferencias.

Cálculo de diferencias del estado del recurso

A diferencia de Terraform que mantiene un único estado de recurso (una combinación de configuración local y estado remoto), el nuevo motor mantiene estas configuraciones locales independientes y solo registra la configuración local en su archivo de estado.

El cálculo de diferencias de estado de recursos se realiza en dos pasos:

1. La configuración del paquete local se compara con la configuración de instantánea usada para la implementación más reciente. El estado remoto no desempeña ningún rol.
2. El estado remoto se compara con la configuración de la imagen instantánea usada para la implementación más reciente.

El resultado es que:

• databricks.yml los cambios de recursos nunca se omiten y siempre desencadenarán una actualización.
• Los campos de recursos no administrados por la implementación no desencadenan un error de resultado incoherente. El motor directo despliega con éxito estos recursos, pero esto puede derivar en una desviación. Los recursos implementados se actualizan durante el siguiente plan o implementación.

Se han quitado las opciones de configuración

Los dos motores gestionan de forma diferente los ajustes que eliminas de la configuración del paquete:

• Con el motor de Terraform, al eliminar un campo de tipo set de su databricks.yml, el valor correspondiente permanece sin cambios en la plataforma. Terraform solo administra los campos que están presentes explícitamente en la configuración, por lo que un campo quitado conserva el valor que tenía en el momento de la última implementación.
• Con el motor directo, al quitar un campo definido de tu databricks.yml, el valor vuelve al valor predeterminado del recurso. Dado que el motor directo compara la configuración local con la instantánea anterior, un campo que ya no está presente se trata como un cambio y el recurso se actualiza a su valor predeterminado en la siguiente implementación.

Para conservar un valor, establézcalo explícitamente en la configuración en lugar de confiar en el valor implementado anteriormente.

Búsqueda de sustituciones de recursos

Las sustituciones de recursos están disponibles para la resolución de IDs de recursos, por ejemplo, ${resources.jobs.my_job.id}. Consulte Sustituciones. La resolución de sustituciones de recursos en el motor de implementación directa se realiza en dos pasos:

1. Las referencias que apuntan a campos que están presentes en la configuración local se resuelven en el valor proporcionado en la configuración local.
2. Las referencias que no están presentes en la configuración local se resuelven desde el estado remoto. Este es el estado capturado mediante la solicitud adecuada GET para un recurso determinado.

El esquema que se usa para resolver una ${resource.*} sustitución se encuentra en el archivo out.fields.txt. Los campos marcados como ALL y STATE se pueden usar para la resolución local. Los campos marcados como ALL o REMOTE se pueden usar para la resolución remota.

Compatibilidad de recursos

Los siguientes recursos requieren el motor de implementación directa y no se admiten con el motor de implementación de Terraform:

• Políticas de clúster
• Catálogos de Unity
• Ubicaciones externas de Unity Catalog
• Secretos del Catálogo Unity
• Espacios de Genie
• Conjuntos de instancias
• Ejecuciones de trabajos
• Puntos de conexión de AI Search
• Servicios MCP
• Servicios de proveedores modelo
• Servicios de modelos
• Calendarios de instantáneas de Postgres

Además, el lifecycle.started campo solo está disponible en el motor de implementación directa y solo para apps, clustersy sql_warehouses. Al establecerse en true, despliega el recurso en modo iniciado. Consulte ciclo de vida.