Memigrasikan dan menyiapkan channel Conda

Saluran paket Conda yang telah dikonfigurasi sebelumnya akan dihapus dari image cluster dan runtime serverless Managed Service untuk Apache Spark. Dokumen ini menjelaskan cara memigrasikan dan mengonfigurasi saluran Conda untuk workload Anda.

Penghapusan saluran Conda yang telah dikonfigurasi sebelumnya

Sebelumnya, image Managed Service untuk Apache Spark menggabungkan saluran Conda yang telah dikonfigurasi sebelumnya, seperti repositori defaults Anaconda. Karena perubahan pemberian lisensi, Managed Service untuk Apache Spark menghapus semua pointer saluran yang telah dikonfigurasi sebelumnya dari semua image dan runtime serverless Managed Service untuk Apache Spark yang lama dan yang akan datang.

  • Perubahan: Perintah yang dijalankan conda install PACKAGE tanpa channel yang diberikan secara eksplisit tidak lagi menyelesaikan paket terhadap repositori default, dan gagal.
  • Yang tidak berubah: Penginstalan paket Python standar dari PyPI (pip install PACKAGE atau properti cluster dataproc:pip.packages) sama sekali tidak terpengaruh.

Ketersediaan gambar lateral bebas saluran

Untuk membantu developer beradaptasi dengan update ini, Managed Service untuk Apache Spark telah merilis versi subminor tanpa saluran seperti yang tercantum dalam tabel berikut. Image ini mempertahankan kompatibilitas biner dan komponen 100% dengan image yang ada, hanya berbeda dalam penghapusan saluran Conda yang telah dikonfigurasi sebelumnya.

Trek gambar Versi lama atau yang terpengaruh Versi lateral yang dipublikasikan tanpa Conda Status dan kompatibilitas
1.3 <= 1.3.95 1.3.96 100% kompatibel dengan 1.3.95; Channel Conda dihapus
1.4 <= 1.4.80 1.4.81 100% kompatibel dengan 1.4.80; Channel Conda dihapus
1,5 <= 1.5.90 1.5.92 100% kompatibel dengan 1.5.90; Channel Conda dihapus
2.0 <= 2.0.160 2.0.161 100% kompatibel dengan 2.0.160; Channel Conda dihapus
2.1 <= 2.1.116 2.1.117, dan 2.1.119 dan yang lebih baru Rilis yang didukung; Saluran Conda dihapus
2.2 <= 2.2.84 2.2.85, dan 2.2.87 dan kemudian Rilis yang didukung; Saluran Conda dihapus
2.3 <= 2.3.31 2.3.32, dan 2.3.36 dan yang lebih baru Rilis yang didukung; Saluran Conda dihapus

Pengaruh penghapusan terhadap workload

  • Cluster yang tidak disematkan: Skrip pembuatan cluster yang menentukan alias versi image (seperti --image-version=2.2-debian12) akan otomatis menerima image bebas saluran baru.
  • Gambar yang disematkan atau kustom: Cluster yang disematkan ke rilis subminor sebelumnya atau yang menggunakan gambar kustom akan terus merujuk pada konfigurasi saluran lama kecuali jika diperbarui. Jika menggunakan gambar yang disematkan, Anda harus meminta perpanjangan waktu untuk mendapatkan waktu tambahan dan bermigrasi ke versi yang didukung dan bebas channel.
  • Kegagalan eksekusi: Setiap tindakan inisialisasi, skrip pipeline, atau tugas yang mengirimkan conda install PACKAGE tanpa menentukan channel akan gagal dengan error penyelesaian channel.

Cara mengonfigurasi channel Conda

Jika workload Anda bergantung pada Conda untuk menginstal paket biner, Anda harus secara eksplisit mendeklarasikan saluran dengan menggunakan salah satu opsi berikut. Untuk menentukan saluran di properti cluster terkait Conda, lihat Menggunakan properti cluster terkait conda.

Opsi 1: Flag command line eksplisit

Opsi ini direkomendasikan untuk penginstalan ad hoc. Teruskan flag --channel saat Anda menjalankan conda install:

conda install --channel conda-forge PACKAGE

Atau gunakan tanda -c singkat:

conda install -c conda-forge PACKAGE

Ganti PACKAGE dengan nama paket yang akan diinstal.

Opsi 2: Tindakan inisialisasi cluster

Opsi ini direkomendasikan untuk lingkungan otomatis. Tambahkan tindakan inisialisasi kustom yang mengonfigurasi saluran yang ingin Anda gunakan dalam file konfigurasi .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

Bermigrasi dari image lama (1.x dan 2.0)

Managed Service untuk Apache Spark versi 1.3, 1.4, 1.5, dan 2.0 tidak didukung selama jangka waktu yang lama. Menjalankan image yang lebih lama menimbulkan risiko operasional dan keamanan yang signifikan, termasuk Kerentanan dan Eksposur Umum (CVE) yang diketahui dalam sistem operasi yang mendasarinya dan dependensi software open source (OSS).

  • Google Cloud akan menghentikan pembuatan gambar secara permanen untuk jalur 1.x dan 2.0.
  • Semua tindakan inisialisasi yang tersedia di repositori GitHub GoogleCloudDataproc/initialization-actions yang hanya mendukung image yang tidak digunakan lagi ini (1.x dan 2.0) juga akan dihapus.
  • Semua beban kerja harus dimigrasikan ke image lateral bebas saluran Conda paling lambat 15 Oktober 2026.
  • Semua beban kerja pada akhirnya harus dimigrasikan ke versi aktif yang didukung (2.1, 2.2, 2.3, atau 3.0 dan yang lebih baru).

Untuk mengetahui informasi selengkapnya, lihat Versi image Managed Service untuk Apache Spark yang tidak didukung.

Ekstensi yang tersedia

Managed Service untuk Apache Spark menyediakan dua jalur ekstensi melalui daftar yang diizinkan yang bersifat keikutsertaan, yang memerlukan persetujuan dari tim layanan.

Jenis ekstensi

Jenis ekstensi berikut tersedia.

Ekstensi solusi sementara Conda

  • Masa berlaku: Maksimum hingga 31 Oktober 2026.
  • Tujuan: Menyediakan buffer operasional langsung bagi pelanggan yang deployment otomatis atau tindakan inisialisasinya terganggu karena pengalihan alias image default pada 25 Agustus 2026 dan 1 September 2026.
  • Manfaat: Memungkinkan project mempertahankan perilaku sebelumnya untuk sementara saat memodifikasi skrip untuk menyertakan --channel atau bertransisi ke gambar tanpa saluran.

Ekstensi penghentian penggunaan gambar lama

  • Masa berlaku: Hingga 31 Desember 2026.
  • Tujuan: Untuk beban kerja penting yang berjalan di 1.x atau 2.0 yang tidak dapat langsung merefaktorisasi kode untuk lingkungan OS Spark 3.x atau yang lebih baru.
  • Manfaat: Memungkinkan Anda terus membuat cluster di jalur lama hingga akhir tahun 2026, sehingga mencegah penghentian produksi secara langsung.
  • Prasyarat: Anda hanya dapat memperoleh ekstensi ini jika workload 1.x dan 2.0 Anda saat ini menggunakan image lateral yang mematuhi Conda.

Persyaratan ekstensi

Ekstensi diatur oleh batasan kepatuhan dan infrastruktur. Agar disetujui, Anda harus memenuhi semua persyaratan berikut:

  • Khusus project yang sudah ada: Ekstensi hanya berlaku untuk Google Cloud ID project yang memiliki histori aktif dalam menjalankan versi ini sebelum Agustus 2026. Project baru tidak akan ditambahkan ke daftar yang diizinkan.
  • Penggantian gambar lateral wajib dilakukan paling lambat 31 Oktober 2026: Jika Anda mendapatkan perpanjangan waktu pada 1.x atau 2.0, Anda harus mentransisikan konfigurasi pembuatan cluster ke versi subminor yang kompatibel dengan Conda secara lateral (1.3.96, 1.4.81, 1.5.92, dan 2.0.161) paling lambat 31 Oktober 2026.
  • Tidak ada penggunaan region global: Untuk versi image 1.5 dan yang lebih lama, cluster tidak boleh di-deploy ke region global lama. Workload harus menggunakan endpoint regional tertentu (misalnya, us-central1 atau europe-west1).
  • Roadmap migrasi yang berkomitmen: Anda harus memiliki rencana modernisasi aktif untuk memindahkan workload ke versi yang didukung dan mematuhi Conda (2.2 dan yang lebih baru, atau 3.0) sebelum batas waktu 31 Desember 2026.

Cara meminta perpanjangan waktu

Untuk meminta penempatan di daftar yang diizinkan untuk ekstensi, kirimkan permintaan melalui salah satu saluran berikut:

  • Email: Kirim permintaan Anda langsung ke dataproc-msa-support@google.com.
  • Kasus dukungan: Ajukan kasus ke Cloud Customer Care yang mereferensikan MSA Penghentian Penggunaan Conda Dataproc.
  • Tim akun: Hubungi Google Cloud Technical Account Manager (TAM) atau Customer Engineer (CE) khusus Anda.

Sertakan informasi berikut dalam permintaan Anda:

  • Google Cloud nama organisasi
  • ID project dan nomor project Google Cloud target
  • Nama atau UUID cluster yang terpengaruh
  • Versi gambar yang sedang digunakan
  • Alasan permintaan perpanjangan dan target tanggal penyelesaian migrasi

Checklist untuk saluran Conda yang mematuhi kebijakan

Selesaikan prioritas berikut secara berurutan.

Prioritas 1: Penemuan dan inventaris workload

  • Identifikasi image yang tidak digunakan lagi: Audit project organisasi Anda untuk menemukan cluster yang berjalan di 1.3, 1.4, 1.5, atau 2.0.

    Perintah berikut mencantumkan versi image cluster aktif di suatu region:

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

    Ganti REGION dengan region tempat cluster Anda berada.

  • Audit penggunaan Conda: Tinjau tindakan inisialisasi (--initialization-actions), skrip startup, dan skrip pengiriman tugas untuk setiap pemanggilan conda install.

Prioritas 2: Triase kegagalan langsung

Jika Anda mengalami gangguan, lakukan hal berikut:

  • Jika pipeline otomatis gagal karena paket Conda tidak ada, segera patch tindakan atau skrip inisialisasi dengan menambahkan --channel conda-forge (atau -c conda-forge):

    conda install -c conda-forge PACKAGE

  • Jika pembuatan cluster gagal karena pemblokiran gambar yang tidak digunakan lagi, segera hubungi dataproc-msa-support@google.com atau TAM Anda untuk meminta pendaftaran daftar yang diizinkan sementara.

Prioritas 3: Lakukan pertukaran subminor lateral

Langkah ini tidak memerlukan perubahan kode.

  • Untuk pipeline yang tidak dapat langsung diupgrade ke versi image 2.2 atau yang lebih baru, perbarui template pembuatan cluster Anda (misalnya, Terraform, Apache Airflow DataprocCreateClusterOperator, Managed Service untuk Apache Airflow, dan skrip CI/CD) untuk menggunakan versi lateral bebas saluran:

    • Ganti 1.3.* dengan 1.3.96.
    • Ganti 1.4.* dengan 1.4.81.
    • Ganti 1.5.* dengan 1.5.92.
    • Ganti 2.0.* dengan 2.0.161.

  • Alasan ini berfungsi: Image ini berisi versi Apache Spark, Apache Hadoop, Apache Hive, dan Java yang sama dengan versi subminor sebelumnya. Mereka menjamin kompatibilitas aplikasi 100% tanpa memerlukan perubahan kode apa pun.

Prioritas 4: Buat ulang cluster yang berjalan lama

Jika Anda memiliki cluster statis yang berjalan lama dan di-deploy pada image sebelumnya, jadwalkan masa pemeliharaan untuk membuat ulang cluster tersebut menggunakan versi subminor lateral terbaru (atau versi 2.x atau 3.x yang didukung dan kompatibel dengan Conda). Membuat ulang cluster memastikan bahwa cluster tersebut mendapatkan semua update konfigurasi dan keamanan penting.

Prioritas 5: Rencanakan upgrade penuh ke versi yang didukung

Target penyelesaian untuk prioritas ini adalah Kuartal 4 tahun 2026.

  • Siapkan lingkungan pengujian di versi image 2.2 (Debian 12, Spark 3.5) atau versi image 3.0, yang tersedia secara umum (GA).
  • Memvalidasi tugas PySpark, Scala, dan Java terhadap spesifikasi API Spark 3.x.
  • Jika Anda memerlukan dukungan modernisasi khusus, gunakan Google Cloud Professional Services Organization (PSO) atau partner migrasi bersertifikasi, seperti Wipro dan HCL.

Pertanyaan umum (FAQ)

Bagian berikut menjawab pertanyaan umum (FAQ) tentang penghapusan channel Conda.

Umum dan latar belakang

Pertanyaan berikut menjelaskan alasan terjadinya perubahan ini dan perbedaan di antara keduanya.

Mengapa Managed Service untuk Apache Spark menghapus saluran Conda yang telah dikonfigurasi sebelumnya?

Karena perubahan persyaratan pemberian lisensi, Managed Service untuk Apache Spark memisahkan layanannya dari saluran Anaconda berpemilik dan beralih ke mekanisme pengemasan open source standar.

Apa perbedaan antara penghapusan channel Conda dan penghentian penggunaan image?

  • Penghapusan channel Conda memengaruhi semua versi Managed Service untuk Apache Spark, termasuk versi 2.1, 2.2, dan 2.3 yang didukung secara aktif, serta runtime serverless. Tindakan ini akan menghapus pointer default ke repositori Anaconda.
  • Penghentian penggunaan image secara khusus memengaruhi image 1.x dan 2.0 lama. Image ini telah mencapai akhir siklus proses (EOL), tidak lagi menerima patch keamanan, dan akan diblokir dari pembuatan cluster.

Masalah teknis dan kompatibilitas

Pertanyaan berikut membahas pengaruh perubahan terhadap penginstalan paket Python, penggunaan Conda, dan kompatibilitas image.

Apakah perubahan ini memengaruhi pip install atau dataproc:pip.packages?

Tidak. Penginstalan paket Python standar menggunakan pip atau properti cluster Managed Service untuk Apache Spark dataproc:pip.packages mengambil langsung dari Python Package Index (PyPI). PyPI sepenuhnya independen dari Conda dan tidak terpengaruh dengan cara apa pun.

Dapatkah organisasi saya terus menggunakan paket Anaconda atau Conda?

Ya. Anda dapat terus menggunakan Conda untuk mengelola lingkungan Anda. Namun, Anda harus menyediakan saluran repositori secara eksplisit. Anda dapat mengarahkan ke saluran conda-forge yang didukung komunitas (dengan menambahkan -c conda-forge) atau mengarahkan ke mirror repositori Anaconda berlisensi pribadi organisasi Anda menggunakan tindakan inisialisasi.

Apa error persisnya yang terjadi jika skrip saya tidak diupdate?

Saat Anda menjalankan conda install PACKAGE pada image tanpa saluran, Conda akan menampilkan error yang menunjukkan bahwa tidak ada saluran yang dikonfigurasi atau paket yang diminta tidak dapat ditemukan di jalur penelusuran default. Contoh: PackagesNotFoundError: The following packages are not available from current channels.

Apa yang dimaksud dengan gambar subminor lateral, dan mengapa saya harus menggunakannya?

Image subminor lateral (seperti 1.5.92 untuk jalur 1.5 atau 2.0.161 untuk jalur 2.0) adalah rilis image yang komponen ekosistem big data intinya (runtime Hadoop, Spark, Hive, Presto, dan Java) tetap sama dengan rilis sebelumnya di jalur tersebut, tetapi saluran Conda yang mendasarinya telah dihapus. Mengupgrade ke versi subminor lateral tidak memerlukan perubahan kode untuk tugas Spark Anda.

Deployment dan ekosistem

Pertanyaan berikut mencakup pengaruh perubahan terhadap beban kerja serverless, deployment Google Kubernetes Engine (GKE), dan layanan orkestrasi terkelola.

Bagaimana pengaruhnya terhadap Managed Service untuk Apache Spark serverless?

Mulai 25 Agustus 2026, workload batch serverless yang baru dikirimkan akan berjalan di image runtime dasar yang tidak berisi channel Conda yang telah dikonfigurasi sebelumnya. Jika Anda memaketkan dependensi menggunakan image container kustom atau tarball lingkungan Conda, pastikan definisi build Anda menentukan --channel conda-forge atau channel pribadi Anda.

Bagaimana pengaruhnya terhadap Managed Service untuk Apache Spark di Google Kubernetes Engine?

Image Managed Service untuk Apache Spark di GKE telah diupdate untuk menghapus channel Conda yang telah dikonfigurasi sebelumnya (misalnya, image runtime 3.5-dataproc-28 dan rilis berikutnya). Dockerfile container kustom yang menjalankan conda install harus diupdate untuk meneruskan --channel eksplisit.

Apakah orchestrator terkelola seperti Managed Service untuk Apache Airflow atau Cloud Data Fusion terpengaruh?

Pipeline standar default yang dikelola oleh Managed Airflow atau Cloud Data Fusion yang memanggil tugas pembuatan cluster Managed Service untuk Apache Spark bawaan tidak terpengaruh, kecuali jika alur kerja Anda mengandalkan tindakan inisialisasi kustom yang menjalankan perintah conda install yang tidak diberi tanda atau menyematkan image 1.x atau 2.0 yang tidak digunakan lagi.

Dukungan dan bantuan

Pertanyaan berikut menjelaskan tempat untuk mendapatkan bantuan terkait migrasi Anda.

Di mana saya bisa mendapatkan bantuan teknis untuk migrasi saya?

  • Untuk pemecahan masalah teknis dan permintaan daftar yang diizinkan, hubungi dataproc-msa-support@google.com atau buka kasus dengan Layanan Pelanggan Cloud.
  • Untuk bantuan migrasi perusahaan, Google Cloud PSO menawarkan paket modernisasi terstruktur, dan partner integrator sistem (SI) bersertifikasi, termasuk Wipro dan HCL, menyediakan layanan migrasi khusus yang memenuhi syarat untuk Dana Layanan Partner (PSF).