Migrace na modul přímého nasazení

Deklarativní balíčky automatizace byly původně postaveny na zprostředkovateli Databricks Terraform pro správu nasazení. Rozhraní příkazového řádku Databricks verze 0.279.0 a vyšší však podporují dva různé moduly nasazení: terraform a přímý. Modul přímého nasazení poskytuje významné výhody a nezávisí na Terraformu.

Nové balíčky vytvořené pomocí Databricks CLI verze 1.3.0 a novější ve výchozím nastavení používají mechanismus přímého nasazení. Sady vytvořené pomocí starších verzí rozhraní příkazového řádku je možné migrovat z modulu nasazení Terraform do přímého modulu nasazení pomocí kroků pro migraci popsaných na této stránce.

Důležité

Databricks doporučuje migraci na přímý modul, protože modul nasazení Terraform bude brzy zastaralý a modul přímého nasazení se stane výchozím. Viz Deklarativní balíčky automatizace budou brzy výchozí pro použití přímého modulu nasazení.

Jaké jsou výhody přímého nasazení?

Nový modul přímého nasazení používá sadu Databricks Go SDK a má následující výhody:

• Vyhýbejte se problémům s firewally, proxy servery a uživatelsky definovanými registry poskytovatelů.
• Podrobné rozdíly změn, které jsou k dispozici pomocí bundle plan -o json
• Rychlejší nasazení
• Žádný požadavek na stažení Terraformu a terraform-provider-databricks před nasazením
• Zkrácení doby potřebné k vydání nových zdrojů balíčku, protože není nutné sladit se s vydáním poskytovatele Terraformu

Jak začít používat přímé nasazení?

Pokud chcete začít používat nový modul přímého nasazení:

• U existujících sad je migrujte pomocí databricks bundle deployment migrate.
• Nasaďte nové sady tak, aby proměnná prostředí DATABRICKS_BUNDLE_ENGINE byla nastavena na direct.

Migrace existující sady

Modul přímého nasazení používá vlastní soubor stavu JSON. Schéma se liší od souboru stavu JSON Terraformu. Příkazbundle deployment migrate převede soubor stavu Terrformu (terraform.tfstate) na přímý soubor stavu nasazení (resources.json). Příkaz načte ID-čka z existujícího nasazení.

1. Provedení úplného nasazení pomocí Terraformu:

   databricks bundle deploy -t my_target
   

2. Migrace nasazení:

   databricks bundle deployment migrate -t my_target
   

3. Ověřte, že migrace proběhla úspěšně. Příkaz databricks bundle plan by měl být úspěšný a neměl by zobrazovat žádné změny.

   databricks bundle plan -t my_target
   

   • Pokud se ověření nezdaří, odeberte nový soubor stavu:

     rm .databricks/bundle/my_target/resources.json
     

   • Pokud ověření proběhne úspěšně, nasaďte sadu pro synchronizaci stavového souboru do pracovního prostoru:

     databricks bundle deploy -t my_target
     

Přímé nasazení nové sady

Příkaz bundle migrate nefunguje na balíčcích, které nebyly nikdy nasazeny, protože neexistuje žádný stavový soubor. Místo toho udělejte jednu z těchto věcí:

• Nastavte bundle.engine v databricks.yml:

  bundle:
    engine: direct
  

• Nastavte proměnnou DATABRICKS_BUNDLE_ENGINE prostředí a nasaďte:

  DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target
  

Pokud je nastavená konfigurace i proměnná prostředí, má tato konfigurace přednost.

Jaké jsou změny v modulu přímého nasazení?

Nový modul přímého nasazení se většinou chová stejně jako modul nasazení Terrform, ale existuje několik rozdílů. Přímý modul konkrétně sleduje místní a vzdálený stav prostředků samostatně a řeší nahrazení prostředků ve dvou krocích.

Výpočet odlišností stavu zdrojů

Na rozdíl od Terraformu, který udržuje jednotný stav prostředků (kombinaci místní konfigurace a vzdáleného stavu), nový modul tyto stavy drží oddělené a zaznamenává pouze místní konfiguraci ve svém souboru se stavem.

Výpočet rozdílu stavu prostředků se provádí ve dvou krocích:

1. Konfigurace místního balíčku je porovnávána s konfigurací snímku použitou pro nejnovější nasazení. Vzdálený stav nemá žádnou roli.
2. Vzdálený stav se porovnává s konfigurací snímku použitou pro nejnovější nasazení.

Výsledek je následující:

• databricks.yml změny zdrojů nikdy nejsou ignorovány a vždy aktivují aktualizaci.
• Pole prostředků, která nejsou zpracována implementací, nevyvolávají chybu nekonzistentního výsledku. Tyto prostředky jsou úspěšně nasazeny přímým enginem, ale to může vést k odchylce. Nasazené prostředky se aktualizují během dalšího plánu nebo nasazení.

Vyhledání náhrady zdroje

Jsou k dispozici náhrady prostředků pro řešení ID prostředků, například ${resources.jobs.my_job.id}. Viz náhrady. Řešení náhrad prostředků v modulu přímého nasazení se provádí ve dvou krocích:

1. Odkazy odkazující na pole, která jsou přítomna v místní konfiguraci, se přeloží na hodnotu zadanou v místní konfiguraci.
2. Odkazy, které nejsou přítomné v místní konfiguraci, jsou řešeny ze vzdáleného stavu. Jedná se o stav načtený pomocí příslušného GET požadavku pro daný prostředek.

Schéma, které se používá k vyřešení ${resource.*} nahrazení, je v souboru out.fields.txt. Pole označená jako ALL a STATE lze je použít pro místní rozlišení. Pole označená jako ALL nebo REMOTE se dají použít pro vzdálené rozlišení.

Kompatibilita prostředků

Následující prostředky vyžadují modul přímého nasazení a nejsou podporovány s modulem nasazení Terraform:

• katalogy (Unity Catalog)
• externí umístění (Unity Catalog)
• Koncové body vektoru vyhledávání

Kromě toho je pole lifecycle.started k dispozici pouze v enginu přímého nasazení a pouze pro apps, clusters a sql_warehouses. Když je nastavena na true, nasadí prostředek ve spuštěném režimu. Viz životní cyklus.