Conda-Kanäle migrieren und einrichten

Vorkonfigurierte Conda-Paket-Channels werden aus Managed Service for Apache Spark-Cluster-Images und serverlosen Runtimes entfernt. In diesem Dokument wird beschrieben, wie Sie Conda-Channels für Ihre Arbeitslasten migrieren und konfigurieren.

Entfernung vorkonfigurierter Conda-Kanäle

Bisher enthielten Managed Service for Apache Spark-Images vorkonfigurierte Conda-Channels, z. B. das defaults-Repository von Anaconda. Aufgrund von Lizenzänderungen werden im Managed Service for Apache Spark alle vorkonfigurierten Channel-Pointer aus allen bisherigen und zukünftigen Managed Service for Apache Spark-Images und serverlosen Runtimes entfernt.

  • Änderungen:Befehle, die conda install PACKAGE ohne explizit angegebenen Channel ausführen, lösen Pakete nicht mehr anhand von Standard-Repositories auf und schlagen fehl.
  • Was sich nicht ändert: Standardmäßige Python-Paketinstallationen von PyPI (pip install PACKAGE oder die Cluster-Property dataproc:pip.packages) sind davon nicht betroffen.

Verfügbarkeit von seitlichen Bildern ohne Kanäle

Damit Entwickler sich an diese Änderung anpassen können, wurden für Managed Service for Apache Spark untergeordnete Release-Versionen ohne Channels veröffentlicht, die in der folgenden Tabelle aufgeführt sind. Diese Images sind zu 100% binär- und komponentenkompatibel mit vorhandenen Images. Der einzige Unterschied besteht darin, dass die vorkonfigurierten Conda-Channels entfernt wurden.

Bildspur Alte oder betroffene Versionen Veröffentlichte laterale Version ohne Conda Status und Kompatibilität
1.3 <= 1.3.95 1.3.96 Zu 100% mit 1.3.95 kompatibel; Conda-Kanäle entfernt
1,4 <= 1.4.80 1.4.81 100% kompatibel mit 1.4.80; Conda-Kanäle entfernt
1,5 <= 1.5.90 1.5.92 100% kompatibel mit 1.5.90; Conda-Kanäle entfernt
2.0 <= 2.0.160 2.0.161 Zu 100% mit 2.0.160 kompatibel; Conda-Kanäle entfernt
2.1 <= 2.1.116 2.1.117 und 2.1.119 und höher Unterstützte Version; Conda-Channels entfernt
2.2 <= 2.2.84 2.2.85 und 2.2.87 und höher Unterstützter Release; Conda-Channels entfernt
2.3 <= 2.3.31 2.3.32 und 2.3.36 und höher Unterstützte Version; Conda-Channels entfernt

Auswirkungen der Entfernung auf Arbeitslasten

  • Nicht angepinnte Cluster:Bei jedem Skript zum Erstellen von Clustern, in dem ein Alias für die Image-Version (z. B. --image-version=2.2-debian12) angegeben ist, wird automatisch das neue kanalfreie Image verwendet.
  • Angepinnte oder benutzerdefinierte Images:Cluster, die an frühere untergeordnete Releases angepinnt sind oder benutzerdefinierte Images verwenden, verweisen weiterhin auf alte Channelkonfigurationen, sofern sie nicht aktualisiert werden. Wenn Sie angepinnte Bilder verwenden, müssen Sie eine Verlängerung beantragen, um zusätzliche Zeit zu erhalten und zu unterstützten, kanalfreien Versionen zu migrieren.
  • Ausführungsfehler: Jede Initialisierungsaktion, jedes Pipeline-Script oder jeder Job, der conda install PACKAGE ohne Angabe eines Kanals sendet, schlägt mit Kanalauflösungsfehlern fehl.

Conda-Kanäle konfigurieren

Wenn Ihre Arbeitslasten von Conda abhängig sind, um Binärpakete zu installieren, müssen Sie Ihren Channel explizit mit einer der folgenden Optionen deklarieren. Wenn Sie stattdessen Channels in Conda-bezogenen Clusterattributen angeben möchten, lesen Sie den Abschnitt Conda-bezogene Clusterattribute verwenden.

Option 1: Explizites Befehlszeilen-Flag

Diese Option wird für Ad-hoc-Installationen empfohlen. Übergeben Sie das Flag --channel, wenn Sie conda install ausführen:

conda install --channel conda-forge PACKAGE

Oder verwenden Sie das kurze Flag -c:

conda install -c conda-forge PACKAGE

Ersetzen Sie PACKAGE durch den Namen des zu installierenden Pakets.

Option 2: Clusterinitialisierungsaktionen

Diese Option wird für automatisierte Umgebungen empfohlen. Fügen Sie eine benutzerdefinierte Initialisierungsaktion hinzu, die den Kanal vorkonfiguriert, den Sie in der Konfigurationsdatei .condarc verwenden möchten:

#!/bin/bash
# Preconfigure the community conda-forge channel or a private enterprise repository.
conda config --add channels conda-forge
conda config --set channel_priority strict

Von Legacy-Images (1.x und 2.0) migrieren

Die Managed Service for Apache Spark-Versionen 1.3, 1.4, 1.5 und 2.0 werden seit längerer Zeit nicht mehr unterstützt. Das Ausführen älterer Images birgt erhebliche Betriebs- und Sicherheitsrisiken, einschließlich bekannter Common Vulnerabilities and Exposures (CVEs) in zugrunde liegenden Betriebssystemen und Open-Source-Software (OSS)-Abhängigkeiten.

  • Google Cloud wird die Bilderstellung für die Tracks 1.x und 2.0 dauerhaft deaktiviert.
  • Alle Initialisierungsaktionen, die im GitHub-Repository GoogleCloudDataproc/initialization-actions verfügbar sind und nur diese verworfenen Images (1.x und 2.0) unterstützen, werden ebenfalls entfernt.
  • Alle Arbeitslasten müssen bis zum 15. Oktober 2026 zu den seitlichen Bildern ohne Conda-Channels migriert werden.
  • Alle Arbeitslasten müssen letztendlich zu aktiven, unterstützten Versionen (2.1, 2.2, 2.3 oder 3.0 und höher) migriert werden.

Weitere Informationen finden Sie unter Nicht unterstützte Managed Service for Apache Spark-Imageversionen.

Verfügbare Erweiterungen

Managed Service for Apache Spark bietet zwei Erweiterungspfade über eine Zulassungsliste mit Opt-in, für die eine Genehmigung durch das Serviceteam erforderlich ist.

Erweiterungstypen

Die folgenden Erweiterungstypen sind verfügbar.

Temporäre Conda-Problemumgehungserweiterung

  • Gültigkeit:Maximal bis zum 31. Oktober 2026.
  • Zweck:Bietet einen sofortigen operativen Puffer für Kunden, deren automatische Bereitstellungen oder Initialisierungsaktionen aufgrund der standardmäßigen Umstellung des Bild-Alias am 25. August 2026 und 1. September 2026 fehlschlagen.
  • Vorteil:Projekte können vorübergehend das bisherige Verhalten beibehalten, während Skripts so geändert werden, dass sie --channel enthalten oder auf kanallose Bilder umgestellt wird.

Einstellung der Legacy-Bilderweiterung

  • Gültigkeit:Bis zum 31. Dezember 2026.
  • Zweck:Für geschäftskritische Arbeitslasten, die unter 1.x oder 2.0 ausgeführt werden und für die der Code nicht sofort für Spark 3.x oder neuere Betriebssystemumgebungen refaktoriert werden kann.
  • Vorteil:Sie können bis Ende 2026 weiterhin Cluster auf Legacy-Tracks erstellen und so unmittelbare Produktionsunterbrechungen vermeiden.
  • Voraussetzung:Sie können diese Erweiterung nur erhalten, wenn für Ihre aktuellen Arbeitslasten der Version 1.x und 2.0 Conda-kompatible seitliche Bilder verwendet werden.

Anforderungen an Erweiterungen

Erweiterungen unterliegen Compliance- und Infrastrukturbeschränkungen. Damit Sie genehmigt werden, müssen Sie alle folgenden Anforderungen erfüllen:

  • Nur für bestehende Projekte:Erweiterungen gelten ausschließlich für Google CloudProjekt-IDs, für die vor August 2026 ein aktiver Verlauf der Ausführung dieser Versionen vorliegt. Neue Projekte werden nicht in die Zulassungsliste aufgenommen.
  • Obligatorischer seitlicher Bildtausch bis zum 31. Oktober 2026:Wenn Sie eine Verlängerung für 1.x oder 2.0 erhalten, müssen Sie Ihre Konfigurationen für die Clustererstellung bis zum 31. Oktober 2026 auf die seitlichen Conda-kompatiblen Subminor-Versionen (1.3.96, 1.4.81, 1.5.92 und 2.0.161) umstellen.
  • Keine Verwendung der Region global:Für Image-Versionen 1.5 und früher dürfen Cluster nicht in der Legacy-Region global bereitgestellt werden. Arbeitslasten müssen bestimmte regionale Endpunkte verwenden (z. B. us-central1 oder europe-west1).
  • Verbindlicher Migrationsplan:Sie benötigen einen aktiven Modernisierungsplan, um Arbeitslasten vor dem 31. Dezember 2026 auf Conda-kompatible unterstützte Versionen (2.2 und höher oder 3.0) zu migrieren.

Fristverlängerung beantragen

Wenn Sie eine Platzierung auf der Zulassungsliste für Erweiterungen beantragen möchten, reichen Sie über einen der folgenden Kanäle einen Antrag ein:

  • E‑Mail:Senden Sie Ihre Anfrage direkt an dataproc-msa-support@google.com.
  • Supportanfrage:Reichen Sie eine Anfrage bei Cloud Customer Care ein, in der auf die Dataproc Conda Deprecation MSA verwiesen wird.
  • Kontoteam:Wenden Sie sich an Ihren dedizierten Google Cloud Technical Account Manager (TAM) oder Customer Engineer (CE).

Dein Antrag muss folgende Angaben enthalten:

  • Google Cloud Name der Organisation
  • Zielprojekt-IDs und ‑nummern Google Cloud
  • Namen oder UUIDs der betroffenen Cluster
  • Aktuell verwendete Image-Versionen
  • Grund für den Antrag auf Verlängerung und angestrebtes Migrationsdatum

Checkliste für konforme Conda-Channels

Gehen Sie die folgenden Prioritäten der Reihe nach durch.

Priorität 1: Arbeitslasten ermitteln und inventarisieren

  • Verworfene Images identifizieren: Prüfen Sie die Projekte Ihrer Organisation auf Cluster, die mit 1.3, 1.4, 1.5 oder 2.0 ausgeführt werden.

    Mit dem folgenden Befehl wird die Image-Version aktiver Cluster in einer Region aufgelistet:

    gcloud dataproc clusters list --region=REGION \
    --format="table(clusterName, status.state, config.softwareConfig.imageVersion)"

    Ersetzen Sie REGION durch die Region, in der sich Ihre Cluster befinden.

  • Conda-Nutzung prüfen:Prüfen Sie Ihre Initialisierungsaktionen (--initialization-actions), Startskripts und Skripts zum Einreichen von Jobs auf Aufrufe von conda install.

Priorität 2: Sofortige Fehlerbehebung

Wenn es zu Ausfällen kommt, gehen Sie so vor:

  • Wenn automatisierte Pipelines aufgrund fehlender Conda-Pakete fehlschlagen, patchen Sie sofort die Initialisierungsaktion oder das Script, indem Sie --channel conda-forge (oder -c conda-forge) hinzufügen:

    conda install -c conda-forge PACKAGE

  • Wenn die Clustererstellung aufgrund von verworfenen Image-Blöcken fehlschlägt, wenden Sie sich sofort an dataproc-msa-support@google.com oder Ihren TAM, um eine vorübergehende Aufnahme in die Zulassungsliste zu beantragen.

Priorität 3: Seitlichen untergeordneten Swap ausführen

Für diesen Schritt sind keine Codeänderungen erforderlich.

  • Für Pipelines, die nicht sofort auf Image-Version 2.2 oder höher aktualisiert werden können, aktualisieren Sie Ihre Vorlagen für die Clustererstellung (z. B. Terraform, Apache Airflow DataprocCreateClusterOperator, Managed Service for Apache Airflow und CI/CD-Skripts), um die kanalfreie laterale Version zu verwenden:

    • Ersetzen Sie 1.3.* durch 1.3.96.
    • Ersetzen Sie 1.4.* durch 1.4.81.
    • Ersetzen Sie 1.5.* durch 1.5.92.
    • Ersetzen Sie 2.0.* durch 2.0.161.

  • Grund: Diese Images enthalten dieselben Versionen von Apache Spark, Apache Hadoop, Apache Hive und Java wie frühere untergeordnete Versionen. Sie garantieren eine 100% ige Anwendungskompatibilität, ohne dass Codeänderungen erforderlich sind.

Priorität 4: Lang laufende Cluster neu erstellen

Wenn Sie statische, lang andauernde Cluster mit älteren Images bereitgestellt haben, planen Sie ein Wartungsfenster, um sie mit den neuesten lateralen untergeordneten Versionen (oder Conda-kompatiblen unterstützten Versionen 2.x oder 3.x) neu zu erstellen. Durch das Neuerstellen der Cluster wird sichergestellt, dass alle wichtigen Sicherheits- und Konfigurationsupdates übernommen werden.

Priorität 5: Vollständiges Upgrade auf unterstützte Versionen planen

Das Ziel für die Fertigstellung dieser Priorität ist das 4. Quartal 2026.

  • Richten Sie Testumgebungen für die Image-Version 2.2 (Debian 12, Spark 3.5) oder die Image-Version 3.0 ein, die allgemein verfügbar ist.
  • PySpark-, Scala- und Java-Jobs anhand von Spark 3.x-API-Spezifikationen validieren.
  • Wenn Sie dedizierte Unterstützung bei der Modernisierung benötigen, wenden Sie sich an die Google CloudProfessional Services Organization (PSO) oder an zertifizierte Migrationspartner wie Wipro und HCL.

Häufig gestellte Fragen

In den folgenden Abschnitten finden Sie Antworten auf häufig gestellte Fragen zum Entfernen des Conda-Channels.

Allgemeines und Hintergrund

In den folgenden Fragen wird erläutert, warum diese Änderungen vorgenommen werden und wie sie sich voneinander unterscheiden.

Warum werden in Managed Service for Apache Spark vorkonfigurierte Conda-Channels entfernt?

Aufgrund von Änderungen an den Lizenzanforderungen entkoppelt Managed Service for Apache Spark seine Dienste von proprietären Anaconda-Kanälen und wechselt zu standardmäßigen Open-Source-Paketierungsmechanismen.

Was ist der Unterschied zwischen dem Entfernen von Conda-Channels und der Einstellung von Images?

  • Die Entfernung des Conda-Kanals betrifft alle Managed Service for Apache Spark-Versionen, einschließlich der aktiv unterstützten Versionen 2.1, 2.2 und 2.3 sowie serverloser Laufzeiten. Dadurch werden Standardzeiger auf Anaconda-Repositories entfernt.
  • Die Einstellung von Bildern betrifft insbesondere Legacy-Bilder der Versionen 1.x und 2.0. Diese Images haben das End of Life erreicht, erhalten keine Sicherheitspatches mehr und können nicht mehr zum Erstellen von Clustern verwendet werden.

Technische Probleme und Kompatibilitätsprobleme

Die folgenden Fragen behandeln, wie sich die Änderungen auf die Installation von Python-Paketen, die Verwendung von Conda und die Image-Kompatibilität auswirken.

Hat diese Änderung Auswirkungen auf pip install oder dataproc:pip.packages?

Nein. Standardmäßige Python-Paketinstallationen mit pip oder der Managed Service for Apache Spark-Cluster-Property dataproc:pip.packages werden direkt aus dem Python Package Index (PyPI) abgerufen. PyPI ist völlig unabhängig von Conda und wird in keiner Weise beeinträchtigt.

Kann meine Organisation weiterhin Anaconda- oder Conda-Pakete verwenden?

Ja. Sie können Conda weiterhin verwenden, um Ihre Umgebungen zu verwalten. Sie müssen jedoch den Repository-Kanal explizit angeben. Sie können mit Initialisierungsaktionen auf den von der Community unterstützten conda-forge-Kanal (durch Hinzufügen von -c conda-forge) oder auf den privaten, lizenzierten Anaconda-Repository-Mirror Ihrer Organisation verweisen.

Welcher Fehler tritt genau auf, wenn mein Script nicht aktualisiert wird?

Wenn Sie conda install PACKAGE für ein kanalfreies Image ausführen, gibt Conda einen Fehler zurück, der darauf hinweist, dass keine Kanäle konfiguriert sind oder das angeforderte Paket in den Standardsuchpfaden nicht gefunden werden kann. Beispiel: PackagesNotFoundError: The following packages are not available from current channels.

Was ist ein untergeordnetes Seitenbild und warum sollte ich es verwenden?

Ein laterales untergeordnetes Image (z. B. 1.5.92 für den 1.5-Track oder 2.0.161 für den 2.0-Track) ist eine Image-Version, in der die wichtigsten Big-Data-Ökosystemkomponenten (Hadoop, Spark, Hive, Presto und Java-Runtimes) mit früheren Versionen in diesem Track identisch sind, die zugrunde liegenden Conda-Channels jedoch entfernt wurden. Für ein Upgrade auf eine laterale Subminor-Version sind keine Codeänderungen für Ihre Spark-Jobs erforderlich.

Bereitstellungen und Ökosystem

Die folgenden Fragen beziehen sich darauf, wie sich die Änderungen auf serverlose Arbeitslasten, Google Kubernetes Engine (GKE)-Bereitstellungen und verwaltete Orchestrierungsdienste auswirken.

Wie wirkt sich das auf Managed Service for Apache Spark Serverless aus?

Ab dem 25. August 2026 werden neu eingereichte serverlose Batcharbeitslasten auf Basis-Laufzeit-Images ausgeführt, die keine vorkonfigurierten Conda-Channels enthalten. Wenn Sie Abhängigkeiten mit benutzerdefinierten Container-Images oder Conda-Umgebungstarballs verpacken, muss in Ihren Build-Definitionen --channel conda-forge oder Ihr privater Channel angegeben sein.

Wie wirkt sich das auf Managed Service for Apache Spark in Google Kubernetes Engine aus?

Die Images für Managed Service for Apache Spark in GKE wurden aktualisiert, um vorkonfigurierte Conda-Channels zu entfernen (z. B. das Laufzeit-Image 3.5-dataproc-28 und nachfolgende Releases). Benutzerdefinierte Container-Dockerfiles, in denen conda install ausgeführt wird, müssen aktualisiert werden, damit ein explizites --channel übergeben wird.

Sind verwaltete Orchestratoren wie Managed Service for Apache Airflow oder Cloud Data Fusion betroffen?

Standardpipelines, die von Managed Airflow oder Cloud Data Fusion verwaltet werden und integrierte Aufgaben zum Erstellen von Managed Service for Apache Spark-Clustern aufrufen, sind nicht betroffen, es sei denn, Ihr Workflow basiert auf benutzerdefinierten Initialisierungsaktionen, die nicht gekennzeichnete conda install-Befehle ausführen oder veraltete 1.x- oder 2.0-Images verwenden.

Support und Unterstützung

In der folgenden Frage wird beschrieben, wo Sie Hilfe bei der Migration erhalten.

Wo erhalte ich technische Unterstützung für meine Migration?

  • Bei der technischen Fehlerbehebung und Anfragen zur Zulassungsliste wenden Sie sich an dataproc-msa-support@google.com oder erstellen Sie einen Fall bei Cloud Customer Care.
  • Für die Unterstützung bei der Enterprise-Migration bietet die Google Cloud PSO strukturierte Modernisierungspakete an. Zertifizierte Systemintegrator-Partner (SI), darunter Wipro und HCL, bieten spezielle Migrationsdienste an, die für Zahlungen für Partner-Dienste (PSF) infrage kommen.