Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Perbarui lingkungan komputasi di AWS Batch
<a name="updating-compute-environments"></a>

AWS Batch menyediakan beberapa strategi untuk memperbarui lingkungan komputasi, masing-masing dirancang untuk skenario dan persyaratan pembaruan tertentu. Pendekatan ini menggunakan API pembaruan dasar yang sama tetapi mewakili metode preskriptif yang berbeda untuk mengelola pembaruan secara efektif. Anda dapat mengelola pembaruan ini menggunakan AWS Batch konsol atau AWS CLI. Memahami strategi ini membantu Anda memilih metode yang paling tepat untuk kebutuhan Anda sambil meminimalkan gangguan pada beban kerja Anda.

Topik ini memberikan ikhtisar tentang strategi pembaruan yang tersedia dan panduan tentang kapan harus menggunakan setiap pendekatan. Untuk prosedur terperinci, lihat bagian individual untuk setiap strategi pembaruan.

**penting**  
AWS Batch membuat dan mengelola beberapa AWS sumber daya atas nama Anda dan dalam akun Anda, termasuk Templat Peluncuran Amazon EC2, Grup Penskalaan Otomatis Amazon EC2, Armada Spot Amazon EC2, dan Cluster Amazon ECS. Sumber daya yang dikelola ini dikonfigurasi secara khusus untuk memastikan AWS Batch operasi yang optimal. Memodifikasi sumber daya yang AWS Batch dikelola secara manual ini, kecuali dinyatakan secara eksplisit dalam AWS Batch dokumentasi, dapat menghasilkan perilaku yang tidak terduga, termasuk lingkungan `INVALID` komputasi, perilaku penskalaan instance suboptimal, pemrosesan beban kerja yang tertunda, atau biaya yang tidak terduga. Modifikasi manual ini tidak dapat didukung secara deterministik oleh layanan. AWS Batch Selalu gunakan yang didukung AWS Batch APIs atau AWS Batch konsol untuk mengelola lingkungan komputasi Anda.  
Modifikasi manual yang tidak didukung termasuk menjalankan tugas atau layanan Amazon ECS Anda sendiri di kluster Amazon ECS yang AWS Batch dikelola, atau memulai proses, daemon, atau layanan tambahan langsung pada instans yang dikelola. AWS Batch AWS Batch mengasumsikan kontrol penuh sumber daya komputasi dalam lingkungan komputasi terkelola dan dapat menghentikan instance, menghentikan tugas, atau menskalakan cluster kapan saja. Beban kerja apa pun yang Anda jalankan di luar pengiriman AWS Batch pekerjaan pada sumber daya terkelola ini dapat terganggu tanpa peringatan. Menjalankan AWS Batch beban non-kerja pada cluster dan instance yang AWS Batch dikelola juga dapat mengganggu penjadwalan AWS Batch pekerjaan dan penskalaan instance.

**Topics**
+ [Komputasi strategi pembaruan lingkungan](#update-strategies)
+ [Memilih strategi pembaruan yang tepat](#choosing-update-strategies)
+ [Pertimbangan pembaruan AMI](#ami-update-considerations)
+ [Lakukan pembaruan penskalaan](scaling-updates.md)
+ [Lakukan pembaruan infrastruktur](infrastructure-updates.md)
+ [Lakukan blue/green pembaruan untuk lingkungan komputasi](blue-green-updates.md)

## Komputasi strategi pembaruan lingkungan
<a name="update-strategies"></a>

Saat Anda menggunakan penskalaan atau pembaruan infrastruktur, lingkungan komputasi Anda diperbarui. Untuk strategi blue/green pembaruan, Anda membuat lingkungan komputasi baru (hijau) dan kemudian memigrasikan beban kerja Anda dari lingkungan komputasi lama (biru) ke lingkungan komputasi baru (hijau).

AWS Batch menyediakan tiga strategi berbeda untuk pembaruan lingkungan komputasi:

Pembaruan penskalaan  
Pembaruan penskalaan menyesuaikan kapasitas lingkungan komputasi Anda dengan menambahkan atau menghapus instance tanpa mengganti instance yang ada. Ini adalah skenario pembaruan tercepat dan tidak memerlukan waktu henti. Gunakan pembaruan penskalaan saat Anda perlu mengubah pengaturan kapasitas (vCPUs). Pembaruan ini biasanya selesai dalam beberapa menit.  
Pembaruan Fargate dilakukan menggunakan prosedur yang sama seperti pembaruan penskalaan. Untuk informasi selengkapnya, lihat [Lakukan pembaruan penskalaan](scaling-updates.md).

Pembaruan infrastruktur  
Pembaruan infrastruktur menggantikan instans di lingkungan komputasi Anda dengan instans baru yang telah memperbarui pengaturan. Pembaruan ini memerlukan peran layanan tertentu dan konfigurasi strategi alokasi tetapi memberikan waktu henti minimal, dengan menjalankan pekerjaan berpotensi terganggu. Gunakan pembaruan infrastruktur saat Anda perlu mengubah jenis instans, konfigurasi AMI, pengaturan jaringan, peran layanan, status lingkungan, atau komponen infrastruktur lainnya. Pembaruan ini biasanya selesai dalam 10-30 menit tergantung pada penyelesaian pekerjaan.  
Untuk informasi selengkapnya, lihat [Lakukan pembaruan infrastruktur](infrastructure-updates.md).

Pembaruan biru/hijau  
Blue/green updates create a new compute environment alongside your existing environment, allowing gradual workload transition with zero downtime. This approach provides the safest update path but requires running two environments temporarily. Use blue/greenpembaruan saat Anda tidak memerlukan waktu henti, ingin menguji perubahan sebelum penerapan penuh, memerlukan kemampuan rollback cepat, atau menggunakan konfigurasi yang tidak didukung untuk pembaruan infrastruktur. Waktu untuk menyelesaikan bervariasi dan dikendalikan oleh Anda.  
Untuk informasi selengkapnya, lihat [Lakukan blue/green pembaruan untuk lingkungan komputasi](blue-green-updates.md).

## Memilih strategi pembaruan yang tepat
<a name="choosing-update-strategies"></a>

Gunakan panduan keputusan ini untuk memilih strategi pembaruan yang paling tepat untuk kebutuhan Anda:

### Pilih pembaruan penskalaan saat
<a name="scaling-updates-when"></a>

Pilih strategi pembaruan penskalaan saat Anda hanya perlu menyesuaikan kapasitas komputasi (vCPUs). Pembaruan penskalaan sangat ideal ketika Anda memerlukan pembaruan cepat tanpa waktu henti dan tidak diperlukan perubahan konfigurasi infrastruktur.

Untuk prosedur terperinci, lihat [Lakukan pembaruan penskalaan](scaling-updates.md).

### Pilih pembaruan infrastruktur saat
<a name="infrastructure-updates-when"></a>

Pilih strategi pembaruan infrastruktur saat Anda perlu mengubah jenis instans, pengaturan AMI, peran layanan, status lingkungan, atau konfigurasi jaringan. Lingkungan Anda harus menggunakan peran *AWSServiceRoleForBatch*terkait layanan dan strategi alokasi`BEST_FIT_PROGRESSIVE`,, `SPOT_CAPACITY_OPTIMIZED` atau. `SPOT_PRICE_CAPACITY_OPTIMIZED` Pembaruan infrastruktur berfungsi dengan baik ketika beberapa gangguan pekerjaan dapat diterima selama pembaruan dan Anda menginginkan pembaruan otomatis ke AMI Amazon ECS terbaru yang dioptimalkan.

Untuk prosedur terperinci, lihat [Lakukan pembaruan infrastruktur](infrastructure-updates.md).

### Pilih blue/green pembaruan saat
<a name="blue-green-updates-when"></a>

Pilih strategi blue/green pembaruan saat nol downtime diperlukan untuk beban kerja Anda atau Anda perlu menguji perubahan sebelum mentransisikan beban kerja produksi. Pendekatan ini penting ketika kemampuan rollback cepat penting, lingkungan Anda menggunakan strategi `BEST_FIT` alokasi, atau lingkungan Anda tidak menggunakan peran terkait layanan. *AWSServiceRoleForBatch* Blue/green pembaruan juga merupakan pilihan terbaik saat Anda menggunakan kustom AMIs yang memerlukan pembaruan manual atau perlu membuat perubahan konfigurasi besar.

Untuk prosedur terperinci, lihat [Lakukan blue/green pembaruan untuk lingkungan komputasi](blue-green-updates.md).

## Pertimbangan pembaruan AMI
<a name="ami-update-considerations"></a>

Pendekatan untuk memperbarui AMIs tergantung pada konfigurasi lingkungan komputasi Anda.

### Memperbarui AMI default yang AWS Batch disediakan ke yang terbaru
<a name="automatic-ami-updates"></a>

AWS Batch dapat memperbarui ke AMI Amazon ECS terbaru yang dioptimalkan selama pembaruan [infrastruktur](infrastructure-updates.md) ketika semua kondisi ini terpenuhi:

**catatan**  
Setelah pembaruan infrastruktur selesai `updateToLatestImageVersion` diatur ke`false`. Untuk memulai pembaruan `updateToLatestImageVersion` lain harus diatur ke`true`.
+ Lingkungan komputasi menggunakan peran *AWSServiceRoleForBatch*terkait layanan.
+ Strategi alokasi diatur ke`BEST_FIT_PROGRESSIVE`,`SPOT_CAPACITY_OPTIMIZED`, atau`SPOT_PRICE_CAPACITY_OPTIMIZED`.
+ Tidak ada ID AMI yang secara eksplisit ditentukan dalam`imageId`,`imageIdOverride`, atau meluncurkan template.
+ `updateToLatestImageVersion` ditetapkan ke `true`.

### Pembaruan AMI menggunakan blue/green penerapan
<a name="manual-ami-updates-blue-green"></a>

Anda harus menggunakan blue/green penerapan untuk memperbarui AMIs dalam skenario ini:
+ Saat menggunakan versi tertentu dari AMI Amazon ECS yang dioptimalkan.
+ Ketika ID AMI ditentukan dalam salah satu dari:
  + Luncurkan template (harus memperbarui template atau menghapusnya).
  + `imageId`Parameter.
  + `imageIdOverride`Parameter dalam konfigurasi EC2.
+ Saat menggunakan strategi `BEST_FIT` alokasi (tidak mendukung pembaruan infrastruktur).
+ Saat tidak menggunakan peran *AWSServiceRoleForBatch*[terkait layanan](using-service-linked-roles-batch-general.md).

### Pembaruan AMI untuk AMI khusus
<a name="manual-ami-updates-custom-ami"></a>

Jika Anda menentukan AMI kustom dalam template peluncuran lingkungan komputasi, `imageId` parameter atau `imageIdOverride` parameter dalam konfigurasi EC2, tidak AWS Batch akan secara otomatis memperbarui AMI kustom Anda selama pembaruan infrastruktur. Anda dapat memperbarui id AMI kustom dengan menentukan id baru dalam parameter yang awalnya digunakan selama pembuatan Lingkungan Komputasi. Jika Anda ingin beralih menggunakan AMI AWS Batch-provided, Anda dapat melakukannya dengan menghapus ID AMI kustom di pembaruan lingkungan komputasi Anda.