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í. Balíčky vytvořené pomocí starších verzí CLI lze migrovat z modulu nasazení Terraform do modulu přímého nasazení. Viz Migrace existující sady.

Od verze 1.14.0 nástroje Databricks CLI se balíčky, které stále používají modul Terraform, po nasazení automaticky migrují na přímý modul, pokud převod při zkušebním spuštění proběhne bez problémů. Chcete-li zrušit odběr, nastavte bundle.engine: terraform nebo DATABRICKS_BUNDLE_ENGINE=terraform. Viz Přímé nasazení nového balíčku.

Důležité

Databricks doporučuje migraci na přímý engine, protože engine pro nasazení Terraformu bude brzy deaktivován. Viz Deklarativní balíčky automatizace budou brzy výchozí pro použití přímého modulu nasazení.

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:

  • Rychlejší nasazení: Nasazení balíčků je až o 40 % rychlejší.
  • Výkonnější a podrobnější ověřování a plánování: Podrobné rozdíly změn pomocí bundle plan -o json sestav podrobností o jednotlivých polích vysvětlující, co aktivovalo danou akci.
  • Plány, které lze znovu použít: bundle deploy --plan plan.json spustí dříve vytvořený plán, čímž zajistí, že se do produkce dostanou pouze schválené akce, a urychlí nasazení, protože výpočet plánu se přeskočí.
  • Jednoduché nastavení: Vyhnete se problémům s firewally, proxy servery a vlastními registry poskytovatelů.
  • Další prostředky: Podporují se další prostředky, jako jsou katalogy, externí umístění, koncové body vyhledávání AI a prostory Genie.
  • Neměnné složky: Prostředky lze volitelně nasadit do neměnné složky pouze pro čtení kvůli ochraně proti neoprávněným změnám a kvůli zajištění konzistence nasazení. Viz immutable_folder.

Začínáme používat přímé nasazení

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

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
    

    Note

    Ve verzích Databricks CLI 0.280.0 až 1.4.x se spustí bundle plan a migrace se zastaví, pokud plán hlásí jakékoli akce. V tomto případě proveďte nové nasazení a opakujte migraci. Pokud to stále selže, můžete kontrolu plánu přeskočit pomocí --noplancheck.

  3. Ověřte, že migrace proběhla úspěšně. Spusťte databricks bundle plan, což by mělo proběhnout úspěšně a nehlásit žádné akce.

    databricks bundle plan -t my_target
    

    Note

    Plán může hlásit změny prostředků i v případě, že místní konfigurace odpovídá nasazeného prostředku. K tomu může dojít, protože předchozí soubor stavu Terraformu obsahuje pole metadat, která platforma naplní po nasazení, která nejsou v konfiguraci sady prostředků. Tyto rozdíly nejsou skutečnými posuny konfigurace a nemění chování úloh. Přímý mechanismus je při dalším bundle deploy uvede do souladu. Podrobnosti o tom, jak přímý modul vypočítá rozdíly, najdete v tématu Výpočet rozdílu stavu prostředků.

    • 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.

Porovnání nástrojů pro nasazení

Nový modul přímého nasazení se většinou chová stejně jako modul nasazení Terrform, ale existuje několik rozdílů.

Výpočet rozdílu stavu prostředků

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í.

Nastavení konfigurace bylo odebráno

Dva moduly zpracovávají nastavení, která odeberete z konfigurace sady, odlišně:

  • Při použití nástroje Terraform odstranění nastaveného pole z vašeho databricks.yml ponechá odpovídající hodnotu na platformě beze změny. Terraform spravuje jenom pole, která jsou explicitně přítomná v konfiguraci, takže odebrané pole uchovává jakoukoli hodnotu, kterou měla v době posledního nasazení.
  • S přímým enginem odstranění pole „set“ z databricks.yml vrátí hodnotu na výchozí hodnotu prostředku. Vzhledem k tomu, že přímý modul porovnává vaši místní konfiguraci s předchozím snímkem, považuje se za změnu pole, které už není k dispozici, a prostředek se aktualizuje na výchozí hodnotu v dalším nasazení.

Pokud chcete zachovat hodnotu, nastavte ji explicitně v konfiguraci a nespoléhat se na dříve nasazenou hodnotu.

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:

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.