Migrar e configurar canais do Conda

Os canais de pacotes conda pré-configurados estão sendo removidos das imagens de cluster e dos ambientes de execução sem servidor do Serviço Gerenciado para Apache Spark. Este documento descreve como migrar e configurar canais do Conda para suas cargas de trabalho.

Remoção de canais do Conda pré-configurados

Anteriormente, as imagens do Serviço Gerenciado para Apache Spark incluíam canais Conda pré-configurados, como o repositório defaults do Anaconda. Devido a mudanças de licenciamento, o Serviço Gerenciado para Apache Spark vai remover todos os ponteiros de canais pré-configurados de todas as imagens e tempos de execução sem servidor do Serviço Gerenciado para Apache Spark, passadas e futuras.

  • O que muda:os comandos que executam conda install PACKAGE sem um canal fornecido explicitamente não resolvem mais pacotes em repositórios padrão e falham.
  • O que não muda:as instalações padrão de pacotes Python do PyPI (pip install PACKAGE ou a propriedade do cluster dataproc:pip.packages) não são afetadas.

Disponibilidade de imagens laterais sem canais

Para ajudar os desenvolvedores a se adaptarem a essa atualização, o Serviço Gerenciado para Apache Spark lançou versões submenores sem canais de lançamento, conforme listado na tabela a seguir. Essas imagens mantêm 100% de compatibilidade binária e de componentes com as imagens atuais, diferindo apenas na remoção dos canais do Conda pré-configurados.

Faixa de imagem Versões legadas ou afetadas Versão lateral publicada sem o Conda Status e compatibilidade
1.3 <= 1.3.95 1.3.96 100% compatível com 1.3.95; canais do Conda removidos
1.4 <= 1.4.80 1.4.81 100% compatível com 1.4.80; canais do Conda removidos
1.5 <= 1.5.90 1.5.92 100% compatível com 1.5.90; canais do Conda removidos
2.0 <= 2.0.160 2.0.161 100% compatível com 2.0.160; canais do Conda removidos
2.1 <= 2.1.116 2.1.117, 2.1.119 e versões mais recentes Versão compatível; canais do Conda removidos
2.2 <= 2.2.84 2.2.85, 2.2.87 e versões mais recentes Versão compatível; canais do Conda removidos
2.3 <= 2.3.31 2.3.32, 2.3.36 e versões mais recentes Versão compatível; canais do Conda removidos

Como a remoção afeta as cargas de trabalho

  • Clusters não fixados:qualquer script de criação de cluster que especifique um alias de versão de imagem (como --image-version=2.2-debian12) recebe automaticamente a nova imagem sem canais.
  • Imagens fixadas ou personalizadas:os clusters fixados em versões submenores anteriores ou que usam imagens personalizadas continuam fazendo referência a configurações de canal antigas a menos que sejam atualizados. Se você usa imagens fixadas, é necessário pedir uma extensão para ter mais tempo e migrar para versões compatíveis e sem canais.
  • Falha na execução:qualquer ação de inicialização, script de pipeline ou job que envie conda install PACKAGE sem especificar um canal falha com erros de resolução de canal.

Como configurar canais do Conda

Se as cargas de trabalho dependerem do Conda para instalar pacotes binários, declare explicitamente seu canal usando uma das seguintes opções. Para especificar canais em propriedades de cluster relacionadas ao Conda, consulte Usar propriedades de cluster relacionadas ao Conda.

Opção 1: flag de linha de comando explícita

Essa opção é recomendada para instalações ad hoc. Transmita a flag --channel ao executar conda install:

conda install --channel conda-forge PACKAGE

Ou use a flag curta -c:

conda install -c conda-forge PACKAGE

Substitua PACKAGE pelo nome do pacote a ser instalado.

Opção 2: ações de inicialização do cluster

Essa opção é recomendada para ambientes automatizados. Adicione uma ação de inicialização personalizada que pré-configure o canal que você quer usar no arquivo de configuração .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

Migrar de imagens legadas (1.x e 2.0)

As versões 1.3, 1.4, 1.5 e 2.0 do Serviço Gerenciado para Apache Spark não têm suporte há muito tempo. Executar imagens anteriores apresenta riscos operacionais e de segurança significativos, incluindo vulnerabilidades e exposições comuns (CVEs) conhecidas em sistemas operacionais e dependências de software de código aberto (OSS).

  • Google Cloud está desativando permanentemente a criação de imagens para as faixas 1.x e 2.0.
  • Todas as ações de inicialização disponíveis no repositório do GitHub GoogleCloudDataproc/initialization-actions que oferecem suporte apenas a essas imagens descontinuadas (1.x e 2.0) também serão removidas.
  • Todas as cargas de trabalho precisam ser migradas para as imagens laterais sem canais do Conda até 15 de outubro de 2026.
  • Todas as cargas de trabalho precisam ser migradas para versões ativas e compatíveis (2.1, 2.2, 2.3 ou 3.0 e mais recentes).

Para mais informações, consulte Versões de imagem incompatíveis do Serviço Gerenciado para Apache Spark.

Extensões disponíveis

O Serviço Gerenciado para Apache Spark oferece dois caminhos de extensão por uma lista de permissões (link em inglês) de inclusão, que exige aprovação da equipe de serviço.

Tipos de extensão

Os seguintes tipos de extensão estão disponíveis.

Extensão temporária de solução alternativa do Conda

  • Validade:até 31 de outubro de 2026.
  • Finalidade:oferece um buffer operacional imediato para clientes cujas implantações automatizadas ou ações de inicialização forem interrompidas devido à troca de alias de imagem padrão em 25 de agosto de 2026 e 1º de setembro de 2026.
  • Benefício:permite que os projetos mantenham temporariamente o comportamento anterior enquanto modificam os scripts para incluir --channel ou fazem a transição para imagens sem canais.

Extensão de descontinuação de imagens legadas

  • Validade:até 31 de dezembro de 2026.
  • Finalidade:para cargas de trabalho essenciais em execução na versão 1.x ou 2.0 que não podem refatorar imediatamente o código para o Spark 3.x ou ambientes de SO mais recentes.
  • Benefício:permite continuar criando clusters em versões legadas até o fim de 2026, evitando interrupções imediatas na produção.
  • Pré-requisito:só é possível obter essa extensão se as cargas de trabalho atuais 1.x e 2.0 usarem imagens laterais compatíveis com o Conda.

Requisitos de extensão

As extensões são regidas por restrições de compliance e infraestrutura. Para ser aprovado, você precisa atender a todos os requisitos a seguir:

  • Somente projetos atuais:as extensões se aplicam estritamente aos IDs de projeto Google Cloudque têm um histórico ativo de execução dessas versões antes de agosto de 2026. Novos projetos não serão adicionados à lista de permissões.
  • Troca obrigatória de imagem lateral até 31 de outubro de 2026:se você receber uma extensão no 1.x ou 2.0, precisará migrar as configurações de criação de cluster para as versões secundárias compatíveis com o Conda (1.3.96, 1.4.81, 1.5.92 e 2.0.161) até 31 de outubro de 2026.
  • Nenhum uso da região global:para versões de imagem 1.5 e anteriores, os clusters não podem ser implantados na região legada global. As cargas de trabalho precisam usar endpoints regionais específicos (por exemplo, us-central1 ou europe-west1).
  • Roteiro de migração comprometido:é necessário ter um plano de modernização ativo para mover cargas de trabalho para versões compatíveis com o Conda (2.2 e mais recentes ou 3.0) antes do prazo de 31 de dezembro de 2026.

Como solicitar uma extensão

Para solicitar a inclusão na lista de permissões de extensões, envie uma solicitação por um dos seguintes canais:

  • E-mail:envie sua solicitação diretamente para dataproc-msa-support@google.com.
  • Caso de suporte:registre um caso no Cloud Customer Care que faça referência ao MSA de descontinuação do Conda do Dataproc.
  • Equipe de conta:entre em contato com seu gerente técnico de contas (TAM) ou engenheiro de clientes (CE) dedicado do Google Cloud .

Inclua as seguintes informações no seu pedido:

  • Google Cloud nome da organização
  • IDs e números de projeto do Google Cloud destino
  • Nomes ou UUIDs dos clusters afetados
  • Versões de imagem em uso
  • Motivo do pedido de extensão e data de conclusão da migração

Lista de verificação para canais do Conda em conformidade

Conclua as prioridades a seguir em ordem.

Prioridade 1: descoberta e inventário de carga de trabalho

  • Identifique imagens descontinuadas:faça uma auditoria nos projetos da sua organização para encontrar clusters em execução nas versões 1.3, 1.4, 1.5 ou 2.0.

    O comando a seguir lista a versão da imagem dos clusters ativos em uma região:

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

    Substitua REGION pela região em que seus clusters estão localizados.

  • Auditar o uso do Conda:revise as ações de inicialização (--initialization-actions), os scripts de inicialização e os scripts de envio de jobs para todas as invocações de conda install.

Prioridade 2: triagem imediata de falhas

Se você estiver enfrentando interrupções, faça o seguinte:

  • Se os pipelines automatizados falharem devido à falta de pacotes do Conda, corrija imediatamente a ação ou o script de inicialização adicionando --channel conda-forge (ou -c conda-forge):

    conda install -c conda-forge PACKAGE

  • Se a criação do cluster falhar devido a blocos de imagem descontinuados, entre em contato imediatamente com dataproc-msa-support@google.com ou com seu TAM para solicitar a inscrição temporária na lista de permissões.

Prioridade 3: execute uma troca lateral de subversão secundária

Essa etapa não exige mudanças no código.

  • Para pipelines que não podem ser atualizados imediatamente para a versão 2.2 ou mais recente da imagem, atualize os modelos de criação de cluster (por exemplo, Terraform, Apache Airflow DataprocCreateClusterOperator, Serviço Gerenciado para Apache Airflow e scripts de CI/CD) para usar a versão lateral sem canais:

    • Substitua 1.3.* por 1.3.96.
    • Substitua 1.4.* por 1.4.81.
    • Substitua 1.5.* por 1.5.92.
    • Substitua 2.0.* por 2.0.161.

  • Por que isso funciona:essas imagens contêm as mesmas versões do Apache Spark, do Apache Hadoop, do Apache Hive e do Java que as versões submenores anteriores. Eles garantem 100% de compatibilidade de aplicativos sem exigir mudanças no código.

Prioridade 4: recriar clusters de longa duração

Se você tiver clusters estáticos e de longa duração implantados em imagens anteriores, agende uma janela de manutenção para recriá-los usando as versões submenores laterais mais recentes (ou versões 2.x ou 3.x compatíveis com Conda). A recriação garante que eles recebam todas as atualizações críticas de segurança e configuração.

Prioridade 5: planejar um upgrade completo para versões compatíveis

A conclusão dessa prioridade está prevista para o quarto trimestre de 2026.

  • Estabeleça ambientes de teste na versão de imagem 2.2 (Debian 12, Spark 3.5) ou na versão de imagem 3.0, que está em disponibilidade geral (GA).
  • Valide jobs do PySpark, Scala e Java em relação às especificações da API Spark 3.x.
  • Se você precisar de suporte dedicado para modernização, use a Google CloudProfessional Services Organization (PSO) ou parceiros certificados de migração, como Wipro e HCL.

Perguntas frequentes

As seções a seguir respondem a perguntas frequentes sobre a remoção do canal do Conda.

Geral e contexto

As perguntas a seguir explicam por que essas mudanças estão acontecendo e como elas são diferentes umas das outras.

Por que o Serviço Gerenciado para Apache Spark está removendo os canais Conda pré-configurados?

Devido a mudanças nos requisitos de licenciamento, o Serviço Gerenciado para Apache Spark está desvinculando os serviços dos canais proprietários do Anaconda e migrando para mecanismos de pacote padrão de código aberto.

Qual é a diferença entre a remoção de canais do Conda e a descontinuação de imagens?

  • A remoção do canal conda afeta todas as versões do Serviço Gerenciado para Apache Spark, incluindo as versões 2.1, 2.2 e 2.3, que têm suporte ativo, e os ambientes de execução sem servidor. Ele remove os ponteiros padrão para repositórios do Anaconda.
  • A descontinuação de imagens afeta especificamente as imagens legadas 1.x e 2.0. Essas imagens chegaram ao fim da vida útil, não recebem mais patches de segurança e serão bloqueadas para a criação de clusters.

Problemas técnicos e de compatibilidade

As perguntas a seguir abordam como as mudanças afetam a instalação de pacotes do Python, o uso do Conda e a compatibilidade de imagens.

Essa mudança afeta o pip install ou o dataproc:pip.packages?

Não. As instalações padrão de pacotes Python usando pip ou a propriedade do cluster do Serviço Gerenciado para Apache Spark dataproc:pip.packages extraem diretamente do índice de pacotes do Python (PyPI). O PyPI é totalmente independente do Conda e não é afetado de forma alguma.

Minha organização pode continuar usando os pacotes Anaconda ou Conda?

Sim. Você pode continuar usando o Conda para gerenciar seus ambientes. No entanto, é preciso fornecer explicitamente o canal do repositório. Você pode apontar para o canal conda-forge com suporte da comunidade (adicionando -c conda-forge) ou para o espelho do repositório Anaconda particular e licenciado da sua organização usando ações de inicialização.

Qual é o erro exato que ocorre se meu script não for atualizado?

Quando você executa conda install PACKAGE em uma imagem sem canais, o Conda retorna um erro indicando que nenhum canal está configurado ou que o pacote solicitado não pode ser encontrado nos caminhos de pesquisa padrão. Por exemplo, PackagesNotFoundError: The following packages are not available from current channels.

O que é uma imagem lateral secundária e por que devo usá-la?

Uma imagem submenor lateral (como 1.5.92 para a faixa 1.5 ou 2.0.161 para a faixa 2.0) é uma versão de imagem em que os principais componentes do ecossistema de big data (Hadoop, Spark, Hive, Presto e tempos de execução Java) permanecem idênticos às versões anteriores nessa faixa, mas os canais Conda subjacentes foram removidos. Fazer upgrade para uma versão submenor lateral não exige mudanças no código dos seus jobs do Spark.

Implantações e ecossistema

As perguntas a seguir abordam como as mudanças afetam as cargas de trabalho sem servidor, as implantações do Google Kubernetes Engine (GKE) e os serviços de orquestração gerenciados.

Como isso afeta o Serviço Gerenciado para Apache Spark sem servidor?

A partir de 25 de agosto de 2026, as cargas de trabalho em lote sem servidor enviadas recentemente serão executadas em imagens de ambiente de execução básico que não contêm canais Conda pré-configurados. Se você empacotar dependências usando imagens de contêiner personalizadas ou tarballs de ambiente do Conda, verifique se as definições de build especificam --channel conda-forge ou seu canal privado.

Como isso afeta o Serviço Gerenciado para Apache Spark no Google Kubernetes Engine?

As imagens do Serviço Gerenciado para Apache Spark no GKE foram atualizadas para remover os canais Conda pré-configurados (por exemplo, a imagem de ambiente de execução 3.5-dataproc-28 e as versões subsequentes). Os Dockerfiles de contêiner personalizado que executam conda install precisam ser atualizados para transmitir um --channel explícito.

Os orquestradores gerenciados, como o Serviço gerenciado para Apache Airflow ou o Cloud Data Fusion, são afetados?

Os pipelines padrão gerenciados pelo Airflow Gerenciado ou pelo Cloud Data Fusion que invocam tarefas integradas de criação de clusters do Serviço Gerenciado para Apache Spark não são afetados, a menos que seu fluxo de trabalho dependa de ações de inicialização personalizadas que executam comandos conda install sem flags ou fixem imagens 1.x ou 2.0 descontinuadas.

Suporte e assistência

A pergunta a seguir descreve onde conseguir ajuda com a migração.

Onde posso receber assistência técnica para minha migração?

  • Para solução de problemas técnicos e solicitações de lista de permissões, entre em contato com dataproc-msa-support@google.com ou abra um caso com o Cloud Customer Care.
  • Para assistência na migração empresarial, a Google Cloud PSO oferece pacotes de modernização estruturados, e parceiros certificados de integração de sistemas (SI), incluindo Wipro e HCL, oferecem serviços de migração dedicados que se qualificam para os Fundos de cobertura dos serviços de parceiros (PSF).