Sebagian atau seluruh informasi di halaman ini mungkin tidak berlaku untuk Trusted Cloud dari S3NS. Lihat Perbedaan dari Google Cloud untuk mengetahui detail selengkapnya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Bersiap untuk mematikan agen startup

Agen startup container yang men-deploy container di instance Compute Engine selama pembuatan VM tidak digunakan lagi.

Dokumen ini menjelaskan cara merencanakan migrasi container yang Anda buat selama pembuatan VM ke layanan lain. Trusted Cloud by S3NS

Informasi umum

Apa yang dimaksud dengan agen startup container di Compute Engine?

Agen startup container memungkinkan Anda men-deploy dan mengonfigurasi container di instance Compute Engine atau di instance dalam grup instance terkelola (MIG) selama pembuatan VM dan meluncurkan container Docker.

Mengapa agen startup penampung tidak digunakan lagi?

Berdasarkan masukan pelanggan, Trusted Cloud by S3NS meningkatkan opsi deployment penampung. Kami telah menghentikan penggunaan agen startup container agar kami dapat memberi Anda opsi yang lebih fleksibel untuk men-deploy container Anda.

Untuk mengetahui informasi selengkapnya tentang opsi yang tidak digunakan lagi, lihat Opsi yang tidak digunakan lagi untuk mengonfigurasi container pada VM.

Apa tonggak penting untuk penghentian penggunaan ini dan apa yang terjadi jika saya tidak mengambil tindakan sebelum batas waktu?

Mulai 31 Juli 2026, alur kerja apa pun yang mengandalkan agen startup penampung atau metadata instance gce-container-declaration akan berhenti berfungsi.

Mulai 31 Juli 2027, Google akan menghentikan dukungan untuk agen startup penampung dan tidak akan ada lagi update untuk VM yang sedang berjalan yang menggunakan metadata gce-container-declaration. Anda akan menjalankan workload dengan risiko Anda sendiri dan hal ini dapat memengaruhi alur kerja Anda.

Sebaiknya Anda memigrasikan penampung ke solusi alternatif jauh sebelum tanggal tersebut untuk memastikan transisi yang lancar.

Kapan saya tidak dapat lagi membuat VM atau MIG baru dengan container yang di-deploy secara langsung menggunakan metadata gce-container-declaration?

12 bulan sejak notifikasi penghentian penggunaan awal, yaitu 31 Juli 2026.

Kapan saya tidak dapat lagi menjalankan deployment container pada VM atau MIG yang menggunakan metadata gce-container-declaration?

Kami akan berhenti mendukung beban kerja apa pun yang di-deploy menggunakan agen startup penampung 24 bulan sejak pemberitahuan penghentian awal, yaitu 31 Juli 2027.

Saya menggunakan cloud-init untuk menjalankan container di VM. Apakah saya terpengaruh oleh perubahan ini?

Tidak. Penghentian ini tidak memengaruhi VM yang dikonfigurasi menggunakan cloud-init. Anda dapat terus menggunakan cloud-init untuk mengonfigurasi instance. Untuk mengetahui informasi selengkapnya, lihat Menggunakan cloud-init dengan Cloud config.

Bagaimana cara mengetahui apakah saya terkena dampak perubahan ini?

Jika Anda men-deploy container di VM selama pembuatan VM menggunakan agen startup container atau dengan menentukan gce-container-declaration, Anda akan terpengaruh oleh penghentian penggunaan ini. Untuk memvalidasi apakah ada instance yang terpengaruh di project Anda, jalankan perintah gcloud CLI berikut:

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

Perintah ini akan memberikan daftar semua instance VM dalam project Anda yang berisi kunci metadata gce-container-declaration. Kunci metadata secara unik mengidentifikasi VM yang termasuk dalam cakupan penghentian penggunaan. Jika Anda menggunakan beberapa project, jalankan perintah di semua project aktif.

Untuk mengetahui informasi selengkapnya tentang cara melihat metadata project, lihat dokumentasi metadata.

Jika Anda memiliki instance tertentu yang ingin diperiksa, jalankan perintah gcloud CLI berikut:

gcloud compute instances describe VM_NAME

Ganti VM_NAME dengan nama instance VM. Perintah ini memberikan semua informasi untuk instance tertentu, termasuk metadata. Jika Anda melihat kunci metadata gce-container-declaration di output perintah, berarti VM Anda terpengaruh oleh perubahan ini.

Apakah ada risiko terhadap keamanan atau privasi project selama migrasi?

Tidak. Keamanan dan privasi adalah fondasi dari semua yang kami lakukan di Google. Saat menggunakan skrip atau solusi terkelola kami, Anda memiliki fleksibilitas untuk mengonfigurasi setelan privasi dan keamanan tertentu guna memenuhi persyaratan Anda. Untuk mengetahui informasi selengkapnya, lihat panduan migrasi.

Solusi alternatif

Apa solusi alternatif yang direkomendasikan untuk container di Compute Engine, dan bagaimana cara memilih solusi yang tepat untuk kebutuhan saya?

Anda dapat memilih salah satu opsi berikut untuk memigrasikan container:

Jika Anda ingin terus men-deploy container di VM atau MIG, atau menjalankan container untuk pengujian dan pengembangan, atau menjalankan workload yang terdiri dari satu VM, gunakan skrip startup atau cloud-init.
Jika Anda memiliki aplikasi container stateless dan tugas berukuran kecil hingga sedang, pertimbangkan Cloud Run. Anda juga dapat menggunakan skrip startup.
Jika penampung Anda adalah tugas batch yang memiliki status akhir yang pasti dan memerlukan resource komputasi tambahan, pertimbangkan Batch. Anda juga dapat menggunakan skrip startup.
Jika Anda memerlukan kontrol dan skalabilitas lanjutan atau tidak dapat memenuhi persyaratan dengan opsi lain, pertimbangkan GKE.

Untuk mendapatkan panduan dan rekomendasi mendetail tentang opsi migrasi, baca panduan migrasi.

Mengapa saya harus mempertimbangkan migrasi ke layanan terkelola seperti Cloud Run, GKE, atau Batch, dibandingkan menggunakan skrip startup?

Sebaiknya pertimbangkan untuk bermigrasi ke solusi container seperti Google Kubernetes Engine, Cloud Run, dan Batch. Layanan terkelola ini menawarkan keuntungan signifikan dibandingkan deployment berbasis VM konvensional, termasuk peningkatan skalabilitas, fleksibilitas, dan kemampuan pengelolaan lanjutan.

Manfaat utamanya meliputi:

Mengurangi overhead pengelolaan: Sebagai layanan terkelola sepenuhnya,Trusted Cloud menangani infrastruktur yang mendasarinya (VM, patching, penskalaan). Pendekatan ini menghemat waktu staf yang berharga dan mengurangi beban operasional Anda.
Menskalakan dan memastikan elastisitas secara otomatis: Layanan ini menyesuaikan resource secara otomatis berdasarkan permintaan. Hal ini menghasilkan pemanfaatan resource yang lebih baik dan potensi penghematan biaya dibandingkan dengan penyediaan VM yang berlebihan.
Mencapai efisiensi biaya untuk beban tidak aktif: Tidak seperti VM, yang menimbulkan biaya meskipun saat tidak aktif, layanan terkelola bisa lebih hemat biaya untuk aplikasi dengan traffic yang berfluktuasi atau rendah.
Manfaatkan ketersediaan paket gratis: GKE, Cloud Run, dan Batch menawarkan paket gratis, sehingga Anda dapat menjalankan workload yang lebih kecil atau melakukan pengujian tanpa biaya.

Untuk panduan mendetail tentang migrasi, lihat panduan migrasi.

Apa pertimbangan biaya untuk setiap solusi alternatif, dan bagaimana perbandingannya dengan penyiapan saat ini?

Skrip startup deployment container atau cloud-init: Menggunakan skrip startup atau cloud-init sebagai pengganti langsung tidak secara inheren mengubah biaya Compute Engine Anda. Anda tetap membayar resource VM pokok.

Layanan terkelola: Beralih ke layanan seperti Cloud Run atau Batch dapat menghemat biaya, terutama untuk aplikasi dengan penggunaan yang bervariasi. Tidak seperti VM yang dikenai biaya meskipun saat tidak digunakan, layanan terkelola ini bisa lebih efisien. Selain itu, tingkat gratis dapat lebih mengurangi biaya untuk workload sementara yang lebih kecil.

Untuk mengetahui informasi selengkapnya, lihat Membandingkan opsi deployment container. Harga bervariasi berdasarkan layanan yang dipilih dan konfigurasi spesifik Anda. Gunakan kalkulator harga untuk mendapatkan perkiraan yang akurat.

Apakah penghentian penggunaan ini berarti bahwa image Container-Optimized OS akan dihentikan penggunaannya, sehingga jika kita ingin menjalankan Docker di VM Compute Engine, kita harus mengonfigurasi template VM kita sendiri?

Tidak, image Container-Optimized OS itu sendiri tidak dihentikan penggunaannya. Perubahan ini terkait cara container dimulai di VM yang menggunakan Container-Optimized OS. Versi Container-Optimized OS yang lebih baru tidak akan lagi mendukung konlet, yang merupakan agen startup yang memulai container menggunakan kunci metadata gce-container-declaration. Artinya, image Container-Optimized OS akan tetap tersedia dan didukung. Namun, Anda harus mengupdate VM untuk menggunakan skrip startup atau konfigurasi cloud-init guna men-deploy container, bukan menggunakan kunci metadata gce-container-declaration.

Proses Migrasi

Apa pendekatan yang direkomendasikan untuk memigrasikan container ke solusi alternatif?

Sebaiknya lakukan langkah-langkah berikut untuk migrasi Anda:

Pahami opsi Anda: Tinjau panduan migrasi untuk mempelajari cara alternatif menjalankan container Anda.
Rencanakan migrasi Anda lebih awal: Untuk memastikan transisi yang lancar, mulailah merencanakan migrasi deployment penampung Anda saat ini jauh sebelum 31 Juli 2026.
Bersiap untuk workload baru: Pastikan workload container baru Anda siap dijalankan di solusi alternatif paling lambat 31 Juli 2026, karena deployment langsung container ke VM atau MIG tidak akan dimungkinkan lagi.
Batas waktu migrasi akhir: Pastikan semua workload container yang ada dimigrasikan ke solusi alternatif paling lambat 31 Juli 2027, saat metode deployment langsung akan dihentikan sepenuhnya.

Apakah saya diwajibkan untuk bermigrasi ke salah satu solusi yang direkomendasikan atau apakah ada alternatif yang dapat saya gunakan?

Kami mendukung fleksibilitas Anda untuk mengadopsi solusi apa pun yang sesuai dengan kebutuhan bisnis Anda dan didukung secara aktif. Referensi seperti panduan migrasi tersedia untuk membantu Anda memilih opsi yang paling sesuai.

Apakah pencadangan atau ekspor data diperlukan sebagai bagian dari proses migrasi?

Meskipun melakukan pencadangan atau ekspor data selalu menjadi praktik terbaik yang penting untuk keamanan data dan kelangsungan bisnis, hal ini bukan merupakan langkah yang diperlukan untuk proses migrasi ini.

Berapa lama waktu yang saya perlukan untuk bermigrasi ke salah satu alternatif, dan apakah ada faktor yang dapat memengaruhi komitmen waktu saya?

Skrip startup deployment container: Penyiapan dan pengujian awal menggunakan skrip startup akan memakan waktu sekitar 1-2 jam. Deployment berikutnya hanya memerlukan waktu beberapa menit.

Layanan terkelola: Memilih solusi Trusted Cloud by S3NS seperti Cloud Run, Batch, atau GKE, yang merupakan penawaran PaaS tanpa server dan terkelola sepenuhnya, mungkin memerlukan investasi waktu dan upaya di awal yang lebih besar. Hal ini disebabkan oleh perubahan mendasar dari pendekatan yang berfokus pada VM (IaaS) di mana Anda mengelola infrastruktur, ke model PaaS di mana platform menangani sebagian besar hal ini. Adaptasi ini mungkin memerlukan perubahan pada aplikasi Anda, seperti memastikan aplikasi tidak memiliki status, tetapi manfaat jangka panjangnya dapat mencakup peningkatan substansial dalam efisiensi operasional, skalabilitas, dan efektivitas biaya.

Untuk panduan tentang transisi ini, lihat panduan migrasi.

Jika saya memilih untuk bermigrasi ke alternatif, apakah akan ada gangguan atau periode nonaktif untuk Trusted Cloud by S3NS project, VM, layanan, dan aplikasi?

Secara umum, transisi ke solusi alternatif yang direkomendasikan dirancang sebagai proses tanpa periode nonaktif.

Untuk migrasi container yang berjalan lama di VM Compute Engine, guna menghindari gangguan, sebaiknya siapkan VM baru dengan konfigurasi alternatif dan alihkan traffic setelah diuji.

Bagaimana pengaruh migrasi ini terhadap konfigurasi Terraform saya?

Jika Anda menggunakan Terraform atau otomatisasi serupa untuk membuat atau mengupdate VM atau MIG dengan container dengan menetapkan kunci metadata gce-container-declaration secara eksplisit, alur kerja Anda akan berhenti berfungsi pada 31 Juli 2026. Untuk menghindari gangguan, Anda harus memperbarui konfigurasi untuk menyertakan skrip startup bagi deployment penampung dan menghapus dependensi pada kunci metadata gce-container-declaration. Untuk mengetahui petunjuk mendetail tentang cara menerapkan perubahan ini, lihat Memigrasikan container yang di-deploy di VM selama pembuatan VM.

Mendapatkan dukungan

Siapa yang harus saya hubungi di Compute Engine jika ada pertanyaan tentang proses migrasi?: Jika Anda memiliki pertanyaan atau memerlukan bantuan, hubungi Dukungan Google Cloud.
Apa saja referensi yang tersedia untuk mendukung migrasi saya dan memberikan panduan teknis?: FAQ ini, panduan migrasi, dan Dukungan Google Cloud tersedia untuk mendukung Anda dalam proses migrasi.