Migrer et configurer des canaux Conda

Les canaux de packages Conda préconfigurés sont supprimés des images de cluster Managed Service pour Apache Spark et des environnements d'exécution sans serveur. Ce document explique comment migrer et configurer des canaux Conda pour vos charges de travail.

Suppression des canaux Conda préconfigurés

Auparavant, les images Managed Service pour Apache Spark incluaient des canaux Conda préconfigurés, tels que le dépôt defaults d'Anaconda. En raison de modifications apportées aux licences, Managed Service pour Apache Spark supprime tous les pointeurs de canaux préconfigurés de toutes les images et de tous les environnements d'exécution sans serveur Managed Service pour Apache Spark passés et futurs.

  • Modifications : les commandes qui exécutent conda install PACKAGE sans canal explicitement fourni ne résolvent plus les packages par rapport aux dépôts par défaut et échouent.
  • Ce qui ne change pas : les installations de packages Python standards à partir de PyPI (pip install PACKAGE ou la propriété de cluster dataproc:pip.packages) ne sont pas du tout affectées.

Disponibilité des images latérales sans canal

Pour aider les développeurs à s'adapter à cette mise à jour, Managed Service pour Apache Spark a publié des versions mineures secondaires sans canaux de publication, comme indiqué dans le tableau suivant. Ces images conservent une compatibilité binaire et de composants à 100% avec les images existantes, la seule différence étant la suppression des canaux Conda préconfigurés.

Piste d'image Anciennes versions ou versions concernées Version latérale publiée sans Conda État et compatibilité
1.3 <= 1.3.95 1.3.96 100% compatible avec 1.3.95 ; canaux Conda supprimés
1.4 <= 1.4.80 1.4.81 100% compatible avec 1.4.80 ; suppression des canaux Conda
1.5 <= 1.5.90 1.5.92 100% compatible avec 1.5.90 ; suppression des canaux Conda
2.0 <= 2.0.160 2.0.161 100% compatible avec 2.0.160 ; canaux Conda supprimés
2.1 <= 2.1.116 2.1.117, et 2.1.119 et versions ultérieures Version compatible ; canaux Conda supprimés
2.2 <= 2.2.84 2.2.85, 2.2.87 et versions ultérieures Version compatible ; canaux Conda supprimés
2.3 <= 2.3.31 2.3.32, et 2.3.36 et versions ultérieures Version compatible ; suppression des canaux Conda

Impact de la suppression sur les charges de travail

  • Clusters non épinglés : tout script de création de cluster qui spécifie un alias de version d'image (tel que --image-version=2.2-debian12) reçoit automatiquement la nouvelle image sans canal.
  • Images épinglées ou personnalisées : les clusters épinglés à des versions mineures antérieures ou qui utilisent des images personnalisées continuent de référencer les anciennes configurations de canaux, sauf s'ils sont mis à jour. Si vous utilisez des images épinglées, vous devez demander un délai supplémentaire pour avoir plus de temps et migrer vers des versions sans chaîne compatibles.
  • Échec de l'exécution : toute action d'initialisation, tout script de pipeline ou tout job qui envoie conda install PACKAGE sans spécifier de canal échoue avec des erreurs de résolution de canal.

Configurer les canaux Conda

Si vos charges de travail dépendent de Conda pour installer des packages binaires, vous devez déclarer explicitement votre canal à l'aide de l'une des options suivantes. Pour spécifier des canaux dans les propriétés de cluster liées à Conda, consultez Utiliser les propriétés de cluster liées à Conda.

Option 1 : Indicateur de ligne de commande explicite

Cette option est recommandée pour les installations ponctuelles. Transmettez l'option --channel lorsque vous exécutez conda install :

conda install --channel conda-forge PACKAGE

Vous pouvez également utiliser l'option courte -c :

conda install -c conda-forge PACKAGE

Remplacez PACKAGE par le nom du package à installer.

Option 2 : Actions d'initialisation de cluster

Cette option est recommandée pour les environnements automatisés. Ajoutez une action d'initialisation personnalisée qui préconfigure le canal que vous souhaitez utiliser dans le fichier de configuration .condarc :

#!/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

Migrer depuis d'anciennes images (1.x et 2.0)

Les versions 1.3, 1.4, 1.5 et 2.0 de Managed Service pour Apache Spark ne sont plus compatibles depuis longtemps. L'exécution d'images antérieures présente des risques opérationnels et de sécurité importants, y compris des failles et des expositions courantes connues (CVE) dans les systèmes d'exploitation sous-jacents et les dépendances logicielles Open Source (OSS).

  • Google Cloud désactive définitivement la création d'images pour les pistes 1.x et 2.0.
  • Toutes les actions d'initialisation disponibles dans le dépôt GitHub GoogleCloudDataproc/initialization-actions qui ne sont compatibles qu'avec ces images obsolètes (1.x et 2.0) seront également supprimées.
  • Toutes les charges de travail doivent migrer vers les images latérales sans canaux Conda d'ici le 15 octobre 2026.
  • Toutes les charges de travail doivent migrer vers des versions actives et compatibles (2.1, 2.2, 2.3 ou 3.0 et versions ultérieures).

Pour en savoir plus, consultez Versions d'image Managed Service pour Apache Spark non compatibles.

Extensions disponibles

Managed Service pour Apache Spark propose deux voies d'extension via une liste d'autorisation à activer, qui nécessite l'approbation de l'équipe du service.

Types d'extensions

Les types d'extensions suivants sont disponibles.

Extension de contournement temporaire de Conda

  • Validité : jusqu'au 31 octobre 2026 maximum.
  • Objectif : fournir une marge opérationnelle immédiate aux clients dont les déploiements ou actions d'initialisation automatisés sont interrompus en raison du changement d'alias d'image par défaut le 25 août 2026 et le 1er septembre 2026.
  • Avantage : permet aux projets de conserver temporairement le comportement précédent tout en modifiant les scripts pour inclure --channel ou passer à des images sans canal.

Extension de l'abandon des anciennes images

  • Validité : jusqu'au 31 décembre 2026.
  • Objectif : Pour les charges de travail critiques exécutées sur la version 1.x ou 2.0 qui ne peuvent pas refactoriser immédiatement le code pour les environnements OS Spark 3.x ou plus récents.
  • Avantage : Vous permet de continuer à créer des clusters sur les versions obsolètes jusqu'à fin 2026, ce qui évite les arrêts de production immédiats.
  • Condition préalable : vous ne pouvez obtenir cette extension que si vos charges de travail 1.x et 2.0 actuelles utilisent des images latérales compatibles avec Conda.

Exigences concernant les extensions

Les extensions sont régies par des contraintes de conformité et d'infrastructure. Pour être approuvé, vous devez remplir toutes les conditions suivantes :

  • Projets existants uniquement : les extensions s'appliquent strictement aux ID de projet Google Cloudqui ont un historique d'exécution actif de ces versions avant août 2026. Les nouveaux projets ne seront pas ajoutés à la liste d'autorisation.
  • Changement d'image latéral obligatoire d'ici le 31 octobre 2026 : si vous bénéficiez d'une extension sur la version 1.x ou 2.0, vous devez migrer vos configurations de création de cluster vers les versions mineures latérales compatibles avec Conda (1.3.96, 1.4.81, 1.5.92 et 2.0.161) au plus tard le 31 octobre 2026.
  • Aucune utilisation de la région global : pour les versions d'image 1.5 et antérieures, les clusters ne doivent pas être déployés dans l'ancienne région global. Les charges de travail doivent utiliser des points de terminaison régionaux spécifiques (par exemple, us-central1 ou europe-west1).
  • Feuille de route de migration engagée : vous devez disposer d'un plan de modernisation actif pour migrer les charges de travail vers des versions compatibles avec Conda (2.2 et versions ultérieures, ou 3.0) avant la date limite du 31 décembre 2026.

Demander une extension

Pour demander à ce que votre extension soit ajoutée à la liste d'autorisation, envoyez une demande par l'un des canaux suivants :

  • E-mail : envoyez votre demande directement à l'adresse dataproc-msa-support@google.com.
  • Demande d'assistance : déposez une demande auprès de Cloud Customer Care en faisant référence au contrat-cadre de services d'abandon de Dataproc Conda.
  • Équipe chargée du compte : contactez votre responsable de compte technique (TAM) ou votre ingénieur client (CE) Google Cloud dédié.

Veuillez inclure les informations suivantes dans votre demande :

  • Nom de l'organisationGoogle Cloud
  • ID et numéros de projet Google Cloud cibles
  • Noms ou UUID des clusters concernés
  • Versions d'image actuellement utilisées
  • Motif de la demande de prolongation et date d'achèvement de la migration ciblée

Checklist pour les canaux Conda conformes

Suivez les priorités suivantes dans l'ordre.

Priorité 1 : Découverte et inventaire des charges de travail

  • Identifier les images obsolètes : auditez les projets de votre organisation pour identifier les clusters exécutés sur les versions 1.3, 1.4, 1.5 ou 2.0.

    La commande suivante liste la version d'image des clusters actifs dans une région :

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

    Remplacez REGION par la région où se trouvent vos clusters.

  • Auditez l'utilisation de Conda : examinez vos actions d'initialisation (--initialization-actions), vos scripts de démarrage et vos scripts d'envoi de jobs pour détecter les appels de conda install.

Priorité 2 : Triage immédiat des échecs

Si vous rencontrez des pannes, procédez comme suit :

  • Si les pipelines automatisés échouent en raison de packages Conda manquants, corrigez immédiatement l'action ou le script d'initialisation en ajoutant --channel conda-forge (ou -c conda-forge) :

    conda install -c conda-forge PACKAGE

  • Si la création du cluster échoue en raison de blocs d'images obsolètes, contactez immédiatement dataproc-msa-support@google.com ou votre TAM pour demander l'inscription temporaire à la liste d'autorisation.

Priorité 3 : Effectuer un échange de sous-mineur latéral

Cette étape ne nécessite aucune modification de code.

  • Pour les pipelines qui ne peuvent pas être immédiatement mis à niveau vers la version 2.2 ou ultérieure de l'image, mettez à jour vos modèles de création de clusters (par exemple, Terraform, Apache Airflow DataprocCreateClusterOperator, Managed Service pour Apache Airflow et scripts CI/CD) pour utiliser la version latérale sans canaux :

    • Remplacez 1.3.* par 1.3.96.
    • Remplacez 1.4.* par 1.4.81.
    • Remplacez 1.5.* par 1.5.92.
    • Remplacez 2.0.* par 2.0.161.

  • Pourquoi cela fonctionne : ces images contiennent les mêmes versions d'Apache Spark, d'Apache Hadoop, d'Apache Hive et de Java que les versions mineures précédentes. Ils garantissent une compatibilité à 100% des applications sans nécessiter de modification du code.

Priorité 4 : Recréer les clusters de longue durée

Si vous avez des clusters statiques de longue durée déployés sur des images plus anciennes, planifiez un intervalle de maintenance pour les recréer à l'aide des dernières versions mineures latérales (ou des versions 2.x ou 3.x compatibles avec Conda). La recréation des clusters garantit qu'ils récupèrent toutes les mises à jour de sécurité et de configuration critiques.

Priorité 5 : Planifier une mise à niveau complète vers des versions compatibles

L'objectif de réalisation de cette priorité est fixé au quatrième trimestre 2026.

  • Établissez des environnements de test sur la version d'image 2.2 (Debian 12, Spark 3.5) ou la version d'image 3.0, qui est généralement disponible (GA).
  • Validez les jobs PySpark, Scala et Java par rapport aux spécifications de l'API Spark 3.x.
  • Si vous avez besoin d'une assistance dédiée à la modernisation, utilisez l' Google CloudProfessional Services Organization (PSO) ou des partenaires de migration certifiés, tels que Wipro et HCL.

Questions fréquentes

Les sections suivantes répondent aux questions fréquentes sur la suppression du canal Conda.

Généralités et contexte

Les questions suivantes expliquent pourquoi ces modifications sont apportées et en quoi elles diffèrent les unes des autres.

Pourquoi Managed Service pour Apache Spark supprime-t-il les canaux Conda préconfigurés ?

En raison de modifications apportées aux exigences de licence, Managed Service pour Apache Spark dissocie ses services des canaux Anaconda propriétaires et passe à des mécanismes d'empaquetage Open Source standards.

Quelle est la différence entre la suppression d'un canal Conda et l'abandon d'une image ?

  • La suppression du canal Conda affecte toutes les versions de Managed Service pour Apache Spark, y compris les versions 2.1, 2.2 et 2.3 activement compatibles, ainsi que les environnements d'exécution sans serveur. Il supprime les pointeurs par défaut vers les dépôts Anaconda.
  • L'abandon des images concerne spécifiquement les anciennes images 1.x et 2.0. Ces images sont en fin de vie, ne reçoivent plus de correctifs de sécurité et ne pourront plus être utilisées pour créer des clusters.

Problèmes techniques et de compatibilité

Les questions suivantes portent sur l'impact des modifications sur l'installation des packages Python, l'utilisation de Conda et la compatibilité des images.

Ce changement affecte-t-il pip install ou dataproc:pip.packages ?

Non. Les installations de packages Python standards à l'aide de pip ou de la propriété de cluster Managed Service pour Apache Spark dataproc:pip.packages sont extraites directement de l'index de packages Python (PyPI). PyPI est totalement indépendant de Conda et n'est en aucun cas affecté.

Mon organisation peut-elle continuer à utiliser les packages Anaconda ou Conda ?

Oui. Vous pouvez continuer à utiliser Conda pour gérer vos environnements. Toutefois, vous devez fournir explicitement le canal du dépôt. Vous pouvez pointer vers le canal conda-forge compatible avec la communauté (en ajoutant -c conda-forge) ou vers le miroir de dépôt Anaconda privé et sous licence de votre organisation à l'aide d'actions d'initialisation.

Quelle erreur exacte se produit si mon script n'est pas mis à jour ?

Lorsque vous exécutez conda install PACKAGE sur une image sans canal, Conda renvoie une erreur indiquant qu'aucun canal n'est configuré ou que le package demandé est introuvable dans les chemins de recherche par défaut. Exemple : PackagesNotFoundError: The following packages are not available from current channels.

Qu'est-ce qu'une image secondaire latérale et pourquoi l'utiliser ?

Une image submineure latérale (telle que 1.5.92 pour la version 1.5 ou 2.0.161 pour la version 2.0) est une version d'image dans laquelle les composants principaux de l'écosystème de big data (Hadoop, Spark, Hive, Presto et les environnements d'exécution Java) restent identiques aux versions précédentes de cette version, mais les canaux Conda sous-jacents ont été supprimés. La mise à niveau vers une version mineure latérale ne nécessite aucune modification du code de vos jobs Spark.

Déploiements et écosystème

Les questions suivantes portent sur l'impact des modifications sur les charges de travail sans serveur, les déploiements Google Kubernetes Engine (GKE) et les services d'orchestration gérés.

Quel est l'impact sur Managed Service pour Apache Spark sans serveur ?

À partir du 25 août 2026, les charges de travail par lot sans serveur nouvellement envoyées s'exécuteront sur des images d'exécution de base qui ne contiennent pas de canaux Conda préconfigurés. Si vous packagez les dépendances à l'aide d'images de conteneur personnalisées ou de fichiers tar.gz d'environnement Conda, assurez-vous que vos définitions de compilation spécifient --channel conda-forge ou votre canal privé.

Quel est l'impact sur Managed Service pour Apache Spark sur Google Kubernetes Engine ?

Les images Managed Service pour Apache Spark sur GKE ont été mises à jour pour supprimer les canaux Conda préconfigurés (par exemple, l'image d'exécution 3.5-dataproc-28 et les versions ultérieures). Les Dockerfiles de conteneurs personnalisés qui exécutent conda install doivent être mis à jour pour transmettre un --channel explicite.

Les orchestrateurs gérés tels que Managed Service pour Apache Airflow ou Cloud Data Fusion sont-ils concernés ?

Les pipelines standards par défaut gérés par Managed Airflow ou Cloud Data Fusion qui appellent des tâches de création de clusters Managed Service pour Apache Spark intégrées ne sont pas affectés, sauf si votre workflow repose sur des actions d'initialisation personnalisées qui exécutent des commandes conda install non signalées ou épinglent des images 1.x ou 2.0 obsolètes.

Assistance

La question suivante décrit où obtenir de l'aide pour votre migration.

Où puis-je obtenir de l'aide technique pour ma migration ?

  • Pour obtenir de l'aide technique ou demander à être ajouté à la liste d'autorisation, contactez dataproc-msa-support@google.com ou ouvrez une demande auprès de Cloud Customer Care.
  • Pour obtenir de l'aide concernant la migration d'entreprise, l' Google Cloud équipe PSO propose des packages de modernisation structurés. Des intégrateurs de systèmes (SI) certifiés, dont Wipro et HCL, fournissent des services de migration dédiés éligibles aux fonds pour les services partenaires (PSF, Partner Service Funds).