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

# Jadwalkan wadah Anda di Amazon ECS
<a name="scheduling_tasks"></a>

Amazon Elastic Container Service (Amazon ECS) adalah sistem konkurensi optimis status bersama yang menyediakan kemampuan penjadwalan fleksibel untuk beban kerja kontainer Anda. Penjadwal Amazon ECS menggunakan informasi status cluster yang sama dengan Amazon ECS API untuk membuat keputusan penempatan yang tepat.

Amazon ECS menyediakan penjadwal layanan untuk tugas dan aplikasi yang berjalan lama. Ini juga menyediakan kemampuan untuk menjalankan tugas mandiri atau tugas terjadwal untuk pekerjaan batch atau tugas tunggal. Anda dapat menentukan strategi dan kendala penempatan tugas untuk menjalankan tugas yang paling sesuai dengan kebutuhan Anda. Misalnya, Anda dapat menentukan apakah tugas berjalan di beberapa Availability Zone atau dalam Availability Zone tunggal. Dan, secara opsional, Anda dapat mengintegrasikan tugas dengan penjadwal kustom atau pihak ketiga Anda sendiri.


| Opsi | Kapan harus digunakan | Informasi selengkapnya | 
| --- | --- | --- | 
| Layanan | Penjadwal layanan cocok untuk layanan dan aplikasi stateless yang berjalan lama. Penjadwal layanan secara opsional juga memastikan bahwa tugas terdaftar terhadap penyeimbang beban Elastic Load Balancing. Anda dapat memperbarui layanan Anda yang dikelola oleh penjadwal layanan. Ini mungkin termasuk men-deploy ketentuan tugas baru atau mengubah jumlah tugas yang diinginkan yang sedang berjalan. Secara default, penjadwal layanan menyebar tugas di beberapa Availability Zone. Namun, Anda dapat menggunakan strategi penempatan tugas dan kendala untuk menyesuaikan keputusan penempatan tugas.  | [Layanan-layanan Amazon ECS](ecs_services.md) | 
| Tugas mandiri | Tugas mandiri cocok untuk proses seperti pekerjaan batch yang melakukan pekerjaan dan kemudian berhenti. Misalnya, Anda dapat memiliki panggilan proses RunTask ketika pekerjaan masuk ke antrian. Tugas menarik pekerjaan dari antrean, melaksanakan pekerjaan, dan kemudian keluar. Menggunakan RunTask, Anda dapat mengizinkan strategi penempatan tugas default untuk mendistribusikan tugas secara acak di klaster Anda. Hal ini meminimalkan kemungkinan instans tunggal mendapatkan jumlah tugas yang tidak proporsional. | [Tugas mandiri Amazon ECS](standalone-tasks.md) | 
| Tugas terjadwal | Tugas terjadwal cocok ketika Anda memiliki tugas untuk dijalankan pada interval yang ditetapkan di cluster Anda, Anda dapat menggunakan EventBridge Scheduler untuk membuat jadwal. Anda dapat menjalankan tugas untuk operasi pencadangan atau pemindaian log. Jadwal EventBridge Scheduler yang Anda buat dapat menjalankan satu atau beberapa tugas di klaster Anda pada waktu yang ditentukan. Acara terjadwal Anda dapat diatur ke interval tertentu (dijalankan setiap N menit, jam, atau hari). Jika tidak, untuk penjadwalan yang lebih rumit, Anda dapat menggunakan cron ekspresi. | [Menggunakan Amazon EventBridge Scheduler untuk menjadwalkan tugas Amazon ECS](tasks-scheduled-eventbridge-scheduler.md) | 

## Opsi Komputasi
<a name="compute-option"></a>

Dengan Amazon ECS, Anda dapat menentukan infrastruktur tugas atau layanan yang dijalankan. Anda dapat menggunakan strategi penyedia kapasitas, atau jenis peluncuran.

Untuk Fargate, penyedia kapasitas adalah Fargate dan Fargate Spot. Untuk EC2, penyedia kapasitas adalah grup Auto Scaling dengan instans kontainer terdaftar.

Strategi penyedia kapasitas mendistribusikan tugas Anda ke seluruh penyedia kapasitas yang terkait dengan klaster Anda.

Hanya penyedia kapasitas yang keduanya sudah terkait dengan cluster dan memiliki `UPDATING` status `ACTIVE` atau yang dapat digunakan dalam strategi penyedia kapasitas. Anda dapat mengaitkan penyedia kapasitas dengan klaster saat membuat klaster. 

Dalam strategi penyedia kapasitas, nilai *dasar* opsional menunjukkan berapa banyak tugas, minimal, yang dijalankan pada penyedia kapasitas tertentu. Hanya satu penyedia kapasitas di strategi penyedia kapasitas yang dapat menentukan nilai dasar.

Nilai *bobot* menentukan persentase relatif dari jumlah total tugas yang diluncurkan yang menggunakan penyedia kapasitas yang ditentukan. Pertimbangkan contoh berikut. Anda memiliki strategi yang berisi dua penyedia kapasitas, dan keduanya memiliki bobot`1`. Ketika persentase dasar tercapai, tugas dibagi secara merata di dua penyedia kapasitas. *Menggunakan logika yang sama, misalkan Anda menentukan bobot untuk *CapacityProvidera dan bobot `1` untuk CapacityProviderB*. `4`* *Kemudian, untuk setiap tugas yang dijalankan menggunakan *CapacityProvidera*, ada empat tugas yang menggunakan CapacityProviderB.*

Opsi komputasi meluncurkan tugas Anda secara langsung di Fargate atau di instans Amazon EC2 yang telah Anda daftarkan secara manual ke cluster Anda.

# Siklus hidup tugas Amazon ECS
<a name="task-lifecycle-explanation"></a>

Ketika tugas dimulai, baik secara manual atau sebagai bagian dari layanan, itu dapat melalui beberapa status sebelum selesai sendiri atau dihentikan secara manual. Beberapa tugas dimaksudkan untuk dijalankan sebagai tugas batch yang secara alami terus berjalan dari `PENDING` ke `RUNNING` ke `STOPPED`. Tugas-tugas lain, yang dapat menjadi bagian dari layanan, dimaksudkan untuk terus berjalan tanpa batas waktu, atau untuk dinaik-turunkan skalanya sesuai kebutuhan.

Ketika perubahan status tugas diminta, seperti menghentikan tugas atau memperbarui jumlah layanan yang diinginkan untuk menskalakannya naik atau turun, agen penampung Amazon ECS melacak perubahan ini sebagai status (`lastStatus`) tugas terakhir yang diketahui dan status (`desiredStatus`) tugas yang diinginkan. Kedua status yang diketahui terakhir dan status yang diinginkan dari tugas dapat dilihat baik di konsol atau dengan menggambarkan tugas dengan API atau AWS CLI.

Diagram alur di bawah ini menunjukkan alur siklus hidup tugas.

![\[Diagram status siklus hidup tugas. Statusnya adalah PROVISIONING, PENDING, ACTIVATING, RUNNING, NONAKTIVATING, STOPING.\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/images/task-lifecycle.png)


## Status siklus hidup
<a name="lifecycle-states"></a>

Berikut ini adalah deskripsi dari masing-masing status siklus hidup tugas.

PENYEDIAAN  
Amazon ECS harus melakukan langkah-langkah tambahan sebelum tugas diluncurkan. Misalnya, untuk tugas yang menggunakan mode jaringan `awsvpc`, antarmuka jaringan elastis perlu ditetapkan.

MENUNGGU  
Ini adalah keadaan transisi di mana Amazon ECS sedang menunggu agen kontainer untuk mengambil tindakan lebih lanjut. Tugas tetap dalam status tertunda sampai ada sumber daya yang tersedia untuk tugas tersebut.

MENGAKTIFKAN  
Ini adalah keadaan transisi di mana Amazon ECS harus melakukan langkah-langkah tambahan setelah tugas diluncurkan tetapi sebelum tugas dapat bertransisi ke `RUNNING` status. Ini adalah keadaan di mana Amazon ECS menarik gambar kontainer, membuat kontainer, mengonfigurasi jaringan tugas, mendaftarkan grup target penyeimbang beban, dan mengonfigurasi penemuan layanan.

BERJALAN  
Tugas ini berhasil berjalan.

MENONAKTIFKAN  
Ini adalah keadaan transisi di mana Amazon ECS harus melakukan langkah-langkah tambahan sebelum tugas dihentikan. Misalnya, untuk tugas yang merupakan bagian dari layanan yang dikonfigurasi untuk menggunakan grup target Elastic Load Balancings, deregistrasi grup target terjadi selama status ini.

BERHENTI  
Ini adalah keadaan transisi di mana Amazon ECS sedang menunggu agen kontainer untuk mengambil tindakan lebih lanjut.  
Untuk kontainer Linux, agen kontainer akan mengirimkan sinyal berhenti yang ditentukan dalam gambar kontainer Anda untuk memberi tahu aplikasi harus selesai dan dimatikan menggunakan `STOPSIGNAL` instruksi. Ini secara `SIGTERM` default. Kemudian akan mengirim `SIGKILL` setelah menunggu `StopTimeout` durasi yang ditetapkan dalam definisi tugas. 

PEMBATALAN PENYEDIAAN  
Amazon ECS harus melakukan langkah-langkah tambahan setelah tugas berhenti tetapi sebelum tugas beralih ke negara bagian`STOPPED`. Misalnya, untuk tugas yang menggunakan mode jaringan`awsvpc`, antarmuka jaringan elastis perlu dilepas dan dihapus.

DIHENTIKAN  
Tugas telah berhasil dihentikan.  
Jika tugas Anda berhenti karena kesalahan, lihat[Melihat Amazon ECS menghentikan kesalahan tugas](stopped-task-errors.md).

DELETED  
Ini adalah keadaan transisi ketika tugas berhenti. Status ini tidak ditampilkan di konsol, tetapi ditampilkan di`describe-tasks`.

# Cara Amazon ECS Menempatkan Tugas di Instans Kontainer
<a name="task-placement"></a>

Anda dapat menggunakan penempatan tugas untuk mengonfigurasi Amazon ECS untuk menempatkan tugas Anda pada instance container yang memenuhi kriteria tertentu, misalnya Availability Zone atau tipe instans.

Berikut ini adalah komponen penempatan tugas:
+ Strategi penempatan tugas - Algoritma untuk memilih instance kontainer untuk penempatan tugas atau tugas untuk penghentian. Misalnya, Amazon ECS dapat memilih instans kontainer secara acak, atau dapat memilih instance kontainer sedemikian rupa sehingga tugas didistribusikan secara merata di seluruh grup instance.
+ Kelompok tugas - Sekelompok tugas terkait, misalnya tugas database.
+ Kendala penempatan tugas - Ini adalah aturan yang harus dipenuhi untuk menempatkan tugas pada instance kontainer. Jika kendala tidak terpenuhi, tugas tidak ditempatkan dan tetap di negara bagian. `PENDING` Misalnya, Anda dapat menggunakan kendala untuk menempatkan tugas hanya pada jenis instance tertentu. 

Amazon ECS memiliki algoritma yang berbeda untuk opsi kapasitas yang berbeda. 

## Instans Terkelola Amazon ECS
<a name="managed-instances-launch-type"></a>

Untuk tugas yang berjalan di Instans Terkelola Amazon ECS, Amazon ECS harus menentukan tempat untuk menempatkan tugas, dan — saat mengurangi jumlah tugas — tugas mana yang harus dihentikan. Amazon ECS membuat penentuan ini berdasarkan persyaratan instans yang ditentukan dalam templat peluncuran penyedia kapasitas, persyaratan yang ditentukan dalam definisi tugas seperti CPU dan memori, dan batasan penempatan tugas.

**catatan**  
Instans Terkelola Amazon ECS tidak mendukung strategi penempatan tugas. Amazon ECS akan mencoba yang terbaik untuk menyebarkan tugas di seluruh Availability Zone yang dapat diakses.

Saat Amazon ECS menempatkan tugas, Amazon menggunakan proses berikut untuk memilih instance container:

1. Identifikasi instance kontainer yang memenuhi persyaratan CPU, GPU, memori, dan port dalam definisi tugas.

1. Identifikasi instance kontainer yang memenuhi kendala penempatan tugas.

1. Identifikasi instance kontainer yang memenuhi persyaratan instans yang ditentukan dalam templat peluncuran penyedia kapasitas.

1. Pilih instance kontainer untuk penempatan tugas.

## EC2
<a name="ec2-launch-type"></a>

Untuk tugas yang menggunakan tipe peluncuran EC2, Amazon ECS harus menentukan tempat untuk menempatkan tugas berdasarkan persyaratan yang ditentukan dalam definisi tugas, seperti CPU dan memori. Demikian pula, saat Anda menurunkan jumlah tugas, Amazon ECS harus menentukan tugas mana yang akan dihentikan. Anda dapat menerapkan strategi dan batasan penempatan tugas untuk menyesuaikan cara Amazon ECS menempatkan dan mengakhiri tugas. 

Strategi penempatan tugas default bergantung pada apakah Anda menjalankan tugas secara manual (tugas mandiri) atau dalam layanan. Untuk tugas yang berjalan sebagai bagian dari layanan Amazon ECS, strategi penempatan tugas `spread` menggunakan. `attribute:ecs.availability-zone` Tidak ada batasan penempatan tugas default untuk tugas yang tidak ada di layanan. Untuk informasi selengkapnya, lihat [Jadwalkan wadah Anda di Amazon ECS](scheduling_tasks.md).

**catatan**  
Strategi penempatan tugas adalah upaya terbaik. Amazon ECS masih mencoba untuk menempatkan tugas bahkan ketika opsi penempatan paling optimal tidak tersedia. Namun, kendala penempatan tugas bersifat mengikat, dan mereka dapat mencegah penempatan tugas. 

Anda dapat menggunakan strategi dan kendala penempatan tugas bersama-sama. Misalnya, Anda dapat menggunakan strategi penempatan tugas dan kendala penempatan tugas untuk mendistribusikan tugas di tugas Availability Zone dan paket bin berdasarkan memori dalam setiap Availability Zone, tetapi hanya untuk instans G2.

Saat Amazon ECS menempatkan tugas, Amazon menggunakan proses berikut untuk memilih instance container:

1. Identifikasi instance kontainer yang memenuhi persyaratan CPU, GPU, memori, dan port dalam definisi tugas.

1. Identifikasi instance kontainer yang memenuhi kendala penempatan tugas.

1. Identifikasi instance kontainer yang memenuhi strategi penempatan tugas.

1. Pilih instance kontainer untuk penempatan tugas.

## Fargate
<a name="fargate-launch-type"></a>

Strategi penempatan tugas dan kendala tidak didukung untuk tugas yang menggunakan Fargate. Fargate akan mencoba yang terbaik untuk menyebarkan tugas di seluruh Availability Zone yang dapat diakses. Jika penyedia kapasitas mencakup Fargate dan Fargate Spot, perilaku spread bersifat independen untuk setiap penyedia kapasitas. 

# Instans Terkelola Amazon ECS penskalaan otomatis dan penempatan tugas
<a name="managed-instance-auto-scaling"></a>

Instans Terkelola Amazon ECS menggunakan algoritme cerdas untuk menskalakan kapasitas klaster secara otomatis dan menempatkan tugas secara efisien di seluruh infrastruktur Anda. Memahami cara kerja algoritme ini membantu Anda mengoptimalkan konfigurasi layanan dan memecahkan masalah perilaku penempatan.

## Algoritma penempatan tugas
<a name="managed-instance-task-placement-algorithm"></a>

Instans Terkelola Amazon ECS menggunakan algoritme penempatan canggih yang menyeimbangkan ketersediaan, pemanfaatan sumber daya, dan persyaratan jaringan saat menjadwalkan tugas.

### Penyebaran Zona Ketersediaan
<a name="managed-instance-az-spread-behavior"></a>

Secara default, Instans Terkelola Amazon ECS memprioritaskan ketersediaan dengan menyebarkan tugas di beberapa Availability Zone:
+ Untuk layanan dengan beberapa tugas, Instans Terkelola Amazon ECS memastikan distribusi di setidaknya 3 instans di Availability Zone yang berbeda bila memungkinkan
+ Perilaku ini memberikan toleransi kesalahan tetapi dapat mengakibatkan pemanfaatan sumber daya yang lebih rendah per instance
+ Penyebaran Availability Zone lebih diutamakan daripada optimasi pengemasan bin

### Perilaku pengepakan bin
<a name="managed-instance-bin-packing"></a>

Meskipun Instans Terkelola Amazon ECS dapat melakukan pengemasan bin untuk memaksimalkan pemanfaatan sumber daya, perilaku ini dipengaruhi oleh konfigurasi jaringan Anda:
+ Untuk mencapai kemasan bin, konfigurasikan layanan Anda untuk menggunakan satu subnet
+ Konfigurasi multi-subnet memprioritaskan distribusi Availability Zone di atas kepadatan sumber daya
+ Pengepakan bin lebih mungkin terjadi selama peluncuran layanan awal daripada selama acara penskalaan

### Pertimbangan kepadatan ENI
<a name="managed-instance-eni-density"></a>

Untuk layanan yang menggunakan mode `awsvpc` jaringan, Instans Terkelola Amazon ECS mempertimbangkan kepadatan Antarmuka Jaringan Elastis (ENI) saat membuat keputusan penempatan:
+ Setiap tugas dalam `awsvpc` mode membutuhkan ENI khusus
+ Jenis instans memiliki batas ENI berbeda yang memengaruhi kepadatan tugas
+ Instans Terkelola Amazon ECS memperhitungkan ketersediaan ENI saat memilih instans target

**catatan**  
Perbaikan perhitungan kepadatan ENI terus dilakukan untuk mengoptimalkan keputusan penempatan.

## Logika keputusan penyedia kapasitas
<a name="managed-instance-capacity-provider-decisions"></a>

Penyedia kapasitas Instans Terkelola Amazon ECS membuat keputusan penskalaan dan penempatan berdasarkan beberapa faktor:

Persyaratan sumber daya  
CPU, memori, dan persyaratan jaringan untuk tugas yang tertunda

Ketersediaan instans  
Kapasitas dan pemanfaatan saat ini di seluruh instans yang ada

Kendala jaringan  
Konfigurasi subnet dan ketersediaan ENI

Distribusi Zona Ketersediaan  
Mempertahankan toleransi kesalahan di beberapa Availability Zone

## Opsi konfigurasi
<a name="managed-instance-configuration-options"></a>

### Strategi pemilihan subnet
<a name="managed-instance-subnet-strategy"></a>

Konfigurasi subnet Anda secara signifikan memengaruhi perilaku penempatan tugas:

Beberapa subnet (default)  
Memprioritaskan penyebaran Availability Zone untuk ketersediaan tinggi  
Dapat mengakibatkan pemanfaatan sumber daya yang lebih rendah per instance  
Direkomendasikan untuk beban kerja produksi yang membutuhkan toleransi kesalahan

Subnet tunggal  
Memungkinkan pengepakan bin untuk pemanfaatan sumber daya yang lebih tinggi  
Mengurangi toleransi kesalahan dengan memusatkan tugas dalam satu Availability Zone  
Cocokkan untuk pengembangan atau beban kerja yang dioptimalkan biaya

### Pertimbangan mode jaringan
<a name="managed-instance-network-mode-considerations"></a>

Mode jaringan yang Anda pilih memengaruhi keputusan penempatan:
+ `awsvpc`mode - Setiap tugas membutuhkan ENI khusus, membatasi kepadatan tugas per instance
+ `host`mode — Tugas menggunakan jaringan host secara langsung, dengan penempatan terutama didorong oleh ketersediaan sumber daya

### Pertimbangan arsitektur CPU
<a name="managed-instance-cpu-architecture-considerations"></a>

`cpuArchitecture`Yang Anda tentukan dalam definisi tugas Anda digunakan untuk menempatkan tugas pada arsitektur tertentu. Jika Anda tidak menentukan`cpuArchitecture`, Amazon ECS akan mencoba menempatkan tugas pada arsitektur CPU apa pun yang tersedia berdasarkan konfigurasi penyedia kapasitas. Anda dapat menentukan `X86_64` atau `ARM64`.

## Pemecahan masalah penempatan tugas
<a name="managed-instance-troubleshooting-placement"></a>

### Pola penempatan umum
<a name="managed-instance-common-placement-patterns"></a>

Memahami pola penempatan yang diharapkan membantu membedakan perilaku normal dari masalah potensial:

Distribusi penyebaran  
Tugas didistribusikan di beberapa instance dengan pemanfaatan sebagian  
Perilaku normal saat menggunakan beberapa subnet  
Menunjukkan prioritas ketersediaan di atas efisiensi sumber daya

Penempatan terkonsentrasi  
Beberapa tugas ditempatkan pada instance yang lebih sedikit dengan pemanfaatan yang lebih tinggi  
Diharapkan saat menggunakan konfigurasi subnet tunggal  
Dapat terjadi selama peluncuran layanan awal

Distribusi tidak merata  
Beberapa kasus banyak digunakan sementara yang lain tetap kurang dimanfaatkan  
Dapat menunjukkan batas ENI atau kendala sumber daya  
Pertimbangkan untuk meninjau jenis instance dan konfigurasi jaringan

### Mengoptimalkan perilaku penempatan
<a name="managed-instance-placement-optimization"></a>

Untuk mengoptimalkan penempatan tugas untuk kebutuhan spesifik Anda:

1. Evaluasi persyaratan ketersediaan Anda versus kebutuhan pengoptimalan biaya

1. Pilih konfigurasi subnet yang sesuai berdasarkan prioritas Anda

1. Pilih jenis instans dengan kapasitas ENI yang memadai untuk mode jaringan Anda

1. Pantau pola penempatan dan sesuaikan konfigurasi sesuai kebutuhan

## Praktik terbaik
<a name="managed-instance-best-practices"></a>
+ **Untuk beban kerja produksi** — Gunakan beberapa subnet di berbagai Availability Zone untuk memastikan ketersediaan tinggi, menerima trade-off dalam pemanfaatan sumber daya
+ **Untuk pengembangan atau pengujian** - Pertimbangkan konfigurasi subnet tunggal untuk memaksimalkan pemanfaatan sumber daya dan mengurangi biaya
+ **Untuk `awsvpc` mode** — Pilih jenis instans dengan kapasitas ENI yang cukup untuk menghindari kendala penempatan
+ **Untuk optimalisasi biaya** — Pantau pola pemanfaatan dan sesuaikan konfigurasi layanan untuk menyeimbangkan ketersediaan dan efisiensi
+ **Untuk pemecahan masalah** - Tinjau konfigurasi subnet dan mode jaringan saat menyelidiki pola penempatan yang tidak terduga

# Gunakan strategi untuk menentukan penempatan tugas Amazon ECS
<a name="task-placement-strategies"></a>

Untuk tugas yang menggunakan tipe peluncuran EC2, Amazon ECS harus menentukan tempat untuk menempatkan tugas berdasarkan persyaratan yang ditentukan dalam definisi tugas, seperti CPU dan memori. Demikian pula, saat Anda menurunkan jumlah tugas, Amazon ECS harus menentukan tugas mana yang akan dihentikan. Anda dapat menerapkan strategi dan batasan penempatan tugas untuk menyesuaikan cara Amazon ECS menempatkan dan mengakhiri tugas. 

Strategi penempatan tugas default bergantung pada apakah Anda menjalankan tugas secara manual (tugas mandiri) atau dalam layanan. Untuk tugas yang berjalan sebagai bagian dari layanan Amazon ECS, strategi penempatan tugas `spread` menggunakan. `attribute:ecs.availability-zone` Tidak ada batasan penempatan tugas default untuk tugas yang tidak ada di layanan. Untuk informasi selengkapnya, lihat [Jadwalkan wadah Anda di Amazon ECS](scheduling_tasks.md).

**catatan**  
Strategi penempatan tugas adalah upaya terbaik. Amazon ECS masih mencoba untuk menempatkan tugas bahkan ketika opsi penempatan paling optimal tidak tersedia. Namun, kendala penempatan tugas bersifat mengikat, dan mereka dapat mencegah penempatan tugas. 

Anda dapat menggunakan strategi dan kendala penempatan tugas bersama-sama. Misalnya, Anda dapat menggunakan strategi penempatan tugas dan kendala penempatan tugas untuk mendistribusikan tugas di tugas Availability Zone dan paket bin berdasarkan memori dalam setiap Availability Zone, tetapi hanya untuk instans G2.

Saat Amazon ECS menempatkan tugas, Amazon menggunakan proses berikut untuk memilih instance container:

1. Identifikasi instance kontainer yang memenuhi persyaratan CPU, GPU, memori, dan port dalam definisi tugas.

1. Identifikasi instance kontainer yang memenuhi kendala penempatan tugas.

1. Identifikasi instance kontainer yang memenuhi strategi penempatan tugas.

1. Pilih instance kontainer untuk penempatan tugas.

Anda menentukan strategi penempatan tugas dalam definisi layanan, atau definisi tugas menggunakan `placementStrategy` parameter.

```
"placementStrategy": [
    {
        "field": "The field to apply the placement strategy against",
        "type": "The placement strategy to use"
    }
]
```

Anda dapat menentukan strategi saat menjalankan task ([RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)), membuat layanan baru ([CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)), atau memperbarui layanan yang ada ([UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)).

Tabel berikut menjelaskan jenis dan bidang yang tersedia.


| jenis | Nilai bidang yang valid | 
| --- | --- | 
| binpack Tugas ditempatkan pada instans kontainer sehingga meninggalkan jumlah paling sedikit untuk CPU atau memori yang tidak terpakai. Strategi ini meminimalkan jumlah instans kontainer yang digunakan. Ketika strategi ini digunakan dan tindakan scale-in diambil, Amazon ECS menghentikan tugas. Hal ini dilakukan berdasarkan jumlah sumber daya yang tersisa pada instance container setelah tugas dihentikan. Instance kontainer yang memiliki sumber daya paling banyak yang tersisa setelah penghentian tugas telah menghentikan tugas tersebut. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 
| random Tugas ditempatkan secara acak. | Tidak digunakan | 
| spreadTugas ditempatkan secara merata berdasarkan nilai yang ditentukan. Tugas layanan tersebar berdasarkan tugas dari layanan tersebut. Tugas mandiri tersebar berdasarkan tugas dari grup tugas yang sama. Untuk informasi selengkapnya tentang grup tugas, lihat [Tugas Amazon ECS terkait grup](task-groups.md). Saat `spread` strategi digunakan dan tindakan penskalaan diambil, Amazon ECS memilih tugas untuk dihentikan yang menjaga keseimbangan di seluruh Availability Zone. Dalam Availability Zone, tugas dipilih secara acak. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 

Strategi penempatan tugas dapat diperbarui untuk layanan yang ada juga. Untuk informasi selengkapnya, lihat [Cara Amazon ECS Menempatkan Tugas di Instans Kontainer](task-placement.md).

Anda dapat membuat strategi penempatan tugas yang menggunakan beberapa strategi dengan membuat array strategi sesuai urutan yang Anda inginkan. Misalnya, jika Anda ingin menyebarkan tugas di seluruh Availability Zones dan kemudian bin pack task berdasarkan memori dalam setiap Availability Zone, tentukan strategi Availability Zone yang diikuti oleh strategi memori. Misalnya strategi, lihat[Contoh strategi penempatan tugas Amazon ECS](strategy-examples.md).

# Contoh strategi penempatan tugas Amazon ECS
<a name="strategy-examples"></a>

Anda dapat menentukan strategi penempatan tugas dengan tindakan berikut: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), dan [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

**Topics**
+ [

## Mendistribusikan tugas secara merata di seluruh Availability Zone
](#even-az)
+ [

## Mendistribusikan tugas secara merata di semua contoh
](#even-instance)
+ [

## Tugas bin pack berdasarkan memori
](#binpack)
+ [

## Tempatkan tugas secara acak
](#random)
+ [

## Mendistribusikan tugas secara merata di seluruh Availability Zone dan kemudian mendistribusikan tugas secara merata di seluruh instance dalam setiap Availability Zone
](#az-instance)
+ [

## Mendistribusikan tugas secara merata di seluruh Availability Zones dan kemudian bin pack task berdasarkan memori dalam setiap Availability Zone
](#az-memory)
+ [

## Mendistribusikan tugas secara merata di seluruh instance dan kemudian tugas bin pack berdasarkan memori
](#instance-memory)

## Mendistribusikan tugas secara merata di seluruh Availability Zone
<a name="even-az"></a>

Strategi berikut mendistribusikan tugas secara merata di seluruh Availability Zone.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    }
]
```

## Mendistribusikan tugas secara merata di semua contoh
<a name="even-instance"></a>

Strategi berikut mendistribusikan tugas secara merata di semua instans.

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## Tugas bin pack berdasarkan memori
<a name="binpack"></a>

Berikut tugas bin pack strategi berdasarkan memori.

```
"placementStrategy": [
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Tempatkan tugas secara acak
<a name="random"></a>

Strategi berikut menempatkan tugas secara acak.

```
"placementStrategy": [
    {
        "type": "random"
    }
]
```

## Mendistribusikan tugas secara merata di seluruh Availability Zone dan kemudian mendistribusikan tugas secara merata di seluruh instance dalam setiap Availability Zone
<a name="az-instance"></a>

Strategi berikut mendistribusikan tugas secara merata di seluruh Availability Zone dan kemudian mendistribusikan tugas secara merata di seluruh instans dalam setiap Availability Zone.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## Mendistribusikan tugas secara merata di seluruh Availability Zones dan kemudian bin pack task berdasarkan memori dalam setiap Availability Zone
<a name="az-memory"></a>

Strategi berikut mendistribusikan tugas secara merata di seluruh Availability Zone dan kemudian tugas bin pack berdasarkan memori dalam setiap Availability Zone.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Mendistribusikan tugas secara merata di seluruh instance dan kemudian tugas bin pack berdasarkan memori
<a name="instance-memory"></a>

Strategi berikut mendistribusikan tugas secara merata di semua instance dan kemudian mengemas tugas berdasarkan memori dalam setiap instance. 

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

# Tugas Amazon ECS terkait grup
<a name="task-groups"></a>

Anda dapat mengidentifikasi satu set tugas terkait dan menempatkannya dalam grup tugas. Semua tugas dengan nama grup tugas yang sama dianggap sebagai satu rangkaian ketika menggunakan strategi penempatan tugas `spread`. Misalnya, Anda menjalankan aplikasi yang berbeda dalam satu cluster, seperti database dan server web. Untuk memastikan bahwa basis data Anda seimbang di seluruh Availability Zone, tambahkan basis data ke grup tugas bernama `databases` dan kemudian gunakan strategi penempatan tugas `spread`. Untuk informasi selengkapnya, lihat [Gunakan strategi untuk menentukan penempatan tugas Amazon ECS](task-placement-strategies.md).

Kelompok tugas juga dapat digunakan sebagai kendala penempatan tugas. Saat Anda menentukan grup tugas dalam `memberOf` batasan, tugas hanya dikirim ke instance kontainer yang menjalankan tugas dalam grup tugas yang ditentukan. Sebagai contoh, lihat [Contoh kendala penempatan tugas Amazon ECS](constraint-examples.md).

Secara default, tugas mandiri menggunakan nama keluarga definisi tugas (misalnya,`family:my-task-definition`) sebagai nama grup tugas jika nama grup tugas kustom tidak ditentukan. Tugas yang diluncurkan sebagai bagian dari layanan menggunakan nama layanan sebagai nama grup tugas dan tidak dapat diubah.

Persyaratan berikut untuk kelompok tugas berlaku.
+ Nama grup tugas harus 255 karakter atau kurang.
+ Setiap tugas bisa berada dalam satu grup.
+ Setelah meluncurkan tugas, Anda tidak dapat memodifikasi grup tugasnya.

# Menentukan Instans Kontainer Mana yang Digunakan Amazon ECS untuk Tugas
<a name="task-placement-constraints"></a>

Batasan penempatan tugas adalah aturan tentang instance kontainer yang digunakan Amazon ECS untuk menentukan apakah tugas diizinkan untuk dijalankan pada instance. Setidaknya satu instance kontainer harus cocok dengan kendala. Jika tidak ada instance yang cocok dengan kendala, tugas tetap dalam keadaan. `PENDING` Saat membuat layanan baru atau memperbarui layanan yang sudah ada, Anda dapat menentukan batasan penempatan tugas untuk tugas layanan. 

Anda dapat menentukan batasan penempatan tugas dalam definisi layanan, definisi tugas, atau tugas menggunakan parameter. `placementConstraint`

```
"placementConstraints": [
    {
        "expression": "The expression that defines the task placement constraints",
        "type": "The placement constraint type to use"
    }
]
```

Tabel berikut menjelaskan cara menggunakan parameter.


| Jenis kendala | Dapat ditentukan kapan | 
| --- | --- | 
| distinctInstanceTempatkan setiap tugas aktif pada instance kontainer yang berbeda.Amazon ECS melihat status tugas yang diinginkan untuk penempatan tugas. Misalnya, jika status yang diinginkan dari tugas yang ada adalah`STOPPED`, (tetapi status terakhir tidak), tugas masuk baru dapat ditempatkan pada instance yang sama meskipun ada kendala `distinctInstance` penempatan. Oleh karena itu, Anda mungkin melihat 2 tugas dengan status terakhir `RUNNING` pada instance yang sama. Kami menyarankan agar pelanggan yang mencari isolasi yang kuat untuk tugas mereka menggunakan Fargate. Fargate menjalankan setiap tugas dalam lingkungan virtualisasi perangkat keras. Ini memastikan bahwa beban kerja kontainer ini tidak berbagi antarmuka jaringan, penyimpanan sementara Fargate, CPU, atau memori dengan tugas lain. Untuk informasi selengkapnya, lihat [Gambaran Umum Keamanan AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf). |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/task-placement-constraints.html)  | 
| memberOfTempatkan tugas pada instans kontainer yang memenuhi ekspresi.  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/task-placement-constraints.html) | 

Bila menggunakan tipe `memberOf` constraint, Anda dapat membuat ekspresi menggunakan bahasa kueri klaster yang menentukan instance container tempat Amazon ECS dapat menempatkan tugas. Ekspresi adalah cara bagi Anda untuk mengelompokkan instance container Anda berdasarkan atribut. Ekspresi masuk dalam `expression ` parameter`placementConstraint`.

## Atribut instans wadah Amazon ECS
<a name="attributes"></a>

Anda dapat menambahkan metadata kustom ke instans kontainer Anda, yang dikenal sebagai *atribut*. Tiap atribut memiliki nama dan nilai string opsional. Anda dapat menggunakan atribut bawaan yang disediakan oleh Amazon ECS atau menentukan atribut khusus.

Bagian berikut berisi contoh built-in, opsional, dan atribut kustom.

### Atribut bawaan
<a name="ecs-automatic-attributes"></a>

Amazon ECS secara otomatis menerapkan atribut berikut ke instance container Anda.

`ecs.ami-id`  
ID AMI yang digunakan untuk meluncurkan instans. Nilai contoh untuk atribut ini adalah `ami-1234abcd`.

`ecs.availability-zone`  
Availability Zone untuk instans. Nilai contoh untuk atribut ini adalah `us-east-1a`.

`ecs.instance-type`  
Jenis instans untuk instans tersebut. Nilai contoh untuk atribut ini adalah `g2.2xlarge`.

`ecs.os-type`  
Sistem operasi untuk instans. Nilai yang mungkin untuk atribut ini adalah `linux` dan `windows`.

`ecs.os-family`  
Versi sistem operasi untuk contoh.  
Untuk contoh Linux, nilai yang valid adalah`LINUX`. Untuk instance Windows, ECS menetapkan nilai dalam format. `WINDOWS_SERVER_<OS_Release>_<FULL or CORE>` Nilai yang valid adalah`WINDOWS_SERVER_2022_FULL`,`WINDOWS_SERVER_2022_CORE`,`WINDOWS_SERVER_20H2_CORE`,`WINDOWS_SERVER_2019_FULL`,`WINDOWS_SERVER_2019_CORE`, dan`WINDOWS_SERVER_2016_FULL`.  
Ini penting untuk wadah Windows dan Windows containers on AWS Fargate karena versi OS dari setiap wadah Windows harus cocok dengan host. Jika versi Windows dari gambar kontainer berbeda dari host, penampung tidak dimulai. Untuk informasi selengkapnya, lihat [Kompatibilitas versi penampung Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11) di situs web dokumentasi Microsoft.  
Jika klaster Anda menjalankan beberapa versi Windows, Anda dapat memastikan bahwa tugas ditempatkan pada instans EC2 yang berjalan pada versi yang sama dengan menggunakan batasan penempatan:. `memberOf(attribute:ecs.os-family == WINDOWS_SERVER_<OS_Release>_<FULL or CORE>)` Untuk informasi selengkapnya, lihat [Mengambil metadata Windows AMI yang dioptimalkan Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).

`ecs.cpu-architecture`  
Arsitektur CPU untuk instans. Nilai contoh untuk atribut ini adalah `x86_64` dan `arm64`.

`ecs.vpc-id`  
VPC tempat instans diluncurkan. Nilai contoh untuk atribut ini adalah `vpc-1234abcd`.

`ecs.subnet-id`  
Subnet yang digunakan instans. Nilai contoh untuk atribut ini adalah `subnet-1234abcd`.

**catatan**  
Instans Terkelola Amazon ECS mendukung subset atribut berikut:  
`ecs.subnet-id`
`ecs.availability-zone`
`ecs.instance-type`
`ecs.cpu-architecture`

### Atribut opsional
<a name="ecs-optional-attributes"></a>

Amazon ECS dapat menambahkan atribut berikut ke instance container Anda.

`ecs.awsvpc-trunk-id`  
Jika atribut ini ada, instans memiliki antarmuka jaringan trunk. Untuk informasi selengkapnya, lihat [Meningkatkan antarmuka jaringan instans kontainer Amazon ECS Linux](container-instance-eni.md).

`ecs.outpost-arn`  
Jika atribut ini ada, itu berisi Amazon Resource Name (ARN) dari Outpost. Untuk informasi selengkapnya, lihat [Layanan Kontainer Elastis Amazon aktif AWS Outposts](using-outposts.md).

`ecs.capability.external`  
Jika atribut ini ada, instans diidentifikasi sebagai instans eksternal. Untuk informasi selengkapnya, lihat [Cluster Amazon ECS untuk instans eksternal](ecs-anywhere.md).

### Atribut kustom
<a name="ecs-custom-attributes"></a>

Anda dapat menerapkan atribut kustom ke instans kontainer Anda. Misalnya, Anda dapat menentukan atribut dengan nama “stack” dan nilai “prod”.

Saat menentukan atribut khusus, Anda harus mempertimbangkan hal berikut.
+ `name` harus berisi antara 1 hingga 128 karakter dan nama boleh berisi huruf (huruf besar dan huruf kecil), angka, tanda hubung, garis bawah, garis miring ke depan, garis miring belakang, atau titik.
+ `value` harus berisi antara 1 hingga 128 karakter dan boleh berisi huruf (huruf besar dan huruf kecil), angka, tanda hubung, garis bawah, titik, tanda (@), garis miring ke depan, garis miring belakang, titik dua, atau spasi. Nilai tidak dapat berisi spasi putih utama atau di belakang.

# Buat ekspresi untuk menentukan instance kontainer untuk tugas Amazon ECS
<a name="cluster-query-language"></a>

Kueri cluster adalah ekspresi yang memungkinkan Anda mengelompokkan objek. Misalnya, Anda dapat mengelompokkan instans kontainer dengan atribut seperti Availability Zone, tipe instans, atau metadata kustom. Untuk informasi selengkapnya, lihat [Atribut instans wadah Amazon ECS](task-placement-constraints.md#attributes).

Setelah menetapkan grup instans penampung, Anda dapat menyesuaikan Amazon ECS untuk menempatkan tugas pada instans penampung berdasarkan grup. Untuk informasi selengkapnya, lihat [Menjalankan aplikasi sebagai tugas Amazon ECS](standalone-task-create.md), dan [Membuat penyebaran pembaruan bergulir Amazon ECS](create-service-console-v2.md). Anda juga dapat menerapkan filter grup ketika mencantumkan instans kontainer.

## Sintaksis ekspresi
<a name="expression-syntax"></a>

Ekspresi memiliki sintaksis berikut:

```
subject operator [argument]
```

**Subjek**  
Atribut atau bidang yang perlu dievaluasi.

`agentConnected`  
Pilih instans kontainer berdasarkan status koneksi agen penampung Amazon ECS mereka. Anda dapat menggunakan filter ini untuk mencari instans dengan agen kontainer yang terputus.  
Operasi yang valid: equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`agentVersion`  
Pilih instans kontainer berdasarkan versi agen penampung Amazon ECS mereka. Anda dapat menggunakan filter ini untuk menemukan instance yang menjalankan versi lama dari agen penampung Amazon ECS.  
Operator yang valid: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`attribute:attribute-name`  
Pilih instans kontainer berdasarkan atribut. Untuk informasi selengkapnya, lihat [Atribut instans wadah Amazon ECS](task-placement-constraints.md#attributes).

`ec2InstanceId`  
Pilih instans kontainer berdasarkan ID instans Amazon EC2 mereka.  
Operasi yang valid: equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`registeredAt`  
Pilih instans kontainer berdasarkan tanggal pendaftaran instans kontainer mereka. Anda dapat menggunakan filter ini untuk menemukan instans yang baru terdaftar atau instans yang sangat usang.  
Operasi yang valid: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)  
Format tanggal yang valid: 2018-06-18T22:28:28\$100:00, 2018-06-18T22:28:28Z, 2018-06-18T22:28:28, 2018-06-18

`runningTasksCount`  
Pilih instans kontainer berdasarkan jumlah tugas yang sedang berjalan. Anda dapat menggunakan filter ini untuk menemukan instans yang kosong atau hampir kosong (hanya beberapa tugas yang berjalan pada instans tersebut).  
Operasi yang valid: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`task:group`  
Pilih instans kontainer oleh grup tugas. Untuk informasi selengkapnya, lihat [Tugas Amazon ECS terkait grup](task-groups.md).

**Operator**  
Operasi perbandingan. Mendukung operasi berikut ini.


|  Operasi  |  Deskripsi  | 
| --- | --- | 
|  ==, equals  |  Kesamaan string  | 
|  \$1=, not\$1equals  |  Ketidaksamaan string  | 
|  >, greater\$1than  |  Lebih besar dari  | 
|  >=, greater\$1than\$1equal  |  Lebih besar dari atau sama dengan  | 
|  <, less\$1than  |  Kurang dari  | 
|  <=, less\$1than\$1equal  |  Kurang dari atau sama dengan  | 
|  exists  |  Subjek ada  | 
|  \$1exists, not\$1exists  |  Subjek tidak ada  | 
|  in  |  Nilai dalam daftar argumen  | 
|  \$1in, not\$1in  |  Nilai tidak dalam daftar argumen  | 
|  =\$1, matches  |  Pola cocok  | 
|  \$1\$1, not\$1matches  |  Pola tidak cocok  | 

**catatan**  
Sebuah ekspresi tunggal tidak dapat berisi tanda kurung. Namun, tanda kurung dapat digunakan untuk menunjukkan prioritas dalam ekspresi majemuk.

**Pendapat**  
Di sebagian besar operasi, argumen adalah nilai literal.

Operasi `in` dan `not_in` menganggap daftar argumen sebagai argumen. Anda menentukan daftar argumen sebagai berikut:

```
[argument1, argument2, ..., argumentN]
```

Operasi matches dan not\$1matches menerima argumen yang sesuai dengan sintaksis ekspresi reguler Java. Untuk informasi selengkapnya, lihat [java.util.regex.Pattern](http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html).

**Ekspresi majemuk**

Anda dapat menggabungkan ekspresi menggunakan operasi Boolean berikut:
+ &&, dan
+ \$1\$1, atau
+ \$1, tidak

Anda dapat menentukan prioritas menggunakan tanda kurung:

```
(expression1 or expression2) and expression3
```

## Contoh ekspresi
<a name="expression-examples"></a>

Berikut ini adalah contoh-contoh ekspresi.

**Contoh: String Sama Dengan**  
Ekspresi berikut memilih instans dengan tipe instans yang ditentukan.

```
attribute:ecs.instance-type == t2.small
```

**Contoh: Daftar Argumen**  
Ekspresi berikut memilih instans di Availability Zone us-east-1a atau us-east-1b.

```
attribute:ecs.availability-zone in [us-east-1a, us-east-1b]
```

**Contoh: Ekspresi Majemuk**  
Ekspresi berikut memilih instance G2 yang tidak berada di Availability Zone us-east-1d.

```
attribute:ecs.instance-type =~ g2.* and attribute:ecs.availability-zone != us-east-1d
```

**Contoh: Afinitas Tugas**  
Ekspresi berikut memilih instans yang meng-host tugas di grup`service:production`.

```
task:group == service:production
```

**Contoh: Afinitas Terbalik Tugas**  
Ekspresi berikut memilih instance yang tidak menghosting tugas dalam grup database.

```
not(task:group == database)
```

**Contoh: Menjalankan penghitungan tugas**  
Ekspresi berikut memilih instans yang hanya menjalankan satu tugas.

```
runningTasksCount == 1
```

**Contoh: Amazon ECS versi agen kontainer**  
Ekspresi berikut memilih instans yang menjalankan versi agen kontainer di bawah 1.14.5.

```
agentVersion < 1.14.5
```

**Contoh: Waktu pendaftaran instans**  
Ekspresi berikut memilih instans yang terdaftar sebelum 13 Februari 2018.

```
registeredAt < 2018-02-13
```

**Contoh: ID instans Amazon EC2**  
Ekspresi berikut memilih instance dengan instans Amazon EC2 berikut. IDs

```
ec2InstanceId in ['i-abcd1234', 'i-wxyx7890']
```

# Contoh kendala penempatan tugas Amazon ECS
<a name="constraint-examples"></a>

Berikut ini adalah contoh kendala penempatan tugas.

Contoh ini menggunakan `memberOf` kendala untuk menempatkan tugas pada instance t2. Ini dapat ditentukan dengan tindakan berikut: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html), dan [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

```
"placementConstraints": [
    {
        "expression": "attribute:ecs.instance-type =~ t2.*",
        "type": "memberOf"
    }
]
```

Contoh menggunakan `memberOf` kendala untuk menempatkan tugas replika pada instance dengan tugas di grup tugas layanan daemon, dengan menghormati strategi penempatan `daemon-service` tugas apa pun yang juga ditentukan. Batasan ini memastikan bahwa tugas layanan daemon ditempatkan pada instans EC2 sebelum tugas layanan replika.

Ganti `daemon-service` dengan nama layanan daemon.

```
"placementConstraints": [
    {
        "expression": "task:group == service:daemon-service",
        "type": "memberOf"
    }
]
```

Contoh tersebut menggunakan kendala `memberOf` untuk menempatkan tugas pada instans dengan tugas-tugas lain di kelompok tugas `databases`, perihal setiap strategi penempatan tugas yang juga ditentukan. Untuk informasi selengkapnya tentang grup tugas, lihat [Tugas Amazon ECS terkait grup](task-groups.md). Ini dapat ditentukan dengan tindakan berikut: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html), dan [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

```
"placementConstraints": [
    {
        "expression": "task:group == databases",
        "type": "memberOf"
    }
]
```

Kendala `distinctInstance` menempatkan setiap tugas dalam grup pada instans yang berbeda. Hal ini dapat ditentukan dengan tindakan berikut: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), dan [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)

Amazon ECS melihat status tugas yang diinginkan untuk penempatan tugas. Misalnya, jika status yang diinginkan dari tugas yang ada adalah`STOPPED`, (tetapi status terakhir tidak), tugas masuk baru dapat ditempatkan pada instance yang sama meskipun ada kendala `distinctInstance` penempatan. Oleh karena itu, Anda mungkin melihat 2 tugas dengan status terakhir `RUNNING` pada instance yang sama.

```
"placementConstraints": [
    {
        "type": "distinctInstance"
    }
]
```

# Tugas mandiri Amazon ECS
<a name="standalone-tasks"></a>

Anda dapat menjalankan aplikasi Anda sebagai tugas ketika Anda memiliki aplikasi yang melakukan beberapa pekerjaan, dan kemudian berhenti, misalnya proses batch. Jika Anda ingin menjalankan tugas satu kali, Anda dapat menggunakan konsol, AWS CLI, APIs, atau SDKs.

Jika Anda perlu menjalankan aplikasi berdasarkan tarif, berbasis cron, atau jadwal satu kali, Anda dapat membuat jadwal menggunakan Scheduler. EventBridge 

## Alur kerja tugas
<a name="task-workflow"></a>

Saat Anda meluncurkan tugas Amazon ECS (tugas mandiri atau oleh layanan Amazon ECS), tugas dibuat dan awalnya dipindahkan ke status. `PROVISIONING` Saat tugas dalam `PROVISIONING` status, baik tugas maupun kontainer tidak ada karena Amazon ECS perlu menemukan kapasitas komputasi untuk menempatkan tugas.

Amazon ECS memilih kapasitas komputasi yang sesuai untuk tugas Anda berdasarkan jenis peluncuran atau konfigurasi penyedia kapasitas. Anda dapat menggunakan penyedia kapasitas dan strategi penyedia kapasitas dengan Fargate dan EC2. Dengan Fargate, Anda tidak perlu memikirkan penyediaan, konfigurasi, dan penskalaan kapasitas cluster Anda. Fargate menangani semua manajemen infrastruktur untuk tugas-tugas Anda. Untuk EC2, Anda dapat mengelola kapasitas klaster dengan mendaftarkan instans Amazon EC2 ke klaster, atau Anda dapat menggunakan penskalaan otomatis cluster untuk menyederhanakan manajemen kapasitas komputasi. Penskalaan otomatis cluster menangani penskalaan kapasitas cluster secara dinamis, sehingga Anda dapat fokus menjalankan tugas. Amazon ECS menentukan tempat untuk menempatkan tugas berdasarkan persyaratan yang Anda tentukan dalam definisi tugas, seperti CPU dan memori, serta batasan dan strategi penempatan Anda. Untuk informasi selengkapnya, lihat, [Cara Amazon ECS Menempatkan Tugas di Instans Kontainer](task-placement.md).

Jika Anda menggunakan penyedia kapasitas dengan penskalaan terkelola diaktifkan, tugas yang tidak dapat dimulai karena kurangnya kapasitas komputasi akan dipindahkan ke `PROVISIONING` status daripada gagal segera. Setelah menemukan kapasitas untuk menempatkan tugas Anda, Amazon ECS menyediakan lampiran yang diperlukan (misalnya, Antarmuka Jaringan Elastis (ENIs) untuk tugas dalam `awsvpc` mode). Ini menggunakan agen kontainer Amazon ECS untuk menarik gambar kontainer Anda, dan kemudian memulai wadah Anda. Setelah penyediaan selesai dan kontainer yang relevan diluncurkan, Amazon ECS memindahkan tugas ke status. `RUNNING` Untuk informasi tentang status tugas, lihat[Siklus hidup tugas Amazon ECS](task-lifecycle-explanation.md).

# Menjalankan aplikasi sebagai tugas Amazon ECS
<a name="standalone-task-create"></a>

Anda dapat membuat tugas untuk proses satu kali menggunakan. Konsol Manajemen AWS

**Untuk membuat tugas mandiri ()Konsol Manajemen AWS**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Konsol Amazon ECS memungkinkan Anda membuat tugas mandiri dari halaman detail klaster atau dari daftar revisi definisi tugas. Gunakan langkah-langkah berikut untuk membuat tugas mandiri Anda tergantung pada halaman sumber daya yang Anda pilih.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/standalone-task-create.html)

1. Untuk **klaster yang ada**, pilih klaster.

   Pilih **Buat klaster** untuk menjalankan tugas di klaster baru

1. Pilih bagaimana tugas Anda didistribusikan di seluruh infrastruktur klaster Anda. Di bawah **Konfigurasi komputasi**, pilih opsi Anda.Untuk menggunakan strategi penyedia kapasitas, Anda harus mengonfigurasi penyedia kapasitas di tingkat klaster. 

   Jika Anda belum mengonfigurasi klaster untuk menggunakan penyedia kapasitas, gunakan jenis peluncuran sebagai gantinya.

   Jika ingin menjalankan beban kerja di Instans Terkelola Amazon ECS, Anda harus menggunakan opsi strategi penyedia Kapasitas.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/standalone-task-create.html)

1. Di bawah **konfigurasi Deployment**, lakukan hal berikut:

   1. Untuk **definisi Tugas**, masukkan definisi tugas.
**penting**  
Konsol memvalidasi pilihan untuk memastikan bahwa keluarga dan revisi definisi tugas yang dipilih kompatibel dengan konfigurasi komputasi yang ditentukan.

   1. Untuk **tugas yang diinginkan**, masukkan jumlah tugas yang akan diluncurkan.

   1. Untuk **grup Tugas**, masukkan nama grup tugas.

1. Jika definisi tugas Anda menggunakan mode `awsvpc` jaringan, **perluas Jaringan**. Gunakan langkah-langkah berikut untuk menentukan konfigurasi kustom.

   1. Untuk **VPC**, pilih VPC yang akan digunakan.

   1. Untuk **Subnet**, pilih satu atau beberapa subnet di VPC yang dipertimbangkan oleh penjadwal tugas saat menempatkan tugas Anda.

   1. Untuk **grup Keamanan**, Anda dapat memilih grup keamanan yang ada atau membuat yang baru. Untuk menggunakan grup keamanan yang ada, pilih grup keamanan dan lanjutkan ke langkah berikutnya. Untuk membuat grup keamanan baru, pilih **Buat grup keamanan baru**. Anda harus menentukan nama grup keamanan, deskripsi, dan kemudian tambahkan satu atau beberapa aturan masuk untuk grup keamanan.

   1. Untuk **IP Publik**, pilih apakah akan menetapkan alamat IP publik secara otomatis ke antarmuka jaringan elastis (ENI) tugas.

      AWS Fargate tugas dapat diberikan alamat IP publik ketika dijalankan di subnet publik sehingga mereka memiliki rute ke internet. Tugas EC2 tidak dapat diberikan IP publik menggunakan bidang ini. Untuk informasi selengkapnya, lihat [opsi jaringan tugas Amazon ECS untuk Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) [dan Alokasikan antarmuka jaringan untuk tugas Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html). .

1. Jika tugas Anda menggunakan volume data yang kompatibel dengan konfigurasi saat penerapan, Anda dapat mengonfigurasi volume dengan memperluas **Volume**.

   Nama volume dan jenis volume dikonfigurasi saat membuat revisi definisi tugas dan tidak dapat diubah saat Anda menjalankan tugas mandiri. Untuk memperbarui nama dan jenis volume, Anda harus membuat revisi definisi tugas baru dan menjalankan tugas dengan menggunakan revisi baru.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/standalone-task-create.html)

1. (Opsional) Untuk menggunakan strategi penempatan tugas selain default, perluas **Penempatan Tugas**, lalu pilih dari opsi berikut.

    Untuk informasi selengkapnya, lihat [Cara Amazon ECS Menempatkan Tugas di Instans Kontainer](task-placement.md).
   + **Penyebaran Seimbang AZ** – Mendistribusikan tugas ke berbagai Zona Ketersediaan dan berbagai instans kontainer di Zona Ketersediaan.
   + **AZ Balanced BinPack** — Mendistribusikan tugas di seluruh Availability Zone dan di seluruh instans kontainer dengan memori yang paling sedikit tersedia.
   + **BinPack**— Mendistribusikan tugas berdasarkan jumlah CPU atau memori yang paling sedikit tersedia.
   + **Satu Tugas per Host** – Menempatkan maksimal satu tugas dari layanan pada setiap instans kontainer.
   + **Kustom** - Tentukan strategi penempatan tugas Anda sendiri. 

   Jika Anda memilih **Kustom**, tentukan algoritme untuk menempatkan tugas dan aturan yang dipertimbangkan selama penempatan tugas.
   + Di bawah **Strategi**, untuk **Jenis** dan **Bidang**, pilih algoritma dan entitas yang akan digunakan untuk algoritme.

     Anda dapat memasukkan maksimal 5 strategi.
   + Di bawah **Constraint**, untuk **Type** dan **Expression**, pilih aturan dan atribut untuk kendala.

     **Misalnya, untuk menyetel batasan untuk menempatkan tugas pada instance T2, untuk **Ekspresi**, masukkan atribut:ecs.instance-type =\$1 t2. **\$1.

     Anda dapat memasukkan maksimal 10 kendala.

1. (Opsional) Untuk mengganti peran IAM tugas, atau peran eksekusi tugas yang ditentukan dalam definisi tugas Anda, perluas **penggantian Tugas**, lalu selesaikan langkah-langkah berikut:

   1. Untuk **peran Tugas**, pilih peran IAM untuk tugas ini. Untuk informasi selengkapnya, lihat [Peran IAM tugas Amazon ECS](task-iam-roles.md).

      Hanya peran dengan hubungan kepercayaan `ecs-tasks.amazonaws.com` yang ditampilkan. Untuk petunjuk tentang cara membuat peran IAM untuk tugas Anda, lihat[Membuat peran tugas IAM](task-iam-roles.md#create_task_iam_policy_and_role).

   1. Untuk **peran eksekusi tugas**, pilih peran eksekusi tugas. Untuk informasi selengkapnya, lihat [Peran IAM pelaksanaan tugas Amazon ECS](task_execution_IAM_role.md).

1. (Opsional) Untuk mengganti perintah kontainer dan variabel lingkungan, perluas **Container Overrides**, lalu perluas container.
   +  Untuk mengirim perintah ke wadah selain perintah definisi tugas, untuk **penggantian Command, masukkan perintah** Docker.
   + Untuk menambahkan variabel lingkungan, pilih **Tambahkan Variabel Lingkungan**. Untuk **Kunci**, masukkan nama variabel lingkungan Anda. Untuk **Nilai**, masukkan nilai string untuk nilai lingkungan Anda (tanpa tanda kutip ganda (`" "`)).

     AWS mengelilingi string dengan tanda kutip ganda (” “) dan meneruskan string ke wadah dalam format berikut:

     ```
     MY_ENV_VAR="This variable contains a string."
     ```

1. (Opsional) Untuk membantu mengidentifikasi tugas Anda, perluas bagian **Tag**, lalu konfigurasikan tag Anda.

   Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag definisi tugas, pilih **Aktifkan tag terkelola Amazon ECS**, lalu pilih Definisi **tugas**.

   Menambah atau menghapus tanda.
   + [Tambahkan tag] Pilih **Tambah tag**, lalu lakukan hal berikut:
     + Untuk **Kunci**, masukkan nama kunci.
     + Untuk **Nilai**, masukkan nilai kunci.
   + [Menghapus tanda] Di samping tanda, pilih **Hapus tanda**.

1. Pilih **Buat**.

# Menggunakan Amazon EventBridge Scheduler untuk menjadwalkan tugas Amazon ECS
<a name="tasks-scheduled-eventbridge-scheduler"></a>

EventBridge Scheduler adalah penjadwal tanpa server yang memungkinkan Anda membuat, menjalankan, dan mengelola tugas dari satu layanan terpusat yang dikelola. Ini menyediakan fungsionalitas penjadwalan satu kali dan berulang yang independen dari bus dan aturan acara. EventBridge Scheduler sangat dapat disesuaikan, dan menawarkan skalabilitas yang ditingkatkan dibandingkan aturan EventBridge terjadwal, dengan serangkaian operasi dan layanan API target yang lebih luas. AWS EventBridge Scheduler menyediakan jadwal berikut yang dapat Anda konfigurasi untuk tugas Anda di konsol EventBridge Scheduler:
+ Berbasis tarif 
+ Berbasis cron

  Anda dapat mengonfigurasi jadwal berbasis cron di zona waktu mana pun.
+ Jadwal satu kali

  Anda dapat mengonfigurasi jadwal satu kali di zona waktu mana pun.

Anda dapat menjadwalkan Amazon ECS Anda menggunakan Amazon EventBridge Scheduler.

Meskipun Anda dapat membuat tugas terjadwal di konsol Amazon ECS, saat ini konsol EventBridge Scheduler menyediakan lebih banyak fungsionalitas.

Selesaikan langkah-langkah berikut sebelum Anda menjadwalkan tugas:

1. Gunakan konsol VPC untuk mendapatkan subnet IDs tempat tugas dijalankan dan grup keamanan IDs untuk subnet. Untuk informasi selengkapnya, lihat [Subnet untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html), [dan Kontrol lalu lintas ke sumber daya AWS Anda menggunakan grup keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) di Panduan Pengguna *Amazon VPC*.

1. Konfigurasikan peran eksekusi EventBridge Scheduler. Untuk informasi selengkapnya, lihat [Mengatur peran eksekusi](https://docs.aws.amazon.com/scheduler/latest/UserGuide/setting-up.html#setting-up-execution-role) di *Panduan Pengguna EventBridge Penjadwal Amazon*. 

1. Jika Anda ingin menggunakan strategi penyedia kapasitas untuk menjalankan tugas, Anda harus memiliki penyedia kapasitas yang terkait dengan cluster.

**Untuk membuat jadwal baru menggunakan konsol**

1. Buka konsol Amazon EventBridge Scheduler di [https://console.aws.amazon.com/scheduler/rumah](https://console.aws.amazon.com/scheduler/home/).

1.  Pada halaman **Jadwal**, pilih **Buat jadwal**. 

1.  Pada halaman **Tentukan detail jadwal**, di bagian **Nama jadwal dan deskripsi**, lakukan hal berikut: 

   1. Untuk **nama Jadwal**, masukkan nama untuk jadwal Anda. Misalnya, **MyTestSchedule**. 

   1. (Opsional) Untuk **Deskripsi**, masukkan deskripsi untuk jadwal Anda. Misalnya, **TestSchedule**.

   1. Untuk **grup Jadwal**, pilih grup jadwal. Jika Anda tidak memiliki grup, pilih **default**. Untuk membuat grup jadwal, pilih **buat jadwal Anda sendiri**. 

      Anda menggunakan grup jadwal untuk menambahkan tag ke grup jadwal. 

1. Pilih opsi jadwal Anda.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

1. (Opsional) Jika Anda memilih **Jadwal berulang** pada langkah sebelumnya, di bagian **Jangka Waktu**, lakukan hal berikut: 

   1. Untuk **Timezone**, pilih zona waktu. 

   1. Untuk **Tanggal dan waktu mulai**, masukkan tanggal yang valid dalam `YYYY/MM/DD` format, lalu tentukan stempel waktu dalam format 24 jam`hh:mm`. 

   1. Untuk **Tanggal dan waktu berakhir**, masukkan tanggal yang valid dalam `YYYY/MM/DD` format, lalu tentukan stempel waktu dalam format 24 jam`hh:mm`. 

1. Pilih **Berikutnya**. 

1. Pada halaman **Pilih target**, lakukan hal berikut: 

   1. Pilih **Semua APIs**, dan kemudian di kotak pencarian masukkan **ECS.** 

   1. Pilih **Amazon ECS.**

   1. Di kotak pencarian, masukkan **RunTask**, lalu pilih **RunTask**.

   1. Untuk **cluster ECS**, pilih cluster.

   1. Untuk **tugas ECS**, pilih definisi tugas yang akan digunakan untuk tugas tersebut.

   1. Pilih bagaimana tugas Anda didistribusikan di seluruh infrastruktur klaster Anda. Perluas **opsi Compute**, lalu pilih salah satu opsi berikut    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

   1. Untuk **Subnet**, masukkan subnet IDs untuk menjalankan tugas di.

   1. Untuk **grup Keamanan**, masukkan grup keamanan IDs untuk subnet.

   1. (Opsional) Untuk menggunakan strategi penempatan tugas selain default, **perluas batasan Penempatan**, lalu masukkan batasan.

       Untuk informasi selengkapnya, lihat [Cara Amazon ECS Menempatkan Tugas di Instans Kontainer](task-placement.md).

   1. (Opsional) Untuk membantu mengidentifikasi tugas Anda, di bawah **Tag**, konfigurasikan tag Anda.

      Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan tag definisi tugas, pilih **Aktifkan tag terkelola Amazon ECS**.

1. Pilih **Berikutnya**. 

1. Pada halaman **Pengaturan**, lakukan hal berikut: 

   1. Untuk mengaktifkan jadwal, di bawah **Status jadwal**, alihkan **Aktifkan** jadwal. 

   1. Untuk mengonfigurasi kebijakan coba lagi untuk jadwal Anda, di bawah **Kebijakan Coba ulang dan antrian surat mati (DLQ**), lakukan hal berikut:
      + **Beralih Coba lagi.**
      + Untuk **Waktu retensi maksimum acara**, masukkan **jam** maksimum dan **min** yang harus disimpan oleh EventBridge Scheduler untuk menyimpan acara yang belum diproses.
      + Waktu maksimum adalah 24 jam.
      + Untuk **percobaan ulang Maksimum**, masukkan jumlah maksimum kali EventBridge Scheduler mencoba ulang jadwal jika target mengembalikan kesalahan. 

         Nilai maksimum adalah 185 percobaan ulang. 

      Dengan kebijakan coba lagi, jika jadwal gagal memanggil targetnya, EventBridge Scheduler menjalankan kembali jadwal. Jika dikonfigurasi, Anda harus mengatur waktu retensi maksimum dan mencoba ulang untuk jadwal.

   1. Pilih tempat EventBridge Scheduler menyimpan acara yang tidak terkirim.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

   1. Untuk menggunakan kunci yang dikelola pelanggan untuk mengenkripsi input target Anda, di bawah **Enkripsi**, pilih **Sesuaikan pengaturan enkripsi (lanjutan)**. 

      Jika Anda memilih opsi ini, masukkan ARN kunci KMS yang ada atau **pilih AWS KMS key Buat** untuk menavigasi ke AWS KMS konsol. Untuk informasi selengkapnya tentang cara EventBridge Scheduler mengenkripsi data Anda saat istirahat, lihat [Enkripsi saat istirahat di Panduan](https://docs.aws.amazon.com/scheduler/latest/UserGuide/encryption-rest.html) Pengguna * EventBridge Penjadwal Amazon*. 

   1. Untuk **Izin**, pilih **Gunakan peran yang ada**, lalu pilih peran.

      Agar EventBridge Scheduler membuat peran eksekusi baru untuk Anda, pilih **Buat peran baru untuk jadwal ini**. Kemudian, masukkan nama untuk **nama Peran**. Jika Anda memilih opsi ini, EventBridge Scheduler melampirkan izin yang diperlukan untuk target template Anda ke peran. 

1. Pilih **Berikutnya**. 

1.  Di halaman **Tinjau dan buat jadwal**, tinjau detail jadwal Anda. Di setiap bagian, pilih **Edit** untuk kembali ke langkah itu dan mengedit detailnya. 

1. Pilih **Buat jadwal**. 

   Anda dapat melihat daftar jadwal baru dan yang sudah ada di halaman **Jadwal**. Di bawah kolom **Status**, verifikasi bahwa jadwal baru Anda **Diaktifkan**. 

## Langkah selanjutnya
<a name="eventbridge-scheduler-next-steps"></a>

Anda dapat menggunakan konsol EventBridge Scheduler atau AWS CLI untuk mengelola jadwal. Untuk informasi selengkapnya, lihat [Mengelola jadwal](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule.html) di *Panduan Pengguna EventBridge Penjadwal Amazon*.

# Menghentikan tugas Amazon ECS
<a name="standalone-task-stop"></a>

Jika Anda tidak perlu lagi menjalankan tugas mandiri, Anda dapat menghentikan tugas tersebut. Konsol Amazon ECS memudahkan untuk menghentikan satu atau lebih tugas.

Anda tidak dapat memulai ulang tugas yang dihentikan mandiri.

Jika Anda ingin menghentikan layanan, lihat[Menghapus layanan Amazon ECS menggunakan konsol](delete-service-v2.md).

**Untuk menghentikan tugas mandiri ()Konsol Manajemen AWS**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada panel navigasi, silakan pilih **Klaster**.

1. Pada halaman **Clusters**, pilih cluster untuk menavigasi ke halaman detail cluster.

1. Pada halaman detail cluster, pilih tab **Tugas**. 

1. Anda dapat memfilter tugas berdasarkan jenis peluncuran menggunakan daftar **jenis peluncuran Filter**.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/standalone-task-stop.html)

# Layanan-layanan Amazon ECS
<a name="ecs_services"></a>

Anda dapat menggunakan layanan Amazon ECS untuk menjalankan dan mempertahankan jumlah instans definisi tugas yang ditentukan secara bersamaan di kluster Amazon ECS. Jika salah satu tugas Anda gagal atau berhenti, penjadwal layanan Amazon ECS meluncurkan contoh lain dari definisi tugas Anda untuk menggantikannya. Ini membantu mempertahankan jumlah tugas yang Anda inginkan dalam layanan.

Anda juga dapat menjalankan layanan Anda secara opsional di belakang penyeimbang beban. Penyeimbang beban mendistribusikan lalu lintas ke seluruh tugas yang terkait dengan layanan.

Kami menyarankan Anda menggunakan penjadwal layanan untuk layanan dan aplikasi stateless yang berjalan lama. Penjadwal layanan memastikan bahwa strategi penjadwalan yang Anda tentukan diikuti dan menjadwal ulang tugas ketika tugas gagal. Misalnya, jika infrastruktur yang mendasarinya gagal, penjadwal layanan menjadwal ulang tugas. Anda dapat menggunakan strategi dan batasan penempatan tugas untuk menyesuaikan cara penjadwal menempatkan dan mengakhiri tugas. Jika tugas dalam layanan berhenti, penjadwal meluncurkan tugas baru untuk menggantikannya. Proses ini berlanjut hingga layanan Anda mencapai jumlah tugas yang Anda inginkan berdasarkan strategi penjadwalan yang digunakan layanan.

Penjadwal layanan juga menggantikan tugas yang ditentukan tidak sehat setelah pemeriksaan kesehatan kontainer atau pemeriksaan kesehatan kelompok sasaran penyeimbang beban gagal. Penggantian ini tergantung pada parameter definisi `maximumPercent` dan `desiredCount` layanan. Jika tugas ditandai tidak sehat, penjadwal layanan akan memulai tugas pengganti terlebih dahulu. Kemudian, hal berikut terjadi.
+ Jika tugas penggantian memiliki status kesehatan`HEALTHY`, penjadwal layanan menghentikan tugas yang tidak sehat
+ Jika tugas penggantian memiliki status kesehatan`UNHEALTHY`, penjadwal akan menghentikan tugas penggantian yang tidak sehat atau tugas tidak sehat yang ada untuk mendapatkan jumlah tugas total yang sama`desiredCount`.

Jika `maximumPercent` parameter membatasi penjadwal untuk memulai tugas penggantian terlebih dahulu, penjadwal akan menghentikan tugas yang tidak sehat satu per satu secara acak untuk membebaskan kapasitas, dan kemudian memulai tugas pengganti. Proses start dan stop berlanjut sampai semua tugas yang tidak sehat diganti dengan tugas-tugas yang sehat. Setelah semua tugas yang tidak sehat telah diganti dan hanya tugas sehat yang berjalan, jika jumlah tugas total melebihi`desiredCount`, tugas sehat dihentikan secara acak hingga jumlah tugas total sama. `desiredCount` Untuk informasi selengkapnya tentang `maximumPercent` dan`desiredCount`, lihat [Parameter definisi layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html).

Penjadwal layanan menyertakan logika yang membatasi seberapa sering tugas dimulai ulang jika tugas berulang kali gagal dimulai. Jika tugas dihentikan tanpa memasukkan `RUNNING` status, penjadwal layanan mulai memperlambat upaya peluncuran dan mengirimkan pesan acara layanan. Perilaku ini mencegah sumber daya yang tidak perlu digunakan untuk tugas yang gagal sebelum Anda dapat menyelesaikan masalah. Setelah layanan diperbarui, penjadwal layanan melanjutkan perilaku penjadwalan normal. Untuk informasi selengkapnya, lihat [Logika throttle layanan Amazon ECS](service-throttle-logic.md) dan [Melihat pesan acara layanan Amazon ECS](service-event-messages.md).

## Opsi komputasi infrastruktur
<a name="service-conmpute-options"></a>

Ada dua opsi komputasi yang mendistribusikan tugas Anda.
+ Strategi penyedia kapasitas menyebabkan Amazon ECS mendistribusikan tugas Anda di satu atau di beberapa penyedia kapasitas. 

  Jika ingin menjalankan beban kerja di Instans Terkelola Amazon ECS, Anda harus menggunakan opsi strategi penyedia Kapasitas.

  Untuk **strategi penyedia kapasitas**, konsol memilih opsi komputasi secara default. Berikut dijelaskan tentang urutan yang digunakan konsol untuk memilih default:
  + Jika klaster Anda memiliki strategi penyedia kapasitas default yang ditentukan, klaster akan dipilih.
  + Jika klaster Anda tidak memiliki strategi penyedia kapasitas default yang ditentukan tetapi Anda memiliki penyedia kapasitas Fargate yang ditambahkan ke klaster, strategi penyedia kapasitas khusus yang menggunakan penyedia `FARGATE` kapasitas dipilih.
  + Jika klaster Anda tidak memiliki strategi penyedia kapasitas default yang ditentukan tetapi Anda memiliki satu atau beberapa penyedia kapasitas grup Auto Scaling yang ditambahkan ke cluster, opsi **Use custom (Advanced)** akan dipilih dan Anda perlu menentukan strategi secara manual.
  + Jika klaster Anda tidak memiliki strategi penyedia kapasitas default yang ditentukan dan tidak ada penyedia kapasitas yang ditambahkan ke cluster, jenis peluncuran Fargate akan dipilih.
+ Jenis peluncuran menyebabkan Amazon ECS meluncurkan tugas kami secara langsung di Fargate atau pada instans EC2 yang terdaftar di kluster Anda.

  Jika ingin menjalankan beban kerja di Instans Terkelola Amazon ECS, Anda harus menggunakan opsi strategi penyedia Kapasitas.

  Secara default layanan dimulai di subnet di VPC cluster Anda.

## Penskalaan otomatis layanan
<a name="service-auto-scaling-options"></a>

Penskalaan otomatis layanan adalah kemampuan untuk menambah atau mengurangi jumlah tugas yang diinginkan di layanan Amazon ECS Anda secara otomatis. Amazon ECS memanfaatkan layanan Application Auto Scaling untuk menyediakan fungsionalitas ini.

Untuk informasi selengkapnya, lihat [Menskalakan layanan Amazon ECS secara otomatis](service-auto-scaling.md).

## Penyeimbangan beban layanan
<a name="service-load-balancing-options"></a>

Layanan Amazon ECS yang dihosting AWS Fargate mendukung Application Load Balancers, Network Load Balancers, dan Gateway Load Balancers. Gunakan tabel berikut untuk mempelajari jenis penyeimbang beban apa yang akan digunakan.


| Jenis Load Balancer | Gunakan dalam kasus ini | 
| --- | --- | 
|  Penyeimbang Beban Aplikasi  | Lalu lintas rute HTTP/HTTPS (atau lapisan 7).Application Load Balancers menawarkan beberapa fitur yang membuatnya menarik untuk digunakan dengan layanan Amazon ECS: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/ecs_services.html) | 
| Penyeimbang Beban Jaringan | Rute lalu lintas TCP atau UDP (atau lapisan 4). | 
| Penyeimbang Beban Gateway | Rute lalu lintas TCP atau UDP (atau lapisan 4). Gunakan peralatan virtual, seperti firewall, sistem deteksi dan pencegahan intrusi, dan sistem inspeksi paket dalam. | 

Untuk informasi selengkapnya, lihat [Menggunakan penyeimbangan beban untuk mendistribusikan lalu lintas layanan Amazon ECS](service-load-balancing.md).

## Layanan interkoneksi
<a name="service-connecting-options"></a>

Jika Anda memerlukan aplikasi untuk terhubung ke aplikasi lain yang berjalan sebagai layanan Amazon ECS, Amazon ECS menyediakan cara-cara berikut untuk melakukan ini tanpa penyeimbang beban:
+ Service Connect - Memungkinkan service-to-service komunikasi dengan penemuan otomatis menggunakan nama pendek dan port standar.
+ Penemuan layanan - Penemuan layanan menggunakan Route 53 untuk membuat namespace untuk layanan Anda, yang memungkinkannya dapat ditemukan melalui DNS.
+ Amazon VPC Lattice - VPC Lattice adalah layanan jaringan aplikasi yang dikelola sepenuhnya untuk menghubungkan, mengamankan, dan memantau layanan Anda di beberapa akun dan. VPCs Ada biaya yang terkait dengannya.

Untuk informasi selengkapnya, lihat [Interkoneksi layanan Amazon ECS](interconnecting-services.md).

# Pengontrol dan strategi penyebaran layanan Amazon ECS
<a name="ecs_service-options"></a>

Sebelum Anda menerapkan layanan Anda, tentukan opsi untuk menerapkannya, dan fitur yang digunakan layanan.

## Strategi penjadwalan
<a name="service-strategy"></a>

Ada dua strategi penjadwal layanan yang tersedia:
+ `REPLICA`Strategi penjadwalan replika menempatkan dan mempertahankan jumlah tugas yang diinginkan di seluruh klaster Anda. Secara default tugas tersebar di seluruh Availability Zone. Anda dapat menggunakan strategi penempatan tugas dan kendala untuk menyesuaikan keputusan penempatan tugas. Untuk informasi selengkapnya, lihat [Strategi penjadwalan replika](#service_scheduler_replica).
+ `DAEMON`—Strategi penjadwalan daemon menerapkan tepat satu tugas pada setiap instance kontainer aktif yang memenuhi semua batasan penempatan tugas yang Anda tentukan di cluster Anda. Saat menggunakan strategi ini, tidak perlu menentukan jumlah tugas yang diinginkan, strategi penempatan tugas, atau menggunakan kebijakan Auto Scaling Layanan. Untuk informasi selengkapnya, lihat [Strategi penjadwalan daemon](#service_scheduler_daemon).
**catatan**  
Tugas Fargate tidak mendukung strategi `DAEMON` penjadwalan.

### Strategi penjadwalan replika
<a name="service_scheduler_replica"></a>

Strategi penjadwalan *replika* menempatkan dan mempertahankan jumlah tugas yang diinginkan di klaster Anda.

Untuk layanan yang menjalankan tugas di Fargate, saat penjadwal layanan meluncurkan tugas baru atau berhenti menjalankan tugas, penjadwal layanan menggunakan upaya terbaik untuk menjaga keseimbangan di seluruh Availability Zone. Anda tidak perlu menentukan strategi penempatan tugas atau kendala.

Saat membuat layanan yang menjalankan tugas pada instans EC2, Anda dapat menentukan strategi dan batasan penempatan tugas secara opsional untuk menyesuaikan keputusan penempatan tugas. Jika tidak ada strategi penempatan tugas atau kendala yang ditentukan, maka secara default penjadwal layanan menyebarkan tugas di seluruh Availability Zones. Penjadwal layanan menggunakan logika berikut:
+ Menentukan instance kontainer mana di klaster Anda yang dapat mendukung definisi tugas layanan Anda (misalnya, atribut CPU, memori, port, dan instance container yang diperlukan).
+ Menentukan instance kontainer mana yang memenuhi batasan penempatan apa pun yang ditentukan untuk layanan.
+ Bila Anda memiliki layanan replika yang bergantung pada layanan daemon (misalnya, tugas router log daemon yang perlu dijalankan sebelum tugas dapat menggunakan logging), buat batasan penempatan tugas yang memastikan bahwa tugas layanan daemon ditempatkan pada instans EC2 sebelum tugas layanan replika. Untuk informasi selengkapnya, lihat [Contoh kendala penempatan tugas Amazon ECS](constraint-examples.md).
+ Ketika ada strategi penempatan yang ditentukan, gunakan strategi itu untuk memilih instance dari kandidat yang tersisa.
+ Jika tidak ada strategi penempatan yang ditentukan, gunakan logika berikut untuk menyeimbangkan tugas di seluruh Availability Zone di klaster Anda:
  + Mengurutkan instance kontainer yang valid. Memberikan prioritas pada instance yang memiliki jumlah tugas yang berjalan paling sedikit untuk layanan ini di Availability Zone masing-masing. Misalnya, jika zona A memiliki satu tugas layanan berjalan, sedangkan zona B dan C masing-masing tidak memliki tugas layanan berjalan, maka instans kontainer yang valid, baik di zona B ataupun C dianggap optimal untuk penempatan.
  + Menempatkan tugas layanan baru pada instance container yang valid di Availability Zone yang optimal berdasarkan langkah sebelumnya. Menyukai instance kontainer dengan jumlah tugas yang berjalan paling sedikit untuk layanan ini.

Kami menyarankan Anda menggunakan fitur penyeimbangan kembali layanan ketika Anda menggunakan `REPLICA` strategi karena membantu memastikan ketersediaan tinggi untuk layanan Anda.

### Strategi penjadwalan daemon
<a name="service_scheduler_daemon"></a>

Strategi penjadwalan *daemon* men-deploy tepat satu tugas untuk setiap instans kontainer aktif yang memenuhi semua batasan penempatan tugas yang ditentukan di klaster Anda. Penjadwal layanan mengevaluasi batasan penempatan tugas untuk menjalankan tugas, dan menghentikan tugas yang tidak memenuhi batasan penempatan. Saat menggunakan strategi ini, Anda tidak perlu menentukan jumlah tugas yang diinginkan, strategi penempatan tugas, atau menggunakan kebijakan Auto Scaling Service.

Amazon ECS menyimpan sumber daya komputasi instans kontainer termasuk CPU, memori, dan antarmuka jaringan untuk tugas daemon. Saat Anda meluncurkan layanan daemon di klaster dengan layanan replika lainnya, Amazon ECS memprioritaskan tugas daemon. Ini berarti bahwa tugas daemon adalah tugas pertama yang diluncurkan pada instance dan tugas terakhir untuk berhenti setelah semua tugas replika dihentikan. Strategi ini memastikan bahwa sumber daya tidak digunakan oleh tugas replika yang tertunda dan tersedia untuk tugas daemon.

Penjadwal layanan daemon tidak menempatkan tugas apa pun pada instance yang memiliki status. `DRAINING` Jika instance kontainer bertransisi ke `DRAINING` status, tugas daemon di atasnya dihentikan. Penjadwal layanan juga memantau saat instans kontainer baru ditambahkan ke klaster Anda dan menambahkan tugas daemon ke dalamnya.

Saat Anda menentukan konfigurasi penerapan, nilai untuk `maximumPercent` parameter harus `100` (ditentukan sebagai persentase), yang merupakan nilai default yang digunakan jika tidak disetel. Nilai default untuk `minimumHealthyPercent` parameter adalah `0` (ditentukan sebagai persentase).

Anda harus memulai ulang layanan ketika Anda mengubah batasan penempatan untuk layanan daemon. Amazon ECS secara dinamis memperbarui sumber daya yang dicadangkan pada instans yang memenuhi syarat untuk tugas daemon. Untuk instans yang sudah ada, penjadwal mencoba menempatkan tugas pada instans. 

Penerapan baru dimulai ketika ada perubahan pada ukuran tugas atau reservasi sumber daya kontainer dalam definisi tugas. Penerapan baru juga dimulai saat memperbarui layanan atau mengatur revisi definisi tugas yang berbeda. Amazon ECS mengambil reservasi CPU dan memori yang diperbarui untuk daemon, dan kemudian memblokir kapasitas itu untuk tugas daemon.

Jika sumber daya tidak mencukupi untuk salah satu kasus di atas, hal-hal berikut akan terjadi:
+ Penempatan tugas gagal.
+ Sebuah CloudWatch peristiwa dihasilkan.
+ Amazon ECS terus mencoba dan menjadwalkan tugas pada instance dengan menunggu sumber daya tersedia. 
+ Amazon ECS membebaskan instans cadangan yang tidak lagi memenuhi kriteria batasan penempatan dan menghentikan tugas daemon terkait.

Strategi penjadwalan daemon dapat digunakan dalam kasus-kasus berikut:
+ Menjalankan kontainer aplikasi
+ Menjalankan kontainer dukungan untuk tugas pencatatan, pemantauan dan pelacakan

Tugas yang menggunakan Fargate atau tipe pengontrol `EXTERNAL` penerapan `CODE_DEPLOY` atau tidak mendukung strategi penjadwalan daemon.

Saat penjadwal layanan berhenti menjalankan tugas, penjadwal layanan mencoba untuk menjaga keseimbangan di seluruh Availability Zone di klaster Anda. Penjadwal menggunakan logika berikut: 
+ Jika strategi penempatan ditentukan, gunakan strategi tersebut untuk memilih tugas mana yang akan diakhiri. Misalnya, jika layanan memiliki strategi penyebaran Availability Zone yang ditentukan, tugas dipilih yang meninggalkan tugas yang tersisa dengan spread terbaik.
+ Jika tidak ada strategi penempatan yang ditentukan, gunakan logika berikut untuk menjaga keseimbangan di seluruh Availability Zone di klaster Anda:
  + Urutkan instance kontainer yang valid. Berikan prioritas pada instance yang memiliki jumlah tugas berjalan terbesar untuk layanan ini di Availability Zone masing-masing. Misalnya, jika zona A memiliki satu tugas layanan yang berjalan dan zona B dan C masing-masing memiliki dua tugas layanan yang berjalan, instance kontainer di zona B atau C dianggap optimal untuk penghentian.
  + Hentikan tugas pada instance container di Availability Zone optimal berdasarkan langkah sebelumnya. Mendukung instance kontainer dengan jumlah tugas yang berjalan terbesar untuk layanan ini.

## Pengontrol penyebaran
<a name="service_deployment-controllers"></a>

Pengontrol penerapan adalah mekanisme yang menentukan bagaimana tugas digunakan untuk layanan Anda. Opsi yang valid adalah:
+ ECS

  Saat membuat layanan yang menggunakan pengontrol `ECS` penyebaran, Anda dapat memilih di antara strategi penerapan berikut:
  + `ROLLING`: Saat Anda membuat layanan yang menggunakan strategi penerapan *rolling update* (`ROLLING`), penjadwal layanan Amazon ECS menggantikan tugas yang sedang berjalan dengan tugas baru. Jumlah tugas yang ditambahkan atau dihapus Amazon ECS dari layanan selama pembaruan bergulir dikendalikan oleh konfigurasi penyebaran layanan. 

    Penerapan pembaruan bergulir paling cocok untuk skenario berikut:
    + Pembaruan layanan bertahap: Anda perlu memperbarui layanan Anda secara bertahap tanpa membuat seluruh layanan offline sekaligus.
    + Persyaratan sumber daya terbatas: Anda ingin menghindari biaya sumber daya tambahan untuk menjalankan dua lingkungan lengkap secara bersamaan (seperti yang dipersyaratkan oleh penerapan biru/hijau).
    + Waktu penerapan yang dapat diterima: Aplikasi Anda dapat mentolerir proses penerapan yang lebih lama, karena pembaruan bergulir menggantikan tugas satu per satu.
    + Tidak perlu roll back instan: Layanan Anda dapat mentolerir proses rollback yang memakan waktu beberapa menit, bukan detik.
    + Proses penyebaran sederhana: Anda lebih memilih pendekatan penerapan langsung tanpa kerumitan mengelola beberapa lingkungan, grup target, dan pendengar.
    + Tidak ada persyaratan penyeimbang beban: Layanan Anda tidak menggunakan atau memerlukan penyeimbang beban, Application Load Balancer, Network Load Balancer, atau Service Connect (yang diperlukan untuk penerapan). blue/green 
    + Aplikasi stateful: Aplikasi Anda mempertahankan status yang membuatnya sulit untuk menjalankan dua lingkungan paralel.
    + Sensitivitas biaya: Anda ingin meminimalkan biaya penerapan dengan tidak menjalankan lingkungan duplikat selama penerapan.

    Pembaruan bergulir adalah strategi penerapan default untuk layanan dan memberikan keseimbangan antara keamanan penerapan dan efisiensi sumber daya untuk banyak skenario aplikasi umum.
  + `BLUE_GREEN`Strategi penyebaran *biru/hijau* (`BLUE_GREEN`) adalah metodologi rilis yang mengurangi waktu henti dan risiko dengan menjalankan dua lingkungan produksi identik yang disebut biru dan hijau. Dengan blue/green penerapan Amazon ECS, Anda dapat memvalidasi revisi layanan baru sebelum mengarahkan lalu lintas produksi kepada mereka. Pendekatan ini memberikan cara yang lebih aman untuk menerapkan perubahan dengan kemampuan untuk memutar kembali dengan cepat jika diperlukan.

     blue/green Penerapan Amazon ECS paling cocok untuk skenario berikut:
    + Validasi layanan: Ketika Anda perlu memvalidasi revisi layanan baru sebelum mengarahkan lalu lintas produksi ke mereka
    + Zero downtime: Saat layanan Anda memerlukan penerapan zero-downtime
    + Instant roll back: Ketika Anda membutuhkan kemampuan untuk memutar kembali dengan cepat jika masalah terdeteksi
    + Persyaratan penyeimbang beban: Ketika layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect
  + `LINEAR`Strategi penyebaran *linier* (`LINEAR`) secara bertahap menggeser lalu lintas dari lingkungan produksi saat ini ke lingkungan baru dengan persentase peningkatan yang sama selama periode waktu tertentu. Dengan penerapan linear Amazon ECS, Anda dapat mengontrol laju pergeseran lalu lintas dan memvalidasi revisi layanan baru dengan peningkatan jumlah lalu lintas produksi.

    Penerapan linier Amazon ECS paling cocok untuk skenario berikut:
    + Validasi bertahap: Ketika Anda ingin secara bertahap memvalidasi versi layanan baru Anda dengan meningkatkan lalu lintas
    + Pemantauan kinerja: Saat Anda membutuhkan waktu untuk memantau metrik dan kinerja selama penerapan
    + Minimalisasi risiko: Ketika Anda ingin meminimalkan risiko dengan mengekspos versi baru ke lalu lintas produksi secara bertahap
    + Persyaratan penyeimbang beban: Ketika layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect
  + `CANARY`Strategi penyebaran *kenari* (`CANARY`) menggeser sebagian kecil lalu lintas ke revisi layanan baru terlebih dahulu, kemudian menggeser lalu lintas yang tersisa sekaligus setelah periode waktu yang ditentukan. Ini memungkinkan Anda untuk menguji versi baru dengan subset pengguna sebelum penerapan penuh.

    Penerapan kenari Amazon ECS paling cocok untuk skenario berikut:
    + Pengujian fitur: Saat Anda ingin menguji fitur baru dengan sebagian kecil pengguna sebelum peluncuran penuh
    + Validasi produksi: Ketika Anda perlu memvalidasi kinerja dan fungsionalitas dengan lalu lintas produksi nyata
    + Kontrol radius ledakan: Saat Anda ingin meminimalkan radius ledakan jika masalah ditemukan di versi baru
    + Persyaratan penyeimbang beban: Ketika layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect
+ Eksternal

  Gunakan pengontrol penerapan pihak ketiga.
+ Penerapan biru/hijau (didukung oleh) AWS CodeDeploy

  CodeDeploy menginstal versi aplikasi yang diperbarui sebagai set tugas pengganti baru dan mengalihkan lalu lintas produksi dari tugas aplikasi asli yang disetel ke set tugas pengganti. Set tugas asli dihentikan setelah penerapan berhasil. Gunakan pengontrol penerapan ini untuk memverifikasi penyebaran layanan baru sebelum mengirim lalu lintas produksi ke sana.

# Deteksi kegagalan deployment Amazon ECS
<a name="deployment-failure-detection"></a>

Amazon ECS menyediakan dua metode untuk mendeteksi kegagalan penerapan:
+ Penyebaran Pemutus Sirkuit
+ CloudWatch Alarm

Kedua metode dapat dikonfigurasi untuk secara otomatis memutar kembali penerapan yang gagal ke keadaan baik terakhir yang diketahui.

Pertimbangkan hal berikut:
+ Kedua metode hanya mendukung jenis penerapan dan blue/green penerapan pembaruan bergulir.
+ Ketika kedua metode digunakan, keduanya dapat memicu kegagalan penerapan.
+ Metode rollback memerlukan penerapan sebelumnya dalam status COMPLETED.
+ EventBridge peristiwa dihasilkan untuk perubahan status penerapan.

# Cara pemutus sirkuit deployment Amazon ECS mendeteksi kegagalan
<a name="deployment-circuit-breaker"></a>

Pemutus sirkuit penyebaran adalah mekanisme pembaruan bergulir yang menentukan apakah tugas mencapai kondisi mapan. Pemutus sirkuit penyebaran memiliki opsi yang secara otomatis akan mengembalikan penerapan yang gagal ke penerapan yang ada dalam status. `COMPLETED`

Saat penerapan layanan mengubah status, Amazon ECS mengirimkan peristiwa perubahan status penerapan layanan ke. EventBridge Hal ini menyediakan cara terprogram untuk memantau status deployment layanan Anda. Untuk informasi selengkapnya, lihat [Acara perubahan status penerapan layanan Amazon ECS](ecs_service_deployment_events.md). Kami menyarankan Anda membuat dan memantau EventBridge aturan dengan angka `eventName` `SERVICE_DEPLOYMENT_FAILED` sehingga Anda dapat mengambil tindakan manual untuk memulai penerapan Anda. Untuk informasi selengkapnya, lihat [Memulai EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) di *Panduan EventBridge Pengguna Amazon*.

Ketika pemutus sirkuit penyebaran menentukan bahwa penerapan gagal, ia mencari penerapan terbaru yang berada dalam keadaan. `COMPLETED` Ini adalah penerapan yang digunakannya sebagai penerapan roll-back. Saat rollback dimulai, penerapan berubah dari a ke. `COMPLETED` `IN_PROGRESS` Ini berarti bahwa penerapan tidak memenuhi syarat untuk rollback lain hingga mencapai status. `COMPLETED` Ketika pemutus sirkuit penyebaran tidak menemukan penyebaran yang dalam `COMPLETED` keadaan, pemutus sirkuit tidak meluncurkan tugas baru dan penyebaran terhenti. 

Saat Anda membuat layanan, penjadwal melacak tugas yang gagal diluncurkan dalam dua tahap.
+ Tahap 1 - Penjadwal memantau tugas untuk melihat apakah mereka bertransisi ke status RUNNING.
  + Sukses - Penerapan memiliki peluang untuk beralih ke status SELESAI karena ada lebih dari satu tugas yang dialihkan ke status RUNNING. Kriteria kegagalan dilewati dan pemutus sirkuit bergerak ke tahap 2.
  + Kegagalan - Ada tugas berturut-turut yang tidak bertransisi ke status RUNNING dan penerapan mungkin bertransisi ke status GAGAL. 
+ Tahap 2 - Penerapan memasuki tahap ini ketika setidaknya ada satu tugas dalam status RUNNING. Pemutus sirkuit memeriksa pemeriksaan kesehatan untuk tugas-tugas dalam penyebaran saat ini yang sedang dievaluasi. Pemeriksaan kesehatan yang divalidasi adalah Elastic Load Balancing AWS Cloud Map , pemeriksaan kesehatan pelayanan, dan pemeriksaan kesehatan kontainer. 
  + Sukses - Setidaknya ada satu tugas dalam keadaan berjalan dengan pemeriksaan kesehatan yang telah berlalu.
  + Kegagalan - Tugas yang diganti karena kegagalan pemeriksaan kesehatan telah mencapai ambang kegagalan.

Pertimbangkan hal berikut ketika Anda menggunakan metode deployment circuit breaker pada suatu layanan. EventBridge menghasilkan aturan.
+ `DescribeServices`Respons memberikan wawasan tentang keadaan penyebaran, `rolloutState` dan`rolloutStateReason`. Saat deployment baru dimulai, status peluncuran dimulai dalam status `IN_PROGRESS`. Saat layanan mencapai kondisi stabil, status peluncuran bertransisi ke `COMPLETED`. Jika layanan gagal mencapai kondisi tunak dan pemutus sirkuit dihidupkan, penyebaran akan beralih ke keadaan. `FAILED` Penerapan dalam `FAILED` status tidak meluncurkan tugas baru apa pun.
+ Selain peristiwa perubahan status penerapan layanan yang dikirim Amazon ECS untuk penerapan yang telah dimulai dan telah selesai, Amazon ECS juga mengirimkan peristiwa ketika penerapan dengan pemutus sirkuit diaktifkan gagal. Kejadian ini menyediakan detail tentang mengapa deployment gagal atau jika deployment dimulai karena rollback. Untuk informasi selengkapnya, lihat [Acara perubahan status penerapan layanan Amazon ECS](ecs_service_deployment_events.md).
+ Jika penerapan baru dimulai karena penerapan sebelumnya gagal dan terjadi rollback, `reason` bidang peristiwa perubahan status penerapan layanan menunjukkan penerapan dimulai karena rollback.
+ Pemutus sirkuit penyebaran hanya didukung untuk layanan Amazon ECS yang menggunakan pengontrol penyebaran pembaruan bergulir (`ECS`).
+ Anda harus menggunakan konsol Amazon ECS, atau AWS CLI ketika Anda menggunakan pemutus sirkuit penyebaran dengan opsi. CloudWatch *Untuk informasi selengkapnya, lihat [Buat layanan menggunakan parameter yang ditentukan](create-service-console-v2.md#create-custom-service) dan buat [layanan di Referensi](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html).AWS Command Line Interface *

`create-service` AWS CLI Contoh berikut menunjukkan cara membuat layanan Linux ketika pemutus sirkuit deployment digunakan dengan opsi rollback.

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

Contoh:

Deployment 1 dalam `COMPLETED` keadaan.

Deployment 2 tidak dapat dimulai, sehingga pemutus sirkuit berputar kembali ke Deployment 1. Penerapan 1 transisi ke negara bagian. `IN_PROGRESS`

Deployment 3 dimulai dan tidak ada penerapan di `COMPLETED` status, jadi Deployment 3 tidak dapat memutar kembali, atau meluncurkan tugas. 

## Ambang batas kegagalan
<a name="failure-threshold"></a>

Pemutus sirkuit penyebaran menghitung nilai ambang batas, dan kemudian menggunakan nilai untuk menentukan kapan harus memindahkan penyebaran ke status. `FAILED`

Pemutus sirkuit penyebaran memiliki ambang minimum 3 dan ambang maksimum 200. dan menggunakan nilai-nilai dalam rumus berikut untuk menentukan kegagalan penerapan.

```
Minimum threshold <= 0.5 * desired task count => maximum threshold
```

Ketika hasil perhitungan lebih besar dari minimum 3, tetapi lebih kecil dari maksimum 200, ambang kegagalan diatur ke ambang batas yang dihitung (dibulatkan ke atas).

**catatan**  
Anda tidak dapat mengubah salah satu nilai ambang batas.

Ada dua tahap untuk pemeriksaan status penerapan.

1. Pemutus sirkuit penyebaran memantau tugas-tugas yang merupakan bagian dari penyebaran dan memeriksa tugas-tugas yang ada di negara bagian. `RUNNING` Penjadwal mengabaikan kriteria kegagalan ketika tugas dalam penerapan saat ini dalam `RUNNING` keadaan dan melanjutkan ke tahap berikutnya. Ketika tugas gagal dicapai di `RUNNING` negara bagian, pemutus sirkuit penyebaran meningkatkan jumlah kegagalan satu per satu. Ketika jumlah kegagalan sama dengan ambang batas, penerapan ditandai sebagai. `FAILED`

1. Tahap ini dimasukkan ketika ada satu atau lebih tugas di `RUNNING` negara bagian. Pemutus sirkuit penyebaran melakukan pemeriksaan kesehatan pada sumber daya berikut untuk tugas-tugas dalam penerapan saat ini:
   + Penyeimbang beban Elastic Load Balancing
   + AWS Cloud Map layanan
   + Pemeriksaan kesehatan kontainer Amazon ECS

   Ketika pemeriksaan kesehatan gagal untuk tugas tersebut, pemutus sirkuit penyebaran meningkatkan jumlah kegagalan satu per satu. Ketika jumlah kegagalan sama dengan ambang batas, penerapan ditandai sebagai. `FAILED`

Tabel berikut menunjukkan beberapa contoh.


| Hitungan tugas yang diinginkan | Penghitungan | Ambang batas | 
| --- | --- | --- | 
|  1  |  <pre>3 <= 0.5 * 1 => 200</pre>  | 3 (nilai yang dihitung kurang dari minimum) | 
|  25  |  <pre>3 <= 0.5 * 25 => 200</pre>  | 13 (nilainya dibulatkan ke atas) | 
|  400  |  <pre>3 <= 0.5 * 400 => 200</pre>  | 200 | 
|  800  |  <pre>3 <= 0.5 * 800 => 200</pre>  | 200 (nilai yang dihitung lebih besar dari maksimum) | 

Misalnya, ketika ambang batas adalah 3, pemutus sirkuit dimulai dengan jumlah kegagalan yang ditetapkan pada 0. Ketika tugas gagal mencapai `RUNNING` status, pemutus sirkuit penyebaran meningkatkan jumlah kegagalan satu per satu. Ketika jumlah kegagalan sama dengan 3, penerapan ditandai sebagai. `FAILED`

Untuk contoh tambahan tentang cara menggunakan opsi rollback, lihat [Mengumumkan pemutus sirkuit penyebaran Amazon ECS.](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/)

# Bagaimana CloudWatch alarm mendeteksi kegagalan penerapan Amazon ECS
<a name="deployment-alarm-failure"></a>

Anda dapat mengonfigurasi Amazon ECS untuk menyetel penerapan menjadi gagal saat mendeteksi bahwa CloudWatch alarm tertentu telah masuk ke status. `ALARM`

Anda dapat mengatur konfigurasi secara opsional untuk mengembalikan penerapan yang gagal ke penerapan yang terakhir selesai.

`create-service` AWS CLI Contoh berikut menunjukkan cara membuat layanan Linux ketika alarm penyebaran digunakan dengan opsi rollback.

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

Pertimbangkan hal berikut saat Anda menggunakan metode CloudWatch alarm Amazon pada suatu layanan.
+ Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser. Amazon ECS menghitung periode waktu ini berdasarkan konfigurasi alarm yang terkait dengan penerapan. Anda tidak dapat menetapkan nilai ini. 
+ Parameter `deploymentConfiguration` permintaan sekarang berisi tipe `alarms` data. Anda dapat menentukan nama alarm, apakah akan menggunakan metode ini, dan apakah akan memulai rollback ketika alarm menunjukkan kegagalan penerapan. Untuk informasi selengkapnya, lihat [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)di *Referensi API Amazon Elastic Container Service*.
+ `DescribeServices`Respons memberikan wawasan tentang keadaan penyebaran, `rolloutState` dan`rolloutStateReason`. Ketika penerapan baru dimulai, status peluncuran dimulai dalam suatu keadaan. `IN_PROGRESS` Ketika layanan mencapai kondisi mapan dan waktu pemanggangan selesai, status peluncuran beralih ke. `COMPLETED` Jika layanan gagal mencapai kondisi mapan dan alarm telah masuk ke `ALARM` status, penyebaran akan beralih ke `FAILED` keadaan. Sebuah deployment dalam status `FAILED` tidak akan meluncurkan tugas baru apa pun.
+ Selain peristiwa perubahan status penerapan layanan yang dikirim Amazon ECS untuk penerapan yang telah dimulai dan telah selesai, Amazon ECS juga mengirimkan peristiwa ketika penerapan yang menggunakan alarm gagal. Kejadian ini menyediakan detail tentang mengapa deployment gagal atau jika deployment dimulai karena rollback. Untuk informasi selengkapnya, lihat [Acara perubahan status penerapan layanan Amazon ECS](ecs_service_deployment_events.md).
+ Jika penerapan baru dimulai karena penerapan sebelumnya gagal dan rollback diaktifkan, `reason` bidang peristiwa perubahan status penerapan layanan akan menunjukkan penerapan dimulai karena rollback.
+ Jika Anda menggunakan pemutus sirkuit penerapan dan CloudWatch alarm Amazon untuk mendeteksi kegagalan, salah satu dapat memulai kegagalan penerapan segera setelah kriteria untuk salah satu metode terpenuhi. Rollback terjadi ketika Anda menggunakan opsi rollback untuk metode yang memulai kegagalan penerapan.
+  CloudWatch Alarm Amazon hanya didukung untuk layanan Amazon ECS yang menggunakan pengontrol penyebaran pembaruan bergulir (`ECS`).
+ Anda dapat mengonfigurasi opsi ini dengan menggunakan konsol Amazon ECS, atau. AWS CLI*Untuk informasi selengkapnya, lihat [Buat layanan menggunakan parameter yang ditentukan](create-service-console-v2.md#create-custom-service) dan buat [layanan di Referensi](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html).AWS Command Line Interface *
+ Anda mungkin memperhatikan bahwa status penerapan tetap `IN_PROGRESS` untuk waktu yang lama. Alasan untuk ini adalah bahwa Amazon ECS tidak mengubah status sampai telah menghapus penerapan aktif, dan ini tidak terjadi sampai setelah waktu pemanggangan. Bergantung pada konfigurasi alarm Anda, penerapan mungkin tampak memakan waktu beberapa menit lebih lama daripada saat Anda tidak menggunakan alarm (meskipun set tugas utama baru ditingkatkan dan penerapan lama diperkecil). Jika Anda menggunakan CloudFormation batas waktu, pertimbangkan untuk meningkatkan batas waktu. Untuk informasi selengkapnya, lihat [Membuat kondisi tunggu di templat](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) di *Panduan AWS CloudFormation Pengguna*.
+ Amazon ECS memanggil `DescribeAlarms` untuk melakukan polling alarm. Panggilan untuk `DescribeAlarms` menghitung kuota CloudWatch layanan yang terkait dengan akun Anda. Jika Anda memiliki AWS layanan lain yang menelepon`DescribeAlarms`, mungkin ada dampak pada Amazon ECS untuk melakukan polling alarm. Misalnya, jika layanan lain membuat `DescribeAlarms` panggilan yang cukup untuk mencapai kuota, layanan itu dibatasi dan Amazon ECS juga dibatasi dan tidak dapat melakukan polling alarm. Jika alarm dihasilkan selama periode pelambatan, Amazon ECS mungkin melewatkan alarm dan pemutaran kembali mungkin tidak terjadi. Tidak ada dampak lain pada penyebaran. Untuk informasi selengkapnya tentang kuota CloudWatch layanan, lihat [kuota CloudWatch layanan](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) di *CloudWatch Panduan Pengguna*.
+ Jika alarm dalam `ALARM` keadaan di awal penerapan, Amazon ECS tidak akan memantau alarm selama penyebaran itu (Amazon ECS mengabaikan konfigurasi alarm). Perilaku ini membahas kasus di mana Anda ingin memulai penerapan baru untuk memperbaiki kegagalan penerapan awal.

## Alarm-alarm yang direkomendasikan
<a name="ecs-deployment-alarms"></a>

Kami menyarankan Anda menggunakan metrik alarm berikut:
+ Jika Anda menggunakan Application Load Balancer, gunakan metrik `HTTPCode_ELB_5XX_Count` dan `HTTPCode_ELB_4XX_Count` Application Load Balancer. Metrik-metrik ini memeriksa lonjakan HTTP. Untuk informasi selengkapnya tentang metrik Application Load Balancer, lihat [CloudWatch metrik untuk Application Load Balancer di *Panduan Pengguna* untuk Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
+ Jika Anda memiliki aplikasi yang sudah ada, gunakan `MemoryUtilization` metrik `CPUUtilization` dan. Metrik-metrik ini memeriksa persentase CPU dan memori yang digunakan klaster atau layanan. Untuk informasi selengkapnya, lihat [Pertimbangan-pertimbangan](cloudwatch-metrics.md#enable_cloudwatch).
+ Jika Anda menggunakan Amazon Simple Queue Service antrian dalam tugas, gunakan metrik Amazon `ApproximateNumberOfMessagesNotVisible` SQS. Metrik ini memeriksa jumlah pesan dalam antrian yang tertunda dan tidak tersedia untuk dibaca segera. Untuk informasi selengkapnya tentang metrik Amazon SQS, lihat Metrik yang [tersedia untuk CloudWatch Amazon SQS di](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) Panduan Pengembang Layanan Antrian Sederhana *Amazon*.

## Waktu menanam
<a name="deployment-bake-time"></a>

Saat Anda menggunakan opsi rollback untuk penerapan layanan Anda, Amazon ECS menunggu sejumlah waktu tambahan setelah revisi layanan target diterapkan sebelum mengirimkan alarm. CloudWatch Ini disebut sebagai waktu memanggang. Kali ini dimulai setelah:
+ Semua tugas untuk revisi layanan target berjalan dan dalam keadaan sehat
+ Revisi layanan sumber diperkecil menjadi 0%

Waktu memanggang default kurang dari 5 menit. Penyebaran layanan ditandai sebagai selesai setelah waktu pemanggangan berakhir.

Anda dapat mengonfigurasi waktu pemanggangan untuk penerapan bergulir. Saat Anda menggunakan CloudWatch alarm untuk mendeteksi kegagalan, jika Anda mengubah waktu pemanggangan, dan kemudian memutuskan Anda menginginkan default Amazon ECS, Anda harus mengatur waktu pemanggangan secara manual.

# Kait siklus hidup untuk penerapan layanan Amazon ECS
<a name="deployment-lifecycle-hooks"></a>

Ketika penerapan dimulai, ia melewati tahapan siklus hidup. Tahapan ini bisa dalam keadaan seperti IN\$1PROGRESS atau berhasil. Anda dapat menggunakan kait siklus hidup, yang merupakan fungsi Lambda yang dijalankan Amazon ECS atas nama Anda pada tahapan siklus hidup yang ditentukan. Fungsinya dapat berupa salah satu dari yang berikut:
+ API asinkron yang memvalidasi pemeriksaan kesehatan dalam waktu 15 menit.
+ API polling yang memulai proses asinkron lain yang mengevaluasi penyelesaian kait siklus hidup. 

Setelah fungsi selesai berjalan, ia harus mengembalikan a `hookStatus` agar penerapan dapat dilanjutkan. Jika a `hookStatus` tidak dikembalikan, atau jika fungsi gagal, penerapan akan kembali. Berikut ini adalah `hookStatus` nilainya:
+ `SUCCEEDED`- penyebaran berlanjut ke tahap siklus hidup berikutnya
+ `FAILED`— penyebaran kembali ke penerapan terakhir yang berhasil.
+ `IN_PROGRESS`- Amazon ECS menjalankan fungsi lagi setelah periode waktu yang singkat. Secara default ini adalah interval 30 detik, namun nilai ini dapat disesuaikan dengan mengembalikan a `callBackDelay` di samping. `hookStatus`

Contoh berikut menunjukkan cara mengembalikan `hookStatus` dengan penundaan callback kustom. Dalam contoh ini, Amazon ECS akan mencoba lagi hook ini dalam 60 detik, bukan default 30 detik:

```
{
    "hookStatus": "IN_PROGRESS",
    "callBackDelay": 60
}
```

Ketika roll back terjadi, Amazon ECS menjalankan kait siklus hidup untuk tahapan siklus hidup berikut:
+ PRODUCTION\$1TRAFFIC\$1SHIFT
+ TEST\$1TRAFFIC\$1SHIFT

## Muatan siklus hidup
<a name="service-deployment-lifecycle-payloads"></a>

 Saat Anda mengonfigurasi kait siklus hidup untuk penerapan layanan ECS, Amazon ECS akan memanggil kait ini pada tahapan tertentu dari proses penerapan. Setiap tahap siklus hidup menyediakan muatan JSON dengan informasi tentang status penerapan saat ini. Dokumen ini menjelaskan struktur payload untuk setiap tahap siklus hidup. 

### Struktur muatan umum
<a name="common-payload-structure"></a>

 Semua muatan tahap siklus hidup mencakup bidang umum berikut: 
+  `serviceArn`- Nama Sumber Daya Amazon (ARN) dari layanan. 
+  `targetServiceRevisionArn`- ARN dari revisi layanan target sedang dikerahkan. 
+  `testTrafficWeights`- Peta revisi layanan ARNs untuk persentase berat lalu lintas uji yang sesuai. 
+  `productionTrafficWeights`- Peta revisi layanan ARNs untuk persentase berat lalu lintas produksi yang sesuai. 

### Muatan tahap siklus hidup
<a name="lifecycle-stage-payloads"></a>

#### RECONCILE\$1SERVICE
<a name="reconcile-service"></a>

 Tahap ini terjadi pada awal proses penyebaran ketika layanan sedang direkonsiliasi. Berikut ini menunjukkan contoh payload untuk tahap siklus hidup ini.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **Harapan pada tahap ini:** 
+ Set tugas utama adalah pada skala 0%

#### PRE\$1SCALE\$1UP
<a name="pre-scale-up"></a>

 Tahap ini terjadi sebelum tugas baru ditingkatkan. Berikut ini menunjukkan contoh payload untuk tahap siklus hidup ini.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Harapan pada tahap ini:** 
+ Tugas revisi layanan hijau berada pada skala 0%

#### POST\$1SCALE\$1UP
<a name="post-scale-up"></a>

 Tahap ini terjadi setelah tugas-tugas baru ditingkatkan dan sehat. Berikut ini menunjukkan contoh payload untuk tahap siklus hidup ini.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Harapan pada tahap ini:** 
+ Tugas revisi layanan hijau berada pada skala 100%
+ Tugas dalam revisi layanan hijau sehat

#### TEST\$1TRAFFIC\$1SHIFT
<a name="test-traffic-shift"></a>

 Tahap ini terjadi ketika lalu lintas uji sedang dialihkan ke tugas revisi layanan hijau. 

Berikut ini menunjukkan contoh payload untuk tahap siklus hidup ini.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {}
}
```

 **Harapan pada tahap ini:** 
+ Lalu lintas uji sedang dalam proses bergerak menuju tugas revisi layanan hijau. 

#### POST\$1TEST\$1TRAFFIC\$1SHIFT
<a name="post-test-traffic-shift"></a>

 Tahap ini terjadi setelah lalu lintas uji telah sepenuhnya bergeser ke tugas-tugas baru. 

Berikut ini menunjukkan contoh payload untuk tahap siklus hidup ini.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Harapan pada tahap ini:** 
+ 100% lalu lintas uji bergerak menuju tugas revisi layanan hijau. 

#### PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="production-traffic-shift"></a>

 Tahap ini terjadi ketika lalu lintas produksi sedang dialihkan ke tugas revisi layanan hijau. 

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **Harapan pada tahap ini:** 
+ Lalu lintas produksi sedang dalam proses pindah ke revisi layanan hijau. 

#### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="post-production-traffic-shift"></a>

 Tahap ini terjadi setelah lalu lintas produksi sepenuhnya dialihkan ke tugas revisi layanan hijau. 

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Harapan pada tahap ini:** 
+ 100% lalu lintas produksi bergerak menuju tugas revisi layanan hijau. 

### Kategori tahap siklus hidup
<a name="lifecycle-stage-categories"></a>

 Tahapan siklus hidup terbagi dalam dua kategori: 

1.  **Tahap pemanggilan tunggal** - Tahapan ini dipanggil hanya sekali selama penerapan layanan: 
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

1.  Tahapan **pemanggilan berulang - Tahapan** ini mungkin dipanggil beberapa kali selama penerapan layanan, misalnya ketika operasi rollback terjadi: 
   + TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT

### Status penerapan selama kait siklus hidup
<a name="deployment-status-during-lifecycle-hooks"></a>

 Saat kait siklus hidup sedang berjalan, status penerapan akan berlaku `IN_PROGRESS` untuk semua tahapan siklus hidup. 


| Tahap Siklus Hidup | Status Penerapan | 
| --- | --- | 
| RECONCILE\$1SERVICE | IN\$1PROGRESS | 
| PRE\$1SCALE\$1UP | IN\$1PROGRESS | 
| POST\$1SCALE\$1UP | IN\$1PROGRESS | 
| TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 

# Menghentikan deployment layanan Amazon ECS
<a name="stop-service-deployment"></a>

Anda dapat menghentikan penerapan secara manual saat penerapan yang gagal tidak terdeteksi oleh pemutus sirkuit atau alarm. CloudWatch Jenis stop berikut tersedia:
+ Rollback - Opsi ini mengembalikan penyebaran layanan ke revisi layanan sebelumnya. 

  Anda dapat menggunakan opsi ini meskipun Anda tidak mengonfigurasi penyebaran layanan untuk opsi rollback. 

Anda dapat menghentikan penerapan yang ada di salah satu status berikut. Untuk informasi selengkapnya tentang status penerapan layanan, lihat[Melihat riwayat layanan menggunakan deployment layanan Amazon ECS](service-deployment.md).
+ PENDING - Penyebaran layanan bergerak ke status ROLLBACK\$1REQUESTED, dan kemudian operasi rollback dimulai.
+ IN\$1PROGRESS - Penyebaran layanan bergerak ke status ROLLBACK\$1REQUESTED, dan kemudian operasi rollback dimulai.
+ STOP\$1REQUESTED - Penyebaran layanan terus berhenti.
+ ROLLBACK\$1REQUESTED - Penyebaran layanan melanjutkan operasi rollback.
+ ROLLBACK\$1IN\$1PROGRESS - Penyebaran layanan melanjutkan operasi rollback.

## Prosedur
<a name="stop-service-deployment-procedure"></a>

Sebelum Anda mulai, konfigurasikan izin yang diperlukan untuk melihat penerapan layanan. Untuk informasi selengkapnya, lihat [Izin diperlukan untuk melihat penerapan layanan Amazon ECS](service-deployment-permissions.md).

------
#### [ Amazon ECS Console ]

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, pilih layanan.

   Halaman detail layanan ditampilkan.

1. Pada halaman detail layanan, pilih **Deployment**.

   Halaman penerapan ditampilkan.

1. Di bawah **Penerapan yang sedang berlangsung**, pilih **Roll back**. Kemudian, di jendela konfirmasi, pilih **Gulung kembali**.

------
#### [ AWS CLI ]

1. Jalankan `list-service-deployments` untuk mengambil ARN penyebaran layanan. 

   Ganti *user-input* dengan nilai-nilai Anda.

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   Perhatikan `serviceDeploymentArn` untuk penerapan yang ingin Anda hentikan.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. Jalankan `stop-service-deployments`. Gunakan `serviceDeploymentArn` yang dikembalikan dari`list-service-deployments`.

   Ganti *user-input* dengan nilai-nilai Anda.

   ```
   aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK
   ```

------

## Langkah selanjutnya
<a name="stop-service-deployment-next-step"></a>

Putuskan perubahan apa yang perlu dilakukan pada layanan, dan kemudian perbarui layanan. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).

# Melakukan deployment layanan Amazon ECS dengan mengganti tugas
<a name="deployment-type-ecs"></a>

Saat Anda membuat layanan yang menggunakan tipe penerapan *rolling update* (`ECS`), penjadwal layanan Amazon ECS menggantikan tugas yang sedang berjalan dengan tugas baru. Jumlah tugas yang ditambahkan atau dihapus Amazon ECS dari layanan selama pembaruan bergulir dikendalikan oleh konfigurasi penyebaran layanan. 

Amazon ECS menggunakan parameter berikut untuk menentukan jumlah tugas:
+ `minimumHealthyPercent`Ini mewakili batas bawah pada jumlah tugas yang harus berjalan dan sehat untuk layanan selama penerapan bergulir atau ketika instance kontainer terkuras, sebagai persen dari jumlah tugas yang diinginkan untuk layanan. Nilai ini dibulatkan ke atas. Sebagai contoh, jika persentase minimum yang sehat adalah `50` dan jumlah tugas yang diinginkan adalah empat, maka penjadwal dapat menghentikan dua tugas yang sudah ada sebelum memulai dua tugas baru. Demikian juga, jika persentase minimum yang sehat adalah 75% dan jumlah tugas yang diinginkan adalah dua, maka penjadwal tidak dapat menghentikan tugas apa pun karena nilai yang dihasilkan juga dua.
+ `maximumPercent`Ini mewakili batas atas jumlah tugas yang harus dijalankan untuk layanan selama penerapan bergulir atau ketika instance kontainer terkuras, sebagai persen dari jumlah tugas yang diinginkan untuk layanan. Nilai ini dibulatkan ke bawah. Misalnya jika persentase maksimum adalah `200` dan jumlah tugas yang diinginkan adalah empat, maka penjadwal dapat memulai empat tugas baru sebelum menghentikan empat tugas yang ada. Demikian juga, jika persentase maksimum adalah `125` dan jumlah tugas yang diinginkan adalah tiga, maka penjadwal tidak dapat memulai tugas apa pun karena nilai yang dihasilkan juga tiga.

Selama penerapan bergulir, ketika tugas menjadi tidak sehat, Amazon ECS menggantikannya untuk menjaga layanan Anda `minimumHealthyPercent` dan melindungi ketersediaan. Tugas yang tidak sehat diganti menggunakan revisi layanan yang sama dengan yang mereka miliki. Ini memastikan bahwa penggantian tugas yang tidak sehat dalam revisi sumber independen dari kegagalan tugas dalam revisi target. Saat `maximumPercent` pengaturan memungkinkan, penjadwal meluncurkan tugas pengganti sebelum menghentikan tugas yang tidak sehat. Jika `maximumPercent` parameter membatasi penjadwal untuk memulai tugas penggantian terlebih dahulu, penjadwal menghentikan satu tugas yang tidak sehat pada satu waktu untuk membebaskan kapasitas sebelum meluncurkan tugas pengganti.

**penting**  
Saat menetapkan persen sehat minimum atau persen maksimum, Anda harus memastikan bahwa penjadwal dapat menghentikan atau memulai setidaknya satu tugas saat penerapan dimulai. Jika layanan Anda memiliki deployment yang macet akibat konfigurasi deployment yang tidak valid, maka pesan kejadian layanan akan dikirimkan. Untuk informasi selengkapnya, lihat [service (*service-name*) tidak dapat menghentikan atau memulai tugas selama penerapan karena konfigurasi penerapan layanan. Perbarui nilai minimumHealthyPercent atau MaximumPercent dan coba lagi.](service-event-messages-list.md#service-event-messages-7).

Penerapan bergulir memiliki 2 metode yang menyediakan cara untuk mengidentifikasi dengan cepat kapan penerapan layanan gagal:
+ [Cara pemutus sirkuit deployment Amazon ECS mendeteksi kegagalan](deployment-circuit-breaker.md)
+ [Bagaimana CloudWatch alarm mendeteksi kegagalan penerapan Amazon ECS](deployment-alarm-failure.md)

Metode ini dapat digunakan secara terpisah atau bersama-sama. Ketika kedua metode digunakan, penerapan disetel ke gagal segera setelah kriteria kegagalan untuk salah satu metode kegagalan terpenuhi.

Gunakan panduan berikut untuk membantu menentukan metode mana yang akan digunakan:
+ Pemutus sirkuit - Gunakan metode ini saat Anda ingin menghentikan penerapan saat tugas tidak dapat dimulai.
+ CloudWatch alarm - Gunakan metode ini ketika Anda ingin menghentikan penyebaran berdasarkan metrik aplikasi.

Kedua metode mendukung pengguliran kembali ke revisi layanan sebelumnya.

## Penerjemahan image kontainer
<a name="deployment-container-image-stability"></a>

Secara default, Amazon ECS menyelesaikan tag gambar kontainer yang ditentukan dalam definisi tugas ke intisari gambar kontainer. Jika Anda membuat layanan yang menjalankan dan mempertahankan satu tugas, tugas tersebut akan digunakan untuk membuat intisari gambar untuk kontainer dalam tugas tersebut. Jika Anda membuat layanan yang menjalankan dan memelihara beberapa tugas, tugas pertama yang dimulai oleh penjadwal layanan selama penerapan akan digunakan untuk membuat intisari gambar untuk kontainer dalam tugas.

Jika tiga atau lebih upaya untuk membuat intisari gambar kontainer gagal, penerapan berlanjut tanpa resolusi intisari gambar. Jika pemutus sirkuit penyebaran diaktifkan, penerapan juga gagal dan diputar kembali.

Setelah intisari gambar kontainer dibuat, Amazon ECS menggunakan intisari untuk memulai tugas lain yang diinginkan, dan untuk pembaruan layanan di masa mendatang. Ini mengarah ke semua tugas dalam layanan yang selalu menjalankan gambar kontainer yang identik, menghasilkan konsistensi versi untuk perangkat lunak Anda.

Anda dapat mengonfigurasi perilaku ini untuk setiap kontainer dalam tugas Anda dengan menggunakan `versionConsistency` parameter dalam definisi penampung. Untuk informasi selengkapnya, lihat [versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency).

**catatan**  
Amazon ECS Agent versi lebih rendah dari `1.31.0` tidak mendukung resolusi intisari gambar. Versi agen `1.31.0` untuk `1.69.0` mendukung resolusi intisari gambar hanya untuk gambar yang didorong ke repositori Amazon ECR. Versi agen `1.70.0` atau yang lebih tinggi mendukung resolusi intisari gambar untuk semua gambar. 
Versi platform Fargate Linux minimum untuk resolusi intisari gambar adalah. `1.3.0` Versi platform Fargate Windows minimum untuk resolusi intisari gambar adalah. `1.0.0`
Amazon ECS tidak menangkap intisari kontainer sespan yang dikelola oleh Amazon ECS, seperti GuardDuty agen keamanan Amazon atau proxy Service Connect.
Untuk mengurangi potensi latensi yang terkait dengan resolusi gambar kontainer dalam layanan dengan beberapa tugas, jalankan versi agen Amazon ECS `1.83.0` atau yang lebih tinggi pada instans kontainer EC2. Untuk menghindari potensi latensi, tentukan intisari gambar kontainer dalam definisi tugas Anda.
Jika Anda membuat layanan dengan jumlah tugas nol yang diinginkan, Amazon ECS tidak dapat membuat intisari kontainer hingga Anda memicu penerapan layanan lain dengan jumlah tugas yang diinginkan lebih besar dari nol.
Untuk membuat intisari gambar yang diperbarui, Anda dapat memaksa penerapan baru. Intisari yang diperbarui akan digunakan untuk memulai tugas baru dan tidak akan memengaruhi tugas yang sudah berjalan. Untuk informasi selengkapnya tentang pemaksaan penerapan baru, lihat [forceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment)di referensi *Amazon ECS API.*
Saat menggunakan penyedia kapasitas EC2, jika kapasitas tidak cukup untuk memulai tugas selama penerapan awal, konsistensi versi perangkat lunak mungkin gagal. Untuk memastikan konsistensi versi dipertahankan bahkan ketika kapasitas terbatas, setel secara eksplisit `versionConsistency: "enabled"` dalam konfigurasi kontainer definisi tugas Anda daripada mengandalkan perilaku default. Hal ini menyebabkan Amazon ECS menunggu hingga kapasitas tersedia sebelum melanjutkan penyebaran.

# Praktik terbaik untuk parameter layanan Amazon ECS
<a name="service-options"></a>

Untuk memastikan tidak ada downtime aplikasi, proses penerapan adalah sebagai berikut:

1. Mulai wadah aplikasi baru sambil menjaga kontainer yang ada tetap berjalan.

1. Periksa apakah wadah baru itu sehat.

1. Hentikan wadah lama.

 Bergantung pada konfigurasi penerapan Anda dan jumlah ruang kosong yang tidak dipesan di klaster Anda, mungkin diperlukan beberapa putaran untuk menyelesaikannya, ganti semua tugas lama dengan tugas baru. 

Ada dua opsi konfigurasi layanan yang dapat Anda gunakan untuk mengubah nomor:
+ `minimumHealthyPercent`: 100% (default)

  Batas bawah pada jumlah tugas untuk layanan Anda yang harus tetap dalam `RUNNING` status selama penerapan. Ini adalah persentase dari yang `desiredCount` dibulatkan ke bilangan bulat terdekat. Parameter ini memungkinkan Anda untuk menyebarkan tanpa menggunakan kapasitas cluster tambahan.
+ `maximumPercent`: 200% (default)

   Batas atas jumlah tugas untuk layanan Anda yang diizinkan di `RUNNING` atau `PENDING` status selama penerapan. Ini adalah persentase dari yang `desiredCount` dibulatkan ke bawah ke bilangan bulat terdekat.

**Contoh: Opsi konfigurasi default**

Pertimbangkan layanan berikut yang memiliki enam tugas, digunakan dalam cluster yang memiliki ruang untuk total delapan tugas. Opsi konfigurasi layanan default tidak memungkinkan penerapan berada di bawah 100% dari enam tugas yang diinginkan.

Proses penyebaran adalah sebagai berikut:

1. Tujuannya adalah untuk mengganti enam tugas.

1. Penjadwal memulai dua tugas baru karena pengaturan default mengharuskan ada enam tugas yang berjalan.

   Sekarang ada enam tugas yang ada dan dua tugas baru.

1. Penjadwal menghentikan dua tugas yang ada.

   Sekarang ada empat tugas yang ada dan dua yang baru.

1. Penjadwal memulai dua tugas baru tambahan.

   Sekarang ada empat tugas yang ada dan empat tugas baru.

1. Penjadwal menutup dua tugas yang ada.

   Sekarang ada dua tugas yang ada dan empat yang baru.

1. Penjadwal memulai dua tugas baru tambahan.

   Sekarang ada dua tugas yang ada dan enam tugas baru

1. Penjadwal menutup dua tugas terakhir yang ada.

   Sekarang ada enam tugas baru.

Dalam contoh di atas, jika Anda menggunakan nilai default untuk opsi, ada 2,5 menit menunggu untuk setiap tugas baru yang dimulai. Selain itu, penyeimbang beban mungkin harus menunggu 5 menit agar tugas lama berhenti. 

**Contoh: Modifikasi `minimumHealthyPercent`**

Anda dapat mempercepat penerapan dengan menyetel `minimumHealthyPercent` nilainya menjadi 50%.

Pertimbangkan layanan berikut yang memiliki enam tugas, digunakan dalam cluster yang memiliki ruang untuk total delapan tugas. Proses penyebaran adalah sebagai berikut:

1. Tujuannya adalah untuk mengganti enam tugas.

1. Penjadwal menghentikan tiga tugas yang ada. 

   Masih ada tiga tugas yang berjalan yang memenuhi `minimumHealthyPercent` nilai.

1. Penjadwal memulai lima tugas baru.

   Ada tiga tugas tugas yang ada dan lima tugas baru.

1. Penjadwal menghentikan tiga tugas yang tersisa.

   Ada lima tugas baru

1. Penjadwal memulai tugas baru terakhir.

   Ada enam tugas baru.

**Contoh: Memodifikasi ruang kosong cluster**

Anda juga dapat menambahkan ruang kosong tambahan sehingga Anda dapat menjalankan tugas tambahan. 

Pertimbangkan layanan berikut yang memiliki enam tugas, digunakan dalam cluster yang memiliki ruang untuk total sepuluh tugas. Proses penyebaran adalah sebagai berikut:

1. Tujuannya adalah untuk mengganti tugas yang ada.

1. Penjadwal menghentikan tiga tugas yang ada,

   Ada tiga tugas yang ada.

1. Penjadwal memulai enam tugas baru.

   Ada tugas yang ada dan enam tugas baru

1. Penjadwal menghentikan tiga tugas yang ada.

   Ada enam tugas baru.

**Rekomendasi**

Gunakan nilai berikut untuk opsi konfigurasi layanan saat tugas Anda menganggur selama beberapa waktu dan tidak memiliki tingkat pemanfaatan yang tinggi.
+ `minimumHealthyPercent`: 50%
+ `maximumPercent`: 200% 

# Membuat penyebaran pembaruan bergulir Amazon ECS
<a name="create-service-console-v2"></a>

Buat layanan untuk menjalankan dan mempertahankan sejumlah contoh tertentu dari definisi tugas secara bersamaan dalam sebuah cluster. Jika salah satu tugas Anda gagal atau berhenti, penjadwal layanan Amazon ECS meluncurkan contoh lain dari definisi tugas Anda untuk menggantikannya. Ini membantu mempertahankan jumlah tugas yang Anda inginkan dalam layanan.

Tentukan parameter konfigurasi berikut sebelum Anda membuat layanan:
+ Ada dua opsi komputasi yang mendistribusikan tugas Anda.
  + **Strategi penyedia kapasitas** menyebabkan Amazon ECS mendistribusikan tugas Anda di satu atau di beberapa penyedia kapasitas. 

    Jika ingin menjalankan beban kerja di Instans Terkelola Amazon ECS, Anda harus menggunakan opsi strategi penyedia Kapasitas.
  + **Jenis peluncuran** menyebabkan Amazon ECS meluncurkan tugas kami secara langsung di Fargate atau pada instans EC2 yang terdaftar di kluster Anda.

    Jika ingin menjalankan beban kerja di Instans Terkelola Amazon ECS, Anda harus menggunakan opsi strategi penyedia Kapasitas.
+ Penentuan tugas yang menggunakan mode atau layanan jaringan `awsvpc` yang dikonfigurasi untuk menggunakan penyeimbang beban harus memiliki konfigurasi jaringan. Secara default, konsol memilih VPC Amazon default bersama dengan semua subnet dan grup keamanan default dalam VPC Amazon default. 
+ Strategi penempatan, Strategi penempatan tugas default mendistribusikan tugas secara merata di seluruh Availability Zone. 

  Kami menyarankan Anda menggunakan penyeimbangan kembali Availability Zone untuk membantu memastikan ketersediaan yang tinggi untuk layanan Anda. Untuk informasi selengkapnya, lihat [Menyeimbangkan Layanan Amazon ECS di Seluruh Zona Ketersediaan](service-rebalancing.md).
+ Saat Anda menggunakan **Jenis Peluncuran** untuk penyebaran layanan Anda, secara default layanan dimulai di subnet di VPC klaster Anda.
+ Untuk **strategi penyedia kapasitas**, konsol memilih opsi komputasi secara default. Berikut dijelaskan tentang urutan yang digunakan konsol untuk memilih default:
  + Jika klaster Anda memiliki strategi penyedia kapasitas default yang ditentukan, klaster akan dipilih.
  + Jika klaster Anda tidak memiliki strategi penyedia kapasitas default yang ditentukan tetapi Anda memiliki penyedia kapasitas Fargate yang ditambahkan ke klaster, strategi penyedia kapasitas khusus yang menggunakan penyedia `FARGATE` kapasitas dipilih.
  + Jika klaster Anda tidak memiliki strategi penyedia kapasitas default yang ditentukan tetapi Anda memiliki satu atau beberapa penyedia kapasitas grup Auto Scaling yang ditambahkan ke cluster, opsi **Use custom (Advanced)** akan dipilih dan Anda perlu menentukan strategi secara manual.
  + Jika klaster Anda tidak memiliki strategi penyedia kapasitas default yang ditentukan dan tidak ada penyedia kapasitas yang ditambahkan ke cluster, jenis peluncuran Fargate akan dipilih.
+ Opsi default deteksi kegagalan penerapan default adalah menggunakan opsi **pemutus sirkuit penyebaran Amazon ECS** dengan opsi **Rollback on** failure.

  Untuk informasi selengkapnya, lihat [Cara pemutus sirkuit deployment Amazon ECS mendeteksi kegagalan](deployment-circuit-breaker.md).
+ Putuskan apakah Anda ingin Amazon ECS menambah atau mengurangi jumlah tugas yang diinginkan dalam layanan Anda secara otomatis. Untuk informasi lihat,[Menskalakan layanan Amazon ECS secara otomatis](service-auto-scaling.md).
+ Jika Anda memerlukan aplikasi untuk terhubung ke aplikasi lain yang berjalan di Amazon ECS, tentukan opsi yang sesuai dengan arsitektur Anda. Untuk informasi selengkapnya, lihat [Interkoneksi layanan Amazon ECS](interconnecting-services.md). 
+ Saat Anda membuat layanan yang menggunakan pemutus sirkuit Amazon ECS, Amazon ECS membuat penyebaran layanan dan revisi layanan. Sumber daya ini memungkinkan Anda untuk melihat informasi terperinci tentang riwayat layanan. Untuk informasi selengkapnya, lihat [Melihat riwayat layanan menggunakan deployment layanan Amazon ECS](service-deployment.md).

  Untuk informasi tentang cara membuat layanan menggunakan AWS CLI, lihat [https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)di *AWS Command Line Interface Referensi*.

  Untuk informasi tentang cara membuat layanan menggunakan AWS CloudFormation, lihat [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html)di *Panduan AWS CloudFormation Pengguna*.

## Buat layanan dengan opsi default
<a name="create-default-service"></a>

Anda dapat menggunakan konsol untuk membuat dan menyebarkan layanan dengan cepat. Layanan ini memiliki konfigurasi berikut:
+ Menyebarkan di VPC dan subnet yang terkait dengan cluster Anda
+ Menyebarkan satu tugas
+ Menggunakan penerapan bergulir
+ Menggunakan strategi penyedia kapasitas dengan penyedia kapasitas default Anda
+ Menggunakan pemutus sirkuit penyebaran untuk mendeteksi kegagalan dan menetapkan opsi untuk secara otomatis memutar kembali penerapan pada kegagalan

Untuk menerapkan layanan menggunakan parameter default ikuti langkah-langkah ini.

**Untuk membuat layanan (konsol Amazon ECS)**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Di halaman navigasi, pilih **Cluster**.

1. Pada halaman **Clusters**, pilih cluster untuk membuat layanan di.

1. Dari tab **Layanan**, pilih **Buat**.

   Halaman **Create Service** akan muncul.

1. Di bawah **rincian Layanan**, lakukan hal berikut:

   1. Untuk **definisi Tugas**, masukkan keluarga definisi tugas dan revisi yang akan digunakan.

   1. Untuk **nama Layanan**, masukkan nama untuk layanan Anda.

1. **Untuk menggunakan ECS Exec untuk men-debug layanan, di bawah **konfigurasi Pemecahan Masalah, pilih Aktifkan** ECS Exec.**

1. Di bawah **konfigurasi Deployment**, lakukan hal berikut:

   1. Untuk **tugas yang diinginkan**, masukkan jumlah tugas untuk diluncurkan dan dipelihara dalam layanan.

1. (Opsional) Untuk membantu mengidentifikasi layanan dan tugas Anda, perluas bagian **Tag**, lalu konfigurasikan tag Anda.

   Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag definisi tugas, pilih **Aktifkan tag terkelola Amazon ECS**, lalu pilih Definisi **tugas**.

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag layanan, pilih **Aktifkan tag terkelola Amazon ECS**, lalu pilih Layanan.**

   Menambah atau menghapus tanda.
   + [Tambahkan tag] Pilih **Tambah tag**, lalu lakukan hal berikut:
     + Untuk **Kunci**, masukkan nama kunci.
     + Untuk **Nilai**, masukkan nilai kunci.
   + [Menghapus tanda] Di samping tanda, pilih **Hapus tanda**.

## Buat layanan menggunakan parameter yang ditentukan
<a name="create-custom-service"></a>

Untuk membuat layanan dengan menggunakan parameter yang ditentukan, ikuti langkah-langkah ini.

**Untuk membuat layanan (konsol Amazon ECS)**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Tentukan sumber daya dari tempat Anda meluncurkan layanan.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/create-service-console-v2.html)

   Halaman **Create Service** akan muncul.

1. Di bawah rincian Layanan, lakukan hal berikut:

   1. Untuk **definisi Tugas**, masukkan definisi tugas yang akan digunakan. Kemudian, untuk **Revisi**, pilih revisi yang akan digunakan.

   1. Untuk **nama Layanan**, masukkan nama untuk layanan Anda.

1. Untuk **klaster yang ada**, pilih cluster.

   Pilih **Buat klaster** untuk menjalankan tugas di klaster baru

1. Pilih bagaimana tugas Anda didistribusikan di seluruh infrastruktur klaster Anda. Di bawah **Konfigurasi komputasi**, pilih opsi Anda.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. **Untuk menggunakan ECS Exec untuk men-debug layanan, di bawah **konfigurasi Pemecahan Masalah, pilih Aktifkan** ECS Exec.**

1. Di bawah **konfigurasi Deployment**, lakukan hal berikut:

   1. Untuk **jenis Layanan**, pilih strategi penjadwalan layanan.
      + **Agar penjadwal menerapkan tepat satu tugas pada setiap instance kontainer aktif yang memenuhi semua batasan penempatan tugas, pilih Daemon.**
      + Untuk menempatkan penjadwal dan mempertahankan jumlah tugas yang diinginkan di cluster Anda, pilih **Replika**.

   1. Jika Anda memilih **Replika**, untuk **tugas yang diinginkan**, masukkan jumlah tugas yang akan diluncurkan dan dipelihara dalam layanan.

   1. **Jika Anda memilih **Replika**, agar Amazon ECS memantau distribusi tugas di seluruh Availability Zone, dan mendistribusikannya kembali ketika ada ketidakseimbangan, di bawah penyeimbangan kembali layanan Availability Zone, pilih **Availability Zone service rebalancing**.**

   1. Untuk **Health check masa tenggang**, masukkan jumlah waktu (dalam detik) yang memasukkan jumlah waktu (dalam detik) bahwa penjadwal layanan mengabaikan Elastic Load Balancing yang tidak sehat, VPC Lattice, dan pemeriksaan kesehatan kontainer setelah tugas pertama kali dimulai. Jika Anda tidak menentukan nilai periode tunggu pemeriksaan kondisi, nilai default 0 akan digunakan.

   1. Tentukan jenis penerapan untuk layanan Anda. Perluas **opsi Deployment**, lalu tentukan parameter berikut.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/create-service-console-v2.html)

   1. Untuk mengonfigurasi cara Amazon ECS mendeteksi dan menangani kegagalan penerapan, perluas **deteksi kegagalan Deployment**, lalu pilih opsi Anda. 

      1. Untuk menghentikan penerapan saat tugas tidak dapat dimulai, pilih **Gunakan pemutus sirkuit penyebaran Amazon ECS**.

         **Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat pemutus sirkuit penyebaran mengatur penerapan ke status gagal, pilih Rollback on failure.**

      1. Untuk menghentikan penerapan berdasarkan metrik aplikasi, pilih **Gunakan CloudWatch alarm.** Kemudian, dari **nama CloudWatch alarm**, pilih alarm. Untuk membuat alarm baru, buka CloudWatch konsol.

         Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat CloudWatch alarm menyetel penerapan ke status gagal, pilih **Rollback on** failure.

1. Jika definisi tugas Anda menggunakan mode `awsvpc` jaringan, Anda dapat menentukan konfigurasi jaringan kustom memperluas **Jaringan**, dan kemudian melakukan hal berikut:

   1. Untuk **VPC**, pilih VPC yang akan digunakan.

   1. Untuk **Subnet**, pilih satu atau beberapa subnet di VPC yang dipertimbangkan oleh penjadwal tugas saat menempatkan tugas Anda.

   1. Untuk **Grup keamanan**, Anda dapat memilih grup keamanan yang sudah ada atau menciptakan grup keamanan baru. Untuk menggunakan grup keamanan yang sudah ada, pilih grup keamanan dan lanjutkan ke langkah selanjutnya. Untuk membuat grup keamanan baru, pilih **Buat grup keamanan baru**. Anda harus menentukan nama grup keamanan, deskripsi, dan kemudian tambahkan satu atau beberapa aturan masuk untuk grup keamanan.

   1. Untuk **IP Publik**, pilih apakah akan menetapkan alamat IP publik secara otomatis ke antarmuka jaringan elastis (ENI) tugas.

      AWS Fargate tugas dapat diberikan alamat IP publik ketika dijalankan di subnet publik sehingga mereka memiliki rute ke internet. Tugas EC2 tidak dapat diberikan IP publik menggunakan bidang ini. Untuk informasi selengkapnya, lihat [opsi jaringan tugas Amazon ECS untuk Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) [dan Alokasikan antarmuka jaringan untuk tugas Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html).

1. (Opsional) Untuk menghubungkan layanan Anda menggunakan Service Connect, perluas **Service Connect**, lalu tentukan yang berikut ini:

   1.  Pilih **Aktifkan Service Connect**.

   1. Di bawah **konfigurasi Service Connect**, tentukan mode klien.
      + Jika layanan Anda menjalankan aplikasi klien jaringan yang hanya perlu terhubung ke layanan lain di namespace, pilih **sisi Klien** saja.
      + Jika layanan Anda menjalankan aplikasi jaringan atau layanan web dan perlu menyediakan titik akhir untuk layanan ini, dan terhubung ke layanan lain di namespace, pilih **Klien** dan server.

   1. Untuk menggunakan namespace yang bukan namespace cluster default, untuk Namespace, pilih **namespace layanan**. Ini bisa berupa namespace yang dibuat secara terpisah di ruang nama Anda Akun AWS atau Wilayah AWS di Region yang sama yang dibagikan dengan akun Anda menggunakan (). AWS Resource Access Manager AWS RAM*Untuk informasi selengkapnya tentang AWS Cloud Map ruang nama bersama, lihat [Berbagi AWS Cloud Map namespace lintas akun](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) di Panduan Pengembang.AWS Cloud Map *

   1. (Opsional) Tentukan konfigurasi log. Pilih **Gunakan koleksi log**. Opsi default mengirimkan log kontainer ke CloudWatch Log. Opsi driver log lainnya dikonfigurasi menggunakan AWS FireLens. Untuk informasi selengkapnya, lihat [Kirim log Amazon ECS ke AWS layanan atau AWS Partner](using_firelens.md).

      Berikut ini menjelaskan setiap tujuan log kontainer secara lebih rinci.
      + **Amazon CloudWatch** — Konfigurasikan tugas untuk mengirim log kontainer ke CloudWatch Log. Opsi driver log default disediakan, yang membuat grup CloudWatch log atas nama Anda. Untuk menentukan nama grup log yang berbeda, ubah nilai opsi driver.
      + **Amazon Data Firehose** — Konfigurasikan tugas untuk mengirim log kontainer ke Firehose. Opsi driver log default disediakan, yang mengirim log ke aliran pengiriman Firehose. Untuk menentukan nama aliran pengiriman yang berbeda, ubah nilai opsi driver.
      + **Amazon Kinesis Data** Streams — Konfigurasikan tugas untuk mengirim log kontainer ke Kinesis Data Streams. Opsi driver log default disediakan, yang mengirim log ke aliran Kinesis Data Streams. Untuk menentukan nama aliran yang berbeda, ubah nilai opsi driver.
      + **Amazon OpenSearch Service** - Konfigurasikan tugas untuk mengirim log kontainer ke domain OpenSearch Layanan. Opsi driver log harus disediakan. 
      + **Amazon S3** — Konfigurasikan tugas untuk mengirim log kontainer ke bucket Amazon S3. Opsi driver log default disediakan, tetapi Anda harus menentukan nama bucket Amazon S3 yang valid.

   1. (Opsional) Untuk mengaktifkan log akses, ikuti langkah-langkah ini:

      1. Perluas **konfigurasi log Access**. Untuk **Format**, pilih **JSON** atau`TEXT`.

      1. Untuk menyertakan parameter kueri dalam log akses, pilih **Sertakan parameter kueri**.

1. (Opsional) Untuk menghubungkan layanan Anda menggunakan Service Discovery, perluas **penemuan Layanan**, lalu lakukan hal berikut.

   1. Pilih **Gunakan penemuan layanan**.

   1. Untuk menggunakan namespace baru, pilih **Buat namespace baru di bawah Konfigurasi namespace****, lalu berikan nama dan deskripsi namespace**. Untuk menggunakan namespace yang ada, **pilih Pilih namespace yang ada lalu pilih namespace** yang ingin Anda gunakan.

   1. Memberikan informasi layanan Service Discovery seperti nama dan deskripsi layanan.

   1. Agar Amazon ECS melakukan pemeriksaan kesehatan tingkat kontainer secara berkala, pilih Aktifkan propagasi kesehatan tugas **Amazon ECS.**

   1. Untuk **jenis rekaman DNS, pilih jenis** rekaman DNS yang akan dibuat untuk layanan Anda. Penemuan layanan Amazon ECS hanya mendukung catatan **A** dan **SRV**, tergantung pada mode jaringan yang ditentukan oleh definisi tugas Anda. Untuk informasi selengkapnya tentang jenis rekaman ini, lihat Jenis [Rekaman DNS yang Didukung](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html) di *Panduan Pengembang Amazon Route 53*.
      + Jika definisi tugas yang ditentukan oleh tugas layanan Anda menggunakan mode `host` jaringan `bridge` atau, hanya jenis catatan **SRV** yang didukung. Pilih nama kontainer dan kombinasi port untuk dikaitkan dengan catatan.
      + Jika definisi tugas yang ditentukan oleh tugas layanan Anda menggunakan mode `awsvpc` jaringan, pilih jenis catatan **A** atau **SRV**. Jika Anda memilih **A**, lewati ke langkah berikutnya. Jika Anda memilih **SRV**, tentukan port tempat layanan dapat ditemukan atau nama kontainer dan kombinasi port untuk dikaitkan dengan catatan.

      Untuk **TTL**, masukkan waktu dalam hitungan detik berapa lama set rekaman di-cache oleh resolver DNS dan oleh browser web.

1. (Opsional) Untuk menghubungkan layanan Anda menggunakan VPC Lattice, xxpand **VPC** Lattice, lalu lakukan hal berikut:

   1. Pilih **Aktifkan Kisi VPC**

   1. Untuk **peran Infrastruktur**, pilih peran infrastruktur.

      Jika Anda belum membuat peran, pilih **Buat peran infrastruktur**.

   1. Di bawah **Grup Target** pilih grup target atau grup. Anda harus memilih setidaknya satu kelompok sasaran dan dapat memiliki maksimal lima. Pilih **Tambahkan grup target** untuk menambahkan grup target tambahan. Pilih **nama Port**, **Protokol**, dan **Port** untuk setiap grup target yang Anda pilih. 

      Untuk menghapus grup target, pilih **Hapus**.
**catatan**  
Jika Anda ingin menambahkan grup target yang ada, Anda perlu menggunakan AWS CLI. *Untuk petunjuk tentang cara menambahkan grup target menggunakan AWS CLI, lihat [daftar target di Referensi](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html). AWS Command Line Interface *
Meskipun layanan VPC Lattice dapat memiliki beberapa grup target, setiap grup target hanya dapat ditambahkan ke satu layanan.

   1. Untuk menyelesaikan konfigurasi VPC Lattice, dengan menyertakan grup target baru Anda dalam tindakan default listener atau dalam aturan layanan VPC Lattice yang ada di konsol VPC Lattice. Untuk informasi selengkapnya, lihat [Aturan pendengar untuk layanan Kisi VPC Anda](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html).

1. (Opsional) Untuk mengonfigurasi penyeimbang beban untuk layanan Anda, perluas **Load balancing**.

   Pilih penyeimbang beban.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (Opsional) Untuk mengonfigurasi Auto Scaling layanan, perluas Service **auto scaling**, lalu tentukan parameter berikut.Untuk menggunakan predicte auto scaling, yang melihat data beban masa lalu dari arus lalu lintas, konfigurasikan setelah Anda membuat layanan. Untuk informasi selengkapnya, lihat [Gunakan pola historis untuk menskalakan layanan Amazon ECS dengan penskalaan prediktif](predictive-auto-scaling.md).

   1. Untuk menggunakan penskalaan otomatis servis, pilih **Penskalaan otomatis layanan**.

   1. Untuk **Jumlah tugas minimum**, masukkan batas bawah jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan berada di bawah hitungan ini.

   1. Untuk **Jumlah tugas maksimum**, masukkan batas atas jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan melebihi hitungan ini.

   1. Pilih jenis kebijakan. Di bawah **Jenis kebijakan penskalaan**, pilih salah satu opsi berikut.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (Opsional) Untuk menggunakan strategi penempatan tugas selain default, perluas **Penempatan Tugas**, lalu pilih dari opsi berikut.

    Untuk informasi selengkapnya, lihat [Cara Amazon ECS Menempatkan Tugas di Instans Kontainer](task-placement.md).
   + **Penyebaran Seimbang AZ** – Mendistribusikan tugas ke berbagai Zona Ketersediaan dan berbagai instans kontainer di Zona Ketersediaan.
   + **AZ Balanced BinPack** — Mendistribusikan tugas di seluruh Availability Zone dan di seluruh instans kontainer dengan memori yang paling sedikit tersedia.
   + **BinPack**— Mendistribusikan tugas berdasarkan jumlah CPU atau memori yang paling sedikit tersedia.
   + **Satu Tugas per Host** – Menempatkan maksimal satu tugas dari layanan pada setiap instans kontainer.
   + **Kustom** - Tentukan strategi penempatan tugas Anda sendiri. 

   Jika Anda memilih **Kustom**, tentukan algoritme untuk menempatkan tugas dan aturan yang dipertimbangkan selama penempatan tugas.
   + Di bawah **Strategi**, untuk **Jenis** dan **Bidang**, pilih algoritma dan entitas yang akan digunakan untuk algoritme.

     Anda dapat memasukkan maksimal 5 strategi.
   + Di bawah **Constraint**, untuk **Type** dan **Expression**, pilih aturan dan atribut untuk kendala.

     **Misalnya, untuk menyetel batasan untuk menempatkan tugas pada instance T2, untuk **Ekspresi**, masukkan atribut:ecs.instance-type =\$1 t2. **\$1.

     Anda dapat memasukkan maksimal 10 kendala.

1. Jika tugas Anda menggunakan volume data yang kompatibel dengan konfigurasi saat penerapan, Anda dapat mengonfigurasi volume dengan memperluas **Volume**.

   Nama volume dan jenis volume dikonfigurasi saat Anda membuat revisi definisi tugas dan tidak dapat diubah saat membuat layanan. Untuk memperbarui nama dan jenis volume, Anda harus membuat revisi definisi tugas baru dan membuat layanan dengan menggunakan revisi baru.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. **Untuk menggunakan ECS Exec untuk men-debug layanan, di bawah **konfigurasi Pemecahan Masalah, pilih Aktifkan** ECS Exec.**

1. (Opsional) Untuk membantu mengidentifikasi layanan dan tugas Anda, perluas bagian **Tag**, lalu konfigurasikan tag Anda.

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag definisi tugas, pilih **Aktifkan tag terkelola Amazon ECS**, lalu untuk **menyebarkan tag dari**, pilih Definisi tugas.**

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag layanan, pilih **Aktifkan tag terkelola Amazon ECS**, lalu untuk **menyebarkan tag dari**, pilih Layanan.**

   Menambah atau menghapus tanda.
   + [Tambahkan tag] Pilih **Tambah tag**, lalu lakukan hal berikut:
     + Untuk **Kunci**, masukkan nama kunci.
     + Untuk **Nilai**, masukkan nilai kunci.
   + [Menghapus tanda] Di samping tanda, pilih **Hapus tanda**.

1. Pilih **Create** (Buat).

## Langkah selanjutnya
<a name="create-service-next-steps"></a>

Berikut ini adalah tindakan tambahan setelah Anda membuat layanan.
+ Konfigurasikan penskalaan otomatis predicte, yang melihat data pemuatan sebelumnya dari arus lalu lintas. Untuk informasi selengkapnya, lihat [Gunakan pola historis untuk menskalakan layanan Amazon ECS dengan penskalaan prediktif](predictive-auto-scaling.md).
+ Lacak penyebaran Anda dan lihat riwayat layanan Anda untuk layanan yang merupakan pemutus sirkuit Amazon ECS. Untuk informasi selengkapnya, lihat [Melihat riwayat layanan menggunakan deployment layanan Amazon ECS](service-deployment.md).

# Penerapan Amazon ECS blue/green
<a name="deployment-type-blue-green"></a>

 blue/green Penyebaran adalah metodologi rilis yang mengurangi waktu henti dan risiko dengan menjalankan dua lingkungan produksi identik yang disebut biru dan hijau. Dengan blue/green penerapan Amazon ECS, Anda dapat memvalidasi revisi layanan baru sebelum mengarahkan lalu lintas produksi kepada mereka. Pendekatan ini memberikan cara yang lebih aman untuk menerapkan perubahan dengan kemampuan untuk memutar kembali dengan cepat jika diperlukan.

## Manfaat
<a name="blue-green-deployment-benefits"></a>

Berikut ini adalah manfaat menggunakan blue/green penerapan:
+ Mengurangi risiko melalui pengujian dengan lalu lintas produksi sebelum beralih produksi. Anda dapat memvalidasi penerapan baru dengan lalu lintas uji sebelum mengarahkan lalu lintas produksi ke sana.
+ Nol penerapan downtime. Lingkungan produksi tetap tersedia selama proses penyebaran, memastikan ketersediaan layanan berkelanjutan.
+ Rollback mudah jika masalah terdeteksi. Jika masalah muncul dengan penerapan hijau, Anda dapat dengan cepat kembali ke penerapan biru tanpa gangguan layanan yang diperpanjang.
+ Lingkungan pengujian terkendali. Lingkungan hijau menyediakan ruang terisolasi untuk menguji fitur baru dengan pola lalu lintas nyata sebelum penyebaran penuh.
+ Proses penyebaran yang dapat diprediksi. Pendekatan terstruktur dengan tahapan siklus hidup yang ditentukan membuat penerapan lebih konsisten dan andal.
+ Validasi otomatis melalui kait siklus hidup. Anda dapat menerapkan pengujian otomatis pada berbagai tahap penerapan untuk memverifikasi fungsionalitas.

## Terminologi
<a name="blue-green-deployment-terms"></a>

Berikut ini adalah ketentuan blue/green penerapan Amazon ECS:
+ Waktu panggang - Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.
+ Blue deployment - Revisi layanan produksi saat ini yang ingin Anda ganti.
+ Penyebaran hijau - Revisi layanan baru yang ingin Anda terapkan.
+ Tahap siklus hidup - Serangkaian peristiwa dalam operasi penyebaran, seperti “setelah pergeseran lalu lintas produksi”.
+ Lifecycle hook - Fungsi Lambda yang memverifikasi penerapan pada tahap siklus hidup tertentu.
+ Listener - Sumber daya Elastic Load Balancing yang memeriksa permintaan koneksi menggunakan protokol dan port yang Anda konfigurasikan. Aturan yang Anda tetapkan untuk pendengar menentukan cara Amazon ECS merutekan permintaan ke target terdaftarnya.
+ Aturan - Sumber daya Elastic Load Balancing yang terkait dengan pendengar. Aturan mendefinisikan bagaimana permintaan dirutekan dan terdiri dari tindakan, kondisi, dan prioritas.
+ Grup sasaran - Sumber daya Elastic Load Balancing yang digunakan untuk merutekan permintaan ke satu atau lebih target terdaftar (misalnya, instans EC2). Bila Anda membuat pendengar, Anda menentukan grup target untuk tindakan default-nya. Lalu lintas diteruskan ke grup target yang ditentukan dalam aturan pendengar.
+ Pergeseran lalu lintas - Proses yang digunakan Amazon ECS untuk mengalihkan lalu lintas dari penyebaran biru ke penyebaran hijau. Untuk blue/green penyebaran Amazon ECS, semua lalu lintas dialihkan dari layanan biru ke layanan hijau sekaligus.

## Pertimbangan-pertimbangan
<a name="blue-green-deployment-considerations"></a>

Pertimbangkan hal berikut saat memilih jenis penerapan:
+ Penggunaan sumber daya: Blue/green penerapan sementara menjalankan revisi layanan biru dan hijau secara bersamaan, yang dapat menggandakan penggunaan sumber daya Anda selama penerapan.
+ Pemantauan penyebaran: Blue/green penerapan memberikan informasi status penyebaran yang lebih rinci, memungkinkan Anda memantau setiap tahap proses penyebaran.
+ Rollback: Blue/green penerapan memudahkan untuk memutar kembali ke versi sebelumnya jika masalah terdeteksi, karena revisi biru terus berjalan hingga waktu pemanggangan berakhir.
+ Kait siklus hidup Network Load Balancer: Jika Anda menggunakan Network Load Balancer untuk blue/green penerapan, ada tambahan 10 menit untuk tahapan siklus hidup TEST\$1TRAFFIC\$1SHIFT dan PRODUCTION\$1TRAFFIC\$1SHIFT. Ini karena Amazon ECS memastikan bahwa aman untuk mengalihkan lalu lintas.

# Alur kerja penerapan blue/green layanan Amazon ECS
<a name="blue-green-deployment-how-it-works"></a>

Proses blue/green penyebaran Amazon ECS mengikuti pendekatan terstruktur dengan enam fase berbeda yang memastikan pembaruan aplikasi yang aman dan andal. Setiap fase melayani tujuan tertentu dalam memvalidasi dan mentransisikan aplikasi Anda dari versi saat ini (biru) ke versi baru (hijau).

1. **Tahap Persiapan**: Ciptakan lingkungan hijau di samping lingkungan biru yang ada. Ini termasuk penyediaan revisi layanan baru, dan menyiapkan kelompok sasaran.

1. **Fase Deployment**: Menyebarkan revisi layanan baru ke lingkungan hijau. Amazon ECS meluncurkan tugas baru menggunakan revisi layanan yang diperbarui sementara lingkungan biru terus melayani lalu lintas produksi.

1. **Fase Pengujian**: Validasi lingkungan hijau menggunakan perutean lalu lintas uji. Application Load Balancer mengarahkan permintaan pengujian ke lingkungan hijau sementara lalu lintas produksi tetap biru.

1. **Fase Pergeseran Lalu** Lintas: Menggeser lalu lintas produksi dari biru ke hijau berdasarkan strategi penerapan yang dikonfigurasi. Fase ini mencakup pos pemeriksaan pemantauan dan validasi.

1. **Fase Pemantauan**: Pantau kesehatan aplikasi, metrik kinerja, dan status alarm selama periode waktu pemanggangan. Operasi rollback dimulai ketika masalah terdeteksi.

1. **Fase Penyelesaian**: Selesaikan penerapan dengan menghentikan lingkungan biru atau mempertahankannya untuk skenario rollback potensial, tergantung pada konfigurasi Anda.

## Alur kerja
<a name="blue-green-deployment-workflow"></a>

Diagram berikut mengilustrasikan alur kerja blue/green penerapan komprehensif, yang menunjukkan interaksi antara Amazon ECS, dan Application Load Balancer:

![\[Diagram komprehensif yang menunjukkan proses blue/green penyebaran di Amazon ECS dengan interaksi komponen terperinci, fase perpindahan lalu lintas, dan pemantauan pos pemeriksaan\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/images/blue-green.png)


Alur kerja penerapan yang disempurnakan mencakup langkah-langkah rinci berikut:

1. **Keadaan Awal**: Layanan biru (produksi saat ini) menangani 100% lalu lintas produksi. Application Load Balancer memiliki satu pendengar dengan aturan yang merutekan semua permintaan ke grup target biru yang berisi tugas biru sehat.

1. **Penyediaan Lingkungan Hijau**: Amazon ECS membuat tugas baru menggunakan definisi tugas yang diperbarui. Tugas-tugas ini terdaftar dengan kelompok target hijau baru tetapi tidak menerima lalu lintas pada awalnya.

1. **Validasi Pemeriksaan Kesehatan**: Application Load Balancer melakukan pemeriksaan kesehatan pada tugas-tugas hijau. Hanya ketika tugas hijau lulus pemeriksaan kesehatan barulah penerapan dilanjutkan ke fase berikutnya.

1. **Uji Perutean Lalu** Lintas: Jika dikonfigurasi, aturan pendengar Application Load Balancer merutekan pola lalu lintas tertentu (seperti permintaan dengan header pengujian) ke lingkungan hijau untuk validasi sementara lalu lintas produksi tetap berwarna biru. Ini dikendalikan oleh pendengar yang sama yang menangani lalu lintas produksi, menggunakan aturan berbeda berdasarkan atribut permintaan.

1. **Pergeseran Lalu Lintas Produksi**: Berdasarkan konfigurasi penyebaran, lalu lintas bergeser dari biru ke hijau. Dalam blue/green penyebaran ECS, ini adalah pergeseran langsung (all-at-once) di mana 100% lalu lintas dipindahkan dari lingkungan biru ke hijau. Application Load Balancer menggunakan pendengar tunggal dengan aturan pendengar yang mengontrol distribusi lalu lintas antara grup target biru dan hijau berdasarkan bobot.

1. **Pemantauan dan Validasi**: Sepanjang pergeseran lalu lintas, Amazon ECS memantau CloudWatch metrik, status alarm, dan kesehatan penyebaran. Pemicu rollback otomatis diaktifkan jika masalah terdeteksi.

1. **Periode Waktu Panggang**: Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.

1. **Pengakhiran Lingkungan Biru**: Setelah pergeseran lalu lintas dan validasi berhasil, lingkungan biru dihentikan untuk membebaskan sumber daya cluster, atau dipertahankan untuk kemampuan rollback yang cepat.

1. **Keadaan Akhir**: Lingkungan hijau menjadi lingkungan produksi baru, menangani 100% lalu lintas. Penerapan ditandai sebagai berhasil.

## Tahapan siklus hidup penerapan
<a name="blue-green-deployment-stages"></a>

Proses blue/green penyebaran berlangsung melalui tahapan siklus hidup yang berbeda (serangkaian peristiwa dalam operasi penyebaran, seperti “setelah pergeseran lalu lintas produksi”), masing-masing dengan tanggung jawab khusus dan pos pemeriksaan validasi. Memahami tahapan ini membantu Anda memantau kemajuan penerapan dan memecahkan masalah secara efektif.

 Setiap tahap siklus hidup dapat bertahan hingga 24 jam. Kami menyarankan agar nilainya tetap di bawah tanda 24 jam. Ini karena proses asinkron membutuhkan waktu untuk memicu kait. Waktu sistem habis, gagal penerapan, dan kemudian memulai rollback setelah tahap mencapai 24 jam. CloudFormation penerapan memiliki batasan batas waktu tambahan. Sementara batas tahap 24 jam tetap berlaku, CloudFormation memberlakukan batas 36 jam pada seluruh penyebaran. CloudFormation gagal penerapan, dan kemudian memulai rollback jika proses tidak selesai dalam waktu 36 jam.


| Tahapan siklus hidup | Deskripsi | Gunakan tahap ini untuk pengait siklus hidup? | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Tahap ini hanya terjadi ketika Anda memulai penyebaran layanan baru dengan lebih dari 1 revisi layanan dalam status AKTIF. | Ya | 
| PRE\$1SCALE\$1UP | Revisi layanan hijau belum dimulai. Revisi layanan biru menangani 100% lalu lintas produksi. Tidak ada lalu lintas uji. | Ya | 
| SKALA\$1UP | Waktu ketika revisi layanan hijau menskalakan hingga 100% dan meluncurkan tugas baru. Revisi layanan hijau tidak melayani lalu lintas apa pun pada saat ini. | Tidak | 
| POST\$1SCALE\$1UP | Revisi layanan hijau telah dimulai. Revisi layanan biru menangani 100% lalu lintas produksi. Tidak ada lalu lintas uji. | Ya | 
| TEST\$1TRAFFIC\$1SHIFT | Revisi layanan biru dan hijau sedang berjalan. Revisi layanan biru menangani 100% lalu lintas produksi. Revisi layanan hijau bermigrasi dari 0% ke 100% lalu lintas pengujian. | Ya | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Pergeseran lalu lintas uji selesai. Revisi layanan hijau menangani 100% lalu lintas pengujian. | Ya | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | Lalu lintas produksi bergeser ke revisi layanan hijau. Revisi layanan hijau bermigrasi dari 0% menjadi 100% dari lalu lintas produksi. | Ya | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Pergeseran lalu lintas produksi selesai. | Ya | 
| BAKE\$1WAKTU | Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan. | Tidak | 
| MEMBERSIHKAN\$1UP | Revisi layanan biru telah sepenuhnya diperkecil menjadi 0 tugas yang berjalan. Revisi layanan hijau sekarang menjadi revisi layanan produksi setelah tahap ini. | Tidak | 

Setiap tahap siklus hidup mencakup pos pemeriksaan validasi bawaan yang harus diteruskan sebelum melanjutkan ke tahap berikutnya. Jika ada validasi yang gagal, penerapan dapat secara otomatis digulirkan kembali untuk menjaga ketersediaan dan keandalan layanan.

Saat Anda menggunakan fungsi Lambda, fungsi tersebut harus menyelesaikan pekerjaan, atau mengembalikan IN\$1PROGRESS dalam waktu 15 menit. Anda dapat menggunakan `callBackDelaySeconds` untuk menunda panggilan ke Lambda. Untuk informasi selengkapnya, lihat [fungsi app.py](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25) di sample-amazon-ecs-blue - green-deployment-patterns on GitHub.

# Sumber daya yang diperlukan untuk penerapan Amazon ECS blue/green
<a name="blue-green-deployment-implementation"></a>

Untuk menggunakan blue/green penyebaran dengan pemindahan lalu lintas terkelola, layanan Anda harus menggunakan salah satu fitur berikut:
+ Elastic Load Balancing
+ Service Connect

Layanan yang tidak menggunakan Service Discovery, Service Connect, VPC Lattice atau Elastic Load Balancing juga dapat blue/green menggunakan penerapan, tetapi tidak mendapatkan manfaat pemindahan lalu lintas terkelola.

Daftar berikut memberikan ikhtisar tingkat tinggi tentang apa yang perlu Anda konfigurasi untuk penerapan Amazon ECS blue/green :
+ Layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect. Konfigurasikan sumber daya yang sesuai.
  + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
  + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)
  + Service Connect - Untuk informasi selengkapnya, lihat[Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary](service-connect-blue-green.md).
+ Setel pengontrol penyebaran layanan ke`ECS`.
+ Konfigurasikan strategi penerapan seperti `blue/green` dalam definisi layanan Anda.
+ Secara opsional, konfigurasikan parameter tambahan seperti:
  + Waktu panggang untuk penerapan baru
  + CloudWatch alarm untuk rollback otomatis
  + Kait siklus hidup penerapan untuk pengujian (ini adalah fungsi Lambda yang berjalan pada tahap penerapan tertentu)

## Praktik terbaik
<a name="blue-green-deployment-best-practices"></a>

Ikuti praktik terbaik berikut untuk penerapan Amazon ECS blue/green yang sukses:
+ Konfigurasikan pemeriksaan kesehatan yang sesuai yang secara akurat mencerminkan kesehatan aplikasi Anda.
+ Tetapkan waktu pemanggangan yang memungkinkan pengujian penerapan hijau yang memadai.
+ Menerapkan CloudWatch alarm untuk secara otomatis mendeteksi masalah dan memicu rollback.
+ Gunakan kait siklus hidup untuk melakukan pengujian otomatis pada setiap tahap penerapan.
+ Pastikan aplikasi Anda dapat menangani revisi layanan biru dan hijau yang berjalan secara bersamaan.
+ Rencanakan kapasitas cluster yang memadai untuk menangani kedua revisi layanan selama penerapan.
+ Uji prosedur rollback Anda sebelum menerapkannya dalam produksi.

# Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari
<a name="alb-resources-for-blue-green"></a>

Untuk menggunakan Application Load Balancers dengan blue/green penerapan Amazon ECS, Anda perlu mengonfigurasi sumber daya tertentu yang memungkinkan perutean lalu lintas antara revisi layanan biru dan hijau. 

## Kelompok-kelompok target
<a name="alb-target-groups"></a>

Untuk blue/green penerapan dengan Elastic Load Balancing, Anda perlu membuat dua grup target:
+ Kelompok sasaran utama untuk revisi layanan biru (lalu lintas produksi saat ini)
+ Grup target alternatif untuk revisi layanan hijau (versi baru)

Kedua grup target harus dikonfigurasi dengan pengaturan berikut:
+ Jenis target: `IP` (untuk Fargate atau EC2 dengan `awsvpc` mode jaringan)
+ Protokol: `HTTP` (atau protokol yang digunakan aplikasi Anda)
+ Port: Port yang didengarkan aplikasi Anda (biasanya `80` untuk HTTP)
+ VPC: VPC yang sama dengan tugas Amazon ECS Anda
+ Pengaturan pemeriksaan Kesehatan: Dikonfigurasi untuk memeriksa kesehatan aplikasi Anda dengan benar

Selama blue/green penerapan, Amazon ECS secara otomatis mendaftarkan tugas dengan grup target yang sesuai berdasarkan tahap penerapan.

**Example Membuat grup target untuk Application Load Balancer**  
Perintah CLI berikut membuat dua kelompok target untuk digunakan dengan Application Load Balancer dalam penerapan: blue/green   

```
aws elbv2 create-target-group \
    --name blue-target-group \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-path / \
    --health-check-protocol HTTP \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2

aws elbv2 create-target-group \
    --name green-target-group \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-path / \
    --health-check-protocol HTTP \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2
```

## Penyeimbang Beban Aplikasi
<a name="alb-load-balancer"></a>

Anda perlu membuat Application Load Balancer dengan konfigurasi berikut:
+ Skema: Menghadapi internet atau internal, tergantung pada kebutuhan Anda
+ Jenis alamat IP: IPv4
+ VPC: VPC yang sama dengan tugas Amazon ECS Anda
+ Subnet: Setidaknya dua subnet di Availability Zone yang berbeda
+ Grup keamanan: Grup keamanan yang memungkinkan lalu lintas di port pendengar

Grup keamanan yang dilampirkan pada Application Load Balancer harus memiliki aturan keluar yang memungkinkan lalu lintas ke grup keamanan yang dilampirkan ke tugas Amazon ECS Anda.

**Example Membuat Application Load Balancer**  
Perintah CLI berikut membuat Load Balancer Aplikasi untuk digunakan dalam penerapan biru/hijau:  

```
aws elbv2 create-load-balancer \
    --name my-application-load-balancer \
    --type application \
    --security-groups sg-abcd1234 \
    --subnets subnet-12345678 subnet-87654321
```

## Pendengar dan aturan
<a name="alb-listeners"></a>

Untuk blue/green penerapan, Anda perlu mengonfigurasi listener di Application Load Balancer Anda:
+ Pendengar produksi: Menangani lalu lintas produksi (biasanya di port 80 atau 443)
  + Awalnya meneruskan lalu lintas ke kelompok sasaran utama (revisi layanan biru)
  + Setelah penyebaran, teruskan lalu lintas ke grup target alternatif (revisi layanan hijau)
+ Uji pendengar (opsional): Menangani lalu lintas pengujian untuk memvalidasi revisi layanan hijau sebelum mengalihkan lalu lintas produksi
  + Dapat dikonfigurasi pada port yang berbeda (misalnya, 8080 atau 8443)
  + Meneruskan lalu lintas ke kelompok sasaran alternatif (revisi layanan hijau) selama pengujian

Selama blue/green penerapan, Amazon ECS secara otomatis memperbarui aturan pendengar untuk merutekan lalu lintas ke grup target yang sesuai berdasarkan tahap penerapan.

**Example Membuat pendengar produksi**  
Perintah CLI berikut membuat pendengar produksi pada port 80 yang meneruskan lalu lintas ke grup target utama (biru):  

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456
```

**Example Membuat pendengar tes**  
Perintah CLI berikut membuat pendengar pengujian pada port 8080 yang meneruskan lalu lintas ke grup target alternatif (hijau):  

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \
    --protocol HTTP \
    --port 8080 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

**Example Membuat aturan pendengar untuk perutean berbasis jalur**  
Perintah CLI berikut membuat aturan yang meneruskan lalu lintas untuk jalur tertentu ke grup target hijau untuk pengujian:  

```
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \
    --priority 10 \
    --conditions Field=path-pattern,Values='/test/*' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

**Example Membuat aturan pendengar untuk perutean berbasis header**  
Perintah CLI berikut membuat aturan yang meneruskan lalu lintas dengan header tertentu ke grup target hijau untuk pengujian:  

```
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \
    --priority 20 \
    --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

## Konfigurasi layanan
<a name="alb-service-configuration"></a>

Anda harus memiliki izin untuk mengizinkan Amazon ECS mengelola sumber daya penyeimbang beban di klaster atas nama Anda. Untuk informasi selengkapnya, lihat [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). 

Saat membuat atau memperbarui layanan Amazon ECS untuk blue/green penerapan dengan Elastic Load Balancing, Anda perlu menentukan konfigurasi berikut.

Ganti *user-input* dengan nilai-nilai Anda.

Komponen kunci dalam konfigurasi ini adalah:
+ `targetGroupArn`: ARN dari kelompok sasaran utama (revisi layanan biru).
+ `alternateTargetGroupArn`: ARN dari kelompok sasaran alternatif (revisi layanan hijau).
+ `productionListenerRule`: ARN dari aturan pendengar untuk lalu lintas produksi.
+ `roleArn`: ARN dari peran yang memungkinkan Amazon ECS mengelola sumber daya Elastic Load Balancing.
+ `strategy`: Setel `BLUE_GREEN` untuk mengaktifkan penerapan biru/hijau.
+ `bakeTimeInMinutes`: Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.
+ `TestListenerRule`: ARN dari aturan pendengar untuk lalu lintas uji. Ini adalah parameter opsional.

```
{
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456",
            "containerName": "container-name",
            "containerPort": 80,
            "advancedConfiguration": {
                "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012",
                "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678",
                "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role"
            }
        }
    ],
    "deploymentConfiguration": {
        "strategy": "BLUE_GREEN",
        "maximumPercent": 200,
        "minimumHealthyPercent": 100,
        "bakeTimeInMinutes": 5
    }
}
```

## Arus lalu lintas selama penyebaran
<a name="alb-traffic-flow"></a>

Selama blue/green penyebaran dengan Elastic Load Balancing, lalu lintas mengalir melalui sistem sebagai berikut:

1. *Status awal*: Semua lalu lintas produksi diarahkan ke kelompok sasaran utama (revisi layanan biru).

1. *Penyebaran revisi layanan hijau*: Amazon ECS menyebarkan tugas baru dan mendaftarkannya ke grup target alternatif.

1. *Lalu lintas pengujian*: Jika pendengar pengujian dikonfigurasi, lalu lintas pengujian dirutekan ke grup target alternatif untuk memvalidasi revisi layanan hijau.

1. *Pergeseran lalu lintas produksi*: Amazon ECS memperbarui aturan pendengar produksi untuk merutekan lalu lintas ke grup target alternatif (revisi layanan hijau).

1. *Waktu memanggang*: Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.

1. *Penyelesaian*: Setelah penerapan berhasil, revisi layanan biru dihentikan.

Jika masalah terdeteksi selama penerapan, Amazon ECS dapat secara otomatis memutar kembali dengan merutekan lalu lintas kembali ke grup target utama (revisi layanan biru).

# Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari
<a name="nlb-resources-for-blue-green"></a>

Untuk menggunakan Network Load Balancer dengan blue/green penerapan Amazon ECS, Anda perlu mengonfigurasi sumber daya tertentu yang memungkinkan perutean lalu lintas antara revisi layanan biru dan hijau. Bagian ini menjelaskan komponen yang diperlukan dan konfigurasinya.

Jika konfigurasi Anda menyertakan Network Load Balancer, Amazon ECS menambahkan penundaan 10 menit ke tahapan siklus hidup berikut:
+ TEST\$1TRAFFIC\$1SHIFT
+ PRODUCTION\$1TRAFFIC\$1SHIFT

Penundaan ini menyebabkan masalah waktu Network Load Balancer yang dapat menyebabkan ketidakcocokan antara bobot lalu lintas yang dikonfigurasi dan perutean lalu lintas aktual di bidang data. 

## Kelompok-kelompok target
<a name="nlb-target-groups"></a>

Untuk blue/green penerapan dengan Network Load Balancer, Anda perlu membuat dua grup target:
+ Kelompok sasaran utama untuk revisi layanan biru (lalu lintas produksi saat ini)
+ Kelompok sasaran alternatif untuk revisi layanan hijau (revisi layanan baru)

Kedua grup target harus dikonfigurasi dengan pengaturan berikut:
+ Jenis target: `ip` (untuk Fargate atau EC2 dengan `awsvpc` mode jaringan)
+ Protokol: `TCP` (atau protokol yang digunakan aplikasi Anda)
+ Port: Port yang didengarkan aplikasi Anda (biasanya `80` untuk HTTP)
+ VPC: VPC yang sama dengan tugas Amazon ECS Anda
+ Pengaturan pemeriksaan Kesehatan: Dikonfigurasi untuk memeriksa kesehatan aplikasi Anda dengan benar

  Untuk pemeriksaan kesehatan TCP, Network Load Balancer membuat koneksi TCP dengan target. Jika koneksi berhasil, target dianggap sehat.

  Untuk pemeriksaan HTTP/HTTPS kesehatan, Network Load Balancer mengirimkan HTTP/HTTPS permintaan ke target dan memverifikasi respons.

Selama blue/green penerapan, Amazon ECS secara otomatis mendaftarkan tugas dengan grup target yang sesuai berdasarkan tahap penerapan.

**Example Membuat grup target untuk Network Load Balancer**  
Perintah AWS CLI berikut membuat dua grup target untuk digunakan dengan Network Load Balancer dalam penerapan: blue/green   

```
aws elbv2 create-target-group \
    --name blue-target-group \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-protocol TCP

aws elbv2 create-target-group \
    --name green-target-group \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-protocol TCP
```

## Penyeimbang Beban Jaringan
<a name="nlb-load-balancer"></a>

Anda perlu membuat Network Load Balancer dengan konfigurasi berikut:
+ Skema: Menghadapi internet atau internal, tergantung pada kebutuhan Anda
+ Jenis alamat IP: IPv4
+ VPC: VPC yang sama dengan tugas Amazon ECS Anda
+ Subnet: Setidaknya dua subnet di Availability Zone yang berbeda

Tidak seperti Application Load Balancer, Network Load Balancer beroperasi pada lapisan transport (Layer 4) dan tidak menggunakan grup keamanan. Sebagai gantinya, Anda perlu memastikan bahwa grup keamanan yang terkait dengan tugas Amazon ECS Anda mengizinkan lalu lintas dari Network Load Balancer pada port listener.

**Example Membuat Network Load Balancer**  
Perintah AWS CLI berikut membuat Network Load Balancer untuk digunakan dalam penerapan: blue/green   

```
aws elbv2 create-load-balancer \
    --name my-network-load-balancer \
    --type network \
    --subnets subnet-12345678 subnet-87654321
```

## Pertimbangan untuk menggunakan NLB dengan penerapan blue/green
<a name="nlb-considerations"></a>

Saat menggunakan Network Load Balancer untuk blue/green penerapan, pertimbangkan hal berikut:
+ **Operasi Layer 4**: Network Load Balancer beroperasi pada lapisan transport (Layer 4) dan tidak memeriksa konten layer aplikasi (Layer 7). Ini berarti Anda tidak dapat menggunakan header atau jalur HTTP untuk keputusan perutean.
+ **Pemeriksaan kesehatan: Pemeriksaan kesehatan** Network Load Balancer terbatas pada protokol TCP, HTTP, atau HTTPS. Untuk pemeriksaan kesehatan TCP, Network Load Balancer hanya memverifikasi bahwa koneksi dapat dibuat.
+ **Pelestarian koneksi**: Network Load Balancers mempertahankan alamat IP sumber klien, yang dapat berguna untuk tujuan keamanan dan pencatatan.
+ **Alamat IP statis**: Network Load Balancer menyediakan alamat IP statis untuk setiap subnet, yang dapat berguna untuk daftar putih atau ketika klien perlu terhubung ke alamat IP tetap.
+ **Lalu lintas uji**: Karena Network Load Balancer tidak mendukung routing berbasis konten, lalu lintas uji harus dikirim ke port yang berbeda dari lalu lintas produksi.

## Pendengar dan aturan
<a name="nlb-listeners"></a>

Untuk blue/green penerapan dengan Network Load Balancer, Anda perlu mengonfigurasi listener:
+ Pendengar produksi: Menangani lalu lintas produksi (biasanya di port 80 atau 443)
  + Awalnya meneruskan lalu lintas ke kelompok sasaran utama (revisi layanan biru)
  + Setelah penyebaran, teruskan lalu lintas ke grup target alternatif (revisi layanan hijau)
+ Uji pendengar (opsional): Menangani lalu lintas pengujian untuk memvalidasi revisi layanan hijau sebelum mengalihkan lalu lintas produksi
  + Dapat dikonfigurasi pada port yang berbeda (misalnya, 8080 atau 8443)
  + Meneruskan lalu lintas ke kelompok sasaran alternatif (revisi layanan hijau) selama pengujian

Tidak seperti Application Load Balancer, Network Load Balancer tidak mendukung aturan routing berbasis konten. Sebaliknya, lalu lintas dirutekan berdasarkan port dan protokol pendengar.

Perintah AWS CLI berikut membuat pendengar produksi dan pengujian untuk Network Load Balancer:

Ganti *user-input* dengan nilai-nilai Anda.

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \
    --protocol TCP \
    --port 80 \
    --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456

aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \
    --protocol TCP \
    --port 8080 \
    --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456
```

## Konfigurasi layanan
<a name="nlb-service-configuration"></a>

Anda harus memiliki izin untuk mengizinkan Amazon ECS mengelola sumber daya penyeimbang beban di klaster atas nama Anda. Untuk informasi selengkapnya, lihat [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). 

Saat membuat atau memperbarui layanan Amazon ECS untuk blue/green penerapan dengan Network Load Balancer, Anda perlu menentukan konfigurasi berikut:

Ganti *user-input* dengan nilai-nilai Anda.

Komponen kunci dalam konfigurasi ini adalah:
+ `targetGroupArn`: ARN dari kelompok sasaran utama (revisi layanan biru)
+ `alternateTargetGroupArn`: ARN dari kelompok sasaran alternatif (revisi layanan hijau)
+ `productionListenerRule`: ARN pendengar untuk lalu lintas produksi
+ `testListenerRule`: (Opsional) ARN pendengar untuk lalu lintas uji
+ `roleArn`: ARN dari peran yang memungkinkan Amazon ECS mengelola sumber daya Network Load Balancer
+ `strategy`: Setel `BLUE_GREEN` untuk mengaktifkan blue/green penerapan
+ `bakeTimeInMinutes`: Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser

```
{
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456",
            "containerName": "container-name",
            "containerPort": 80,
            "advancedConfiguration": {
                "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456",
                "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456",
                "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567",
                "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role"
            }
        }
    ],
    "deploymentConfiguration": {
        "strategy": "BLUE_GREEN",
        "maximumPercent": 200,
        "minimumHealthyPercent": 100,
        "bakeTimeInMinutes": 5
    }
}
```

## Arus lalu lintas selama penyebaran
<a name="nlb-traffic-flow"></a>

Selama blue/green penyebaran dengan Network Load Balancer, lalu lintas mengalir melalui sistem sebagai berikut:

1. *Status awal*: Semua lalu lintas produksi diarahkan ke kelompok sasaran utama (revisi layanan biru).

1. *Penyebaran revisi layanan hijau*: Amazon ECS menyebarkan tugas baru dan mendaftarkannya ke grup target alternatif.

1. *Lalu lintas pengujian*: Jika pendengar pengujian dikonfigurasi, lalu lintas pengujian dirutekan ke grup target alternatif untuk memvalidasi revisi layanan hijau.

1. *Pergeseran lalu lintas produksi*: Amazon ECS memperbarui pendengar produksi untuk merutekan lalu lintas ke grup target alternatif (revisi layanan hijau).

1. *Waktu memanggang*: Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.

1. *Penyelesaian*: Setelah penerapan berhasil, revisi layanan biru dihentikan.

Jika masalah terdeteksi selama penerapan, Amazon ECS dapat secara otomatis memutar kembali dengan merutekan lalu lintas kembali ke grup target utama (revisi layanan biru).

# Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary
<a name="service-connect-blue-green"></a>

Saat menggunakan Service Connect dengan blue/green penerapan, Anda perlu mengonfigurasi komponen tertentu untuk mengaktifkan perutean lalu lintas yang tepat antara revisi layanan biru dan hijau. Bagian ini menjelaskan komponen yang diperlukan dan konfigurasinya.

## Gambaran umum arsitektur
<a name="service-connect-blue-green-architecture"></a>

Service Connect membangun kemampuan service discovery dan service mesh melalui proxy sespan terkelola yang secara otomatis disuntikkan ke tugas Amazon ECS Anda. Proksi ini menangani keputusan perutean, percobaan ulang, dan pengumpulan metrik, sambil AWS Cloud Map menyediakan backend registri layanan. Saat Anda menerapkan layanan dengan Service Connect diaktifkan, layanan akan mendaftarkan dirinya sendiri AWS Cloud Map, dan layanan klien menemukannya melalui namespace.

Dalam implementasi Service Connect standar, layanan klien terhubung ke nama layanan logis, dan proxy sidecar menangani perutean ke instance layanan yang sebenarnya. Dengan blue/green penerapan, model ini diperluas untuk menyertakan perutean lalu lintas uji melalui konfigurasi. `testTrafficRules`

Selama blue/green penerapan, komponen kunci berikut bekerja sama:
+ **Service Connect Proxy**: Semua lalu lintas antar layanan melewati proxy Service Connect, yang membuat keputusan perutean berdasarkan konfigurasi.
+ **AWS Cloud Map Pendaftaran**: Penerapan biru dan hijau mendaftar AWS Cloud Map, tetapi penerapan hijau awalnya terdaftar sebagai titik akhir “uji”.
+ **Uji Perutean Lalu** Lintas: Konfigurasi `testTrafficRules` dalam Service Connect menentukan cara mengidentifikasi dan merutekan lalu lintas pengujian ke penerapan hijau. Hal ini dicapai melalui **routing berbasis header**, di mana header HTTP tertentu dalam permintaan mengarahkan lalu lintas ke revisi pengujian. Secara default, Service Connect mengenali `x-amzn-ecs-blue-green-test` header untuk protokol berbasis HTTP ketika tidak ada aturan khusus yang ditentukan.
+ **Konfigurasi Klien**: Semua klien di namespace secara otomatis menerima rute produksi dan pengujian, tetapi hanya permintaan yang cocok dengan aturan pengujian yang akan masuk ke penerapan hijau.

Apa yang membuat pendekatan ini kuat adalah menangani kompleksitas penemuan layanan selama transisi. Saat lalu lintas bergeser dari penyebaran biru ke hijau, semua konektivitas dan mekanisme penemuan diperbarui secara otomatis. Tidak perlu memperbarui catatan DNS, mengkonfigurasi ulang penyeimbang beban, atau menerapkan perubahan penemuan layanan secara terpisah karena mesh layanan menangani semuanya.

## Perutean dan pengujian lalu lintas
<a name="service-connect-blue-green-traffic-routing"></a>

Service Connect menyediakan kemampuan perutean lalu lintas tingkat lanjut untuk blue/green penerapan, termasuk routing berbasis header dan konfigurasi alias klien untuk skenario pengujian.

### Uji aturan header lalu lintas
<a name="service-connect-test-traffic-header-rules"></a>

Selama blue/green penerapan, Anda dapat mengonfigurasi aturan header lalu lintas pengujian untuk merutekan permintaan tertentu ke revisi layanan hijau (baru) untuk tujuan pengujian. Ini memungkinkan Anda untuk memvalidasi versi baru dengan lalu lintas terkontrol sebelum menyelesaikan penerapan.

Service Connect menggunakan **perutean berbasis header** untuk mengidentifikasi lalu lintas pengujian. Secara default, Service Connect mengenali `x-amzn-ecs-blue-green-test` header untuk protokol berbasis HTTP ketika tidak ada aturan khusus yang ditentukan. Ketika header ini hadir dalam permintaan, proxy Service Connect secara otomatis merutekan permintaan ke penerapan hijau untuk pengujian.

Aturan header lalu lintas pengujian memungkinkan Anda untuk:
+ Mengarahkan permintaan dengan header khusus ke revisi layanan green
+ Menguji fungsionalitas baru dengan subset lalu lintas
+ Memvalidasi perilaku layanan sebelum cutover lalu lintas penuh
+ Mengimplementasikan strategi pengujian canary
+ Lakukan pengujian integrasi dalam lingkungan seperti produksi

Mekanisme routing berbasis header bekerja mulus dengan arsitektur aplikasi yang ada. Layanan klien tidak perlu mengetahui proses blue/green penerapan - mereka hanya menyertakan header yang sesuai saat mengirim permintaan pengujian, dan proxy Service Connect menangani logika perutean secara otomatis.

Untuk informasi selengkapnya tentang mengonfigurasi aturan header lalu lintas pengujian, lihat [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html)di *Referensi API Amazon Elastic Container Service*.

### Aturan pencocokan header
<a name="service-connect-header-match-rules"></a>

Aturan pencocokan header menentukan kriteria untuk merutekan lalu lintas pengujian selama blue/green penerapan. Anda dapat mengonfigurasi beberapa kondisi pencocokan untuk mengontrol secara persis permintaan mana yang diarahkan ke revisi layanan green.

Pencocokan header mendukung:
+ Pencocokan nilai header secara persis
+ Pemeriksaan keberadaan header
+ Pencocokan berbasis pola
+ Beberapa kombinasi header

Contoh kasus penggunaannya adalah mengarahkan permintaan dengan string agen pengguna tertentu, versi API, atau penanda fitur ke layanan green untuk pengujian.

Untuk informasi selengkapnya tentang konfigurasi pencocokan header, lihat [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html)di *Referensi API Amazon Elastic Container Service*.

### Alias klien untuk penerapan blue/green
<a name="service-connect-client-alias-blue-green"></a>

Alias klien menyediakan titik akhir DNS yang stabil untuk layanan selama penerapan. blue/green Mereka memungkinkan perutean lalu lintas yang mulus antara revisi layanan biru dan hijau tanpa memerlukan aplikasi klien untuk mengubah titik akhir koneksi mereka.

Selama blue/green penerapan, alias klien:
+ Pertahankan nama DNS yang konsisten untuk koneksi klien
+ Aktifkan peralihan lalu lintas otomatis antara revisi layanan
+ Mendukung strategi migrasi lalu lintas bertahap
+ Memberikan kemampuan rollback dengan mengarahkan lalu lintas ke revisi biru

Anda dapat mengonfigurasi beberapa alias klien untuk port atau protokol yang berbeda, memungkinkan arsitektur layanan yang kompleks untuk mempertahankan konektivitas selama penerapan.

Untuk informasi selengkapnya tentang konfigurasi alias klien, lihat [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html)di *Referensi API Amazon Elastic Container Service*.

### Praktik terbaik untuk perutean lalu lintas
<a name="service-connect-blue-green-best-practices"></a>

Saat menerapkan perutean lalu lintas untuk blue/green penerapan dengan Service Connect, pertimbangkan praktik terbaik berikut:
+ **Mulailah dengan pengujian berbasis header**: Gunakan aturan header lalu lintas pengujian untuk memvalidasi layanan green dengan lalu lintas terkontrol sebelum mengalihkan semua lalu lintas.
+ **Konfigurasikan pemeriksaan kesehatan**: Pastikan layanan biru dan hijau memiliki pemeriksaan kesehatan yang sesuai yang dikonfigurasi untuk mencegah lalu lintas perutean ke instance yang tidak sehat.
+ **Pantau metrik layanan**: Lacak indikator performa utama untuk kedua revisi layanan selama deployment untuk mengidentifikasi masalah sejak awal.
+ **Strategi rollback rencana**: Konfigurasikan alias klien dan aturan perutean untuk mengaktifkan rollback cepat ke layanan biru jika masalah terdeteksi.
+ **Uji logika pencocokan header**: Lakukan validasi aturan pencocokan header Anda di lingkungan nonproduksi sebelum menerapkannya ke deployment produksi.

## Alur kerja blue/green penerapan Service Connect
<a name="service-connect-blue-green-workflow"></a>

Memahami cara Service Connect mengelola proses blue/green penerapan membantu Anda menerapkan dan memecahkan masalah penerapan secara efektif. Alur kerja berikut menunjukkan bagaimana komponen yang berbeda berinteraksi selama setiap fase penerapan.

### Fase penyebaran
<a name="service-connect-deployment-phases"></a>

 blue/green Penerapan Service Connect berlangsung melalui beberapa fase berbeda:

1. **Keadaan Awal**: Layanan biru menangani 100% lalu lintas produksi. Semua layanan klien di namespace terhubung ke layanan biru melalui nama layanan logis yang dikonfigurasi di Service Connect.

1. **Registrasi Layanan Hijau**: Ketika penerapan hijau dimulai, ia mendaftar AWS Cloud Map sebagai titik akhir “uji”. Proxy Service Connect di layanan klien secara otomatis menerima konfigurasi rute produksi dan pengujian.

1. **Uji Perutean Lalu Lintas**: Permintaan yang berisi header lalu lintas pengujian (seperti`x-amzn-ecs-blue-green-test`) secara otomatis dirutekan ke layanan hijau oleh proxy Service Connect. Lalu lintas produksi terus mengalir ke layanan biru.

1. **Persiapan Pergeseran Lalu** Lintas: Setelah pengujian berhasil, proses penyebaran mempersiapkan pergeseran lalu lintas produksi. Layanan biru dan hijau tetap terdaftar dan sehat.

1. **Production Traffic Shift**: Konfigurasi Service Connect memperbarui untuk merutekan lalu lintas produksi ke layanan hijau. Ini terjadi secara otomatis tanpa memerlukan pembaruan layanan klien atau perubahan DNS.

1. **Periode Waktu Panggang**: Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.

1. **Deregistrasi Layanan Biru**: Setelah pergeseran lalu lintas dan validasi berhasil, layanan biru dideregistrasi dari dan dihentikan, menyelesaikan penerapan. AWS Cloud Map 

### Perilaku proxy Service Connect
<a name="service-connect-proxy-behavior"></a>

Proxy Service Connect memainkan peran penting dalam mengelola lalu lintas selama blue/green penerapan. Memahami perilakunya membantu Anda merancang strategi pengujian dan penerapan yang efektif.

Perilaku proxy kunci selama blue/green penerapan:
+ **Penemuan Rute Otomatis**: Proxy secara otomatis menemukan rute produksi dan pengujian dari AWS Cloud Map tanpa memerlukan restart aplikasi atau perubahan konfigurasi.
+ **Perutean Berbasis Header**: Proxy memeriksa header permintaan masuk dan merutekan lalu lintas ke revisi layanan yang sesuai berdasarkan aturan lalu lintas pengujian yang dikonfigurasi.
+ **Integrasi Pemeriksaan Kesehatan**: Proxy hanya mengarahkan lalu lintas ke instance layanan sehat, secara otomatis mengecualikan tugas yang tidak sehat dari kumpulan perutean.
+ **Coba lagi dan Pemutusan Sirkuit**: Proxy menyediakan logika coba ulang bawaan dan kemampuan pemutusan sirkuit, meningkatkan ketahanan selama penerapan.
+ **Koleksi Metrik**: Proxy mengumpulkan metrik terperinci untuk layanan biru dan hijau, memungkinkan pemantauan komprehensif selama penerapan.

### Pembaruan penemuan layanan
<a name="service-connect-service-discovery-updates"></a>

Salah satu keuntungan utama menggunakan Service Connect untuk blue/green penerapan adalah penanganan otomatis pembaruan penemuan layanan. blue/green Penerapan tradisional seringkali memerlukan pembaruan DNS yang kompleks atau konfigurasi ulang penyeimbang beban, tetapi Service Connect mengelola perubahan ini secara transparan.

Selama penerapan, Service Connect menangani:
+ **Pembaruan Namespace**: Namespace Service Connect secara otomatis menyertakan titik akhir layanan biru dan hijau, dengan aturan perutean yang sesuai.
+ **Konfigurasi Klien**: Semua layanan klien di namespace secara otomatis menerima informasi perutean yang diperbarui tanpa memerlukan restart atau pemindahan.
+ **Transisi Bertahap**: Pembaruan penemuan layanan terjadi secara bertahap dan aman, memastikan tidak ada gangguan pada permintaan yang sedang berlangsung.
+ **Rollback Support**: Jika rollback diperlukan, Service Connect dapat dengan cepat mengembalikan konfigurasi penemuan layanan untuk mengarahkan lalu lintas kembali ke layanan biru.

# Membuat penyebaran Amazon ECS blue/green
<a name="deploy-blue-green-service"></a>

 Dengan menggunakan blue/green penerapan Amazon ECS, Anda dapat membuat dan menguji perubahan layanan sebelum menerapkannya di lingkungan produksi. 

## Prasyarat
<a name="deploy-blue-green-service-prerequisites"></a>

Lakukan operasi berikut sebelum Anda memulai blue/green penerapan. 

1. Konfigurasikan izin yang sesuai.
   + Untuk informasi tentang izin Elastic Load Balancing, lihat. [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)
   + Untuk informasi tentang izin Lambda, lihat [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md)

1.  blue/green Penerapan Amazon ECS mengharuskan layanan Anda menggunakan salah satu fitur berikut: Konfigurasikan sumber daya yang sesuai.
   + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
   + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)
   + Service Connect - Untuk informasi selengkapnya, lihat[Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary](service-connect-blue-green.md).

1. Putuskan apakah Anda ingin menjalankan fungsi Lambda untuk tahapan siklus hidup.
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + TEST\$1TRAFFIC\$1SHIFT
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

   Untuk informasi selengkapnya, lihat [Membuat fungsi Lambda dengan konsol di Panduan AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) *Pengembang*.

## Prosedur
<a name="deploy-blue-green-service-procedure"></a>

Anda dapat menggunakan konsol atau AWS CLI untuk membuat blue/green layanan Amazon ECS.

------
#### [ Console ]

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Tentukan sumber daya dari tempat Anda meluncurkan layanan.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

   Halaman **Create service** ditampilkan.

1. Di bawah **rincian Layanan**, lakukan hal berikut:

   1. Untuk **keluarga definisi Tugas**, pilih definisi tugas yang akan digunakan. Kemudian, untuk **revisi definisi Tugas**, masukkan revisi yang akan digunakan.

   1. Untuk **nama Layanan**, masukkan nama untuk layanan Anda.

1. Untuk menjalankan layanan di klaster yang ada, untuk **klaster yang ada**, pilih klaster. Untuk menjalankan layanan di klaster baru, pilih **Buat klaster** 

1. Pilih bagaimana tugas Anda didistribusikan di seluruh infrastruktur klaster Anda. Di bawah **Konfigurasi komputasi**, pilih opsi Anda.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. Di bawah **konfigurasi Deployment**, lakukan hal berikut:

   1. Untuk **jenis Layanan**, pilih **Replika.**

   1. Untuk **tugas yang diinginkan**, masukkan jumlah tugas untuk diluncurkan dan dipelihara dalam layanan.

   1. **Agar Amazon ECS memantau distribusi tugas di seluruh Availability Zone, dan mendistribusikannya kembali saat terjadi ketidakseimbangan, di bawah penyeimbangan kembali layanan **Availability Zone, pilih penyeimbangan kembali layanan** Availability Zone.**

   1. Untuk **masa tenggang pemeriksaan Kesehatan**, masukkan jumlah waktu (dalam detik) bahwa penjadwal layanan mengabaikan Elastic Load Balancing, VPC Lattice, dan pemeriksaan kesehatan kontainer yang tidak sehat setelah tugas pertama kali dimulai. Jika Anda tidak menentukan nilai periode tunggu pemeriksaan kondisi, nilai default 0 akan digunakan.

1. 

   1. Untuk **waktu Panggang**, masukkan jumlah menit revisi layanan biru dan hijau akan berjalan secara bersamaan sebelum revisi biru dihentikan. Ini memungkinkan waktu untuk verifikasi dan pengujian.

   1. (Opsional) Jalankan fungsi Lambda untuk dijalankan pada tahap penerapan tertentu. Di bawah **Deployment lifecycle hooks**, pilih tahapan untuk menjalankan kait siklus hidup.

      Untuk menambahkan kait siklus hidup:

      1. Pilih **Tambahkan**.

      1. Untuk **fungsi Lambda**, masukkan nama fungsi atau ARN.

      1. Untuk **Peran**, pilih peran IAM yang memiliki izin untuk menjalankan fungsi Lambda.

      1. Untuk **tahapan Siklus Hidup**, pilih tahapan saat fungsi Lambda harus dijalankan.

1. Untuk mengonfigurasi cara Amazon ECS mendeteksi dan menangani kegagalan penerapan, perluas **deteksi kegagalan Deployment**, lalu pilih opsi Anda. 

   1. Untuk menghentikan penerapan saat tugas tidak dapat dimulai, pilih **Gunakan pemutus sirkuit penyebaran Amazon ECS**.

      **Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat pemutus sirkuit penyebaran mengatur penerapan ke status gagal, pilih Rollback on failure.**

   1. Untuk menghentikan penerapan berdasarkan metrik aplikasi, pilih **Gunakan CloudWatch alarm.** Kemudian, dari **nama CloudWatch alarm**, pilih alarm. Untuk membuat alarm baru, buka CloudWatch konsol.

      Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat CloudWatch alarm menyetel penerapan ke status gagal, pilih **Rollback on** failure.

1. (Opsional) Untuk menghubungkan layanan Anda menggunakan Service Connect, perluas **Service Connect**, lalu tentukan yang berikut ini:

   1.  Pilih **Aktifkan Service Connect**.

   1. Di bawah **konfigurasi Service Connect**, tentukan mode klien.
      + Jika layanan Anda menjalankan aplikasi klien jaringan yang hanya perlu terhubung ke layanan lain di namespace, pilih **sisi Klien** saja.
      + Jika layanan Anda menjalankan aplikasi jaringan atau layanan web dan perlu menyediakan titik akhir untuk layanan ini, dan terhubung ke layanan lain di namespace, pilih **Klien** dan server.

   1. Untuk menggunakan namespace yang bukan namespace cluster default, untuk Namespace, pilih **namespace layanan**. Ini bisa berupa namespace yang dibuat secara terpisah di ruang nama Anda Akun AWS atau Wilayah AWS di Region yang sama yang dibagikan dengan akun Anda menggunakan (). AWS Resource Access Manager AWS RAM*Untuk informasi selengkapnya tentang AWS Cloud Map ruang nama bersama, lihat [Berbagi AWS Cloud Map namespace lintas akun](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) di Panduan Pengembang.AWS Cloud Map *

   1. (Opsional) Konfigurasikan aturan header lalu lintas uji untuk blue/green penerapan. Di bawah **Uji perutean lalu lintas**, tentukan yang berikut ini:

      1. Pilih **Aktifkan aturan header lalu lintas pengujian** untuk merutekan permintaan tertentu ke revisi layanan hijau selama pengujian.

      1. Untuk **aturan pencocokan Header**, konfigurasikan kriteria untuk lalu lintas pengujian perutean:
         + **Nama header**: Masukkan nama header HTTP untuk dicocokkan (misalnya, `X-Test-Version` atau`User-Agent`).
         + **Jenis kecocokan**: Pilih kriteria yang cocok:
           + **Pencocokan tepat**: Permintaan rute di mana nilai header sama persis dengan nilai yang ditentukan
           + **Header hadir**: Permintaan rute yang berisi header yang ditentukan, terlepas dari nilainya
           + **Pencocokan pola**: Permintaan rute di mana nilai header cocok dengan pola tertentu
         + **Nilai header** (jika menggunakan kecocokan persis atau kecocokan pola): Masukkan nilai atau pola yang cocok.

         Anda dapat menambahkan beberapa aturan pencocokan header untuk membuat logika perutean yang kompleks. Permintaan yang cocok dengan aturan yang dikonfigurasi akan diarahkan ke revisi layanan hijau untuk pengujian.

      1. Pilih **Tambahkan aturan header** untuk mengonfigurasi kondisi pencocokan header tambahan.
**catatan**  
Aturan header lalu lintas uji memungkinkan Anda memvalidasi fungsionalitas baru dengan lalu lintas terkontrol sebelum menyelesaikan penerapan penuh. Ini memungkinkan Anda untuk menguji revisi layanan hijau dengan permintaan khusus (seperti yang dari alat pengujian internal atau pengguna beta) sambil mempertahankan arus lalu lintas normal ke revisi layanan biru.

   1. (Opsional) Tentukan konfigurasi log. Pilih **Gunakan koleksi log**. Opsi default mengirimkan log kontainer ke CloudWatch Log. Opsi driver log lainnya dikonfigurasi menggunakan AWS FireLens. Untuk informasi selengkapnya, lihat [Kirim log Amazon ECS ke AWS layanan atau AWS Partner](using_firelens.md).

      Berikut ini menjelaskan setiap tujuan log kontainer secara lebih rinci.
      + **Amazon CloudWatch** — Konfigurasikan tugas untuk mengirim log kontainer ke CloudWatch Log. Opsi driver log default disediakan, yang membuat grup CloudWatch log atas nama Anda. Untuk menentukan nama grup log yang berbeda, ubah nilai opsi driver.
      + **Amazon Data Firehose** — Konfigurasikan tugas untuk mengirim log kontainer ke Firehose. Opsi driver log default disediakan, yang mengirim log ke aliran pengiriman Firehose. Untuk menentukan nama aliran pengiriman yang berbeda, ubah nilai opsi driver.
      + **Amazon Kinesis Data** Streams — Konfigurasikan tugas untuk mengirim log kontainer ke Kinesis Data Streams. Opsi driver log default disediakan, yang mengirim log ke aliran Kinesis Data Streams. Untuk menentukan nama aliran yang berbeda, ubah nilai opsi driver.
      + **Amazon OpenSearch Service** - Konfigurasikan tugas untuk mengirim log kontainer ke domain OpenSearch Layanan. Opsi driver log harus disediakan. 
      + **Amazon S3** — Konfigurasikan tugas untuk mengirim log kontainer ke bucket Amazon S3. Opsi driver log default disediakan, tetapi Anda harus menentukan nama bucket Amazon S3 yang valid.

1. (Opsional) Konfigurasikan **Load balancing untuk penerapan** biru/hijau.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. (Opsional) Untuk membantu mengidentifikasi layanan dan tugas Anda, perluas bagian **Tag**, lalu konfigurasikan tag Anda.

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag definisi tugas, pilih **Aktifkan tag terkelola Amazon ECS**, lalu untuk **menyebarkan tag dari**, pilih Definisi tugas.**

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag layanan, pilih **Aktifkan tag terkelola Amazon ECS**, lalu untuk **menyebarkan tag dari**, pilih Layanan.**

   Menambah atau menghapus tanda.
   + [Tambahkan tag] Pilih **Tambah tag**, lalu lakukan hal berikut:
     + Untuk **Kunci**, masukkan nama kunci.
     + Untuk **Nilai**, masukkan nilai kunci.
   + [Menghapus tanda] Di samping tanda, pilih **Hapus tanda**.

1. Pilih **Buat**.

------
#### [ AWS CLI ]

1. Buat file dengan nama `service-definition.json` dengan konten berikut ini.

   Ganti *user-input* dengan nilai-nilai Anda.

   ```
   {
     "serviceName": "myBlueGreenService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "BLUE_GREEN",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "bakeTimeInMinutes": 2,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       },
       "lifecycleHooks": [
         {
           "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample",
           "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke",
           "lifecycleStages": [
             "PRE_SCALE_UP"
           ]
         }
       ]
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Jalankan `create-service`.

   Ganti *user-input* dengan nilai-nilai Anda.

   ```
   aws ecs create-service --cli-input-json file://service-definition.json
   ```

   Atau, Anda dapat menggunakan contoh berikut yang membuat layanan blue/green penyebaran dengan konfigurasi penyeimbang beban:

   ```
   aws ecs create-service \
      --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \
      --service-name "blue-green-example-service" \
      --task-definition "nginxServer:1" \
      --launch-type "FARGATE" \
      --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \
      --desired-count 3 \
      --deployment-controller "type=ECS" \
      --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \
      --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}"
   ```

------

## Langkah selanjutnya
<a name="deploy-blue-green-service-next-steps"></a>
+ Perbarui layanan untuk memulai penyebaran. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).
+ Pantau proses penyebaran untuk memastikannya mengikuti blue/green pola:
  + Revisi layanan hijau dibuat dan ditingkatkan
  + Lalu lintas uji diarahkan ke revisi hijau (jika dikonfigurasi)
  + Lalu lintas produksi dialihkan ke revisi hijau
  + Setelah waktu memanggang, revisi biru dihentikan

# Memecahkan masalah penerapan Amazon ECS blue/green
<a name="troubleshooting-blue-green"></a>

Berikut ini memberikan solusi untuk masalah umum yang mungkin Anda temui saat menggunakan blue/green penerapan dengan Amazon ECS. Blue/green kesalahan penerapan dapat terjadi selama fase berikut:
+ *Jalur sinkron*: Kesalahan yang segera muncul sebagai respons `CreateService` atau panggilan `UpdateService` API.
+ *Jalur asinkron*: Kesalahan yang muncul di `statusReason` bidang `DescribeServiceDeployments` dan menyebabkan rollback penerapan

**Tip**  
Anda dapat menggunakan asisten AI [Server MCP Amazon ECS](ecs-mcp-introduction.md) with untuk memantau penerapan dan memecahkan masalah penerapan menggunakan bahasa alami.

## Masalah konfigurasi penyeimbang beban
<a name="troubleshooting-blue-green-load-balancer"></a>

Konfigurasi penyeimbang beban adalah komponen penting dari blue/green penerapan di Amazon ECS. Konfigurasi yang tepat dari aturan pendengar, grup target, dan tipe penyeimbang beban sangat penting untuk penerapan yang berhasil. Bagian ini mencakup masalah konfigurasi penyeimbang beban umum yang dapat menyebabkan blue/green penerapan gagal.

Saat memecahkan masalah penyeimbang beban, penting untuk memahami hubungan antara aturan pendengar dan kelompok sasaran. Dalam blue/green penerapan:
+ Aturan pendengar produksi mengarahkan lalu lintas ke revisi layanan (biru) yang saat ini aktif
+ Aturan test listener dapat digunakan untuk memvalidasi revisi layanan baru (hijau) sebelum mengalihkan lalu lintas produksi
+ Grup sasaran digunakan untuk mendaftarkan instance kontainer dari setiap revisi layanan
+ Selama penyebaran, lalu lintas secara bertahap bergeser dari revisi layanan biru ke revisi layanan hijau dengan menyesuaikan bobot kelompok sasaran dalam aturan pendengar

### Kesalahan konfigurasi aturan pendengar
<a name="troubleshooting-blue-green-listener-rules"></a>

Masalah berikut terkait dengan konfigurasi aturan listener yang salah untuk blue/green penerapan.

Menggunakan ARN pendengar Application Load Balancer alih-alih ARN aturan pendengar  
*Pesan kesalahan*: `productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456`  
*Solusi*: Saat menggunakan Application Load Balancer, Anda harus menentukan aturan pendengar ARN untuk `productionListenerRule` dan, `testListenerRule` bukan ARN pendengar. Untuk Network Load Balancers, Anda harus menggunakan ARN pendengar.  
 *Untuk informasi tentang cara menemukan ARN listener, [lihat Listener untuk Application Load Balancers Anda di Panduan Pengguna Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) Balancer.* ARN untuk aturan memiliki format. `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...`

Menggunakan aturan yang sama untuk pendengar produksi dan pengujian  
*Pesan kesalahan*: `The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789`  
*Solusi*: Anda harus menggunakan aturan pendengar yang berbeda untuk lalu lintas produksi dan pengujian. Buat aturan listener terpisah untuk lalu lintas pengujian yang merutekan ke grup target pengujian Anda.

Grup target tidak terkait dengan aturan pendengar  
*Pesan kesalahan*: `Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.`  
*Solusi*: Baik grup target utama dan grup target alternatif harus dikaitkan dengan aturan pendengar produksi atau aturan pendengar pengujian. Perbarui konfigurasi penyeimbang beban Anda untuk memastikan kedua grup target terkait dengan aturan pendengar Anda dengan benar.

Aturan pendengar pengujian tidak ada dengan Application Load Balancer  
*Pesan kesalahan*: `For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup`  
*Solusi*: Bila Anda menggunakan Application Load Balancer, jika kedua grup target tidak terkait dengan aturan pendengar produksi, Anda harus menentukan aturan listener pengujian. Tambahkan a `testListenerRule` ke konfigurasi Anda dan pastikan kedua grup target terkait dengan aturan produksi atau pengujian listener. Untuk informasi selengkapnya, lihat [Listener untuk Application Load Balancer Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) di Panduan Pengguna *Application* Load Balancer.

### Kesalahan konfigurasi grup sasaran
<a name="troubleshooting-blue-green-target-groups"></a>

Masalah berikut terkait dengan konfigurasi grup target yang salah untuk blue/green penerapan.

Beberapa grup target dengan lalu lintas dalam aturan pendengar  
*Pesan kesalahan*: `Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic`  
*Solusi*: Sebelum memulai blue/green penerapan, pastikan hanya satu grup target yang menerima lalu lintas (memiliki bobot bukan nol) dalam aturan pendengar Anda. Perbarui konfigurasi aturan listener Anda untuk menyetel bobot ke nol untuk grup target apa pun yang seharusnya tidak menerima lalu lintas.

Gandakan grup target di seluruh entri penyeimbang beban  
*Pesan kesalahan*: `Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123`  
*Solusi*: Setiap kelompok sasaran ARN harus unik di semua entri penyeimbang beban dalam definisi layanan Anda. Tinjau konfigurasi Anda dan pastikan Anda menggunakan grup target yang berbeda untuk setiap entri penyeimbang beban.

Kelompok target tak terduga dalam aturan pendengar produksi  
*Pesan kesalahan*: `Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789`  
*Solusi*: Aturan pendengar produksi adalah meneruskan lalu lintas ke grup target yang tidak ditentukan dalam definisi layanan Anda. Pastikan aturan listener dikonfigurasi untuk meneruskan lalu lintas hanya ke grup target yang ditentukan dalam definisi layanan Anda.   
Untuk informasi selengkapnya, lihat [meneruskan tindakan](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions) di *Panduan Pengguna Application Load Balancer*.

### Kesalahan konfigurasi tipe penyeimbang beban
<a name="troubleshooting-blue-green-load-balancer-types"></a>

Masalah berikut terkait dengan konfigurasi tipe penyeimbang beban yang salah untuk blue/green penerapan.

Mencampur konfigurasi Classic Load Balancer dan Application Load Balancer atau Network Load Balancer  
*Pesan kesalahan*: `All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)`  
Classic Load Balancer adalah load balancer generasi sebelumnya dari Elastic Load Balancing. Kami menyarankan Anda untuk bermigrasi ke penyeimbang beban generasi saat ini. Untuk informasi selengkapnya, lihat [Memigrasi Classic Load Balancer Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html).
*Solusi*:. Gunakan semua Classic Load Balancer atau semua Application Load Balancer dan Network Load Balancer.  
Untuk Application Load Balancers dan Network Load Balancers, tentukan hanya bidangnya. `targetGroupArn`

Menggunakan konfigurasi lanjutan dengan Classic Load Balancer  
*Pesan kesalahan*: `advancedConfiguration field is not allowed with ELBv1 loadBalancers`  
*Solusi*: Konfigurasi lanjutan untuk blue/green penerapan hanya didukung dengan Application Load Balancers dan Network Load Balancer. Jika Anda menggunakan Classic Load Balancer (ditentukan dengan`loadBalancerName`), Anda tidak dapat menggunakan bidang tersebut. `advancedConfiguration` Baik beralih ke Application Load Balancer, atau hapus bidang. `advancedConfiguration`

Konfigurasi lanjutan yang tidak konsisten di seluruh penyeimbang beban  
*Pesan kesalahan*: `Either all or none of the provided loadBalancers must have advancedConfiguration defined`  
*Solusi*: Jika Anda menggunakan beberapa penyeimbang beban, Anda harus menentukan `advancedConfiguration` untuk semuanya atau tidak satupun dari mereka. Perbarui konfigurasi Anda untuk memastikan konsistensi di semua entri penyeimbang beban.

Konfigurasi lanjutan yang tidak ada dengan blue/green penerapan  
*Pesan kesalahan*: `advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy`  
*Solusi*: Saat menggunakan strategi blue/green penyebaran dengan Application Load Balancers, Anda harus menentukan `advancedConfiguration` bidang untuk semua entri penyeimbang beban. Tambahkan yang diperlukan `advancedConfiguration` ke konfigurasi penyeimbang beban Anda.

## Masalah izin
<a name="troubleshooting-blue-green-permissions"></a>

Masalah berikut terkait dengan izin yang tidak memadai untuk blue/green penerapan.

Kebijakan Missing trust tentang infrastructure role  
*Pesan kesalahan*: `Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.`  
*Solusi*: Peran IAM yang ditentukan untuk mengelola sumber daya penyeimbang beban tidak memiliki kebijakan kepercayaan yang benar. Perbarui kebijakan kepercayaan peran untuk memungkinkan layanan mengambil peran. Kebijakan kepercayaan harus mencakup:    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

Izin baca tidak ada pada peran penyeimbang beban  
*Pesan kesalahan*: `service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)`  
*Solusi*: Peran IAM yang digunakan untuk mengelola sumber daya penyeimbang beban tidak memiliki izin untuk membaca informasi kesehatan target. Tambahkan `elasticloadbalancing:DescribeTargetHealth` izin ke kebijakan peran. Untuk informasi tentang izin Elastic Load Balancing, lihat. [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)

Izin tulis tidak ada pada peran penyeimbang beban  
*Pesan kesalahan*: `service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)`  
*Solusi*: Peran IAM yang digunakan untuk mengelola sumber daya penyeimbang beban tidak memiliki izin untuk mendaftarkan target. Tambahkan `elasticloadbalancing:RegisterTargets` izin ke kebijakan peran. Untuk informasi tentang izin Elastic Load Balancing, lihat. [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)

Izin tidak ada untuk mengubah aturan pendengar  
*Pesan kesalahan*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action`  
*Solusi*: Peran IAM yang digunakan untuk mengelola sumber daya penyeimbang beban tidak memiliki izin untuk memodifikasi pendengar. Tambahkan `elasticloadbalancing:ModifyListener` izin ke kebijakan peran. Untuk informasi tentang izin Elastic Load Balancing, lihat. [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)

Untuk blue/green penerapan, sebaiknya lampirkan kebijakan `AmazonECS-ServiceLinkedRolePolicy` terkelola ke peran infrastruktur Anda, yang mencakup semua izin yang diperlukan untuk mengelola sumber daya penyeimbang beban.

## Masalah kait siklus hidup
<a name="troubleshooting-blue-green-lifecycle-hooks"></a>

Masalah berikut terkait dengan kait siklus hidup dalam penerapan. blue/green 

Kebijakan trust yang salah tentang Lambda hook role  
*Pesan kesalahan*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin`  
*Solusi*: Peran IAM yang ditentukan untuk hook siklus hidup Lambda tidak memiliki kebijakan kepercayaan yang benar. Perbarui kebijakan kepercayaan peran untuk memungkinkan layanan mengambil peran. Kebijakan kepercayaan harus mencakup:    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

Lambda hook mengembalikan status GAGAL  
*Pesan kesalahan*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.`  
*Solusi*: Fungsi Lambda yang ditentukan sebagai kait siklus hidup mengembalikan status GAGAL. Periksa log fungsi Lambda di CloudWatch log Amazon untuk menentukan alasan kegagalan, dan perbarui fungsi untuk menangani peristiwa penerapan dengan benar.

Izin tidak ada untuk menjalankan fungsi Lambda  
*Pesan kesalahan*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action`  
*Solusi*: Peran IAM yang digunakan untuk hook siklus hidup Lambda tidak memiliki izin untuk menjalankan fungsi Lambda. Tambahkan `lambda:InvokeFunction` izin ke kebijakan peran untuk ARN fungsi Lambda tertentu. Untuk informasi tentang izin Lambda, lihat. [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md)

Batas waktu fungsi Lambda atau respons tidak valid  
*Pesan kesalahan*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null`  
*Solusi*: Fungsi Lambda habis waktu atau mengembalikan respons yang tidak valid. Pastikan bahwa fungsi Lambda Anda mengembalikan respons yang valid dengan `hookStatus` bidang yang disetel ke salah satu atau`SUCCEEDED`. `FAILED` Juga, periksa apakah batas waktu fungsi Lambda diatur dengan tepat untuk logika validasi Anda. Untuk informasi selengkapnya, lihat [Kait siklus hidup untuk penerapan layanan Amazon ECS](deployment-lifecycle-hooks.md).  
Contoh respons Lambda yang valid:  

```
{
  "hookStatus": "SUCCEEDED",
  "reason": "Validation passed"
}
```

# Deployment linier Amazon ECS
<a name="deployment-type-linear"></a>

Penerapan linier secara bertahap mengalihkan lalu lintas dari revisi layanan lama ke yang baru dengan peningkatan yang sama dari waktu ke waktu, memungkinkan Anda untuk memantau setiap langkah sebelum melanjutkan ke langkah berikutnya. Dengan penerapan linear Amazon ECS, kendalikan laju pergeseran lalu lintas dan validasi revisi layanan baru dengan peningkatan jumlah lalu lintas produksi. Pendekatan ini menyediakan cara terkontrol untuk menerapkan perubahan dengan kemampuan untuk memantau kinerja pada setiap kenaikan.

## Sumber daya yang terlibat dalam penyebaran linier
<a name="linear-deployment-resources"></a>

Berikut ini adalah sumber daya yang terlibat dalam penyebaran linier Amazon ECS:
+ Pergeseran lalu lintas - Proses yang digunakan Amazon ECS untuk mengalihkan lalu lintas produksi. Untuk penerapan linier Amazon ECS, lalu lintas digeser dalam peningkatan persentase yang sama dengan waktu tunggu yang dapat dikonfigurasi di antara setiap kenaikan.
+ Persentase langkah - Persentase lalu lintas yang bergeser dalam setiap kenaikan selama penyebaran linier. Bidang ini mengambil Double untuk nilai, dan nilai yang valid adalah dari 3.0 hingga 100.0.
+ Step bake time - Durasi untuk menunggu di antara setiap kenaikan pergeseran lalu lintas selama penerapan linier. Nilai yang valid adalah dari 0 - 1440 menit.
+ Waktu pemanggangan penyebaran - Waktu, dalam hitungan menit, Amazon ECS menunggu setelah mengalihkan semua lalu lintas produksi ke revisi layanan baru, sebelum mengakhiri revisi layanan lama. Ini adalah durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.
+ Tahap siklus hidup - Serangkaian peristiwa dalam operasi penyebaran, seperti “setelah pergeseran lalu lintas produksi”.
+ Lifecycle hook - Fungsi Lambda yang berjalan pada tahap siklus hidup tertentu. Anda dapat membuat fungsi yang memverifikasi penerapan. Fungsi Lambda atau kait siklus hidup yang dikonfigurasi untuk PRODUCTION\$1TRAFFIC\$1SHIFT akan dipanggil pada setiap langkah pergeseran lalu lintas produksi.
+ Grup sasaran - Sumber daya Elastic Load Balancing yang digunakan untuk merutekan permintaan ke satu atau lebih target terdaftar (misalnya, instans EC2). Bila Anda membuat pendengar, Anda menentukan grup target untuk tindakan default-nya. Lalu lintas diteruskan ke grup target yang ditentukan dalam aturan pendengar.
+ Listener - Sumber daya Elastic Load Balancing yang memeriksa permintaan koneksi menggunakan protokol dan port yang Anda konfigurasikan. Aturan yang Anda tetapkan untuk pendengar menentukan cara Amazon ECS merutekan permintaan ke target terdaftarnya.
+ Aturan - Sumber daya Elastic Load Balancing yang terkait dengan pendengar. Aturan mendefinisikan bagaimana permintaan dirutekan dan terdiri dari tindakan, kondisi, dan prioritas.

## Pertimbangan-pertimbangan
<a name="linear-deployment-considerations"></a>

Pertimbangkan hal berikut saat memilih jenis penerapan:
+ Penggunaan sumber daya: Penerapan linier menjalankan sementara revisi layanan biru dan hijau secara bersamaan, yang dapat menggandakan penggunaan sumber daya Anda selama penerapan.
+ Pemantauan penyebaran: Penerapan linier memberikan informasi status penyebaran terperinci, memungkinkan Anda memantau setiap tahap proses penyebaran dan setiap kenaikan pergeseran lalu lintas.
+ Rollback: Penerapan linier memudahkan untuk memutar kembali ke versi sebelumnya jika masalah terdeteksi, karena revisi biru terus berjalan hingga waktu pemanggangan berakhir.
+ Validasi bertahap: Penerapan linier memungkinkan Anda memvalidasi revisi baru dengan peningkatan jumlah lalu lintas produksi, memberikan kepercayaan lebih dalam penerapan.
+ Durasi penyebaran: Penerapan linier membutuhkan waktu lebih lama untuk diselesaikan daripada all-at-once penerapan karena pergeseran lalu lintas tambahan dan waktu tunggu di antara langkah-langkah.

## Cara kerja penerapan Linear
<a name="linear-deployment-how-works"></a>

Proses penyebaran Amazon ECS Linear mengikuti pendekatan terstruktur dengan enam fase berbeda yang memastikan pembaruan aplikasi yang aman dan andal. Setiap fase melayani tujuan tertentu dalam memvalidasi dan mentransisikan aplikasi Anda dari versi saat ini (biru) ke versi baru (hijau).

1. Tahap Persiapan: Ciptakan lingkungan hijau di samping lingkungan biru yang ada.

1. Fase Deployment: Menyebarkan revisi layanan baru ke lingkungan hijau. Amazon ECS meluncurkan tugas baru menggunakan revisi layanan yang diperbarui sementara lingkungan biru terus melayani lalu lintas produksi.

1. Fase Pengujian: Validasi lingkungan hijau menggunakan perutean lalu lintas uji. Application Load Balancer mengarahkan permintaan pengujian ke lingkungan hijau sementara lalu lintas produksi tetap biru.

1. Fase Pergeseran Lalu Lintas Linear: Secara bertahap mengalihkan lalu lintas produksi dari biru ke hijau dalam peningkatan persentase yang sama berdasarkan strategi penerapan yang dikonfigurasi.

1. Fase Pemantauan: Pantau kesehatan aplikasi, metrik kinerja, dan status alarm selama periode waktu pemanggangan. Operasi rollback dimulai ketika masalah terdeteksi.

1. Fase Penyelesaian: Selesaikan penerapan dengan mengakhiri lingkungan biru.

Fase pergeseran lalu lintas linier mengikuti langkah-langkah ini:
+ Awal - Penyebaran dimulai dengan 100% lalu lintas yang diarahkan ke revisi layanan biru (saat ini). Revisi layanan hijau (baru) menerima lalu lintas pengujian tetapi tidak ada lalu lintas produksi pada awalnya.
+ Pergeseran lalu lintas inkremental - Lalu lintas secara bertahap bergeser dari biru ke hijau dengan peningkatan persentase yang sama. Misalnya, dengan konfigurasi langkah 10,0%, pergeseran lalu lintas terjadi sebagai berikut:
  + Langkah 1:10,0% menjadi hijau, 90,0% menjadi biru
  + Langkah 2:20,0% menjadi hijau, 80,0% ke biru
  + Langkah 3:30,0% menjadi hijau, 70,0% menjadi biru
  + Dan seterusnya hingga 100% mencapai hijau
+ Step bake time - Di antara setiap kenaikan shift lalu lintas, penerapan menunggu durasi yang dapat dikonfigurasi (step bake time) untuk memungkinkan pemantauan dan validasi kinerja revisi baru dengan peningkatan beban lalu lintas. Perhatikan, bahwa waktu pemanggangan langkah terakhir dilewati setelah lalu lintas bergeser 100,0%.
+ Lifecycle hooks - Fungsi Lambda opsional dapat dijalankan pada berbagai tahap siklus hidup selama penerapan untuk melakukan validasi otomatis, pemantauan, atau logika kustom. Fungsi Lambda atau kait siklus hidup yang dikonfigurasi untuk PRODUCTION\$1TRAFFIC\$1SHIFT akan dipanggil pada setiap langkah pergeseran lalu lintas produksi.

## Tahapan siklus hidup penerapan
<a name="linear-deployment-lifecycle-stages"></a>

Proses penyebaran Linear berlangsung melalui tahapan siklus hidup yang berbeda, masing-masing dengan tanggung jawab khusus dan pos pemeriksaan validasi. Memahami tahapan ini membantu Anda memantau kemajuan penerapan dan memecahkan masalah secara efektif.

Setiap tahap siklus hidup dapat bertahan hingga 24 jam dan sebagai tambahan setiap langkah pergeseran lalu lintas di PRODUCTION\$1TRAFFIC\$1SHIFT dapat bertahan hingga 24 jam. Kami menyarankan agar nilainya tetap di bawah tanda 24 jam. Ini karena proses asinkron membutuhkan waktu untuk memicu kait. Waktu sistem habis, gagal penerapan, dan kemudian memulai rollback setelah tahap mencapai 24 jam.

CloudFormation penerapan memiliki batasan batas waktu tambahan. Sementara batas tahap 24 jam tetap berlaku, CloudFormation memberlakukan batas 36 jam pada seluruh penyebaran. CloudFormation gagal penerapan, dan kemudian memulai rollback jika proses tidak selesai dalam waktu 36 jam.


| Tahapan siklus hidup | Deskripsi | Dukungan kait siklus hidup | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Tahap ini hanya terjadi ketika Anda memulai penyebaran layanan baru dengan lebih dari 1 revisi layanan dalam status AKTIF. | Ya | 
| PRE\$1SCALE\$1UP | Revisi layanan hijau belum dimulai. Revisi layanan biru menangani 100% lalu lintas produksi. Tidak ada lalu lintas uji. | Ya | 
| SKALA\$1UP | Waktu ketika revisi layanan hijau menskalakan hingga 100% dan meluncurkan tugas baru. Revisi layanan hijau tidak melayani lalu lintas apa pun pada saat ini. | Tidak | 
| POST\$1SCALE\$1UP | Revisi layanan hijau telah dimulai. Revisi layanan biru menangani 100% lalu lintas produksi. Tidak ada lalu lintas uji. | Ya | 
| TEST\$1TRAFFIC\$1SHIFT | Revisi layanan biru dan hijau sedang berjalan. Revisi layanan biru menangani 100% lalu lintas produksi. Revisi layanan hijau bermigrasi dari 0% ke 100% lalu lintas pengujian. | Ya | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Pergeseran lalu lintas uji selesai. Revisi layanan hijau menangani 100% lalu lintas pengujian. | Ya | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | Lalu lintas secara bertahap bergeser dari biru ke hijau dalam peningkatan persentase yang sama sampai hijau menerima 100% lalu lintas. Setiap shift lalu lintas memanggil kait siklus hidup dengan batas waktu 24 jam. | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Pergeseran lalu lintas produksi selesai. | Ya | 
| BAKE\$1WAKTU | Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan. | Tidak | 
| MEMBERSIHKAN\$1UP | Revisi layanan biru telah sepenuhnya diperkecil menjadi 0 tugas yang berjalan. Revisi layanan hijau sekarang menjadi revisi layanan produksi setelah tahap ini. | Tidak | 

# Sumber daya yang diperlukan untuk penerapan linier Amazon ECS
<a name="linear-deployment-implementation"></a>

Untuk menggunakan penyebaran linier dengan pemindahan lalu lintas terkelola, layanan Anda harus menggunakan salah satu fitur berikut:
+ Elastic Load Balancing
+ Service Connect

Daftar berikut memberikan ikhtisar tingkat tinggi tentang apa yang perlu Anda konfigurasi untuk penerapan linear Amazon ECS:
+ Layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect. Konfigurasikan sumber daya yang sesuai.
  + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
  + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)
  + Service Connect - Untuk informasi selengkapnya, lihat[Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary](service-connect-blue-green.md).
+ Setel pengontrol penyebaran layanan ke`ECS`.
+ Konfigurasikan strategi penerapan seperti `linear` dalam definisi layanan Anda.
+ Secara opsional, konfigurasikan parameter tambahan seperti:
  + Waktu panggang untuk penerapan baru
  + Persentase lalu lintas yang bergeser dalam setiap kenaikan.
  + Durasi dalam hitungan menit untuk menunggu di antara setiap kenaikan shift lalu lintas. 
  + CloudWatch alarm untuk rollback otomatis
  + Kait siklus hidup penerapan (ini adalah fungsi Lambda yang berjalan pada tahap penerapan tertentu seperti BEFORE\$1INSTALL, PRODUCTION\$1TRAFFIC\$1SHIFT, atau POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT)

## Praktik terbaik
<a name="linear-deployment-best-practices"></a>

Ikuti praktik terbaik berikut untuk penerapan linier Amazon ECS yang sukses:
+ **Pastikan aplikasi Anda dapat menangani kedua revisi layanan yang berjalan secara bersamaan.**
+ **Rencanakan kapasitas cluster yang memadai untuk menangani kedua revisi layanan selama penerapan.**
+ **Uji prosedur rollback Anda sebelum menerapkannya dalam produksi.**
+ Konfigurasikan pemeriksaan kesehatan yang sesuai yang secara akurat mencerminkan kesehatan aplikasi Anda.
+ Tetapkan waktu pemanggangan yang memungkinkan pengujian revisi layanan baru yang memadai.
+ Menerapkan CloudWatch alarm untuk secara otomatis mendeteksi masalah dan memicu rollback.
+ Pilih persentase langkah dan waktu panggang yang menyeimbangkan kecepatan penerapan dengan kebutuhan validasi.
+ Gunakan persentase langkah yang lebih kecil (5-10%) untuk aplikasi penting untuk meminimalkan paparan risiko.
+ Atur waktu memanggang langkah yang lebih lama untuk aplikasi yang membutuhkan waktu untuk pemanasan atau stabilkan.
+ Menerapkan CloudWatch alarm untuk secara otomatis mendeteksi masalah dan memicu rollback pada setiap kenaikan lalu lintas.
+ Pantau metrik aplikasi dengan cermat selama setiap pergeseran lalu lintas untuk mendeteksi penurunan kinerja lebih awal.
+ Pastikan aplikasi Anda dapat menangani kedua revisi layanan yang berjalan secara bersamaan.
+ Uji prosedur rollback Anda pada persentase lalu lintas yang berbeda sebelum menerapkannya dalam produksi.

# Membuat penyebaran linier Amazon ECS
<a name="deploy-linear-service"></a>

Dengan menggunakan penerapan linier Amazon ECS, Anda dapat secara bertahap menggeser lalu lintas dengan peningkatan yang sama selama interval waktu yang ditentukan. Ini memberikan validasi terkontrol pada setiap langkah proses penerapan.

## Prasyarat
<a name="deploy-linear-service-prerequisites"></a>

Lakukan operasi berikut sebelum Anda memulai penerapan linier.

1. Konfigurasikan izin yang sesuai.
   + Untuk informasi tentang izin Elastic Load Balancing, lihat. [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)
   + Untuk informasi tentang izin Lambda, lihat. [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md)

1. Penerapan linear Amazon ECS mengharuskan layanan Anda menggunakan salah satu fitur berikut: Konfigurasikan sumber daya yang sesuai.
   + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
   + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)
   + Service Connect - Untuk informasi selengkapnya, lihat[Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary](service-connect-blue-green.md).

## Prosedur
<a name="deploy-linear-service-procedure"></a>

Anda dapat menggunakan konsol atau AWS CLI untuk membuat layanan penyebaran linear Amazon ECS.

------
#### [ Console ]

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Tentukan sumber daya dari tempat Anda meluncurkan layanan.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-linear-service.html)

   Halaman **Create service** ditampilkan.

1. Di bawah **rincian Layanan**, lakukan hal berikut:

   1. Untuk **keluarga definisi Tugas**, pilih definisi tugas yang akan digunakan. Kemudian, untuk **revisi definisi Tugas**, masukkan revisi yang akan digunakan.

   1. Untuk **nama Layanan**, masukkan nama untuk layanan Anda.

1. Untuk menjalankan layanan di klaster yang ada, untuk **klaster yang ada**, pilih klaster. Untuk menjalankan layanan di klaster baru, pilih **Buat klaster** 

1. Pilih bagaimana tugas Anda didistribusikan di seluruh infrastruktur klaster Anda. Di bawah **Konfigurasi komputasi**, pilih opsi Anda.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. Di bawah **konfigurasi Deployment**, lakukan hal berikut:

   1. Untuk **jenis Layanan**, pilih **Replika.**

   1. Untuk **tugas yang diinginkan**, masukkan jumlah tugas untuk diluncurkan dan dipelihara dalam layanan.

   1. **Agar Amazon ECS memantau distribusi tugas di seluruh Availability Zone, dan mendistribusikannya kembali saat terjadi ketidakseimbangan, di bawah penyeimbangan kembali layanan **Availability Zone, pilih penyeimbangan kembali layanan** Availability Zone.**

   1. Untuk **masa tenggang pemeriksaan Kesehatan**, masukkan jumlah waktu (dalam detik) bahwa penjadwal layanan mengabaikan Elastic Load Balancing, VPC Lattice, dan pemeriksaan kesehatan kontainer yang tidak sehat setelah tugas pertama kali dimulai. Jika Anda tidak menentukan nilai periode tunggu pemeriksaan kondisi, nilai default 0 akan digunakan.

1. Di bawah **konfigurasi Deployment**, konfigurasikan pengaturan penerapan linier:

   1. Untuk **strategi Deployment**, pilih **Linear**.

   1. Untuk **persentase kenaikan lalu lintas**, masukkan persentase lalu lintas yang akan digeser di setiap kenaikan (misalnya, 10% untuk menggeser lalu lintas dalam kenaikan 10%).

   1. Untuk **Interval antar kenaikan**, masukkan waktu dalam menit untuk menunggu di antara setiap kenaikan shift lalu lintas.

   1. Untuk **waktu Bake**, masukkan jumlah menit revisi layanan biru dan hijau akan berjalan secara bersamaan setelah pergeseran lalu lintas terakhir sebelum revisi biru dihentikan.

   1. (Opsional) Jalankan fungsi Lambda untuk dijalankan pada tahap penerapan tertentu. Di bawah **Deployment lifecycle hooks**, pilih tahapan untuk menjalankan kait siklus hidup.

      Untuk menambahkan kait siklus hidup:

      1. Pilih **Tambahkan**.

      1. Untuk **fungsi Lambda**, masukkan nama fungsi atau ARN.

      1. Untuk **Peran**, pilih peran IAM yang memiliki izin untuk menjalankan fungsi Lambda.

      1. Untuk **tahapan Siklus Hidup**, pilih tahapan saat fungsi Lambda harus dijalankan.

1. Untuk mengonfigurasi cara Amazon ECS mendeteksi dan menangani kegagalan penerapan, perluas **deteksi kegagalan Deployment**, lalu pilih opsi Anda. 

   1. Untuk menghentikan penerapan saat tugas tidak dapat dimulai, pilih **Gunakan pemutus sirkuit penyebaran Amazon ECS**.

      **Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat pemutus sirkuit penyebaran mengatur penerapan ke status gagal, pilih Rollback on failure.**

   1. Untuk menghentikan penerapan berdasarkan metrik aplikasi, pilih **Gunakan CloudWatch alarm.** Kemudian, dari **nama CloudWatch alarm**, pilih alarm. Untuk membuat alarm baru, buka CloudWatch konsol.

      Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat CloudWatch alarm menyetel penerapan ke status gagal, pilih **Rollback on** failure.

1. (Opsional) Untuk menghubungkan layanan Anda menggunakan Service Connect, perluas **Service Connect**, lalu tentukan yang berikut ini:

   1.  Pilih **Aktifkan Service Connect**.

   1. Di bawah **konfigurasi Service Connect**, tentukan mode klien.
      + Jika layanan Anda menjalankan aplikasi klien jaringan yang hanya perlu terhubung ke layanan lain di namespace, pilih **sisi Klien** saja.
      + Jika layanan Anda menjalankan aplikasi jaringan atau layanan web dan perlu menyediakan titik akhir untuk layanan ini, dan terhubung ke layanan lain di namespace, pilih **Klien** dan server.

   1. Untuk menggunakan namespace yang bukan namespace cluster default, untuk Namespace, pilih **namespace layanan**. Ini bisa berupa namespace yang dibuat secara terpisah di ruang nama Anda Akun AWS atau Wilayah AWS di Region yang sama yang dibagikan dengan akun Anda menggunakan (). AWS Resource Access Manager AWS RAM*Untuk informasi selengkapnya tentang AWS Cloud Map ruang nama bersama, lihat [Berbagi AWS Cloud Map namespace lintas akun](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) di Panduan Pengembang.AWS Cloud Map *

   1. (Opsional) Konfigurasikan aturan header lalu lintas uji untuk penerapan linier. Di bawah **Uji perutean lalu lintas**, tentukan yang berikut ini:

      1. Pilih **Aktifkan aturan header lalu lintas pengujian** untuk merutekan permintaan tertentu ke revisi layanan hijau selama pengujian.

      1. Untuk **aturan pencocokan Header**, konfigurasikan kriteria untuk lalu lintas pengujian perutean:
         + **Nama header**: Masukkan nama header HTTP untuk dicocokkan (misalnya, `X-Test-Version` atau`User-Agent`).
         + **Jenis kecocokan**: Pilih kriteria yang cocok:
           + **Pencocokan tepat**: Permintaan rute di mana nilai header sama persis dengan nilai yang ditentukan
           + **Header hadir**: Permintaan rute yang berisi header yang ditentukan, terlepas dari nilainya
           + **Pencocokan pola**: Permintaan rute di mana nilai header cocok dengan pola tertentu
         + **Nilai header** (jika menggunakan kecocokan persis atau kecocokan pola): Masukkan nilai atau pola yang cocok.

         Anda dapat menambahkan beberapa aturan pencocokan header untuk membuat logika perutean yang kompleks. Permintaan yang cocok dengan aturan yang dikonfigurasi akan diarahkan ke revisi layanan hijau untuk pengujian.

      1. Pilih **Tambahkan aturan header** untuk mengonfigurasi kondisi pencocokan header tambahan.
**catatan**  
Aturan header lalu lintas uji memungkinkan Anda memvalidasi fungsionalitas baru dengan lalu lintas terkontrol sebelum menyelesaikan penerapan penuh. Ini memungkinkan Anda untuk menguji revisi layanan hijau dengan permintaan khusus (seperti yang dari alat pengujian internal atau pengguna beta) sambil mempertahankan arus lalu lintas normal ke revisi layanan biru.

   1. (Opsional) Tentukan konfigurasi log. Pilih **Gunakan koleksi log**. Opsi default mengirimkan log kontainer ke CloudWatch Log. Opsi driver log lainnya dikonfigurasi menggunakan AWS FireLens. Untuk informasi selengkapnya, lihat [Kirim log Amazon ECS ke AWS layanan atau AWS Partner](using_firelens.md).

      Berikut ini menjelaskan setiap tujuan log kontainer secara lebih rinci.
      + **Amazon CloudWatch** — Konfigurasikan tugas untuk mengirim log kontainer ke CloudWatch Log. Opsi driver log default disediakan, yang membuat grup CloudWatch log atas nama Anda. Untuk menentukan nama grup log yang berbeda, ubah nilai opsi driver.
      + **Amazon Data Firehose** — Konfigurasikan tugas untuk mengirim log kontainer ke Firehose. Opsi driver log default disediakan, yang mengirim log ke aliran pengiriman Firehose. Untuk menentukan nama aliran pengiriman yang berbeda, ubah nilai opsi driver.
      + **Amazon Kinesis Data** Streams — Konfigurasikan tugas untuk mengirim log kontainer ke Kinesis Data Streams. Opsi driver log default disediakan, yang mengirim log ke aliran Kinesis Data Streams. Untuk menentukan nama aliran yang berbeda, ubah nilai opsi driver.
      + **Amazon OpenSearch Service** - Konfigurasikan tugas untuk mengirim log kontainer ke domain OpenSearch Layanan. Opsi driver log harus disediakan. 
      + **Amazon S3** — Konfigurasikan tugas untuk mengirim log kontainer ke bucket Amazon S3. Opsi driver log default disediakan, tetapi Anda harus menentukan nama bucket Amazon S3 yang valid.

1. (Opsional) Konfigurasikan **Load balancing** untuk penerapan linier.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. (Opsional) Untuk membantu mengidentifikasi layanan dan tugas Anda, perluas bagian **Tag**, lalu konfigurasikan tag Anda.

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag definisi tugas, pilih **Aktifkan tag terkelola Amazon ECS**, lalu untuk **menyebarkan tag dari**, pilih Definisi tugas.**

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag layanan, pilih **Aktifkan tag terkelola Amazon ECS**, lalu untuk **menyebarkan tag dari**, pilih Layanan.**

   Menambah atau menghapus tanda.
   + [Tambahkan tag] Pilih **Tambah tag**, lalu lakukan hal berikut:
     + Untuk **Kunci**, masukkan nama kunci.
     + Untuk **Nilai**, masukkan nilai kunci.
   + [Menghapus tanda] Di samping tanda, pilih **Hapus tanda**.

1. Pilih **Buat**.

------
#### [ AWS CLI ]

1. Buat file dengan nama `linear-service-definition.json` dengan konten berikut ini.

   Ganti *user-input* dengan nilai-nilai Anda.

   ```
   {
     "serviceName": "myLinearService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "LINEAR",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "linearConfiguration": {
         "stepPercentage": 10.0,
         "stepBakeTimeInMinutes":6
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Jalankan `create-service`.

   ```
   aws ecs create-service --cli-input-json file://linear-service-definition.json
   ```

------

## Langkah selanjutnya
<a name="deploy-linear-service-next-steps"></a>
+ Perbarui layanan untuk memulai penyebaran. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).
+ Pantau proses penyebaran untuk memastikannya mengikuti pola linier:
  + Revisi layanan hijau dibuat dan ditingkatkan
  + Lalu lintas digeser secara bertahap pada interval yang ditentukan
  + Setiap kenaikan menunggu interval yang ditentukan sebelum shift berikutnya
  + Setelah semua lalu lintas bergeser, waktu memanggang dimulai
  + Setelah waktu memanggang, revisi biru dihentikan

# Deployment canary Amazon ECS
<a name="canary-deployment"></a>

Penyebaran Canary pertama-tama merutekan sebagian kecil lalu lintas ke revisi baru untuk pengujian awal, kemudian menggeser semua lalu lintas yang tersisa sekaligus setelah fase kenari selesai dengan sukses. Dengan penerapan kenari Amazon ECS, validasi revisi layanan baru dengan lalu lintas pengguna nyata sambil meminimalkan eksposur risiko. Pendekatan ini menyediakan cara terkontrol untuk menerapkan perubahan dengan kemampuan untuk memantau kinerja dan memutar kembali dengan cepat jika masalah terdeteksi.

## Sumber daya yang terlibat dalam penyebaran kenari
<a name="canary-deployment-resources"></a>

Berikut ini adalah sumber daya yang terlibat dalam penyebaran kenari Amazon ECS:
+ Pergeseran lalu lintas - Proses yang digunakan Amazon ECS untuk mengalihkan lalu lintas produksi. Untuk penyebaran kenari Amazon ECS, lalu lintas digeser dalam dua fase: pertama ke persentase kenari, lalu menyelesaikan penyebaran.
+ Persentase kenari - Persentase lalu lintas yang diarahkan ke versi baru selama periode evaluasi.
+ Waktu memanggang kenari - Durasi untuk memantau versi kenari sebelum melanjutkan dengan penyebaran penuh.
+ Waktu pemanggangan penyebaran - Waktu, dalam hitungan menit, Amazon ECS menunggu setelah mengalihkan semua lalu lintas produksi ke revisi layanan baru, sebelum mengakhiri revisi layanan lama. Ini adalah durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.
+ Tahap siklus hidup - Serangkaian peristiwa dalam operasi penyebaran, seperti “setelah pergeseran lalu lintas produksi”.
+ Lifecycle hook - Fungsi Lambda yang berjalan pada tahap siklus hidup tertentu. Anda dapat membuat fungsi yang memverifikasi penerapan.
+ Kelompok sasaran - Sumber daya Elastic Load Balancing yang digunakan untuk merutekan permintaan ke satu atau lebih target terdaftar (misalnya, instans EC2). Bila Anda membuat pendengar, Anda menentukan grup target untuk tindakan default-nya. Lalu lintas diteruskan ke grup target yang ditentukan dalam aturan pendengar.
+ Listener - Sumber daya Elastic Load Balancing yang memeriksa permintaan koneksi menggunakan protokol dan port yang Anda konfigurasikan. Aturan yang Anda tetapkan untuk pendengar menentukan cara Amazon ECS merutekan permintaan ke target terdaftarnya.
+ Aturan - Sumber daya Elastic Load Balancing yang terkait dengan pendengar. Aturan mendefinisikan bagaimana permintaan dirutekan dan terdiri dari tindakan, kondisi, dan prioritas.

## Pertimbangan-pertimbangan
<a name="canary-deployment-considerations"></a>

Pertimbangkan hal berikut saat memilih jenis penerapan:
+ Penggunaan sumber daya: Penerapan Canary menjalankan set tugas asli dan canary secara bersamaan selama periode evaluasi, meningkatkan penggunaan sumber daya.
+ Volume lalu lintas: Pastikan persentase kenari menghasilkan lalu lintas yang cukup untuk validasi yang berarti dari versi baru.
+ Kompleksitas pemantauan: Penerapan Canary memerlukan pemantauan dan perbandingan metrik antara dua versi yang berbeda secara bersamaan.
+ Kecepatan rollback: Penerapan Canary memungkinkan rollback cepat dengan mengalihkan lalu lintas kembali ke set tugas asli.
+ Mitigasi risiko: Penerapan Canary memberikan mitigasi risiko yang sangat baik dengan membatasi eksposur ke sebagian kecil pengguna.
+ Durasi penerapan: Penerapan Canary mencakup periode evaluasi yang memperpanjang waktu penerapan keseluruhan tetapi memberikan peluang validasi.

## Cara kerja penerapan kenari
<a name="canary-how-it-works"></a>

Proses penyebaran Amazon ECS Canary mengikuti pendekatan terstruktur dengan enam fase berbeda yang memastikan pembaruan aplikasi yang aman dan andal. Setiap fase melayani tujuan tertentu dalam memvalidasi dan mentransisikan aplikasi Anda dari versi saat ini (biru) ke versi baru (hijau).

1. Tahap Persiapan: Ciptakan lingkungan hijau di samping lingkungan biru yang ada.

1. Fase Deployment: Menyebarkan revisi layanan baru ke lingkungan hijau. Amazon ECS meluncurkan tugas baru menggunakan revisi layanan yang diperbarui sementara lingkungan biru terus melayani lalu lintas produksi.

1. Fase Pengujian: Validasi lingkungan hijau menggunakan perutean lalu lintas uji. Application Load Balancer mengarahkan permintaan pengujian ke lingkungan hijau sementara lalu lintas produksi tetap biru.

1. Fase Pergeseran Lalu Lintas Canary: Pergeseran persentase lalu lintas yang dikonfigurasi ke revisi layanan hijau baru selama fase kenari, diikuti dengan pergeseran 100,0% lalu lintas ke revisi layanan Hijau

1. Fase Pemantauan: Pantau kesehatan aplikasi, metrik kinerja, dan status alarm selama periode waktu pemanggangan. Operasi rollback dimulai ketika masalah terdeteksi.

1. Fase Penyelesaian: Selesaikan penerapan dengan mengakhiri lingkungan biru.

Fase pergeseran lalu lintas kenari mengikuti langkah-langkah ini:
+ Awal - Penyebaran dimulai dengan 100% lalu lintas yang diarahkan ke revisi layanan biru (saat ini). Revisi layanan hijau (baru) menerima lalu lintas pengujian tetapi tidak ada lalu lintas produksi pada awalnya.
+ Pergeseran lalu lintas kenari - Ini adalah strategi pergeseran lalu lintas dua langkah.
  + Langkah 1:10,0% menjadi hijau, 90,0% menjadi biru
  + Langkah 2:100,0% menjadi hijau, 0,0% menjadi biru
+ Waktu memanggang kenari - Menunggu durasi yang dapat dikonfigurasi (waktu memanggang kenari) setelah pergeseran lalu lintas kenari untuk memungkinkan pemantauan dan validasi kinerja revisi baru dengan peningkatan beban lalu lintas.
+ Lifecycle hooks - Fungsi Lambda opsional dapat dijalankan pada berbagai tahap siklus hidup selama penerapan untuk melakukan validasi otomatis, pemantauan, atau logika kustom. Fungsi Lambda atau kait siklus hidup yang dikonfigurasi untuk PRODUCTION\$1TRAFFIC\$1SHIFT akan dipanggil pada setiap langkah pergeseran lalu lintas produksi.

### Tahapan siklus hidup penerapan
<a name="canary-deployment-lifecycle-stages"></a>

Proses penyebaran kenari berlangsung melalui tahapan siklus hidup yang berbeda, masing-masing dengan tanggung jawab khusus dan pos pemeriksaan validasi. Memahami tahapan ini membantu Anda memantau kemajuan penerapan dan memecahkan masalah secara efektif.

Setiap tahap siklus hidup dapat bertahan hingga 24 jam dan sebagai tambahan setiap langkah pergeseran lalu lintas di PRODUCTION\$1TRAFFIC\$1SHIFT dapat bertahan hingga 24 jam. Kami menyarankan agar nilainya tetap di bawah tanda 24 jam. Ini karena proses asinkron membutuhkan waktu untuk memicu kait. Waktu sistem habis, gagal penerapan, dan kemudian memulai rollback setelah tahap mencapai 24 jam.

CloudFormation penerapan memiliki batasan batas waktu tambahan. Sementara batas tahap 24 jam tetap berlaku, CloudFormation memberlakukan batas 36 jam pada seluruh penyebaran. CloudFormation gagal penerapan, dan kemudian memulai rollback jika proses tidak selesai dalam waktu 36 jam.


**Tahapan siklus hidup**  

| Tahapan siklus hidup | Deskripsi | Dukungan kait siklus hidup | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Tahap ini hanya terjadi ketika Anda memulai penyebaran layanan baru dengan lebih dari 1 revisi layanan dalam status AKTIF. | Ya | 
| PRE\$1SCALE\$1UP | Revisi layanan hijau belum dimulai. Revisi layanan biru menangani 100% lalu lintas produksi. Tidak ada lalu lintas uji. | Ya | 
| SKALA\$1UP | Waktu ketika revisi layanan hijau menskalakan hingga 100% dan meluncurkan tugas baru. Revisi layanan hijau tidak melayani lalu lintas apa pun pada saat ini. | Tidak | 
| POST\$1SCALE\$1UP | Revisi layanan hijau telah dimulai. Revisi layanan biru menangani 100% lalu lintas produksi. Tidak ada lalu lintas uji. | Ya | 
| TEST\$1TRAFFIC\$1SHIFT | Revisi layanan biru dan hijau sedang berjalan. Revisi layanan biru menangani 100% lalu lintas produksi. Revisi layanan hijau bermigrasi dari 0% ke 100% lalu lintas pengujian. | Ya | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Pergeseran lalu lintas uji selesai. Revisi layanan hijau menangani 100% lalu lintas pengujian. | Ya | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | Lalu lintas produksi kenari diarahkan ke revisi hijau dan kait siklus hidup dipanggil dengan batas waktu 24 jam. Langkah kedua menggeser lalu lintas produksi yang tersisa ke revisi hijau. | Ya | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Pergeseran lalu lintas produksi selesai. | Ya | 
| BAKE\$1WAKTU | Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan. | Tidak | 
| MEMBERSIHKAN\$1UP | Revisi layanan biru telah sepenuhnya diperkecil menjadi 0 tugas yang berjalan. Revisi layanan hijau sekarang menjadi revisi layanan produksi setelah tahap ini. | Tidak | 

### Parameter konfigurasi
<a name="canary-configuration-parameters"></a>

Penerapan Canary memerlukan parameter konfigurasi berikut:
+ Persentase kenari - Persentase lalu lintas untuk rute ke revisi layanan baru selama fase kenari. Hal ini memungkinkan pengujian dengan subset terkontrol dari lalu lintas produksi.
+ Waktu memanggang kenari - Durasi untuk menunggu selama fase kenari sebelum memindahkan lalu lintas yang tersisa ke revisi layanan baru. Ini memberikan waktu untuk memantau dan memvalidasi versi baru.

### Manajemen lalu lintas
<a name="canary-traffic-management"></a>

Penerapan Canary menggunakan grup target penyeimbang beban untuk mengelola distribusi lalu lintas:
+ Grup target asli - Berisi tugas dari versi stabil saat ini dan menerima sebagian besar lalu lintas.
+ Grup target Canary - Berisi tugas dari versi baru dan menerima persentase kecil lalu lintas untuk pengujian.
+ Perutean tertimbang - Penyeimbang beban menggunakan aturan perutean tertimbang untuk mendistribusikan lalu lintas antar grup target berdasarkan persentase kenari yang dikonfigurasi.

### Pemantauan dan validasi
<a name="canary-monitoring-validation"></a>

Penyebaran kenari yang efektif bergantung pada pemantauan komprehensif:
+ Pemeriksaan Kesehatan - Kedua set tugas harus lulus pemeriksaan kesehatan sebelum menerima lalu lintas.
+ Perbandingan metrik - Bandingkan indikator kinerja utama antara versi asli dan versi kenari, seperti waktu respons, tingkat kesalahan, dan throughput.
+ Rollback otomatis - Konfigurasikan CloudWatch alarm untuk memicu rollback secara otomatis jika versi kenari menunjukkan kinerja yang menurun.
+ Validasi manual - Gunakan periode evaluasi untuk meninjau log, metrik, dan umpan balik pengguna secara manual sebelum melanjutkan.

### Praktik terbaik untuk penyebaran kenari
<a name="canary-best-practices"></a>

Ikuti praktik terbaik ini untuk memastikan penerapan kenari yang berhasil dengan layanan.

#### Pilih persentase lalu lintas yang sesuai
<a name="canary-traffic-percentage"></a>

Pertimbangkan faktor-faktor ini ketika memilih persentase lalu lintas kenari:
+ Mulai dari yang kecil - Mulailah dengan 5-10% lalu lintas untuk meminimalkan dampak jika terjadi masalah.
+ Pertimbangkan kekritisan aplikasi - Gunakan persentase yang lebih kecil untuk aplikasi mission-critical dan persentase yang lebih besar untuk layanan yang kurang kritis.
+ Akun untuk volume lalu lintas - Pastikan persentase kenari menghasilkan lalu lintas yang cukup untuk validasi yang berarti.

#### Tetapkan periode evaluasi yang sesuai
<a name="canary-evaluation-time"></a>

Konfigurasikan periode evaluasi berdasarkan pertimbangan ini:
+ Berikan waktu yang cukup - Tetapkan periode evaluasi yang cukup lama untuk menangkap data kinerja yang berarti, biasanya 10-30 menit.
+ Pertimbangkan pola lalu lintas - Akun untuk pola lalu lintas aplikasi Anda dan waktu penggunaan puncak.
+ Menyeimbangkan kecepatan dan keamanan - Periode evaluasi yang lebih lama memberikan lebih banyak data tetapi kecepatan penyebaran lambat.

#### Melaksanakan pemantauan komprehensif
<a name="canary-monitoring-setup"></a>

Siapkan pemantauan untuk melacak kinerja penerapan kenari:
+ Metrik kunci - Memantau waktu respons, tingkat kesalahan, throughput, dan pemanfaatan sumber daya untuk kedua set tugas.
+ Rollback berbasis alarm - Konfigurasikan CloudWatch alarm untuk memicu rollback secara otomatis ketika metrik melebihi ambang batas.
+ Analisis komparatif - Siapkan dasbor untuk membandingkan metrik antara versi asli dan kenari. side-by-side
+ Metrik bisnis - Sertakan metrik khusus bisnis seperti rasio konversi atau keterlibatan pengguna di samping metrik teknis.

#### Rencanakan strategi rollback
<a name="canary-rollback-strategy"></a>

Bersiaplah untuk skenario rollback potensial dengan strategi ini:
+ Rollback otomatis - Konfigurasikan pemicu rollback otomatis berdasarkan pemeriksaan kesehatan dan metrik kinerja.
+ Prosedur rollback manual - Dokumentasikan prosedur yang jelas untuk rollback manual saat pemicu otomatis tidak menangkap semua masalah.
+ Pengujian rollback - Uji prosedur rollback secara teratur untuk memastikan mereka bekerja dengan benar saat diperlukan.

#### Validasi secara menyeluruh sebelum penerapan
<a name="canary-testing-validation"></a>

Pastikan validasi menyeluruh sebelum melanjutkan dengan penerapan canary:
+ Pengujian pra-penerapan - Uji perubahan lingkungan pementasan secara menyeluruh sebelum penerapan canary.
+ Konfigurasi pemeriksaan Kesehatan - Pastikan pemeriksaan kesehatan secara akurat mencerminkan kesiapan dan fungsionalitas aplikasi.
+ Validasi ketergantungan - Verifikasi bahwa versi baru kompatibel dengan layanan hilir dan hulu.
+ Konsistensi data - Pastikan perubahan skema database dan migrasi data kompatibel ke belakang.

#### Mengkoordinasikan keterlibatan tim
<a name="canary-team-coordination"></a>

Pastikan koordinasi tim yang efektif selama penyebaran kenari:
+ Jendela penyebaran - Jadwalkan penyebaran kenari selama jam kerja ketika tim tersedia untuk memantau dan merespons.
+ Saluran komunikasi - Menetapkan saluran komunikasi yang jelas untuk status penyebaran dan eskalasi masalah.
+ Tugas peran - Tentukan peran dan tanggung jawab untuk pemantauan, pengambilan keputusan, dan eksekusi rollback.

# Sumber daya yang diperlukan untuk penyebaran kenari Amazon ECS
<a name="canary-deployment-implementation"></a>

Untuk menggunakan penyebaran kenari dengan pemindahan lalu lintas terkelola, layanan Anda harus menggunakan salah satu fitur berikut:
+ Elastic Load Balancing
+ Service Connect

Daftar berikut memberikan ikhtisar tingkat tinggi tentang apa yang perlu Anda konfigurasi untuk penerapan kenari Amazon ECS:
+ Layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect. Konfigurasikan sumber daya yang sesuai.
  + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
  + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)
  + Service Connect - Untuk informasi selengkapnya, lihat[Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary](service-connect-blue-green.md).
+ Setel pengontrol penyebaran layanan ke`ECS`.
+ Konfigurasikan strategi penerapan seperti `canary` dalam definisi layanan Anda.
+ Secara opsional, konfigurasikan parameter tambahan seperti:
  + Waktu panggang untuk penerapan baru
  + Persentase lalu lintas untuk rute ke revisi layanan baru selama fase kenari. 
  + Durasi menunggu selama fase kenari sebelum mengalihkan lalu lintas yang tersisa ke revisi layanan baru. 
  + CloudWatch alarm untuk rollback otomatis
  + Kait siklus hidup penerapan (ini adalah fungsi Lambda yang berjalan pada tahap penerapan tertentu)

## Praktik terbaik
<a name="canary-deployment-best-practices"></a>

Ikuti praktik terbaik ini untuk keberhasilan penerapan Amazon ECS lcanary:
+ **Pastikan aplikasi Anda dapat menangani kedua revisi layanan yang berjalan secara bersamaan.**
+ **Rencanakan kapasitas cluster yang memadai untuk menangani kedua revisi layanan selama penerapan.**
+ **Uji prosedur rollback Anda sebelum menerapkannya dalam produksi.**
+ Konfigurasikan pemeriksaan kesehatan yang sesuai yang secara akurat mencerminkan kesehatan aplikasi Anda.
+ Tetapkan waktu pemanggangan yang memungkinkan pengujian penerapan hijau yang memadai.
+ Menerapkan CloudWatch alarm untuk secara otomatis mendeteksi masalah dan memicu rollback.
+ Gunakan kait siklus hidup untuk melakukan pengujian otomatis pada setiap tahap penerapan.
+ Mulailah dengan persentase kenari kecil (5-10%) untuk meminimalkan dampak jika terjadi masalah.
+ Tetapkan periode evaluasi yang tepat yang memungkinkan waktu yang cukup untuk pengumpulan data kinerja yang bermakna.
+ Menerapkan pemantauan komprehensif dengan CloudWatch alarm untuk pemicu rollback otomatis.
+ Konfigurasikan pemeriksaan kesehatan yang secara akurat mencerminkan kesiapan dan fungsionalitas aplikasi Anda.
+ Pantau metrik teknis (waktu respons, tingkat kesalahan) dan metrik bisnis selama evaluasi.
+ Pastikan aplikasi Anda dapat menangani pemisahan lalu lintas tanpa masalah sesi atau status.
+ Rencanakan prosedur rollback dan uji secara teratur untuk memastikan mereka bekerja saat diperlukan.
+ Jadwalkan penyebaran kenari selama jam kerja ketika tim dapat memantau dan merespons.
+ Validasi perubahan secara menyeluruh di lingkungan pementasan sebelum penerapan canary.
+ Dokumentasikan prosedur yang jelas untuk intervensi manual dan keputusan rollback.

# Membuat penyebaran kenari Amazon ECS
<a name="deploy-canary-service"></a>

Dengan menggunakan penyebaran kenari Amazon ECS, Anda dapat mengalihkan sebagian kecil lalu lintas ke revisi layanan baru Anda (“kenari”). Validasi penyebaran, dan kemudian geser lalu lintas yang tersisa sekaligus setelah interval yang ditentukan. Pendekatan ini memungkinkan Anda untuk menguji fungsionalitas baru dengan risiko minimal sebelum penerapan penuh.

## Prasyarat
<a name="deploy-canary-service-prerequisites"></a>

Lakukan operasi berikut sebelum Anda memulai penyebaran kenari.

1. Konfigurasikan izin yang sesuai.
   + Untuk informasi tentang izin Elastic Load Balancing, lihat. [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)
   + Untuk informasi tentang izin Lambda, lihat. [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md)

1. Penerapan kenari Amazon ECS mengharuskan layanan Anda menggunakan salah satu fitur berikut: Konfigurasikan sumber daya yang sesuai.
   + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
   + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)
   + Service Connect - Untuk informasi selengkapnya, lihat[Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary](service-connect-blue-green.md).

## Prosedur
<a name="deploy-canary-service-procedure"></a>

Anda dapat menggunakan konsol atau AWS CLI untuk membuat layanan penyebaran kenari Amazon ECS.

------
#### [ Console ]

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Tentukan sumber daya dari tempat Anda meluncurkan layanan.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-canary-service.html)

   Halaman **Create service** ditampilkan.

1. Di bawah **rincian Layanan**, lakukan hal berikut:

   1. Untuk **keluarga definisi Tugas**, pilih definisi tugas yang akan digunakan. Kemudian, untuk **revisi definisi Tugas**, masukkan revisi yang akan digunakan.

   1. Untuk **nama Layanan**, masukkan nama untuk layanan Anda.

1. Untuk menjalankan layanan di klaster yang ada, untuk **klaster yang ada**, pilih klaster. Untuk menjalankan layanan di klaster baru, pilih **Buat klaster** 

1. Pilih bagaimana tugas Anda didistribusikan di seluruh infrastruktur klaster Anda. Di bawah **Konfigurasi komputasi**, pilih opsi Anda.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. Di bawah **konfigurasi Deployment**, lakukan hal berikut:

   1. Untuk **jenis Layanan**, pilih **Replika.**

   1. Untuk **tugas yang diinginkan**, masukkan jumlah tugas untuk diluncurkan dan dipelihara dalam layanan.

   1. **Agar Amazon ECS memantau distribusi tugas di seluruh Availability Zone, dan mendistribusikannya kembali saat terjadi ketidakseimbangan, di bawah penyeimbangan kembali layanan **Availability Zone, pilih penyeimbangan kembali layanan** Availability Zone.**

   1. Untuk **masa tenggang pemeriksaan Kesehatan**, masukkan jumlah waktu (dalam detik) bahwa penjadwal layanan mengabaikan Elastic Load Balancing, VPC Lattice, dan pemeriksaan kesehatan kontainer yang tidak sehat setelah tugas pertama kali dimulai. Jika Anda tidak menentukan nilai periode tunggu pemeriksaan kondisi, nilai default 0 akan digunakan.

1. Di bawah **konfigurasi Deployment**, konfigurasikan pengaturan penerapan canary:

   1. Untuk **strategi Deployment**, pilih **Canary**.

   1. Untuk **persentase Canary**, masukkan persentase lalu lintas untuk beralih ke revisi layanan hijau pada tahap pertama (misalnya, 10% untuk lalu lintas kenari awal).

   1. Untuk **waktu memanggang Canary**, masukkan waktu dalam hitungan menit untuk menunggu sebelum mengalihkan lalu lintas yang tersisa ke revisi layanan hijau.

   1. Untuk **waktu Bake**, masukkan jumlah menit revisi layanan biru dan hijau akan berjalan secara bersamaan setelah pergeseran lalu lintas terakhir sebelum revisi biru dihentikan.

   1. (Opsional) Jalankan fungsi Lambda untuk dijalankan pada tahap penerapan tertentu. Di bawah **Deployment lifecycle hooks**, pilih tahapan untuk menjalankan kait siklus hidup.

      Untuk menambahkan kait siklus hidup:

      1. Pilih **Tambahkan**.

      1. Untuk **fungsi Lambda**, masukkan nama fungsi atau ARN.

      1. Untuk **Peran**, pilih peran IAM yang memiliki izin untuk menjalankan fungsi Lambda.

      1. Untuk **tahapan Siklus Hidup**, pilih tahapan saat fungsi Lambda harus dijalankan.

1. Untuk mengonfigurasi cara Amazon ECS mendeteksi dan menangani kegagalan penerapan, perluas **deteksi kegagalan Deployment**, lalu pilih opsi Anda. 

   1. Untuk menghentikan penerapan saat tugas tidak dapat dimulai, pilih **Gunakan pemutus sirkuit penyebaran Amazon ECS**.

      **Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat pemutus sirkuit penyebaran mengatur penerapan ke status gagal, pilih Rollback on failure.**

   1. Untuk menghentikan penerapan berdasarkan metrik aplikasi, pilih **Gunakan CloudWatch alarm.** Kemudian, dari **nama CloudWatch alarm**, pilih alarm. Untuk membuat alarm baru, buka CloudWatch konsol.

      Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat CloudWatch alarm menyetel penerapan ke status gagal, pilih **Rollback on** failure.

1. (Opsional) Untuk menghubungkan layanan Anda menggunakan Service Connect, perluas **Service Connect**, lalu tentukan yang berikut ini:

   1.  Pilih **Aktifkan Service Connect**.

   1. Di bawah **konfigurasi Service Connect**, tentukan mode klien.
      + Jika layanan Anda menjalankan aplikasi klien jaringan yang hanya perlu terhubung ke layanan lain di namespace, pilih **sisi Klien** saja.
      + Jika layanan Anda menjalankan aplikasi jaringan atau layanan web dan perlu menyediakan titik akhir untuk layanan ini, dan terhubung ke layanan lain di namespace, pilih **Klien** dan server.

   1. Untuk menggunakan namespace yang bukan namespace cluster default, untuk Namespace, pilih **namespace layanan**. Ini bisa berupa namespace yang dibuat secara terpisah di ruang nama Anda Akun AWS atau Wilayah AWS di Region yang sama yang dibagikan dengan akun Anda menggunakan (). AWS Resource Access Manager AWS RAM*Untuk informasi selengkapnya tentang AWS Cloud Map ruang nama bersama, lihat [Berbagi AWS Cloud Map namespace lintas akun](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) di Panduan Pengembang.AWS Cloud Map *

   1. (Opsional) Konfigurasikan aturan header lalu lintas uji untuk penerapan kenari. Di bawah **Uji perutean lalu lintas**, tentukan yang berikut ini:

      1. Pilih **Aktifkan aturan header lalu lintas pengujian** untuk merutekan permintaan tertentu ke revisi layanan hijau selama pengujian.

      1. Untuk **aturan pencocokan Header**, konfigurasikan kriteria untuk lalu lintas pengujian perutean:
         + **Nama header**: Masukkan nama header HTTP untuk dicocokkan (misalnya, `X-Test-Version` atau`User-Agent`).
         + **Jenis kecocokan**: Pilih kriteria yang cocok:
           + **Pencocokan tepat**: Permintaan rute di mana nilai header sama persis dengan nilai yang ditentukan
           + **Header hadir**: Permintaan rute yang berisi header yang ditentukan, terlepas dari nilainya
           + **Pencocokan pola**: Permintaan rute di mana nilai header cocok dengan pola tertentu
         + **Nilai header** (jika menggunakan kecocokan persis atau kecocokan pola): Masukkan nilai atau pola yang cocok.

         Anda dapat menambahkan beberapa aturan pencocokan header untuk membuat logika perutean yang kompleks. Permintaan yang cocok dengan aturan yang dikonfigurasi akan diarahkan ke revisi layanan hijau untuk pengujian.

      1. Pilih **Tambahkan aturan header** untuk mengonfigurasi kondisi pencocokan header tambahan.
**catatan**  
Aturan header lalu lintas uji memungkinkan Anda memvalidasi fungsionalitas baru dengan lalu lintas terkontrol sebelum menyelesaikan penerapan penuh. Ini memungkinkan Anda untuk menguji revisi layanan hijau dengan permintaan khusus (seperti yang dari alat pengujian internal atau pengguna beta) sambil mempertahankan arus lalu lintas normal ke revisi layanan biru.

   1. (Opsional) Tentukan konfigurasi log. Pilih **Gunakan koleksi log**. Opsi default mengirimkan log kontainer ke CloudWatch Log. Opsi driver log lainnya dikonfigurasi menggunakan AWS FireLens. Untuk informasi selengkapnya, lihat [Kirim log Amazon ECS ke AWS layanan atau AWS Partner](using_firelens.md).

      Berikut ini menjelaskan setiap tujuan log kontainer secara lebih rinci.
      + **Amazon CloudWatch** — Konfigurasikan tugas untuk mengirim log kontainer ke CloudWatch Log. Opsi driver log default disediakan, yang membuat grup CloudWatch log atas nama Anda. Untuk menentukan nama grup log yang berbeda, ubah nilai opsi driver.
      + **Amazon Data Firehose** — Konfigurasikan tugas untuk mengirim log kontainer ke Firehose. Opsi driver log default disediakan, yang mengirim log ke aliran pengiriman Firehose. Untuk menentukan nama aliran pengiriman yang berbeda, ubah nilai opsi driver.
      + **Amazon Kinesis Data** Streams — Konfigurasikan tugas untuk mengirim log kontainer ke Kinesis Data Streams. Opsi driver log default disediakan, yang mengirim log ke aliran Kinesis Data Streams. Untuk menentukan nama aliran yang berbeda, ubah nilai opsi driver.
      + **Amazon OpenSearch Service** - Konfigurasikan tugas untuk mengirim log kontainer ke domain OpenSearch Layanan. Opsi driver log harus disediakan. 
      + **Amazon S3** — Konfigurasikan tugas untuk mengirim log kontainer ke bucket Amazon S3. Opsi driver log default disediakan, tetapi Anda harus menentukan nama bucket Amazon S3 yang valid.

1. (Opsional) Konfigurasikan **Load balancing** untuk penerapan canary.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. (Opsional) Untuk membantu mengidentifikasi layanan dan tugas Anda, perluas bagian **Tag**, lalu konfigurasikan tag Anda.

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag definisi tugas, pilih **Aktifkan tag terkelola Amazon ECS**, lalu untuk **menyebarkan tag dari**, pilih Definisi tugas.**

   **Agar Amazon ECS secara otomatis menandai semua tugas yang baru diluncurkan dengan nama cluster dan tag layanan, pilih **Aktifkan tag terkelola Amazon ECS**, lalu untuk **menyebarkan tag dari**, pilih Layanan.**

   Menambah atau menghapus tanda.
   + [Tambahkan tag] Pilih **Tambah tag**, lalu lakukan hal berikut:
     + Untuk **Kunci**, masukkan nama kunci.
     + Untuk **Nilai**, masukkan nilai kunci.
   + [Menghapus tanda] Di samping tanda, pilih **Hapus tanda**.

1. Pilih **Buat**.

------
#### [ AWS CLI ]

1. Buat file dengan nama `canary-service-definition.json` dengan konten berikut ini.

   Ganti *user-input* dengan nilai-nilai Anda.

   ```
   {
     "serviceName": "myCanaryService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "CANARY",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "canaryConfiguration" : {
           "canaryPercent" : 5.0,
           "canaryBakeTime" : 10
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Jalankan `create-service`.

   ```
   aws ecs create-service --cli-input-json file://canary-service-definition.json
   ```

------

## Langkah selanjutnya
<a name="deploy-canary-service-next-steps"></a>

Setelah mengonfigurasi penerapan kenari Anda, selesaikan langkah-langkah ini:
+ Perbarui layanan untuk memulai penyebaran. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).
+ Pantau proses penyebaran untuk memastikannya mengikuti pola kenari:
  + Revisi layanan hijau dibuat dan ditingkatkan
  + Sebagian kecil lalu lintas (kenari) digeser ke revisi hijau
  + Sistem menunggu interval kenari yang ditentukan
  + Lalu lintas yang tersisa digeser sekaligus ke revisi hijau
  + Setelah waktu memanggang, revisi biru dihentikan

## Terminologi penyebaran
<a name="deployment-terminology"></a>

Istilah berikut digunakan di seluruh dokumentasi penyebaran Amazon ECS:

Penerapan biru-hijau  
Strategi penyebaran yang menciptakan lingkungan baru (hijau) di samping lingkungan yang ada (biru), kemudian mengalihkan lalu lintas dari biru ke hijau setelah validasi.

Penyebaran kenari  
Strategi penyebaran yang merutekan sebagian kecil lalu lintas ke versi baru sambil mempertahankan mayoritas pada versi stabil untuk validasi.

Penyebaran linier  
Strategi penyebaran yang secara bertahap menggeser lalu lintas dari versi lama ke versi baru dengan peningkatan yang sama dari waktu ke waktu.

Penyebaran bergulir  
Strategi penyebaran yang menggantikan instance versi lama dengan instance versi baru satu per satu.

Set tugas  
Kumpulan tugas yang menjalankan definisi tugas yang sama dalam layanan selama penerapan.

Grup target  
Pengelompokan logis target yang menerima lalu lintas dari penyeimbang beban selama penerapan.

Pengendali deployment  
Metode yang digunakan untuk menerapkan versi baru layanan Anda, seperti Amazon ECS CodeDeploy, atau pengontrol eksternal.

Rollback  
Proses mengembalikan ke versi aplikasi Anda sebelumnya saat masalah terdeteksi selama penerapan.

# Menyebarkan layanan Amazon ECS menggunakan pengontrol pihak ketiga
<a name="deployment-type-external"></a>

Jenis penyebaran *eksternal* memungkinkan Anda menggunakan pengontrol penyebaran pihak ketiga untuk kontrol penuh atas proses penyebaran untuk layanan Amazon ECS. Detail untuk layanan Anda dikelola, baik oleh tindakan API manajemen layanan (`CreateService`, `UpdateService`, dan `DeleteService`) ataupun tindakan API manajemen set tugas (`CreateTaskSet`, `UpdateTaskSet`, `UpdateServicePrimaryTaskSet`, dan `DeleteTaskSet`). Setiap tindakan API mengelola subset parameter definisi layanan.

Tindakan API `UpdateService` memperbarui jumlah yang diinginkan dan parameter masa tenggang pemeriksaan kondisi untuk suatu layanan. Jika opsi komputasi, versi platform, detail penyeimbang beban, konfigurasi jaringan, atau definisi tugas perlu diperbarui, Anda harus membuat set tugas baru.

Tindakan API `UpdateTaskSet` hanya memperbarui parameter skala untuk set tugas.

Tindakan API `UpdateServicePrimaryTaskSet` memodifikasi set tugas mana dalam layanan yang merupakan set tugas utama. Saat Anda memanggil tindakan API `DescribeServices`, tindakan tersebut mengembalikan semua bidang yang ditentukan untuk set tugas utama. Jika set tugas utama untuk layanan diperbarui, maka nilai parameter set tugas apa pun yang ada di set tugas utama baru yang berbeda dari set tugas utama lama di layanan akan diperbarui ke nilai baru saat set tugas utama baru ditentukan. Jika tidak ada set tugas utama yang ditentukan untuk layanan, maka saat menjelaskan layanan, bidang set tugas adalah nol.

## Pertimbangan penyebaran eksternal
<a name="deployment-type-external-considerations"></a>

Pertimbangkan hal berikut saat menggunakan tipe deployment eksternal:
+ Jenis penyeimbang beban yang didukung adalah Application Load Balancer atau Penyeimbang Beban Jaringan.
+ Jenis pengontrol Fargate atau `EXTERNAL` deployment tidak mendukung strategi penjadwalan. `DAEMON`
+  AutoScaling Integrasi aplikasi dengan Amazon ECS hanya mendukung layanan Amazon ECS sebagai target. Dimensi skalabel yang didukung untuk Amazon ECS adalah `ecs:service:DesiredCount` - jumlah tugas layanan Amazon ECS. Tidak ada integrasi langsung antara Application AutoScaling dan Amazon ECS task set. Set tugas Amazon ECS menghitung `ComputedDesiredCount` berdasarkan layanan Amazon ECS. `DesiredCount`

## Alur kerja penerapan eksternal
<a name="deployment-type-external-workflow"></a>

Berikut ini adalah alur kerja dasar untuk mengelola penyebaran eksternal di Amazon ECS.

**Untuk mengelola layanan Amazon ECS menggunakan pengontrol penyebaran eksternal**

1. Buat layanan Amazon ECS. Satu-satunya parameter yang diperlukan adalah nama layanan. Anda dapat menentukan parameter berikut saat membuat layanan menggunakan pengendali deployment eksternal. Semua parameter layanan lainnya ditentukan saat membuat set tugas dalam layanan.  
`serviceName`  
Tipe: String  
Diperlukan: Ya  
Nama layanan Anda. Mengizinkan hingga 255 huruf (huruf besar dan huruf kecil), angka, tanda hubung, dan garis bawah. Nama layanan harus unik dalam sebuah klaster, tetapi Anda dapat memiliki layanan yang bernama sama di beberapa klaster dalam satu Wilayah atau lebih.  
`desiredCount`  
Jumlah instantiasi dari tugas yang ditentukan menetapkan penentuan tugas untuk ditempatkan dan tetap berjalan dalam layanan.  
`deploymentConfiguration`  
Parameter deployment opsional yang mengendalikan seberapa banyak tugas yang dijalankan selama deployment dan urutan penghentian serta mulainya tugas.   
`tags`  
Tipe: Array objek   
Wajib: Tidak  
Metadata yang Anda terapkan ke layanan untuk membantu Anda mengkategorikan dan mengaturnya. Setiap tag terdiri atas sebuah kunci dan sebuah nilai opsional, dan Anda menentukan sendiri keduanya. Ketika layanan dihapus, tag akan dihapus juga. Maksimal 50 tag dapat diterapkan ke layanan. Untuk informasi selengkapnya, lihat [Menandai sumber daya Amazon ECS](ecs-using-tags.md).  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.    
`key`  
Tipe: String  
Batasan Panjang: Panjang minimum 1. Panjang maksimum 128.  
Wajib: Tidak  
Satu bagian dari pasangan nilai kunci yang membentuk tanda. Kunci adalah label umum yang bertindak seperti kategori untuk nilai tanda yang lebih spesifik.  
`value`  
Tipe: String  
Batasan Panjang: Panjang minimum 0. Panjang maksimum 256.  
Wajib: Tidak  
Bagian opsional pasangan nilai kunci yang membentuk tanda. Nilai bertindak sebagai deskriptor dalam kategori tanda (kunci).  
`enableECSManagedTags`  
Menentukan apakah akan menggunakan tag terkelola Amazon ECS untuk tugas dalam layanan. Untuk informasi selengkapnya, lihat [Gunakan tag untuk penagihan](ecs-using-tags.md#tag-resources-for-billing).  
`propagateTags`  
Tipe: String  
Nilai yang valid: `TASK_DEFINITION` \$1 `SERVICE`  
Wajib: Tidak  
Menentukan apakah akan menyalin tag dari definisi tugas atau layanan untuk tugas-tugas dalam layanan. Jika tidak ada nilai yang ditentukan, tag tidak disalin. Tag hanya dapat disalin ke tugas dalam layanan selama pembuatan layanan. Untuk menambahkan tag ke tugas setelah pembuatan layanan atau pembuatan tugas, gunakan tindakan `TagResource` API.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.  
`schedulingStrategy`  
Strategi penjadwalan yang akan digunakan. Layanan yang menggunakan pengendali deployment eksternal hanya mendukung strategi penjadwalan `REPLICA`.  
`placementConstraints`  
Susunan objek batasan penempatan yang akan digunakan untuk tugas di layanan Anda. Anda dapat menentukan maksimal 10 batasan per tugas (batas ini mencakup batasan dalam penentuan tugas dan batasan yang ditentukan pada waktu aktif). Jika Anda menggunakan Fargate, batasan penempatan tugas tidak didukung.  
`placementStrategy`  
Strategi batasan objek yang akan digunakan untuk tugas-tugas dalam layanan Anda. Anda dapat menentukan maksimal empat aturan strategi per layanan.

   Berikut ini adalah contoh penentuan layanan untuk membuat layanan menggunakan pengendali deployment eksternal.

   ```
   {
       "cluster": "",
       "serviceName": "",
       "desiredCount": 0,
       "role": "",
       "deploymentConfiguration": {
           "maximumPercent": 0,
           "minimumHealthyPercent": 0
       },
       "placementConstraints": [
           {
               "type": "distinctInstance",
               "expression": ""
           }
       ],
       "placementStrategy": [
           {
               "type": "binpack",
               "field": ""
           }
       ],
       "schedulingStrategy": "REPLICA",
       "deploymentController": {
           "type": "EXTERNAL"
       },
       "tags": [
           {
               "key": "",
               "value": ""
           }
       ],
       "enableECSManagedTags": true,
       "propagateTags": "TASK_DEFINITION"
   }
   ```

1. Buat set tugas awal. Set tugas berisi detail berikut tentang layanan Anda:  
`taskDefinition`  
Penentuan tugas untuk tugas-tugas dalam set tugas yang akan digunakan.  
`launchType`  
Tipe: String  
Nilai yang valid: `EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
Wajib: Tidak  
Jenis peluncuran untuk menjalankan layanan Anda. Jika jenis peluncuran tidak ditentukan, default `capacityProviderStrategy` digunakan secara default.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.  
Jika `launchType` ditentukan, parameter `capacityProviderStrategy` harus dihilangkan.  
`platformVersion`  
Tipe: String  
Wajib: Tidak  
Versi platform tempat tugas Anda dalam layanan berjalan. Versi platform hanya ditentukan untuk tugas yang menggunakan tipe peluncuran Fargate. Jika tidak ditentukan, versi terbaru (`LATEST`) digunakan secara default.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.  
AWS Versi platform Fargate digunakan untuk merujuk ke lingkungan runtime tertentu untuk infrastruktur tugas Fargate. Saat menentukan versi `LATEST` platform saat menjalankan tugas atau membuat layanan, Anda mendapatkan versi platform terbaru yang tersedia untuk tugas Anda. Saat Anda meningkatkan layanan, tugas tersebut menerima versi platform yang ditentukan pada penerapan layanan saat ini. Untuk informasi selengkapnya, lihat [Versi platform Fargate untuk Amazon ECS](platform-fargate.md).  
Versi platform tidak ditentukan untuk tugas yang menggunakan tipe peluncuran EC2.  
`loadBalancers`  
Objek penyeimbang beban yang mewakili penyeimbang beban yang akan digunakan bersama layanan Anda. Saat menggunakan pengontrol penyebaran eksternal, hanya Application Load Balancer dan Network Load Balancer yang didukung. Jika Anda menggunakan Application Load Balancer, hanya satu grup target Application Load Balancer yang diizinkan per set tugas.  
Cuplikan berikut menunjukkan contoh `loadBalancer` objek untuk digunakan.  

   ```
   "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
   ]
   ```
Saat menentukan objek `loadBalancer`, Anda harus menentukan `targetGroupArn` dan menghilangkan parameter `loadBalancerName`.  
`networkConfiguration`  
Konfigurasi jaringan untuk layanan. Parameter ini diperlukan untuk penentuan tugas yang menggunakan mode jaringan `awsvpc` untuk menerima antarmuka jaringan elastisnya sendiri, dan tidak didukung untuk mode jaringan lainnya. Untuk informasi lebih lanjut tentang jaringan untuk Fargate, lihat. [Opsi jaringan tugas Amazon ECS untuk Fargate](fargate-task-networking.md)  
`serviceRegistries`  
Detail registri penemuan layanan yang akan ditetapkan ke layanan ini. Untuk informasi selengkapnya, lihat [Gunakan penemuan layanan untuk menghubungkan layanan Amazon ECS dengan nama DNS](service-discovery.md).  
`scale`  
Persentase titik mengambang dari jumlah tugas yang diinginkan untuk menempatkan dan agar tetap berjalan di serangkaian tugas. Nilai ditetapkan sebagai total persentase dari `desiredCount` layanan. Nilai yang diterima adalah angka antara 0 hingga 100.

   Berikut ini adalah contoh JSON untuk membuat set tugas untuk pengendali deployment eksternal.

   ```
   {
       "service": "",
       "cluster": "",
       "externalId": "",
       "taskDefinition": "",
       "networkConfiguration": {
           "awsvpcConfiguration": {
               "subnets": [
                   ""
               ],
               "securityGroups": [
                   ""
               ],
               "assignPublicIp": "DISABLED"
           }
       },
       "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
       ],
       "serviceRegistries": [
           {
               "registryArn": "",
               "port": 0,
               "containerName": "",
               "containerPort": 0
           }
       ],
       "launchType": "EC2",
       "capacityProviderStrategy": [
           {
               "capacityProvider": "",
               "weight": 0,
               "base": 0
           }
       ],
       "platformVersion": "",
       "scale": {
           "value": null,
           "unit": "PERCENT"
       },
       "clientToken": ""
   }
   ```

1. Saat perubahan layanan dibutuhkan, gunakan tindakan API `UpdateService`, `UpdateTaskSet`, atau `CreateTaskSet` tergantung pada parameter mana yang Anda perbarui. Jika Anda membuat set tugas, maka gunakan parameter `scale` untuk setiap set tugas di layanan untuk menentukan berapa banyak tugas yang harus tetap berjalan di layanan. Misalnya, jika Anda memiliki layanan yang berisi `tasksetA` dan Anda membuat `tasksetB`, maka Anda dapat menguji validitas `tasksetB` sebelum akan menransisikan lalu lintas produksi ke sana. Anda dapat mengatur `scale` untuk kedua set tugas ke `100`, dan saat Anda siap untuk menransisikan semua lalu lintas produksi ke `tasksetB`, Anda dapat memperbarui `scale` untuk `tasksetA` ke `0` untuk menurunkan skalanya.

# CodeDeploy penerapan biru/hijau untuk Amazon ECS
<a name="deployment-type-bluegreen"></a>

Kami menyarankan Anda menggunakan blue/green penyebaran Amazon ECS. Untuk informasi selengkapnya, lihat [Membuat penyebaran Amazon ECS blue/green](deploy-blue-green-service.md).

Tipe penyebaran *biru/hijau* menggunakan model blue/green penerapan yang dikendalikan oleh. CodeDeploy Gunakan jenis penerapan ini untuk memverifikasi penyebaran layanan baru sebelum mengirim lalu lintas produksi ke layanan tersebut. Untuk informasi selengkapnya, lihat [Apa yang ada CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) di *Panduan AWS CodeDeploy Pengguna*. Memvalidasi status layanan Amazon ECS sebelum penerapan

Ada tiga cara lalu lintas dapat bergeser selama blue/green penyebaran:
+ **Canary** — Lalu lintas digeser dalam dua peningkatan. Anda dapat memilih dari opsi Canary yang telah ditentukan sebelumnya yang menentukan persentase lalu lintas yang dialihkan ke set tugas yang diperbarui pada kenaikan pertama dan interval, dalam menit, sebelum lalu lintas yang tersisa dialihkan pada kenaikan kedua.
+ **Linear** — Lalu lintas digeser dalam peningkatan yang sama dengan jumlah menit yang sama antara setiap kenaikan. Anda dapat memilih dari opsi linier yang telah ditentukan sebelumnya yang menentukan persentase lalu lintas yang dialihkan pada setiap kenaikan dan jumlah menit di antara setiap kenaikan.
+ **A ll-at-once** - Semua lalu lintas digeser dari set tugas asli ke set tugas yang diperbarui sekaligus.

Berikut ini adalah komponen Amazon ECS CodeDeploy yang digunakan saat layanan menggunakan jenis blue/green penerapan:

**CodeDeploy aplikasi**  
Kumpulan sumber CodeDeploy daya. Ini terdiri dari satu atau beberapa grup deployment.

**CodeDeploy kelompok penyebaran**  
Pengaturan deployment. Pengaturan tersebut terdiri dari hal-hal berikut:  
+ Klaster dan layanan Amazon ECS
+ Grup target penyeimbang beban dan informasi pendengar
+ Strategi roll back deployment
+ Pengaturan perutean ulang lalu lintas
+ Pengaturan pengakhiran revisi asli
+ Konfigurasi deployment
+ CloudWatch konfigurasi alarm yang dapat diatur untuk menghentikan penerapan
+ Pengaturan SNS atau CloudWatch Acara untuk notifikasi
Untuk informasi selengkapnya, lihat [Bekerja dengan Grup Penerapan](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) di *Panduan AWS CodeDeploy Pengguna*.

**CodeDeploy konfigurasi penerapan**  
Menentukan bagaimana CodeDeploy rute lalu lintas produksi ke tugas pengganti Anda ditetapkan selama penerapan. Konfigurasi deployment canary dan linier yang telah ditentukan berikut ini tersedia. Anda juga dapat membuat deployment canary dan linier yang ditentukan secara khusus. Untuk informasi selengkapnya, lihat [Bekerja dengan Konfigurasi Penerapan](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) di *AWS CodeDeploy Panduan Pengguna*.  
+ **CodeDeployDefault. ECSAllAtOnce**: Menggeser semua lalu lintas ke wadah Amazon ECS yang diperbarui sekaligus
+ **CodeDeployDefault. ECSLinear10PercentEvery1Menit**: Menggeser 10 persen lalu lintas setiap menit sampai semua lalu lintas bergeser.
+ **CodeDeployDefault. ECSLinear10PercentEvery3 Menit**: Menggeser 10 persen lalu lintas setiap 3 menit sampai semua lalu lintas bergeser.
+ **CodeDeployDefault. ECSCanary10Persent5Menit**: Menggeser 10 persen lalu lintas pada kenaikan pertama. 90 persen sisanya di-deploy lima menit kemudian.
+ **CodeDeployDefault. ECSCanary10Persent15 Menit**: Menggeser 10 persen lalu lintas pada kenaikan pertama. Sisa 90 persen di-deploy 15 menit kemudian.

**Revisi**  
Revisi adalah file spesifikasi CodeDeploy aplikasi (AppSpec file). Dalam AppSpec file tersebut, Anda menentukan ARN lengkap dari definisi tugas dan wadah serta port set tugas pengganti Anda di mana lalu lintas akan dirutekan saat penerapan baru dibuat. Nama kontainer harus merupakan salah satu dari nama kontainer yang direferensikan dalam penentuan tugas Anda. Jika konfigurasi jaringan atau versi platform telah diperbarui dalam definisi layanan, Anda juga harus menentukan detail tersebut dalam AppSpec file. Anda juga dapat menentukan fungsi Lambda yang akan dijalankan selama peristiwa siklus hidup penerapan. Fungsi Lambda memungkinkan Anda menjalankan pengujian dan mengembalikan metrik selama penerapan. Untuk informasi selengkapnya, lihat [Referensi AppSpec File](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html) di *Panduan AWS CodeDeploy Pengguna*.

## Pertimbangan-pertimbangan
<a name="deployment-type-bluegreen-considerations"></a>

Pertimbangkan hal berikut saat menggunakan jenis blue/green penerapan:
+ Saat layanan Amazon ECS yang menggunakan jenis blue/green penerapan awalnya dibuat, kumpulan tugas Amazon ECS dibuat.
+ Anda harus mengonfigurasi layanan untuk menggunakan Application Load Balancer atau Network Load Balancer. Berikut ini adalah persyaratan penyeimbang beban:
  + Anda harus menambahkan listener produksi ke penyeimbang beban, yang digunakan untuk merutekan lalu lintas produksi.
  + Listener uji opsional dapat ditambahkan ke penyeimbang beban, yang digunakan untuk merutekan lalu lintas uji. Jika Anda menentukan listener pengujian, CodeDeploy rute lalu lintas pengujian Anda ke set tugas pengganti selama penerapan.
  + Baik listener produksi maupun listener uji, harus memiliki penyeimbang beban yang sama.
  + Anda harus menentukan grup target untuk penyeimbang beban. Grup target merutekan lalu lintas ke set tugas asli yang di layanan melalui listener produksi.
  + Ketika Network Load Balancer digunakan, hanya konfigurasi `CodeDeployDefault.ECSAllAtOnce` penerapan yang didukung.
+ Untuk layanan yang dikonfigurasi untuk menggunakan penskalaan otomatis layanan dan tipe deployment biru/hijau, penskalaan otomatis tidak akan diblokir selama deployment, akan tetapi deployment mungkin akan mengalami kegagalan di beberapa keadaan. Hal-hal berikut menjelaskan perilaku tersebut secara lebih detail.
  + Jika layanan sedang diskalakan dan penerapan dimulai, set tugas hijau dibuat dan CodeDeploy akan menunggu hingga satu jam untuk tugas hijau yang disetel mencapai kondisi tunak dan tidak akan mengalihkan lalu lintas apa pun hingga selesai.
  + Jika layanan sedang dalam proses blue/green penyebaran dan peristiwa penskalaan terjadi, lalu lintas akan terus bergeser selama 5 menit. Jika layanan tidak mencapai kondisi tunak dalam 5 menit, CodeDeploy akan menghentikan penerapan dan menandainya sebagai gagal.
+ Tugas yang menggunakan Fargate atau jenis pengontrol `CODE_DEPLOY` penerapan tidak mendukung strategi penjadwalan. `DAEMON`
+ Saat Anda awalnya membuat grup CodeDeploy aplikasi dan penyebaran, Anda harus menentukan yang berikut:
  + Anda harus menentukan dua grup target untuk penyeimbang beban. Satu grup target harus menjadi grup target awal yang ditentukan untuk penyeimbang beban saat layanan Amazon ECS dibuat. Satu-satunya persyaratan grup target kedua adalah tidak dapat dikaitkan dengan penyeimbang beban yang berbeda dari yang digunakan oleh layanan.
+ Saat Anda membuat CodeDeploy penerapan untuk layanan Amazon ECS, CodeDeploy buat *set tugas pengganti (atau set* *tugas hijau*) dalam penerapan. Jika Anda menambahkan pendengar pengujian ke penyeimbang beban, CodeDeploy rute lalu lintas pengujian Anda ke set tugas pengganti. Ini adalah saat Anda dapat menjalankan uji validasi apa pun. Kemudian CodeDeploy merutekan ulang lalu lintas produksi dari set tugas asli ke set tugas pengganti sesuai dengan pengaturan perutean ulang lalu lintas untuk grup deployment.

## Izin IAM yang diperlukan
<a name="deployment-type-bluegreen-IAM"></a>

Blue/green deployments are made possible by a combination of the Amazon ECS and CodeDeploy APIs. Users must have the appropriate permissions for these services before they can use Amazon ECS blue/greenpenyebaran di Konsol Manajemen AWS atau dengan atau. AWS CLI SDKs 

Selain izin IAM standar untuk membuat dan memperbarui layanan, Amazon ECS memerlukan izin berikut. Izin ini telah ditambahkan ke kebijakan `AmazonECS_FullAccess` IAM. Untuk informasi selengkapnya, lihat [Amazonecs\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess).
+ `codedeploy:CreateApplication`
+ `codedeploy:CreateDeployment`
+ `codedeploy:CreateDeploymentGroup`
+ `codedeploy:GetApplication`
+ `codedeploy:GetDeployment`
+ `codedeploy:GetDeploymentGroup`
+ `codedeploy:ListApplications`
+ `codedeploy:ListDeploymentGroups`
+ `codedeploy:ListDeployments`
+ `codedeploy:StopDeployment`
+ `codedeploy:GetDeploymentTarget`
+ `codedeploy:ListDeploymentTargets`
+ `codedeploy:GetDeploymentConfig`
+ `codedeploy:GetApplicationRevision`
+ `codedeploy:RegisterApplicationRevision`
+ `codedeploy:BatchGetApplicationRevisions`
+ `codedeploy:BatchGetDeploymentGroups`
+ `codedeploy:BatchGetDeployments`
+ `codedeploy:BatchGetApplications`
+ `codedeploy:ListApplicationRevisions`
+ `codedeploy:ListDeploymentConfigs`
+ `codedeploy:ContinueDeployment`
+ `sns:ListTopics`
+ `cloudwatch:DescribeAlarms`
+ `lambda:ListFunctions`

**catatan**  
Selain izin Amazon ECS standar yang diperlukan untuk menjalankan tugas dan layanan, pengguna juga memerlukan `iam:PassRole` izin untuk menggunakan peran IAM untuk tugas.

CodeDeploy memerlukan izin untuk memanggil Amazon ECS APIs, memodifikasi Elastic Load Balancing, menjalankan fungsi Lambda, dan CloudWatch menjelaskan alarm, serta izin untuk mengubah jumlah layanan yang diinginkan atas nama Anda. Sebelum membuat layanan Amazon ECS yang menggunakan jenis blue/green penyebaran, Anda harus membuat peran IAM (). `ecsCodeDeployRole` Untuk informasi selengkapnya, lihat [Peran Amazon ECS CodeDeploy IAM](codedeploy_IAM_role.md).

# Migrasikan penerapan CodeDeploy blue/green deployments to Amazon ECS blue/green
<a name="migrate-codedeploy-to-ecs-bluegreen"></a>

CodeDeploy blue/green and Amazon ECS blue/greenpenerapan menyediakan fungsionalitas serupa, tetapi berbeda dalam cara Anda mengonfigurasi dan mengelolanya.

## CodeDeploy ikhtisar penyebaran biru/hijau
<a name="codedeploy-bluegreen-overview"></a>

Saat membuat layanan Amazon ECS menggunakan CodeDeploy, Anda:

1. Buat penyeimbang beban dengan pendengar produksi dan (opsional) pendengar pengujian. Setiap pendengar dikonfigurasi dengan aturan tunggal (default) yang merutekan semua lalu lintas ke satu grup target (grup target utama).

1. Buat layanan Amazon ECS, dikonfigurasi untuk menggunakan pendengar dan grup target, dengan `deploymentController` jenis yang disetel ke. `CODE_DEPLOY` Pembuatan layanan menghasilkan pembuatan set tugas (biru) yang terdaftar dengan grup target yang ditentukan.

1. Buat grup CodeDeploy penyebaran (sebagai bagian dari CodeDeploy aplikasi), dan konfigurasikan dengan detail cluster Amazon ECS, nama layanan, pendengar penyeimbang beban, dua grup target (grup target utama yang digunakan dalam aturan pendengar produksi, dan grup target sekunder yang akan digunakan untuk tugas pengganti), peran layanan (untuk memberikan izin CodeDeploy untuk memanipulasi Amazon ECS dan sumber daya Elastic Load Balancing) dan berbagai parameter yang mengontrol perilaku penerapan.

Dengan CodeDeploy, versi baru layanan digunakan menggunakan`CreateDeployment()`, menentukan nama CodeDeploy aplikasi, nama grup penyebaran, dan AppSpec file yang memberikan rincian revisi baru dan kait siklus hidup opsional. CodeDeploy Penerapan membuat set tugas pengganti (hijau) dan mendaftarkan tugasnya dengan kelompok target sekunder. Ketika ini menjadi sehat, tersedia untuk pengujian (opsional) dan untuk produksi. Dalam kedua kasus, perutean ulang dicapai dengan mengubah aturan pendengar masing-masing untuk menunjuk ke kelompok target sekunder yang terkait dengan set tugas hijau. Rollback dicapai dengan mengubah aturan pendengar produksi kembali ke grup target utama.

## Ikhtisar blue/green penyebaran Amazon ECS
<a name="ecs-bluegreen-overview"></a>

Dengan blue/green penerapan Amazon ECS, Konfigurasi penyebaran adalah bagian dari layanan Amazon ECS itu sendiri:

1. Anda harus melakukan pra-konfigurasi pendengar produksi penyeimbang beban dengan aturan yang mencakup dua grup target dengan bobot 1 dan 0.

1. Anda perlu menentukan sumber daya berikut, atau memperbarui sumber daya layanan: 
   + ARN dari aturan pendengar ini 
   + Kedua kelompok sasaran
   + Peran IAM untuk memberikan izin Amazon ECS untuk memanggil Elastic Load Balancing APIs
   + Peran IAM opsional untuk menjalankan fungsi Lambda
   + Atur `deploymentController` tipe ke `ECS` dan `deploymentConfiguration.strategy` ke`BLUE_GREEN`. Ini menghasilkan pembuatan penyebaran layanan (biru) yang tugasnya terdaftar pada kelompok target utama.

Dengan Amazon ECS biru/hijau, revisi layanan baru dibuat dengan menelepon Amazon ECS`UpdateService()`, memberikan rincian revisi baru. Penyebaran layanan membuat tugas revisi layanan baru (hijau) dan mendaftarkannya ke grup target sekunder. Amazon ECS menangani operasi perutean ulang dan rollback dengan mengalihkan bobot pada aturan pendengar.

## Perbedaan implementasi utama
<a name="implementation-differences"></a>

Sementara kedua pendekatan menghasilkan pembuatan serangkaian tugas awal, implementasi yang mendasarinya berbeda:
+ CodeDeploy menggunakan set tugas, sedangkan Amazon ECS menggunakan revisi layanan. Kumpulan tugas Amazon ECS adalah konstruksi lama yang telah digantikan oleh revisi dan penerapan layanan Amazon ECS. Yang terakhir menawarkan visibilitas yang lebih besar ke dalam proses penyebaran, serta penyebaran layanan dan riwayat revisi layanan.
+ Dengan CodeDeploy, kait siklus hidup ditentukan sebagai bagian dari AppSpec file yang dipasok ke. `CreateDeployment()` Ini berarti bahwa kait dapat diubah dari satu penerapan ke penerapan berikutnya. Dengan Amazon ECS biru/hijau, kait ditentukan sebagai bagian dari konfigurasi layanan, dan pembaruan apa pun akan memerlukan panggilan. `UpdateService()`
+ Keduanya CodeDeploy dan Amazon ECS blue/green menggunakan Lambda untuk implementasi hook, tetapi input dan output yang diharapkan berbeda.

  Dengan CodeDeploy, fungsi harus memanggil `PutLifecycleEventHookExecutionStatus()` untuk mengembalikan status hook, yang bisa berupa `SUCCEEDED` atau`FAILED`. Dengan Amazon ECS, respons Lambda digunakan untuk menunjukkan status hook.
+ CodeDeploy memanggil setiap hook sebagai panggilan satu kali, dan mengharapkan status eksekusi akhir akan dikembalikan dalam waktu satu jam. Kait Amazon ECS lebih fleksibel karena dapat mengembalikan `IN_PROGRESS` indikator, yang menandakan bahwa kait harus dipanggil kembali berulang kali hingga menghasilkan atau. `SUCCEEDED` `FAILED` Untuk informasi selengkapnya, lihat [Kait siklus hidup untuk penerapan layanan Amazon ECS](deployment-lifecycle-hooks.md).

## Pendekatan migrasi
<a name="migration-paths"></a>

Ada tiga pendekatan utama untuk bermigrasi dari CodeDeploy blue/green to Amazon ECS blue/green penerapan. Setiap pendekatan memiliki karakteristik yang berbeda dalam hal kompleksitas, risiko, kemampuan rollback, dan potensi downtime.

### Menggunakan kembali sumber daya Elastic Load Balancing yang sama dengan yang digunakan CodeDeploy
<a name="inplace-update"></a>

Anda memperbarui layanan Amazon ECS yang ada untuk menggunakan pengontrol penyebaran Amazon ECS dengan strategi penerapan, bukan pengontrol blue/green penerapan. CodeDeploy Pertimbangkan hal berikut saat menggunakan pendekatan ini:
+ Prosedur migrasi lebih sederhana karena Anda memperbarui pengontrol penyebaran dan strategi penyebaran layanan Amazon ECS yang ada.
+ Tidak ada downtime saat dikonfigurasi dan dimigrasikan dengan benar.
+ Rollback mengharuskan Anda mengembalikan revisi layanan.
+ Risikonya tinggi karena tidak ada konfigurasi paralel biru/hijau.

Anda menggunakan pendengar penyeimbang beban dan grup target yang sama dengan yang digunakan. CodeDeploy Jika Anda menggunakan CloudFormation, lihat[Migrasi template CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green CloudFormation](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md).

1. Ubah aturan default production/test pendengar untuk menyertakan grup target alternatif dan atur bobot grup target utama menjadi 1 dan grup target alternatif ke 0.

   Untuk CodeDeploy, pendengar penyeimbang beban yang dilampirkan ke layanan dikonfigurasi dengan aturan tunggal (default) yang merutekan semua lalu lintas ke satu grup target. Untuk Amazon ECS biru/hijau, pendengar penyeimbang beban harus dikonfigurasi sebelumnya dengan aturan yang mencakup dua grup target dengan bobot. Kelompok target utama harus diberi bobot ke 1 dan kelompok target alternatif harus diberi bobot ke 0.

1. Perbarui layanan Amazon ECS yang ada dengan memanggil `UpdateService` API dan menyetel parameter `deploymentController` ke`ECS`, dan parameter `deploymentStrategy` ke`BLUE_GREEN`. Tentukan ARNs grup target, grup target alternatif, pendengar produksi, dan pendengar uji opsional.

1. Verifikasi bahwa layanan berfungsi seperti yang diharapkan.

1. Hapus CodeDeploy pengaturan untuk layanan Amazon ECS ini karena Anda sekarang menggunakan Amazon ECS biru/hijau.

### Layanan baru dengan penyeimbang beban yang ada
<a name="new-service-existing-lb"></a>

Pendekatan ini menggunakan blue/green strategi untuk migrasi. 

Pertimbangkan hal berikut saat menggunakan pendekatan ini:
+ Ada gangguan minimal. Ini hanya terjadi selama pertukaran port Elastic Load Balancing.
+ Rollback mengharuskan Anda mengembalikan swap port Elastic Load Balancing.
+ Risikonya rendah karena ada konfigurasi paralel. Oleh karena itu Anda dapat menguji sebelum shift lalu lintas.

1. Biarkan pendengar, grup target, dan layanan Amazon ECS untuk CodeDeploy penyiapan utuh sehingga Anda dapat dengan mudah mengembalikan ke pengaturan ini jika diperlukan.

1. Buat grup target baru dan pendengar baru (dengan port berbeda dari pendengar asli) di bawah penyeimbang beban yang ada. Kemudian, buat layanan Amazon ECS baru yang cocok dengan layanan Amazon ECS yang ada kecuali yang Anda gunakan `ECS` sebagai pengontrol penerapan, `BLUE_GREEN` sebagai strategi penerapan, dan teruskan ARNs untuk grup target baru dan aturan pendengar baru.

1. Verifikasi pengaturan baru dengan mengirim lalu lintas HTTP secara manual ke layanan. Jika semuanya berjalan dengan baik, tukar port pendengar asli dan pendengar baru untuk mengarahkan lalu lintas ke pengaturan baru.

1. Verifikasi pengaturan baru, dan jika semuanya terus berfungsi seperti yang diharapkan, hapus CodeDeploy pengaturan.

### Layanan baru dengan penyeimbang beban baru
<a name="new-service-new-lb"></a>

Seperti pendekatan sebelumnya, pendekatan ini menggunakan blue/green strategi untuk migrasi. Perbedaan utamanya adalah peralihan dari CodeDeploy pengaturan ke pengaturan Amazon ECS blue/green terjadi pada lapisan proxy terbalik di atas penyeimbang beban. Contoh implementasi untuk lapisan proxy terbalik adalah Route 53 dan CloudFront.

Pendekatan ini cocok untuk pelanggan yang sudah memiliki lapisan proxy terbalik ini, dan jika semua komunikasi dengan layanan terjadi melaluinya (misalnya, tidak ada komunikasi langsung di tingkat penyeimbang beban).

Pertimbangkan hal berikut saat menggunakan pendekatan ini:
+ Ini membutuhkan lapisan proxy terbalik.
+ Prosedur migrasi lebih kompleks karena Anda perlu memperbarui pengontrol penyebaran dan strategi penyebaran layanan Amazon ECS yang ada.
+ Ada gangguan minimal. Ini hanya terjadi selama pertukaran port Elastic Load Balancing.
+ Rollback mengharuskan Anda membalikkan perubahan konfigurasi proxy.
+ Risikonya rendah karena ada konfigurasi paralel. Oleh karena itu Anda dapat menguji sebelum shift lalu lintas.

1. Jangan mengubah CodeDeploy pengaturan yang ada secara utuh (penyeimbang beban, pendengar, grup target, layanan Amazon ECS, dan grup penerapan). CodeDeploy 

1. Buat penyeimbang beban baru, grup target, dan pendengar yang dikonfigurasi untuk penerapan Amazon ECS. blue/green 

   Konfigurasikan sumber daya yang sesuai.
   + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
   + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)

1. Buat layanan baru dengan `ECS` sebagai pengontrol penerapan dan `BLUE_GREEN` sebagai strategi penyebaran, menunjuk ke sumber daya penyeimbang beban baru.

1. Verifikasi pengaturan baru dengan mengujinya melalui penyeimbang beban baru.

1. Perbarui konfigurasi proxy terbalik untuk merutekan lalu lintas ke penyeimbang beban baru.

1. Amati revisi layanan baru, dan jika semuanya terus berfungsi seperti yang diharapkan, hapus CodeDeploy pengaturan.

## Langkah selanjutnya
<a name="post-migration-considerations"></a>

Setelah bermigrasi ke penerapan Amazon ECS blue/green :
+ Perbarui skrip dan CI/CD pipeline penerapan Anda untuk menggunakan Amazon ECS `UpdateService` API, bukan API. CodeDeploy `CreateDeployment`
+ Perbarui pemantauan dan peringatan Anda untuk melacak penerapan layanan Amazon ECS alih-alih penerapan. CodeDeploy 
+ Pertimbangkan untuk menerapkan pengujian otomatis dari proses penerapan baru Anda untuk memastikannya berfungsi seperti yang diharapkan.

# Migrasi dari penyebaran CodeDeploy blue/green to an Amazon ECS blue/green layanan
<a name="migrate-code-deploy-to-ecs-blue-green"></a>

 Dengan menggunakan blue/green penerapan Amazon ECS, Anda dapat membuat dan menguji perubahan layanan sebelum menerapkannya di lingkungan produksi. 

Anda harus membuat kait siklus hidup baru untuk penerapan Amazon ECS Anda. blue/green 

## Prasyarat
<a name="migrate-code-deploy-to-ecs-blue-green-prerequisites"></a>

Lakukan operasi berikut sebelum Anda memulai blue/green penerapan.

1. Ganti peran Amazon ECS CodeDeploy IAM dengan izin berikut.
   + Untuk informasi tentang izin Elastic Load Balancing, lihat. [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)
   + Untuk informasi tentang izin Lambda, lihat. [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md)

1. Matikan CodeDeploy otomatisasi. Untuk informasi selengkapnya, lihat [Bekerja dengan grup penerapan CodeDeploy di](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) *Panduan CodeDeploy Pengguna*. 

1. Pastikan Anda memiliki informasi berikut dari CodeDeploy blue/green deployment. You can reuse this information for the Amazon ECS blue/green penerapan Anda:
   + Kelompok sasaran produksi
   + Pendengar produksi
   + Aturan produksi
   + Kelompok sasaran uji

     Ini adalah kelompok sasaran untuk revisi layanan hijau,

1. Pastikan grup target Application Load Balancer terkait dengan aturan listener dengan benar:
   + Jika Anda tidak menggunakan pendengar pengujian, kedua grup target (produksi dan pengujian) harus dikaitkan dengan aturan pendengar produksi.
   + Jika Anda menggunakan pendengar pengujian, satu grup target harus ditautkan ke aturan pendengar produksi dan grup target lainnya harus ditautkan ke aturan pendengar pengujian.

   Jika persyaratan ini tidak terpenuhi, penyebaran layanan akan gagal dengan kesalahan berikut: `Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.`

1. Verifikasi bahwa tidak ada penerapan layanan yang sedang berlangsung untuk layanan. Untuk informasi selengkapnya, lihat [Melihat riwayat layanan menggunakan deployment layanan Amazon ECS](service-deployment.md).

1.  blue/green Penerapan Amazon ECS mengharuskan layanan Anda menggunakan salah satu fitur berikut: Konfigurasikan sumber daya yang sesuai.
   + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
   + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)
   + Service Connect - Untuk informasi selengkapnya, lihat[Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary](service-connect-blue-green.md).

1. Putuskan apakah Anda ingin menjalankan fungsi Lambda untuk tahapan siklus hidup untuk tahapan dalam penerapan Amazon ECS. blue/green 
   + Pra skala
   + Setelah skala naik
   + Uji pergeseran lalu lintas
   + Setelah uji pergeseran lalu lintas
   + Pergeseran lalu lintas produksi
   + Setelah pergeseran lalu lintas produksi

   Buat fungsi Lambda untuk setiap tahap siklus hidup. Untuk informasi selengkapnya, lihat [Membuat fungsi Lambda dengan konsol di Panduan AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) *Pengembang*.

Untuk informasi selengkapnya tentang memperbarui pengontrol penerapan layanan, lihat[Perbarui parameter layanan Amazon ECS](update-service-parameters.md).

## Prosedur
<a name="migrate-code-deploy-to-ecs-procedure"></a>

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

   Halaman detail cluster ditampilkan.

1. Dari tab **Layanan**, pilih layanan.

   Halaman detail layanan ditampilkan.

1. Di spanduk, pilih **Perbarui jenis pengontrol penerapan**.

   Halaman **jenis pengontrol penyebaran Migrasi** ditampilkan.

1. Perluas **Baru**, lalu tentukan parameter berikut.

   1. Untuk **jenis pengontrol Deployment**, pilih **ECS**.

   1. Untuk **strategi Deployment**, pilih **Biru/hijau**.

   1. Untuk **waktu Panggang**, masukkan waktu revisi layanan biru dan hijau berjalan.

   1. Untuk menjalankan fungsi Lambda untuk tahap siklus hidup, di bawah **Deployment lifecyce hooks** lakukan hal berikut untuk setiap fungsi Lambda yang unik:

      1. Pilih **Tambahkan**.

         Ulangi untuk setiap fungsi unik yang ingin Anda jalankan.

      1. Untuk **fungsi Lambda**, masukkan nama fungsi.

      1. Untuk **Peran**, pilih peran yang Anda buat dalam prasyarat dengan izin biru/hijau.

         Untuk informasi selengkapnya, lihat [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md).

      1. Untuk tahapan **Siklus Hidup, pilih tahapan** yang dijalankan fungsi Lambda.

      1.  (Opsional) Untuk **detail Hook**, masukkan pasangan kunci-nilai yang memberikan informasi tentang hook.

1. Perluas **Load Balancing**, dan konfigurasikan berikut ini:

   1. Untuk **Peran**, pilih peran yang Anda buat dalam prasyarat dengan izin. blue/green 

      Untuk informasi selengkapnya, lihat [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md).

   1. Untuk **Listener**, pilih pendengar produksi dari penerapan CodeDeploy biru/hijau Anda.

   1. Untuk **aturan Produksi**, pilih aturan produksi dari penerapan CodeDeploy biru/hijau Anda.

   1. Untuk **aturan Uji**, pilih aturan pengujian dari penerapan CodeDeploy biru/hijau Anda.

   1. Untuk **grup Target**, pilih grup target produksi dari penyebaran CodeDeploy biru/hijau Anda.

   1. Untuk **grup target Alternatif, pilih grup** target pengujian dari penerapan CodeDeploy biru/hijau Anda.

1. Pilih **Perbarui**.

## Langkah selanjutnya
<a name="migrate-code-deploy-to-ecs-blue-green-next-steps"></a>
+ Perbarui layanan untuk memulai penyebaran. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).
+ Pantau proses penyebaran untuk memastikannya mengikuti pola biru/hijau:
  + Revisi layanan hijau dibuat dan ditingkatkan
  + Lalu lintas uji diarahkan ke revisi hijau (jika dikonfigurasi)
  + Lalu lintas produksi dialihkan ke revisi hijau
  + Setelah waktu memanggang, revisi biru dihentikan

# Migrasi template CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green CloudFormation
<a name="migrate-codedeploy-to-ecs-bluegreen-cloudformation-template"></a>

Migrasikan CloudFormation template yang menggunakan strategi CodeDeploy blue/green deployments for Amazon ECS services to one that uses the native Amazon ECS blue/green penerapan. Migrasi mengikuti pendekatan “Gunakan kembali sumber daya Elastic Load Balancing yang sama yang digunakan CodeDeploy untuk”. Untuk informasi selengkapnya, lihat [Migrasikan penerapan CodeDeploy blue/green deployments to Amazon ECS blue/green](migrate-codedeploy-to-ecs-bluegreen.md).

## Template sumber
<a name="source-template"></a>

Template ini menggunakan `AWS::CodeDeployBlueGreen` transform dan `AWS::CodeDeploy::BlueGreen` hook untuk mengimplementasikan blue/green penerapan untuk layanan Amazon ECS.

### Sumber
<a name="code-deploy-source"></a>

Ini adalah CloudFormation template lengkap menggunakan penyebaran CodeDeploy biru/hijau. *Untuk informasi selengkapnya, lihat [contoh templat penerapan biru/hijau di Panduan](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json) Pengguna: AWS CloudFormation *

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Transform": [
    "AWS::CodeDeployBlueGreen"
  ],
  "Hooks": {
    "CodeDeployBlueGreenHook": {
      "Type": "AWS::CodeDeploy::BlueGreen",
      "Properties": {
        "TrafficRoutingConfig": {
          "Type": "TimeBasedCanary",
          "TimeBasedCanary": {
            "StepPercentage": 15,
            "BakeTimeMins": 5
          }
        },
        "Applications": [
          {
            "Target": {
              "Type": "AWS::ECS::Service",
              "LogicalID": "ECSDemoService"
            },
            "ECSAttributes": {
              "TaskDefinitions": [
                "BlueTaskDefinition",
                "GreenTaskDefinition"
              ],
              "TaskSets": [
                "BlueTaskSet",
                "GreenTaskSet"
              ],
              "TrafficRouting": {
                "ProdTrafficRoute": {
                  "Type": "AWS::ElasticLoadBalancingV2::Listener",
                  "LogicalID": "ALBListenerProdTraffic"
                },
                "TargetGroups": [
                  "ALBTargetGroupBlue",
                  "ALBTargetGroupGreen"
                ]
              }
            }
          }
        ]
      }
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "EXTERNAL"
        }
      }
    },
    "BlueTaskSet": {
      "Type": "AWS::ECS::TaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "LaunchType": "FARGATE",
        "NetworkConfiguration": {
          "AwsVpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "PlatformVersion": "1.4.0",
        "Scale": {
          "Unit": "PERCENT",
          "Value": 100
        },
        "Service": {"Ref": "ECSDemoService"},
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}
          }
        ]
      }
    },
    "PrimaryTaskSet": {
      "Type": "AWS::ECS::PrimaryTaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "Service": {"Ref": "ECSDemoService"},
        "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]}
      }
    }
  }
}
```

## Langkah migrasi
<a name="migration-steps"></a>

### Hapus CodeDeploy sumber daya spesifik
<a name="remove-codedeploy-resources"></a>

Anda tidak lagi membutuhkan properti berikut:
+ `AWS::CodeDeployBlueGreen`Transformasi
+ `CodeDeployBlueGreenHook`Kaitnya
+ `GreenTaskSet`Sumber daya `GreenTaskDefinition` dan sumber daya (ini akan dikelola oleh Amazon ECS)
+ Sumber `PrimaryTaskSet` daya (Amazon ECS akan mengelola set tugas secara internal)

### Konfigurasikan ulang pendengar penyeimbang beban
<a name="reconfigure-load-balancer"></a>

Ubah `ALBListenerProdTraffic` sumber daya untuk menggunakan tindakan maju dengan dua kelompok target:

```
{
  "DefaultActions": [
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "Weight": 1
          },
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
            "Weight": 0
          }
        ]
      }
    }
  ]
}
```

### Perbarui properti penerapan
<a name="update-ecs-service"></a>

Perbarui dan tambahkan yang berikut ini:
+ Ubah `DeploymentController` properti dari `EXTERNAL` ke`ECS`.
+ Tambahkan `Strategy` properti dan atur ke BLUE\$1GREEN.
+ Tambahkan `BakeTimeInMinutes` properti.

  ```
  {
    "DeploymentConfiguration": {
      "MaximumPercent": 200,
      "MinimumHealthyPercent": 100,
      "DeploymentCircuitBreaker": {
        "Enable": true,
        "Rollback": true
      },
      "BakeTimeInMinutes": 5,
      "Strategy": "BLUE_GREEN"
    }
  }
  ```
+ Tambahkan konfigurasi penyeimbang beban ke layanan:

  ```
  {
    "LoadBalancers": [
      {
        "ContainerName": "DemoApp",
        "ContainerPort": 80,
        "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
        "AdvancedConfiguration": {
          "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
          "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
          "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
        }
      }
    ]
  }
  ```
+ Tambahkan referensi definisi tugas ke layanan:

  ```
  {
    "TaskDefinition": {"Ref": "BlueTaskDefinition"}
  }
  ```

### Buat ECSInfrastructure RolePolicyForLoadBalancers peran Amazon
<a name="create-ecs-service-role"></a>

Tambahkan peran IAM baru yang memungkinkan Amazon ECS mengelola sumber daya penyeimbang beban. Untuk informasi selengkapnya, lihat [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)

## Rekomendasi pengujian
<a name="testing-recommendations"></a>

1. Menerapkan template yang dimigrasi ke lingkungan non-produksi.

1. Verifikasi bahwa layanan diterapkan dengan benar dengan konfigurasi awal.

1. Uji penerapan dengan memperbarui definisi tugas dan mengamati proses penerapan biru/hijau.

1. Verifikasi bahwa lalu lintas bergeser dengan benar antara penerapan biru dan hijau.

1. Uji fungsionalitas rollback dengan memaksa kegagalan penerapan.

## Template setelah migrasi
<a name="migrated-template"></a>

### Template akhir
<a name="ecs-bluegreen-template"></a>

Ini adalah CloudFormation template lengkap menggunakan blue/green penyebaran Amazon ECS:

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "ECSInfrastructureRoleForLoadBalancers": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "AllowAccessToECSForInfrastructureManagement",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "ECS"
        },
        "DeploymentConfiguration": {
          "MaximumPercent": 200,
          "MinimumHealthyPercent": 100,
          "DeploymentCircuitBreaker": {
            "Enable": true,
            "Rollback": true
          },
          "BakeTimeInMinutes": 5,
          "Strategy": "BLUE_GREEN"
        },
        "NetworkConfiguration": {
          "AwsvpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "LaunchType": "FARGATE",
        "PlatformVersion": "1.4.0",
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "AdvancedConfiguration": {
              "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
              "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
              "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
            }
          }
        ]
      }
    }
  }
}
```

# Bermigrasi dari CodeDeploy biru/hijau ke penyebaran layanan pembaruan bergulir Amazon ECS
<a name="migrate-code-deploy-to-ecs-rolling"></a>

 Anda dapat memigrasikan penerapan layanan dari penerapan CodeDeploy biru/hijau ke penerapan pembaruan bergulir Amazon ECS. Ini menjauhkan Anda dari CodeDeploy ketergantungan untuk menggunakan penerapan terintegrasi.

Penjadwal layanan Amazon ECS menggantikan tugas yang sedang berjalan dengan tugas baru. Jumlah tugas yang ditambahkan atau dihapus Amazon ECS dari layanan selama pembaruan bergulir dikendalikan oleh konfigurasi penyebaran layanan.

## Prasyarat
<a name="migrate-code-deploy-to-ecs-rolling-prerequisites"></a>

Lakukan operasi berikut sebelum Anda memulai blue/green penerapan. 

1. Anda tidak lagi membutuhkan peran Amazon ECS CodeDeploy IAM.

1. Matikan CodeDeploy otomatisasi. Untuk informasi selengkapnya, lihat [Bekerja dengan grup penerapan CodeDeploy di](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) *Panduan CodeDeploy Pengguna*.

1. Verifikasi bahwa tidak ada penerapan layanan yang sedang berlangsung untuk layanan. Untuk informasi selengkapnya, lihat [Melihat riwayat layanan menggunakan deployment layanan Amazon ECS](service-deployment.md).

Untuk informasi selengkapnya tentang memperbarui pengontrol penerapan layanan, lihat[Perbarui parameter layanan Amazon ECS](update-service-parameters.md).

## Prosedur
<a name="migrate-code-deploy-to-ecs-rolling-procedure"></a>

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

   Halaman detail cluster ditampilkan.

1. Dari tab **Layanan**, pilih layanan.

   Halaman detail layanan ditampilkan.

1. Di spanduk, pilih **Migrasi.**

   Halaman **konfigurasi Update deployment** ditampilkan.

1. Perluas **opsi Deployment**, lalu tentukan parameter berikut.

   1. Untuk **jenis pengontrol Deployment**, pilih **ECS**.

   1. Untuk **strategi Deployment**, pilih **Pembaruan bergulir**.

   1. Untuk **tugas yang menjalankan Min**, masukkan batas bawah pada jumlah tugas dalam layanan yang harus tetap dalam `RUNNING` status selama penerapan, sebagai persentase dari jumlah tugas yang diinginkan (dibulatkan ke bilangan bulat terdekat). Untuk informasi selengkapnya, lihat [Konfigurasi penerapan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration).

   1. Untuk **tugas yang berjalan Max**, masukkan batas atas jumlah tugas dalam layanan yang diizinkan dalam `PENDING` status `RUNNING` atau selama penerapan, sebagai persentase dari jumlah tugas yang diinginkan (dibulatkan ke bilangan bulat terdekat).

1. Perluas **Load Balancing**, lalu konfigurasikan yang berikut ini:

   1. Untuk **Peran**, pilih peran yang Anda buat dalam prasyarat dengan izin. blue/green 

      Untuk informasi selengkapnya, lihat [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md).

   1. Untuk **Listener**, pilih pendengar produksi dari penerapan CodeDeploy biru/hijau Anda.

   1. Untuk **grup Target**, pilih grup target produksi dari penyebaran CodeDeploy biru/hijau Anda.

1. Pilih **Perbarui**.

## Langkah selanjutnya
<a name="migrate-code-deploy-to-ecs-rolling-next-steps"></a>

Anda harus memperbarui layanan agar perubahan diterapkan. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).

# Perbarui strategi penyebaran Amazon ECS
<a name="migrate-deployment-strategies"></a>

Amazon ECS mendukung beberapa strategi penerapan untuk memperbarui layanan Anda. Anda dapat bermigrasi di antara strategi ini berdasarkan persyaratan aplikasi Anda. Topik ini menjelaskan cara bermigrasi antara penerapan bergulir dan penerapan. blue/green 

## Memahami strategi penyebaran Amazon ECS
<a name="deployment-strategies-overview"></a>

Sebelum bermigrasi antar strategi penerapan, penting untuk memahami cara kerja setiap strategi dan perbedaan utamanya:

**Penerapan bergulir**  
Dalam penerapan bergulir, Amazon ECS menggantikan versi aplikasi yang sedang berjalan dengan versi baru. Penjadwal layanan menggunakan parameter persentase sehat minimum dan maksimum untuk menentukan strategi penerapan.  
Penyebaran bergulir lebih sederhana untuk diatur tetapi memberikan kontrol yang lebih sedikit atas proses penyebaran dan perutean lalu lintas.

**Penerapan biru/hijau**  
Dalam blue/green penerapan, Amazon ECS membuat versi baru layanan Anda (hijau) di samping versi yang ada (biru). Ini memungkinkan Anda untuk memverifikasi versi baru sebelum merutekan lalu lintas produksi ke sana.  
Penerapan biru/hijau memberikan kontrol lebih besar atas proses penyebaran, termasuk perpindahan lalu lintas, pengujian, dan kemampuan rollback.

## Praktik terbaik
<a name="migration-best-practices"></a>

Ikuti praktik terbaik ini saat bermigrasi antar strategi penerapan:
+ **Uji di lingkungan non-produksi**: Selalu uji pembaruan di lingkungan non-produksi sebelum menerapkan perubahan pada layanan produksi.
+ **Rencana untuk rollback**: Miliki rencana rollback jika pembaruan tidak berfungsi seperti yang diharapkan.
+ **Monitor selama transisi**: Pantau layanan Anda dengan cermat selama dan setelah migrasi untuk memastikannya terus beroperasi dengan benar.
+ **Perbarui dokumentasi**: Perbarui dokumentasi penerapan Anda untuk mencerminkan strategi penerapan baru.
+ **Pertimbangkan dampak lalu lintas**: Pahami bagaimana pembaruan dapat memengaruhi lalu lintas ke layanan Anda dan rencanakan dengan tepat.

# Memperbarui strategi penerapan dari pembaruan bergulir ke Amazon ECS biru/hijau
<a name="update-rolling-to-bluegreen"></a>

Anda dapat bermigrasi dari penerapan pembaruan bergulir ke penerapan Amazon ECS blue/green saat Anda ingin membuat dan menguji perubahan layanan sebelum menerapkannya di lingkungan produksi. 

## Prasyarat
<a name="update-rolling-to-bluegreen-prerequisites"></a>

Sebelum memigrasikan layanan Anda dari bergulir ke blue/green penerapan, pastikan Anda memiliki yang berikut:
+  Tunggu hingga penerapan saat ini selesai. 
+ Layanan Amazon ECS yang ada menggunakan strategi penyebaran bergulir.
+ Jika Anda memiliki beberapa revisi layanan yang melayani lalu lintas, Amazon ECS mencoba mengkonsolidasikan lalu lintas ke satu revisi selama migrasi. Jika gagal, Anda mungkin perlu memperbarui layanan secara manual untuk menggunakan satu revisi sebelum bermigrasi.
+ Konfigurasikan izin yang sesuai.
  + Untuk informasi tentang izin Elastic Load Balancing, lihat. [Peran IAM infrastruktur Amazon ECS untuk penyeimbang beban](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)
  + Untuk informasi tentang izin Lambda, lihat. [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md)
+ Tergantung pada konfigurasi, Anda perlu melakukan salah satu dari yang berikut:
  + Jika layanan Anda menggunakan Elastic Load Balancing, perbarui layanan Anda dengan `AdvancedConfiguration` yang baru dan mulai penerapan bergulir. 
  + Jika layanan Anda menggunakan Service Connect, perbarui layanan Anda dan mulai penerapan bergulir. 
  + Jika layanan Anda menggunakan Elastic Load Balancing dan Service Connect, lakukan kedua langkah di atas (Anda dapat menggunakan satu UpdateService permintaan). 
  + Jika layanan Anda tidak menggunakan salah satu dari yang di atas, maka tidak diperlukan operasi tambahan.
+  blue/green Penyebaran Amazon ECS mengharuskan layanan Anda menggunakan salah satu fitur berikut. Konfigurasikan sumber daya yang sesuai.
  + Application Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Application Load Balancer untuk penerapan biru/hijau, linier, dan kenari](alb-resources-for-blue-green.md)
  + Network Load Balancer - Untuk informasi lebih lanjut, lihat. [Sumber daya Network Load Balancer untuk penerapan Amazon ECS biru/hijau, linier, dan kenari](nlb-resources-for-blue-green.md)
  + Service Connect - Untuk informasi selengkapnya, lihat[Sumber daya Service Connect untuk penerapan Amazon ECS biru/hijau, linier, dan canary](service-connect-blue-green.md).

## Prosedur
<a name="update-rolling-to-bluegreen-procedure"></a>

1. Buka konsol Amazon ECS di[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada panel navigasi, silakan pilih **Klaster**.

1. Pada halaman **Clusters**, pilih cluster yang berisi layanan yang ingin Anda migrasikan.

   Halaman detail Cluster ditampilkan.

1. Pada halaman **detail Cluster**, pilih tab **Layanan**.

1. Pilih layanan, lalu pilih **Perbarui**.

   Halaman layanan Update ditampilkan

1. Perluas **opsi Deployment**, lalu lakukan hal berikut:

1. Untuk **strategi Deployment**, pilih **Biru/hijau**.

1. Konfigurasikan pengaturan blue/green penerapan:

   1. Untuk **waktu Panggang**, masukkan jumlah menit revisi layanan biru dan hijau akan berjalan secara bersamaan sebelum revisi biru dihentikan. 

      Ini memungkinkan waktu untuk verifikasi dan pengujian.

   1. (Opsional) Konfigurasikan fungsi Lambda untuk berjalan pada tahap penerapan tertentu. Di bawah **kait siklus hidup Deployment, konfigurasikan fungsi** Lambda untuk tahapan berikut:
      + **Pre scale up**: Berjalan sebelum meningkatkan revisi layanan hijau
      + **Pasca peningkatan skala: Berjalan** setelah meningkatkan revisi layanan hijau
      + **Uji pergeseran lalu lintas**: Berjalan selama perutean lalu lintas uji ke revisi layanan hijau
      + **Pergeseran lalu lintas pasca uji**: Berjalan setelah lalu lintas uji diarahkan ke revisi layanan hijau
      + **Pergeseran lalu lintas produksi**: Berjalan selama perutean lalu lintas produksi ke revisi layanan hijau
      + **Pergeseran lalu lintas pasca produksi**: Berjalan setelah lalu lintas produksi diarahkan ke revisi layanan hijau

      Untuk menambahkan kait siklus hidup:

      1. Pilih **Tambahkan**.

      1. Untuk **fungsi Lambda**, masukkan nama fungsi atau ARN.

      1. Untuk **Peran**, pilih peran IAM yang memiliki izin untuk menjalankan fungsi Lambda.

      1. Untuk **tahapan Siklus Hidup**, pilih tahapan saat fungsi Lambda harus dijalankan.

      1. Opsional: Untuk **detail Hook**, masukkan pasangan nilai kunci untuk memberikan informasi tambahan ke hook.

1. Konfigurasikan pengaturan penyeimbang beban:

   1. Di bawah **Load balancing**, verifikasi bahwa layanan Anda dikonfigurasi untuk menggunakan penyeimbang beban.

   1. Untuk **grup Target**, pilih kelompok target utama untuk lingkungan produksi (biru) Anda.

   1. Untuk **grup target Alternatif**, pilih grup target untuk lingkungan pengujian (hijau) Anda.

   1. Untuk aturan **Production listener, pilih aturan** listener untuk merutekan lalu lintas produksi.

   1. Opsional: Untuk aturan **Test listener, pilih aturan** listener untuk merutekan lalu lintas pengujian ke lingkungan hijau Anda.

   1. Untuk **Peran**, pilih peran IAM yang memungkinkan Amazon ECS mengelola penyeimbang beban Anda.

1. Tinjau perubahan konfigurasi Anda, lalu pilih **Perbarui**.

## Langkah selanjutnya
<a name="update-rolling-to-bluegreen-next-steps"></a>
+ Perbarui layanan untuk memulai penyebaran. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).
+ Pantau proses penyebaran untuk memastikannya mengikuti blue/green pola:
  + Revisi layanan hijau dibuat dan ditingkatkan
  + Lalu lintas uji diarahkan ke revisi hijau (jika dikonfigurasi)
  + Lalu lintas produksi dialihkan ke revisi hijau
  + Setelah waktu memanggang, revisi biru dihentikan

# Memperbarui strategi penerapan dari Amazon ECS blue/green ke pembaruan bergulir
<a name="update-bluegreen-to-rolling"></a>

Anda dapat memigrasikan blue/green penerapan ke penerapan pembaruan bergulir.

Ingatlah pertimbangan berikut saat bermigrasi ke penerapan bergulir:
+ **Penanganan lalu lintas**: Dengan penerapan bergulir, tugas baru mulai menerima lalu lintas segera setelah mereka lulus pemeriksaan kesehatan. Tidak ada fase pengujian terpisah seperti blue/green penerapan.
+ **Efisiensi sumber daya**: Penerapan bergulir biasanya menggunakan sumber daya yang lebih sedikit daripada blue/green penerapan karena mereka mengganti tugas secara bertahap daripada menciptakan lingkungan duplikat yang lengkap.
+ **Kompleksitas rollback**: Penerapan bergulir membuat rollback lebih kompleks dibandingkan dengan penerapan. blue/green Jika Anda perlu memutar kembali, Anda harus memulai penerapan baru dengan definisi tugas sebelumnya.
+ **Kecepatan penyebaran**: Penyebaran bergulir mungkin membutuhkan waktu lebih lama untuk diselesaikan daripada blue/green penerapan, terutama untuk layanan dengan banyak tugas.
+ **Konfigurasi penyeimbang beban: Konfigurasi** penyeimbang beban Anda yang ada akan terus bekerja dengan penerapan bergulir, tetapi perilaku pergeseran lalu lintas akan berbeda.

## Prasyarat
<a name="update-bluegreen-to-rolling-prerequisites"></a>

Sebelum memigrasikan layanan Anda dari blue/green ke penerapan bergulir, pastikan Anda memiliki yang berikut:
+ Layanan Amazon ECS yang ada menggunakan strategi blue/green penyebaran
+ Tidak ada penerapan yang sedang berlangsung untuk layanan (tunggu hingga penerapan saat ini selesai)
+ Pemahaman yang jelas tentang bagaimana layanan Anda akan berperilaku dengan penerapan bergulir

**catatan**  
Anda tidak dapat memigrasikan layanan ke penerapan bergulir jika layanan tersebut memiliki penerapan yang sedang berlangsung. Tunggu hingga penerapan saat ini selesai sebelum melanjutkan.

## Prosedur migrasi
<a name="update-bluegreen-to-rolling-procedure"></a>

Ikuti langkah-langkah berikut untuk memigrasikan layanan Amazon ECS Anda dari blue/green ke penerapan bergulir:

1. Buka konsol Amazon ECS di[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada panel navigasi, silakan pilih **Klaster**.

1. Pada halaman **Clusters**, pilih cluster yang berisi layanan yang ingin Anda migrasikan.

1. Pada halaman **detail Cluster**, pilih tab **Layanan**.

1. Pilih layanan yang ingin Anda migrasikan, lalu pilih **Perbarui**.

1. Pada halaman **Layanan Perbarui**, navigasikan ke bagian **Opsi penyebaran** dan perluas jika perlu.

1. Untuk **strategi Deployment**, pilih **Pembaruan bergulir**.

1. Konfigurasikan pengaturan penerapan bergulir:

   1. Untuk **Persentase sehat minimum**, masukkan persentase minimum tugas yang harus tetap dalam `RUNNING` keadaan selama penerapan. Nilai ini ditentukan sebagai persentase dari jumlah tugas yang diinginkan untuk layanan.

   1. Untuk **persen Maksimum**, masukkan persentase maksimum tugas yang diizinkan di `PENDING` negara bagian `RUNNING` atau selama penerapan. Nilai ini ditentukan sebagai persentase dari jumlah tugas yang diinginkan untuk layanan.

1. Opsional: Di bawah **deteksi kegagalan Deployment**, konfigurasikan cara Amazon ECS mendeteksi dan menangani kegagalan penerapan:

   1. Untuk mengaktifkan pemutus sirkuit penyebaran, pilih **Gunakan pemutus sirkuit penyebaran**.

   1. Untuk secara otomatis memutar kembali penerapan yang gagal, pilih **Rollback on failure**.

1. Tinjau perubahan konfigurasi Anda, lalu pilih **Perbarui** untuk menyimpan perubahan Anda dan memigrasikan layanan ke penerapan bergulir.

Amazon ECS akan memperbarui konfigurasi layanan Anda untuk menggunakan strategi penerapan bergulir. Lain kali Anda memperbarui layanan Anda, itu akan menggunakan proses penyebaran bergulir.

**catatan**  
Saat Anda bermigrasi dari blue/green ke penerapan bergulir, Amazon ECS menangani transisi dengan:  
Mengidentifikasi revisi layanan aktif saat ini yang melayani lalu lintas.
Mempertahankan konfigurasi penyeimbang beban yang ada tetapi mengubah cara penerapan baru ditangani.
Mempersiapkan layanan untuk penerapan bergulir di masa depan.

## Langkah selanjutnya
<a name="update-bluegreen-to-rolling-next-steps"></a>
+ Perbarui layanan untuk memulai penyebaran. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).

# Memecahkan masalah pembaruan strategi penerapan Amazon ECS
<a name="troubleshooting-deployment-controller-migration"></a>

Bagian ini memberikan solusi untuk masalah umum yang mungkin Anda temui saat memigrasikan strategi penerapan.

## Beberapa revisi layanan atau set tugas
<a name="troubleshooting-multiple-task-sets"></a>

Masalah berikut terkait dengan memiliki beberapa revisi layanan untuk penerapan.

Beberapa set tugas saat memperbarui pengontrol penyebaran ECS  
*Pesan kesalahan*: `Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.`  
*Solusi*: Kesalahan ini terjadi ketika mencoba mengubah jenis pengontrol penerapan layanan dengan beberapa set tugas aktif. Untuk mengatasi masalah ini untuk pengontrol `CODE_DEPLOY` atau `EXTERNAL` penerapan:  

1. Periksa set tugas saat ini:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets"
   ```

1. Tunggu hingga penerapan yang sedang berlangsung selesai.

1. Memaksa penerapan baru untuk membersihkan set tugas:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment
   ```

1. Jika perlu, hapus set tugas tambahan secara manual:

   ```
   aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id
   ```

1. Setelah hanya satu set tugas yang tersisa, coba lagi perbarui pengontrol penerapan.
Untuk informasi selengkapnya, lihat [Pengontrol dan strategi penyebaran layanan Amazon ECS](ecs_service-options.md).

Set tugas utama tidak ada saat memperbarui `ECS` pengontrol penerapan  
*Pesan kesalahan*: `Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.`  
*Solusi*: Kesalahan ini terjadi ketika mencoba mengubah jenis pengontrol penerapan layanan yang tidak memiliki set tugas utama. Untuk menyelesaikan masalah ini:  

1. Verifikasi status layanan dan set tugas. ). Jika set tugas ada dalam layanan, itu harus ditandai sebagai`ACTIVE`. 

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id]
   ```

   Jika tidak ada set tugas di `ACTIVE` negara bagian, memigrasikan penerapan. Untuk informasi selengkapnya, lihat [Pendekatan migrasi](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths). 

1. Jika layanan tidak memiliki tugas yang berjalan, gunakan setidaknya satu tugas dengan memperbarui layanan:

   ```
   aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id
   ```

   Ini akan menandai tugas (sebelumnya`ACTIVE`) yang ditetapkan dalam layanan sebagai `PRIMARY` status.

1. Tunggu tugas mencapai status berjalan stabil. Anda dapat memeriksa statusnya dengan:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments"
   ```

1. Setelah layanan memiliki tugas utama yang ditetapkan dengan tugas yang sedang berjalan, coba lagi memperbarui pengontrol penerapan.
Untuk informasi selengkapnya, lihat [Pengontrol dan strategi penyebaran layanan Amazon ECS](ecs_service-options.md).

## Ketidakcocokan antara jenis deteksi kegagalan penerapan dan pengontrol penerapan
<a name="troubleshooting-failure-detection"></a>

Masalah berikut terkait dengan ketidakcocokan antara jenis deteksi kegagalan penerapan dan pengontrol penerapan.

Pemutus sirkuit penyebaran dengan pengontrol non-ECS  
*Pesan kesalahan*: `Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*Solusi*: Kesalahan ini terjadi ketika mencoba mengaktifkan fitur pemutus sirkuit penyebaran pada layanan yang tidak menggunakan pengontrol penyebaran. `ECS` Pemutus sirkuit penyebaran hanya kompatibel dengan pengontrol `ECS` penyebaran.  

1. Periksa pengontrol penerapan layanan Anda saat ini:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Perbarui layanan Anda untuk menggunakan pengontrol `ECS` penerapan:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Setelah layanan menggunakan pengontrol `ECS` penyebaran, aktifkan pemutus sirkuit penyebaran:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}"
   ```
Untuk informasi selengkapnya, lihat [Cara pemutus sirkuit deployment Amazon ECS mendeteksi kegagalan](deployment-circuit-breaker.md).

Rollback berbasis alarm dengan pengontrol non-ECS  
*Pesan kesalahan*: `Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*Solusi*: Kesalahan ini terjadi ketika mencoba mengkonfigurasi rollback berbasis alarm pada layanan yang tidak menggunakan pengontrol penerapan. `ECS` Fitur rollback berbasis alarm hanya kompatibel dengan pengontrol penerapan. `ECS`  

1. Periksa pengontrol penerapan layanan Anda saat ini:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Perbarui layanan Anda untuk menggunakan pengontrol `ECS` penerapan:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Setelah layanan menggunakan pengontrol `ECS` penyebaran, konfigurasikan rollback berbasis alarm:

   ```
   aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}"
   ```
Untuk informasi selengkapnya, lihat [Bagaimana CloudWatch alarm mendeteksi kegagalan penerapan Amazon ECS](deployment-alarm-failure.md).

## Ketidakcocokan antara Service Connect dan pengontrol penerapan
<a name="troubleshooting-service-connect-mismatch"></a>

Masalah berikut terkait dengan ketidakcocokan antara Service Connect dan pengontrol penerapan.

`EXTERNAL`pengontrol dengan Service Connect  
*Pesan kesalahan*: `The EXTERNAL deployment controller type is not supported for services using Service Connect.`  
*Solusi*: Kesalahan ini terjadi saat mencoba menggunakan pengontrol `EXTERNAL` penerapan dengan layanan yang mengaktifkan Service Connect. `EXTERNAL`Kontroler tidak kompatibel dengan Service Connect.  

1. Periksa apakah layanan Anda mengaktifkan Service Connect:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration"
   ```

1. Jika Anda perlu menggunakan pengontrol `EXTERNAL` penyebaran, nonaktifkan Service Connect dengan memperbarui layanan Anda:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}"
   ```

1. Atau, jika Anda harus menggunakan Service Connect, gunakan pengontrol `ECS` penerapan sebagai gantinya:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Untuk informasi selengkapnya, lihat [Pengontrol dan strategi penyebaran layanan Amazon ECS](ecs_service-options.md).

Service Connect dengan pengontrol non-ECS  
*Pesan kesalahan*: `Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.`  
*Solusi*: Kesalahan ini terjadi ketika mencoba mengaktifkan Service Connect pada yang tidak menggunakan pengontrol `ECS` penerapan. Fitur Service Connect hanya kompatibel dengan pengontrol `ECS` penerapan.  

1. Periksa pengontrol penerapan layanan Anda saat ini:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Perbarui layanan Anda untuk menggunakan pengontrol penyebaran ECS:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Setelah layanan menggunakan pengontrol penyebaran ECS, aktifkan Service Connect:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace"
   ```
Untuk informasi selengkapnya, lihat [Pengontrol dan strategi penyebaran layanan Amazon ECS](ecs_service-options.md).

## Ketidakcocokan antara jenis pengontrol dan strategi penjadwalan
<a name="troubleshooting-controller-type-scheduling"></a>

Masalah berikut terkait dengan ketidakcocokan antara jenis pengontrol dan strategi penjadwalan.

`CODE_DEPLOY`controller dengan strategi `DAEMON` penjadwalan  
*Pesan kesalahan*: `The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*Solusi*: Kesalahan ini terjadi ketika mencoba menggunakan pengontrol penyebaran CODE\$1DEPLOY dengan layanan yang menggunakan strategi penjadwalan. `DAEMON` `CODE_DEPLOY`Pengontrol hanya kompatibel dengan strategi `REPLICA` penjadwalan.  

1. Periksa strategi penjadwalan layanan Anda saat ini:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. Jika Anda memerlukan blue/green penerapan, ubah layanan Anda untuk menggunakan strategi `REPLICA` penjadwalan:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. Atau, jika Anda harus menggunakan strategi `DAEMON` penjadwalan, gunakan pengontrol `ECS` penerapan sebagai gantinya:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Untuk informasi selengkapnya, lihat [Pengontrol dan strategi penyebaran layanan Amazon ECS](ecs_service-options.md).

Pengontrol EKSTERNAL dengan strategi penjadwalan DAEMON  
*Pesan kesalahan*: `The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*Solusi*: Kesalahan ini terjadi ketika mencoba menggunakan pengontrol penyebaran EKSTERNAL dengan layanan ECS yang menggunakan strategi penjadwalan DAEMON. Pengontrol EKSTERNAL hanya kompatibel dengan strategi penjadwalan REPLICA.  

1. Periksa strategi penjadwalan layanan Anda saat ini:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. Jika Anda perlu menggunakan pengontrol `EXTERNAL` penerapan, ubah layanan Anda untuk menggunakan strategi `REPLICA` penjadwalan:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. Atau, jika Anda harus menggunakan strategi `DAEMON` penjadwalan, gunakan pengontrol `ECS` penerapan sebagai gantinya:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Untuk informasi selengkapnya, lihat [Pengontrol dan strategi penyebaran layanan Amazon ECS](ecs_service-options.md).

Registri layanan dengan tipe peluncuran eksternal  
*Pesan kesalahan*: `Service registries are not supported for external launch type.`  
*Solusi*: Kesalahan ini terjadi ketika mencoba mengonfigurasi penemuan layanan (pendaftar layanan) untuk layanan yang menggunakan jenis peluncuran. `EXTERNAL` Penemuan layanan tidak kompatibel dengan jenis `EXTERNAL` peluncuran.  

1. Periksa jenis peluncuran layanan Anda saat ini:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType"
   ```

1. Jika Anda memerlukan penemuan layanan, ubah layanan Anda untuk menggunakan jenis `EC2` atau `FARGATE` peluncuran:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE
   ```

1. Atau, jika Anda harus menggunakan jenis `EXTERNAL` peluncuran, hapus konfigurasi registri layanan:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]"
   ```
Untuk informasi selengkapnya, lihat [Pengontrol dan strategi penyebaran layanan Amazon ECS](ecs_service-options.md).

## Kembalikan pembaruan pengontrol penerapan
<a name="troubleshooting-revert"></a>

Jika Anda memutuskan ingin kembali ke pengontrol penerapan sebelumnya, Anda dapat melakukan salah satu hal berikut:
+ Jika Anda menggunakan CloudFormation, Anda dapat menggunakan template sebelumnya untuk membuat tumpukan baru. Untuk informasi selengkapnya, lihat [Membuat tumpukan dari](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) *Panduan CloudFormation Pengguna*.
+ Jika Anda menggunakan konsol Amazon ECS, atau AWS CLI, Anda dapat memperbarui layanan. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).

  Jika Anda menggunakan perintah update-service, gunakan `--deployment-controller` opsi dan atur ke controller deployment sebelumnya.

# Melihat riwayat layanan menggunakan deployment layanan Amazon ECS
<a name="service-deployment"></a>

Penyebaran layanan memberikan pandangan komprehensif tentang penerapan Anda. Penyebaran layanan memberikan informasi berikut tentang layanan:
+ Konfigurasi beban kerja yang saat ini diterapkan (revisi layanan sumber)
+ Konfigurasi beban kerja yang sedang digunakan (revisi layanan target)
+ Status deployment
+ Jumlah tugas gagal yang terdeteksi oleh pemutusan sirkuit
+  CloudWatch Alarm yang ada di alarm
+ Ketika penyebaran layanan dimulai dan selesai
+ Rincian rollback jika terjadi

Untuk informasi tentang properti penyebaran layanan, lihat[Properti yang disertakan dalam penyebaran layanan Amazon ECS](service-deployment-property.md).

Penyebaran layanan hanya-baca dan masing-masing memiliki ID unik. 

Ada tiga tahap penyebaran layanan:


| Stage | Definisi | Negara bagian terkait | 
| --- | --- | --- | 
| Tertunda | Penyebaran layanan telah dibuat, tetapi belum dimulai | PENDING | 
| Berkelanjutan | Penyebaran layanan sedang berlangsung |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-deployment.html)  | 
| Selesai  | Penyebaran layanan telah selesai (berhasil atau tidak berhasil) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-deployment.html)  | 

Anda menggunakan penerapan layanan untuk memahami siklus hidup layanan Anda dan untuk menentukan apakah ada tindakan yang perlu Anda lakukan. Misalnya, jika rollback terjadi, Anda mungkin perlu menyelidiki penyebaran layanan dan melihat peristiwa layanan.

Anda dapat melihat riwayat 90 hari terbaru untuk penerapan yang dibuat pada atau setelah 25 Oktober 2024 dengan menggunakan konsol, API, dan. AWS CLI

Anda dapat menghentikan penerapan yang belum selesai. Untuk informasi selengkapnya, lihat [Menghentikan deployment layanan Amazon ECS](stop-service-deployment.md).

## Siklus hidup penyebaran layanan
<a name="service-deployments-lifecycle"></a>

Amazon ECS membuat penyebaran layanan baru secara otomatis ketika salah satu tindakan berikut terjadi:
+ Seorang pengguna membuat layanan.
+ Pengguna memperbarui layanan dan menggunakan opsi force new deployment.
+ Pengguna memperbarui satu atau beberapa properti layanan yang memerlukan penerapan.

Saat penerapan sedang berlangsung, Amazon ECS memperbarui properti penyebaran layanan berikut untuk mencerminkan kemajuan penerapan layanan:
+ Negara
+ Jumlah tugas yang sedang berjalan

  Jumlah tugas yang berjalan yang ditunjukkan dalam revisi layanan mungkin tidak sama dengan jumlah sebenarnya dari tugas yang sedang berjalan. Nomor ini mewakili jumlah tugas yang berjalan saat penerapan selesai. Misalnya, jika Anda meluncurkan tugas independen dari deployment layanan, tugas tersebut tidak disertakan dalam jumlah tugas yang sedang berjalan untuk revisi layanan.
+ Deteksi kegagalan pemutus sirkuit:
  + Jumlah tugas yang gagal dimulai
+ CloudWatch deteksi kegagalan alarm
  + Alarm yang aktif
+ Informasi rollback:
  + Waktu mulai
  + Alasan rollback
  + ARN dari revisi layanan yang digunakan untuk rollback
+ Alasan status

Amazon ECS menghapus penyebaran layanan saat Anda menghapus layanan.

## Status penyebaran layanan
<a name="service-deployments-states"></a>

Penyebaran layanan dimulai dalam `PENDING` status. 

Ilustrasi berikut menunjukkan status penyebaran layanan yang dapat terjadi setelah `PENDING` status:`IN_PROGRESS`,,,`ROLLBACK_REQUESTED`,`SUCCESSFUL`,`STOP_REQUESTED`, `ROLLBACK_IN_PROGRESSS` `ROLLBACK_FAILED``ROLLBACK_SUCCESSFUL`, dan. `STOPPED`

![\[Penyebaran layanan STOP_REQUESTED, SUCCESSFUSED, dan ROLLBACK_IN_PROGRESS menyatakan yang dapat terjadi setelah status IN_PROGRESS.\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/images/service-deployment-states.png)


Informasi berikut memberikan rincian tentang status penyebaran layanan:
+ `PENDING`- Penyebaran layanan telah dibuat, tetapi belum dimulai.

  Negara dapat pindah ke`IN_PROGRESS`,`ROLLBACK_REQUESTED`,`STOP_REQUESTED`, atau`STOPPED`.
+ `IN_PROGRESS`- Penyebaran layanan sedang berlangsung.

  Negara dapat pindah ke`SUCCESSFUL`,`STOP_REQUESTED`,`ROLLBACK_REQUESTED`,`ROLLBACK_IN_PROGRESS`, dan`STOPPED`.
+ `STOP_REQUESTED`- Status penyebaran layanan berpindah ke `STOP_REQUESTED` saat salah satu hal berikut terjadi:
  + Seorang pengguna memulai penyebaran layanan baru.
  + Opsi rollback tidak digunakan untuk mekanisme deteksi kegagalan (pemutus sirkuit atau berbasis alarm) dan layanan tidak mencapai keadaan. `SUCCESSFUL`

  Negara bergerak ke`STOPPED`.
+  `ROLLBACK_REQUESTED`- Status penyebaran layanan berpindah ke `ROLLBACK_REQUESTED` saat pengguna meminta rollback melalui konsol, API, atau CLI.

  Negara dapat pindah ke`SUCCESSFUL`,`ROLLBACK_IN_PROGRESS`, dan`STOPPED`.
+ `SUCCESSFUL`- Status penyebaran layanan bergerak ke `SUCCESSFUL` saat penyebaran layanan berhasil diselesaikan.
+  `ROLLBACK_IN_PROGRESS`- Status penyebaran layanan bergerak ke `ROLLBACK_IN_PROGRESS` saat opsi rollback digunakan untuk mekanisme deteksi kegagalan (pemutus sirkuit atau berbasis alarm) dan layanan gagal.

   Negara bergerak ke`ROLLBACK_SUCCESSFUL`, atau`ROLLBACK_FAILED`.

# Properti yang disertakan dalam penyebaran layanan Amazon ECS
<a name="service-deployment-property"></a>

Properti berikut disertakan dalam penyebaran layanan.


| Properti | Deskripsi | 
| --- | --- | 
|  Penyebaran layanan ARN  |  ARN dari penyebaran layanan.  | 
| Layanan ARN |  ARN layanan untuk penyebaran layanan ini.  | 
|  ARN klaster  |  ARN untuk cluster yang menjadi tuan rumah layanan.  | 
| Waktu pembuatan penyebaran layanan | Waktu penyebaran layanan dibuat.  | 
| Waktu mulai penyebaran layanan | Waktu penyebaran layanan dimulai.  | 
|  Waktu penyelesaian penyebaran layanan  | Waktu penyebaran layanan selesai. | 
| Waktu penyebaran layanan dihentikan | Waktu penyebaran layanan berhenti.  | 
| Waktu pembaruan penyebaran layanan | Waktu penyebaran layanan terakhir diperbarui.  | 
| Revisi layanan sumber |  Revisi layanan yang sedang berjalan.  Untuk informasi tentang properti yang disertakan, lihat[Properti yang termasuk dalam revisi layanan Amazon ECS](service-revision-property.md).  | 
| Konfigurasi deployment | Parameter penyebaran termasuk konfigurasi pemutus sirkuit, alarm yang menentukan.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-deployment-property.html) | 
| Revisi layanan target | Revisi layanan untuk menyebarkan. Setelah penerapan berhasil diselesaikan, revisi layanan target adalah revisi layanan yang sedang berjalan. | 
| Status penyebaran layanan | Status penyebaran layanan.Nilai yang valid adalah PENDING, SUCCESS, STOP\$1REQUESTED, STOP\$1IN\$1PROGRESS, IN\$1PROGRESS, ROLLBACK\$1IN\$1PROGRESS, ROLLBACK\$1SUCCESSFUL, dan ROLLBACK\$1FAILED. | 
| Informasi status penyebaran layanan | Informasi tentang mengapa penyebaran layanan dalam status saat ini. Misalnya, pemutus sirkuit mendeteksi kegagalan. | 
|  Informasi rollback | Opsi rollback yang digunakan penyebaran layanan saat penerapan gagal. | 
| Opsi pemutus sirkuit penyebaran layanan | Pemutus sirkuit yang menentukan penyebaran layanan gagal. | 
| CloudWatch alarm untuk penyebaran layanan |  CloudWatch Alarm yang menentukan kapan penerapan layanan gagal. | 

# Izin diperlukan untuk melihat penerapan layanan Amazon ECS
<a name="service-deployment-permissions"></a>

 Saat Anda mengikuti praktik terbaik pemberian hak istimewa paling sedikit, Anda perlu menambahkan izin tambahan untuk melihat penerapan layanan di konsol.

Anda memerlukan akses ke tindakan berikut:
+ ListServiceDeployments
+ DescribeServiceDeployments
+ DescribeServiceRevisions

Anda memerlukan akses ke sumber daya berikut:
+ Layanan
+ Penyebaran layanan
+ Revisi Layanan

Kebijakan contoh berikut berisi izin yang diperlukan, dan membatasi tindakan ke layanan tertentu. 

Ganti`account`,`cluster-name`, dan `service-name` dengan nilai-nilai Anda.

------
#### [ JSON ]

****  

```
{
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "ecs:ListServiceDeployments",
            "ecs:DescribeServiceDeployments",
            "ecs:DescribeServiceRevisions"
        ],
        "Resource": [
            "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name",
            "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*",
            "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*"
            ]
        }
   ]
}
```

------

# Melihat penyebaran layanan Amazon ECS
<a name="view-service-deployment"></a>

Anda dapat melihat riwayat 90 hari terbaru untuk penerapan yang dibuat pada atau setelah 25 Oktober 2024. Penyebaran layanan dapat berada di salah satu status berikut:
+ Sedang berlangsung 
+ Tertunda
+ Selesai

 Anda dapat menggunakan informasi ini untuk menentukan apakah Anda perlu memperbarui cara layanan digunakan, atau revisi layanan. Untuk informasi tentang properti yang disertakan, lihat[Properti yang disertakan dalam penyebaran layanan Amazon ECS](service-deployment-property.md).

Sebelum Anda mulai, konfigurasikan izin yang diperlukan untuk melihat penerapan layanan. Untuk informasi selengkapnya, lihat [Izin diperlukan untuk melihat penerapan layanan Amazon ECS](service-deployment-permissions.md).

------
#### [ Amazon ECS Console ]

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, pilih layanan.

   Halaman detail layanan ditampilkan.

1. Pada halaman detail layanan, pilih **Deployment**.

1. Pilih penyebaran layanan untuk dilihat.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/view-service-deployment.html)

   Halaman detail penyebaran layanan muncul.

1. (Opsional) Bandingkan revisi layanan untuk melihat perbedaannya.

   Di bawah **Revisi layanan**, pilih **Bandingkan revisi**, lalu pilih 2 revisi untuk membandingkan.

   Revisi layanan ditampilkan side-by-side dengan perbedaan yang disorot.

------
#### [ AWS CLI ]

1. Jalankan `list-service-deployments` untuk mengambil ARN penyebaran layanan. 

   Ganti variabel dengan nilai Anda.

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   Perhatikan serviceDeploymentArn untuk penerapan yang ingin Anda lihat.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. Jalankan `describe-service-deployments`. Gunakan `serviceDeploymentArn` yang dikembalikan dari`list-service-deployments`.

   Ganti variabel dengan nilai Anda.

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

------

## Langkah selanjutnya
<a name="view-service-deployment-next-step"></a>

Anda dapat melihat detail untuk revisi layanan dalam penerapan. Untuk informasi selengkapnya, lihat [Melihat detail revisi layanan Amazon ECS](view-service-revision.md)

# Revisi layanan Amazon ECS
<a name="service-revision"></a>

Revisi layanan berisi catatan konfigurasi beban kerja yang coba di-deploy oleh Amazon ECS. Setiap kali Anda membuat atau melakukan deployment layanan, Amazon ECS secara otomatis membuat dan menangkap konfigurasi yang Anda coba deploy dalam revisi layanan.

 Revisi layanan bersifat read-only dan memiliki pengidentifikasi unik. Untuk informasi tentang properti yang disertakan, lihat[Properti yang termasuk dalam revisi layanan Amazon ECS](service-revision-property.md).

 Revisi layanan memberikan manfaat sebagai berikut:
+ Selama penerapan layanan, Anda dapat membandingkan revisi layanan (sumber) yang saat ini diterapkan dengan yang sedang digunakan (target).
+ Saat Anda menggunakan opsi rollback untuk penerapan layanan, Amazon ECS secara otomatis mengembalikan penerapan layanan ke revisi layanan terakhir yang berhasil diterapkan.
+ Revisi layanan berisi catatan konfigurasi beban kerja dalam satu sumber daya. 

## Siklus hidup revisi layanan
<a name="service-revisions-lifecycle"></a>

Amazon ECS secara otomatis membuat revisi layanan baru saat Anda membuat layanan, atau memperbarui properti layanan yang memulai penerapan.

 Amazon ECS tidak membuat revisi layanan baru untuk operasi rollback. Amazon ECS menggunakan revisi layanan terakhir yang berhasil untuk rollback. 

Revisi layanan tidak dapat diubah.

Amazon ECS menghapus revisi layanan saat Anda menghapus layanan.

Anda dapat melihat revisi layanan yang dibuat pada atau setelah 25 Oktober 2024 dengan menggunakan konsol, API, dan CLI.

# Properti yang termasuk dalam revisi layanan Amazon ECS
<a name="service-revision-property"></a>

Properti berikut termasuk dalam revisi layanan.


| Sumber daya | Deskripsi | 
| --- | --- | 
|  Layanan ARN  |  ARN yang mengidentifikasi layanan.  | 
|  ARN klaster  |  ARN untuk cluster yang menjadi tuan rumah layanan.  | 
|  Definisi tugas ARN  |  ARN dari definisi tugas yang digunakan untuk tugas layanan.  | 
|  Registrasi layanan  |  Rincian untuk pendaftar layanan yang digunakan untuk penemuan layanan. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Penyedia kapasitas |  Rincian strategi penyedia kapasitas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Image kontainer |  Detail tentang gambar kontainer.  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Jaringan |  Konfigurasi jaringan untuk layanan. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Jenis peluncuran | Opsi komputasi yang digunakan untuk layanan. | 
| Properti khusus fargate |  Saat menggunakan Fargate, ini adalah informasi tentang versi Fargate. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Volume Amazon EBS yang dikonfigurasi saat penerapan |  Konfigurasi untuk volume yang ditentukan dalam definisi tugas sebagai volume yang dikonfigurasi pada waktu peluncuran.  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-revision-property.html)  | 
|  Service Connect |  Konfigurasi Service Connect. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Penyeimbang beban layanan |  Penyeimbang beban yang merutekan lalu lintas layanan. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Pemantauan Runtime | Menunjukkan jika Runtime Monitoring aktif. | 
| Tanggal pembuatan |  Tanggal revisi layanan dibuat.  | 
| Kisi VPC |  Konfigurasi VPC Lattice untuk revisi layanan.  | 

# Melihat detail revisi layanan Amazon ECS
<a name="view-service-revision"></a>

Anda dapat melihat informasi tentang jenis revisi layanan berikut yang dibuat pada atau setelah 25 Oktober 2024:
+ Sumber -Konfigurasi beban kerja yang saat ini digunakan
+ Target - Konfigurasi beban kerja sedang digunakan

------
#### [ Amazon ECS Console ]

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, pilih layanan.

   Halaman detail layanan ditampilkan.

1. Pada halaman detail layanan, pilih **Deployment**.

1. Pilih revisi layanan untuk dilihat.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/view-service-revision.html)

------
#### [ AWS CLI ]

1. Jalankan `describe-service-deployments` untuk mengambil ARN revisi layanan. 

   Ganti variabel dengan nilai Anda.

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

   Perhatikan `arn` untuk `sourceServiceRevisions` atau`targetServiceRevisions`.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "updatedAt": "2024-09-10T16:49:35.572000+00:00",
               "sourceServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "targetServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "status": "IN_PROGRESS",
               "deploymentConfiguration": {
                   "deploymentCircuitBreaker": {
                       "enable": false,
                       "rollback": false
                   },
                   "maximumPercent": 200,
                   "minimumHealthyPercent": 100
               }
           }
       ],
       "failures": []
   }
   ```

1. Jalankan `describe-service-revisions`. Gunakan `arn` yang dikembalikan dari`describe-service-deployments`.

   Ganti variabel dengan nilai Anda.

   ```
   aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095
   ```

------

# Menyeimbangkan Layanan Amazon ECS di Seluruh Zona Ketersediaan
<a name="service-rebalancing"></a>

Mulai 5 September 2025, Amazon ECS memungkinkan penyeimbangan kembali Availability Zone untuk semua layanan yang memenuhi syarat untuk fitur tersebut. Layanan memenuhi syarat ketika penyebaran Availability Zone adalah strategi penempatan tugas pertama, atau ketika tidak ada strategi penempatan.

Untuk membantu aplikasi Anda mencapai ketersediaan tinggi, kami sarankan untuk mengonfigurasi layanan multi-tugas Anda agar berjalan di beberapa Zona Ketersediaan. Untuk layanan yang menentukan strategi penempatan pertama mereka sebagai penyebaran Availability Zone, AWS lakukan upaya terbaik untuk mendistribusikan tugas layanan secara merata di seluruh Availability Zone yang tersedia.

Namun, mungkin ada kalanya jumlah tugas yang berjalan di satu Zona Ketersediaan tidak sama dengan di Zona Ketersediaan lainnya, seperti setelah gangguan Zona Ketersediaan. Untuk mengatasi ketidakseimbangan tugas ini, Anda dapat mengaktifkan fitur penyeimbangan ulang Zona Ketersediaan.

Dengan penyeimbangan ulang Zona Ketersediaan, Amazon ECS terus memantau distribusi tugas di seluruh Zona Ketersediaan untuk setiap layanan Anda. Ketika Amazon ECS mendeteksi distribusi tugas yang tidak merata, Amazon ECS secara otomatis akan mengambil tindakan untuk menyeimbangkan ulang beban kerja di seluruh Zona Ketersediaan. Hal ini melibatkan peluncuran tugas baru di Zona Ketersediaan dengan tugas paling sedikit dan mengakhiri tugas di Zona Ketersediaan yang kelebihan beban.

Distribusi ulang ini memastikan tidak ada satu Zona Ketersediaan yang menjadi titik kegagalan, sehingga membantu menjaga ketersediaan keseluruhan aplikasi dengan kontainer. Proses penyeimbangan ulang otomatis menghilangkan kebutuhan akan intervensi manual, sehingga mempercepat waktu pemulihan setelah suatu peristiwa.

Berikut ini adalah ikhtisar proses penyeimbangan kembali Availability Zone:

1. Amazon ECS mulai memantau layanan setelah mencapai kondisi tunak, dan melihat jumlah tugas yang berjalan di setiap Availability Zone.

1. Amazon ECS melakukan operasi berikut ketika mendeteksi ketidakseimbangan dalam jumlah tugas yang berjalan di setiap Availability Zone:
   + Mengirim acara layanan yang menunjukkan bahwa penyeimbangan kembali Availability Zone dimulai.
   + Memulai tugas di Availability Zones dengan jumlah tugas yang berjalan paling sedikit
   + Menghentikan tugas di Availability Zones dengan jumlah tugas yang berjalan terbesar.
   + Penjadwal menunggu tugas yang baru dimulai `HEALTHY` dan `RUNNING` sebelum menghentikan tugas di Availability Zone yang terlalu berskala.
   + Mengirim acara layanan dengan hasil penyeimbangan kembali Availability Zone.

## Bagaimana Amazon ECS mendeteksi distribusi tugas yang tidak merata
<a name="service-rebalancing-imbalance"></a>

Amazon ECS menentukan ketidakseimbangan dalam jumlah tugas yang berjalan di setiap Availability Zone dengan membagi jumlah tugas yang diinginkan layanan dengan jumlah Availability Zone yang dikonfigurasi. Jika jumlah tugas yang diinginkan tidak dibagi secara merata, Amazon ECS mendistribusikan sisa tugas secara merata di seluruh Availability Zone yang dikonfigurasi. Setiap Availability Zone harus memiliki setidaknya satu tugas.

Misalnya, pertimbangkan layanan Amazon ECS dengan hitungan dua tugas yang diinginkan yang dikonfigurasi untuk dua Availability Zone. Dalam skenario ini, jumlah tugas yang diinginkan terbagi secara merata. Distribusi yang seimbang akan menjadi satu tugas per Availability Zone. Jika ada dua tugas di Availability Zone 1 dan zero task di Availability Zone 2, Amazon ECS akan memulai rebalancing dengan memulai tugas di Availability Zone 2 sebelum menghentikan tugas di Availability Zone 1.

Sekarang, pertimbangkan layanan Amazon ECS dengan hitungan tiga tugas yang diinginkan yang dikonfigurasi untuk dua Availability Zone. Dalam skenario ini, jumlah tugas yang diinginkan tidak membagi secara merata. Distribusi yang seimbang akan menjadi satu tugas di Availability Zone 1 dan dua tugas di Availability Zone 2 karena setiap Availability Zone memiliki setidaknya satu tugas dan tugas sisanya ditempatkan di Availability Zone 2.

Pertimbangkan layanan Amazon ECS yang memiliki jumlah lima tugas yang diinginkan yang dikonfigurasi untuk tiga Availability Zone. Dalam skenario ini, jumlah tugas yang diinginkan tidak membagi secara merata. Distribusi yang seimbang akan menjadi satu tugas di Availability Zone 1 dan dua tugas masing-masing di Availability Zones 2 dan 3. Setelah memperhitungkan setiap Availability Zone yang masing-masing memiliki satu tugas, dua tugas yang tersisa didistribusikan secara merata di seluruh Availability Zone.

## Pertimbangan untuk mengonfigurasi penyeimbangan kembali Availability Zone
<a name="service-rebalancing-configurations"></a>

Pertimbangkan hal berikut ketika Anda ingin mengonfigurasi penyeimbangan kembali Availability Zone:
+ Penyeimbangan ulang Availability Zone mendukung penyedia kapasitas Fargate dan EC2, dan didukung pada Instans Terkelola Amazon ECS. Untuk Fargate, Amazon ECS akan secara otomatis mendistribusikan kembali tugas di seluruh Availability Zone yang tersedia untuk menjaga keseimbangan. Untuk penyedia kapasitas EC2, Amazon ECS menyeimbangkan kembali tugas di seluruh instans kontainer yang ada dengan upaya terbaik, dengan menghormati strategi dan batasan penempatan yang Anda tentukan. Namun, Amazon ECS tidak dapat meluncurkan instans baru di Availability Zone yang kurang dimanfaatkan sebagai bagian dari proses penyeimbangan kembali, sehingga membatasi penyeimbangan kembali ke instance container yang ada.
+ Penyeimbangan ulang Availability Zone berfungsi dalam konfigurasi berikut:
  + Layanan yang menggunakan `Replica` strategi
  + Layanan yang menentukan penyebaran Availability Zone sebagai strategi penempatan tugas pertama, atau tidak menentukan strategi penempatan.
+ Anda tidak dapat menggunakan penyeimbangan kembali Availability Zone dengan layanan yang memenuhi salah satu kriteria berikut:
  + Menggunakan `Daemon` strategi
  + Menggunakan tipe `EXTERNAL` peluncuran (ECS Anywhere)
  + Menggunakan 100% untuk `maximumPercent` nilai
  + Menggunakan Classic Load Balancer
  + Menggunakan `attribute:ecs.availability-zone` sebagai kendala penempatan tugas

## Strategi penempatan dan kendala penempatan dengan penyeimbangan kembali Availability Zone
<a name="service-rebalancing-placement-constraints"></a>

Strategi penempatan menentukan cara Amazon ECS memilih instans kontainer dan Availability Zone untuk penghentian penempatan tugas. Kendala penempatan tugas adalah aturan yang menentukan apakah tugas diizinkan untuk dijalankan pada instance kontainer tertentu.

Untuk EC2, Anda dapat menggunakan strategi penempatan dan batasan penempatan bersama dengan penyeimbangan kembali Availability Zone. Namun, agar penyeimbangan kembali Availability Zone berfungsi, strategi penempatan spread Availability Zone harus menjadi strategi pertama yang ditentukan.

Penyeimbangan kembali Availability Zone kompatibel dengan berbagai kombinasi strategi penempatan. Misalnya, Anda dapat membuat strategi yang pertama-tama mendistribusikan tugas secara merata di seluruh Availability Zone, lalu bin pack tugas berdasarkan memori dalam setiap Availability Zone. Dalam hal ini, penyeimbangan kembali Availability Zone berfungsi karena strategi penyebaran Availability Zone ditentukan terlebih dahulu.

Penting untuk dicatat bahwa penyeimbangan kembali Availability Zone tidak akan berfungsi jika strategi pertama dalam array strategi penempatan bukan komponen penyebaran Availability Zone. Persyaratan ini memastikan bahwa fokus utama distribusi tugas adalah menjaga keseimbangan di seluruh Availability Zone, yang sangat penting untuk ketersediaan tinggi.

Untuk informasi selengkapnya tentang strategi dan kendala penempatan tugas, lihat. [Cara Amazon ECS Menempatkan Tugas di Instans Kontainer](task-placement.md)

Strategi penempatan tugas dan kendala tidak didukung untuk tugas yang menggunakan Fargate. Fargate akan mencoba yang terbaik untuk menyebarkan tugas di seluruh Availability Zone yang dapat diakses. Jika penyedia kapasitas mencakup Fargate dan Fargate Spot, perilaku spread bersifat independen untuk setiap penyedia kapasitas.

Contoh strategi berikut mendistribusikan tugas secara merata di seluruh Availability Zones, dan kemudian bin pack tugas berdasarkan memori dalam setiap Availability Zone. Penyeimbangan ulang Availability Zone kompatibel dengan layanan karena `spread` strateginya adalah yang pertama.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Aktifkan penyeimbangan kembali Availability Zone
<a name="service-rebalancing-use"></a>

Anda perlu mengaktifkan penyeimbangan kembali Availability Zone untuk layanan baru dan yang sudah ada.

Anda dapat mengaktifkan dan menonaktifkan penyeimbangan kembali Availability Zone menggunakan konsol,, APIs AWS CLI, dan. CloudFormation

Perilaku default `AvailabilityZoneRebalancing` berbeda antara membuat dan memperbarui permintaan:
+ Untuk membuat permintaan layanan, bila tidak ada nilai yang ditentukan`AvailabilityZoneRebalancing`, Amazon ECS akan me-default nilainya ke. `ENABLED`
+ Untuk permintaan layanan pembaruan, jika tidak ada nilai yang ditentukan`AvailabilityZoneRebalancing`, Amazon ECS default ke nilai layanan yang ada. `AvailabilityZoneRebalancing` Jika layanan tidak pernah memiliki `AvailabilityZoneRebalancing` nilai yang ditetapkan, Amazon ECS memperlakukan ini sebagai`DISABLED`.


| Jenis Layanan | API | Konsol | CLI | 
| --- | --- | --- | --- | 
| yang ada | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) |  [Memperbarui layanan Amazon ECS](update-service-console-v2.md)  | [layanan pembaruan-](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | 
| Baru | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) |  [Membuat penyebaran pembaruan bergulir Amazon ECS](create-service-console-v2.md)  | [membuat-layanan](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | 

Contoh berikut menunjukkan cara mengaktifkan penyeimbangan kembali layanan saat membuat layanan baru:

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-definition:1 \
    --desired-count 6 \
    --availability-zone-rebalancing ENABLED
```

# Lacak penyeimbangan kembali Zona Ketersediaan Amazon ECS
<a name="track-service-rebalancing"></a>

Anda dapat memverifikasi apakah penyeimbangan ulang Availability Zone diaktifkan untuk layanan di konsol atau dengan menelepon. `describe-services` Contoh berikut dapat digunakan untuk melihat status dengan CLI.

Responsnya akan berupa `ENABLED` atau`DISABLED`.

```
aws ecs describe-services \
    --services service-name \
    --cluster cluster-name \
    --query services[0].availabilityZoneRebalancing
```

## Acara layanan
<a name="service-info-events"></a>

Amazon ECS mengirimkan peristiwa tindakan layanan untuk membantu Anda memahami siklus hidup penyeimbangan ulang Availability Zone. 


| Peristiwa | Skenario | Tipe | Pelajari selengkapnya | 
| --- | --- | --- | --- | 
| SERVICE\$1REBALANCING\$1STARTED | Amazon ECS memulai operasi penyeimbangan kembali Availability Zone | INFO | [service (*service-name*) tidak AZ seimbang dengan *number-tasks* tugas di dalam*Availability Zone 1*, *number-tasks* di*Availability Zone 2*, dan *number-tasks* di*Availability Zone 3*. AZ Rebalancing sedang berlangsung.](service-rebalancing-event-messages-list.md#service-rebalancing-started) | 
| SERVICE\$1REBALANCING\$1COMPLETED | Operasi penyeimbangan kembali Availability Zone selesai |  INFO | [service (*service-name*) adalah AZ seimbang dengan *number-tasks* tugas-tugas dalam*Availability Zone 1*, *number-tasks* tugas di*Availability Zone 2*, dan *number-tasks* tugas di*Availability Zone 3*.](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | 
| TASKS\$1STARTED | Amazon ECS berhasil memulai tugas sebagai bagian dari operasi penyeimbangan kembali Availability Zone | INFO | [*service-name*telah memulai *number-tasks* tugas *Availability Zone* ke AZ Rebalance:*task-ids*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | 
| TASKS\$1STOPPED | Amazon ECS berhasil menghentikan tugas sebagai bagian dari operasi penyeimbangan kembali Availability Zone | INFO | [*service-name*telah berhenti *number-tasks* menjalankan tugas *Availability Zone* karena penyeimbangan kembali AZ:. *task-id*](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | 
| SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | Amazon ECS gagal memulai tugas sebagai bagian dari operasi penyeimbangan kembali Availability Zone | ERROR | Untuk EC2, lihat [service (*service-name*) tidak dapat menempatkan tugas *Availability Zone* karena tidak ada instance kontainer yang memenuhi semua persyaratannya.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance) Untuk Fargate, lihat [service (*service-name*) tidak dapat menempatkan tugas di*Availability Zone*.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure) | 
| TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | Operasi penyeimbangan kembali Availability Zone diblokir karena perlindungan tugas sedang digunakan. | INFO | [service (*service-name*) tidak dapat melakukan AZ Rebalance karena *task-set-name* tidak dapat menskalakan karena*reason*.](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | 
| SERVICE\$1REBALANCING\$1STOPPED | Operasi penyeimbangan kembali Availability Zone berhenti. Amazon ECS mengirimkan acara tambahan yang memberikan informasi lebih lanjut. | INFO | [service (*service-name*) menghentikan AZ Rebalancing.](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | 

## Peristiwa perubahan status tugas
<a name="task-state-change-events"></a>

Amazon ECS mengirimkan peristiwa perubahan status tugas (`START`) untuk setiap tugas yang dimulai sebagai bagian dari proses penyeimbangan kembali.

Amazon ECS mengirimkan peristiwa perubahan status tugas (`STOPPED`) untuk setiap tugas yang dihentikan sebagai bagian dari proses penyeimbangan kembali. Alasannya diatur ke`Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)`.

Untuk informasi lebih lanjut tentang acara, lihat[Acara perubahan status tugas Amazon ECS](ecs_task_events.md).

## Pemecahan masalah penyeimbangan kembali layanan
<a name="service-rebalancing-troubleshooting"></a>

Jika Anda mengalami masalah dengan penyeimbangan kembali layanan, pertimbangkan langkah-langkah pemecahan masalah berikut:

Penyeimbangan kembali tidak dimulai  
Verifikasi bahwa:  
+ Penyeimbangan kembali layanan diaktifkan untuk layanan Anda
+ Layanan Anda menggunakan konfigurasi yang didukung (lihat[Pertimbangan untuk mengonfigurasi penyeimbangan kembali Availability Zone](#service-rebalancing-configurations))
+ Layanan Anda telah mencapai kondisi mapan

Kegagalan penempatan tugas selama penyeimbangan kembali  
Jika Anda melihat `SERVICE_TASK_PLACEMENT_FAILURE` acara:  
+ Untuk EC2: Periksa apakah Anda memiliki instance kontainer yang tersedia di Zona Ketersediaan target
+ Untuk Fargate: Periksa apakah ada kendala sumber daya atau kuota layanan yang membatasi penempatan tugas
+ Tinjau batasan penempatan tugas Anda untuk memastikan mereka tidak mencegah distribusi tugas yang tepat

Penyeimbangan kembali berhenti secara tak terduga  
Jika Anda melihat `SERVICE_REBALANCING_STOPPED` acara:  
+ Periksa perlindungan tugas yang mungkin menghalangi operasi
+ Cari penerapan layanan bersamaan yang dapat mengganggu penyeimbangan kembali
+ Tinjau peristiwa layanan untuk informasi tambahan tentang mengapa penyeimbangan kembali dihentikan

## Praktik terbaik untuk penyeimbangan kembali layanan
<a name="service-rebalancing-best-practices"></a>

Ikuti praktik terbaik ini untuk mendapatkan hasil maksimal dari penyeimbangan kembali layanan:
+ **Memantau operasi penyeimbangan kembali** - Siapkan CloudWatch alarm untuk memantau peristiwa layanan yang terkait dengan penyeimbangan kembali untuk mengidentifikasi masalah apa pun dengan cepat.
+ **Pertimbangkan dampak kinerja** - Sadarilah bahwa operasi penyeimbangan kembali dapat meningkatkan penggunaan sumber daya sementara saat tugas baru dimulai sebelum tugas lama dihentikan.
+ **Gunakan perlindungan tugas secara strategis** - Jika Anda memiliki tugas penting yang tidak boleh dihentikan selama penyeimbangan kembali, pertimbangkan untuk menggunakan perlindungan tugas.
+ **Rencanakan kapasitas EC2** - Untuk EC2, pastikan Anda memiliki instans kontainer yang cukup di semua Availability Zone untuk mendukung penyeimbangan kembali yang efektif.
+ **Uji perilaku penyeimbangan kembali** - Sebelum mengandalkan penyeimbangan kembali dalam produksi, uji bagaimana layanan Anda berperilaku selama operasi penyeimbangan kembali di lingkungan non-produksi.

# Menggunakan penyeimbangan beban untuk mendistribusikan lalu lintas layanan Amazon ECS
<a name="service-load-balancing"></a>

Layanan Anda secara opsional dapat dikonfigurasi untuk menggunakan Elastic Load Balancing untuk mendistribusikan lalu lintas secara merata di seluruh tugas dalam layanan Anda.

**catatan**  
Bila Anda menggunakan set tugas, semua tugas dalam set harus dikonfigurasi untuk menggunakan Elastic Load Balancing atau untuk tidak menggunakan Elastic Load Balancing. 

Layanan Amazon ECS yang dihosting AWS Fargate mendukung Application Load Balancers, Network Load Balancers, dan Gateway Load Balancers. Gunakan tabel berikut untuk mempelajari jenis penyeimbang beban apa yang akan digunakan.


| Jenis Load Balancer | Gunakan dalam kasus ini | 
| --- | --- | 
|  Penyeimbang Beban Aplikasi  | Lalu lintas rute HTTP/HTTPS (atau lapisan 7).Application Load Balancers menawarkan beberapa fitur yang membuatnya menarik untuk digunakan dengan layanan Amazon ECS: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/service-load-balancing.html) | 
| Penyeimbang Beban Jaringan | Rute lalu lintas TCP atau UDP (atau lapisan 4). | 
| Penyeimbang Beban Gateway | Rute lalu lintas TCP atau UDP (atau lapisan 4). Gunakan peralatan virtual, seperti firewall, sistem deteksi dan pencegahan intrusi, dan sistem inspeksi paket dalam. | 

Kami menyarankan Anda menggunakan Application Load Balancer untuk layanan Amazon ECS Anda sehingga Anda dapat memanfaatkan fitur-fitur terbaru ini, kecuali layanan Anda memerlukan fitur yang hanya tersedia dengan Network Load Balancers atau Gateway Load Balancer. Untuk informasi selengkapnya tentang Elastic Load Balancing dan perbedaan antara jenis load balancer, lihat Panduan Pengguna [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/).

Dengan penyeimbang beban, Anda hanya membayar apa yang Anda gunakan. Untuk informasi selengkapnya, lihat [Harga Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/pricing/). 

# Mengoptimalkan parameter pemeriksaan kondisi penyeimbang beban untuk Amazon ECS
<a name="load-balancer-healthcheck"></a>

Load balancer merutekan permintaan hanya ke target sehat di Availability Zones untuk penyeimbang beban. Setiap target didaftarkan ke kelompok sasaran. Penyeimbang beban memeriksa kesehatan setiap target, menggunakan pengaturan pemeriksaan kesehatan kelompok sasaran. Setelah Anda mendaftarkan target, itu harus melewati satu pemeriksaan kesehatan agar dianggap sehat. Amazon ECS memonitor penyeimbang beban. Penyeimbang beban secara berkala mengirimkan pemeriksaan kesehatan ke wadah Amazon ECS. Agen Amazon ECS memantau, dan menunggu penyeimbang beban melaporkan kesehatan kontainer. Ia melakukan ini sebelum menganggap wadah berada dalam status sehat.

Dua parameter pemeriksaan kesehatan Elastic Load Balancing memengaruhi kecepatan penerapan:
+ Interval pemeriksaan kesehatan: Menentukan perkiraan jumlah waktu, dalam hitungan detik, antara pemeriksaan kesehatan wadah individu. Secara default, penyeimbang beban memeriksa setiap 30 detik.

  Parameter ini dinamai:
  + `HealthCheckIntervalSeconds`di Elastic Load Balancing API
  + **Interval** pada konsol Amazon EC2
+ Jumlah ambang batas yang sehat: Menentukan jumlah keberhasilan pemeriksaan kesehatan berturut-turut yang diperlukan sebelum mempertimbangkan wadah yang tidak sehat sehat. Secara default, penyeimbang beban memerlukan lima pemeriksaan kesehatan yang lewat sebelum melaporkan bahwa wadah target sehat.

  Parameter ini dinamai:
  + `HealthyThresholdCount`di Elastic Load Balancing API
  + **Ambang batas yang sehat** di konsol Amazon EC2

**Penting:** Untuk target yang baru terdaftar, hanya satu pemeriksaan kesehatan yang berhasil diperlukan untuk mempertimbangkan target yang sehat, terlepas dari pengaturan jumlah ambang batas yang sehat. Jumlah ambang batas yang sehat hanya berlaku ketika target beralih dari keadaan tidak sehat kembali ke keadaan sehat.

Dengan pengaturan default, jika target menjadi tidak sehat dan kemudian pulih, total waktu untuk menentukan kesehatan wadah adalah dua menit dan 30 detik (`30 seconds * 5 = 150 seconds`).

Anda dapat mempercepat proses pemeriksaan kesehatan jika layanan Anda dimulai dan stabil dalam waktu kurang dari 10 detik. Untuk mempercepat proses, kurangi interval pemeriksaan kesehatan dan jumlah ambang batas yang sehat.
+ `HealthCheckIntervalSeconds`(Nama Elastic Load Balancing API) atau **Interval** (nama konsol Amazon EC2): 5
+ `HealthyThresholdCount`(Nama Elastic Load Balancing API) atau **ambang Healthy** (nama konsol Amazon EC2): 2

Dengan pengaturan ini, proses pemeriksaan kesehatan membutuhkan waktu 10 detik dibandingkan dengan default dua menit dan 30 detik.

Untuk informasi selengkapnya tentang parameter pemeriksaan kesehatan Elastic Load Balancing, lihat [Pemeriksaan Kesehatan untuk grup target Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) di Panduan Pengguna *Elastic Load Balancing*.

# Optimalkan parameter pengurasan koneksi penyeimbang beban untuk Amazon ECS
<a name="load-balancer-connection-draining"></a>

Untuk memungkinkan pengoptimalan, klien mempertahankan koneksi tetap hidup ke layanan kontainer. Ini memungkinkan permintaan berikutnya dari klien tersebut untuk menggunakan kembali koneksi yang ada. Saat Anda ingin menghentikan lalu lintas ke kontainer, Anda memberi tahu penyeimbang beban. Penyeimbang beban secara berkala memeriksa untuk melihat apakah klien menutup koneksi tetap hidup. Amazon ECS memantau penyeimbang beban, dan menunggu penyeimbang beban melaporkan bahwa koneksi tetap hidup ditutup (target dalam keadaan). `UNUSED`

Jumlah waktu yang menunggu penyeimbang beban untuk memindahkan target ke `UNUSED` status adalah penundaan deregistrasi. Anda dapat mengonfigurasi parameter penyeimbang beban berikut untuk mempercepat penerapan Anda.
+ `deregistration_delay.timeout_seconds`: 300 (default)

Ketika Anda memiliki layanan dengan waktu respons di bawah 1 detik, atur parameter ke nilai berikut agar penyeimbang beban hanya menunggu 5 detik sebelum memutuskan koneksi antara klien dan layanan back-end: 
+ `deregistration_delay.timeout_seconds`: 5 

**catatan**  
Jangan atur nilainya menjadi 5 detik saat Anda memiliki layanan dengan permintaan yang berumur panjang, seperti unggahan file yang lambat atau koneksi streaming.

## Responsif SIGTERM
<a name="sigterm"></a>

Amazon ECS pertama kali mengirimkan sinyal berhenti ke tugas untuk memberi tahu aplikasi harus selesai dan dimatikan. Sinyal ini dapat didefinisikan dalam gambar kontainer Anda dengan instruksi STOPSIGNAL dan akan default ke SIGTERM. Kemudian, Amazon ECS mengirimkan pesan SIGKILL. Ketika aplikasi mengabaikan SIGTERM, layanan Amazon ECS harus menunggu untuk mengirim sinyal SIGKILL untuk menghentikan proses. 

Jumlah waktu yang Amazon ECS menunggu untuk mengirim pesan SIGKILL ditentukan oleh opsi agen Amazon ECS berikut:
+ `ECS_CONTAINER_STOP_TIMEOUT`: 30 (default)

  Untuk informasi selengkapnya tentang parameter agen kontainer, lihat [Agen Kontainer Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) di GitHub.

Untuk mempercepat masa tunggu, atur parameter agen Amazon ECS ke nilai berikut:
+ `ECS_CONTAINER_STOP_TIMEOUT`: 2

  Jika aplikasi Anda membutuhkan waktu lebih dari 1 detik, kalikan nilainya dengan 2 dan gunakan angka itu sebagai nilainya.

Dalam hal ini, Amazon ECS menunggu 2 detik hingga wadah dimatikan, dan kemudian Amazon ECS mengirimkan pesan SIGKILL ketika aplikasi tidak berhenti.

Anda juga dapat memodifikasi kode aplikasi untuk menjebak sinyal SIGTERM dan bereaksi terhadapnya. Berikut ini adalah contoh di JavaScript: 

```
process.on('SIGTERM', function() { 
  server.close(); 
})
```

Kode ini menyebabkan server HTTP berhenti mendengarkan permintaan baru, menyelesaikan menjawab permintaan dalam penerbangan, dan kemudian proses Node.js berakhir karena loop peristiwa tidak ada hubungannya. Mengingat hal ini, jika dibutuhkan proses hanya 500 ms untuk menyelesaikan permintaan dalam penerbangannya, itu berakhir lebih awal tanpa harus menunggu batas waktu berhenti dan dikirimi SIGKILL. 

# Menggunakan Application Load Balancer untuk Amazon ECS
<a name="alb"></a>

Application Load Balancer membuat keputusan routing di layer aplikasi (HTTP/HTTPS), mendukung routing berbasis jalur, dan dapat merutekan permintaan ke satu atau beberapa port pada setiap instance container di cluster Anda. Aplikasi Load Balancer mendukung pemetaan port host dinamis. Misalnya, jika definisi kontainer tugas Anda menentukan port 80 untuk port kontainer NGINX, dan port 0 untuk port host, maka port host dipilih secara dinamis dari rentang port sementara instance kontainer (seperti 32768 hingga 61000 pada AMI Amazon ECS terbaru yang dioptimalkan). Ketika tugas diluncurkan, kontainer NGINX terdaftar dengan Application Load Balancer sebagai ID instance dan kombinasi port, dan lalu lintas didistribusikan ke ID instance dan port yang sesuai dengan container tersebut. Pemetaan dinamis ini mengizinkan Anda memiliki banyak tugas dari satu layanan pada instans kontainer yang sama. Untuk informasi selengkapnya, lihat [Panduan Pengguna untuk Penyeimbang Beban Aplikasi](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/).

Untuk informasi tentang praktik terbaik untuk menyetel parameter guna mempercepat penerapan Anda, lihat:
+ [Mengoptimalkan parameter pemeriksaan kondisi penyeimbang beban untuk Amazon ECS](load-balancer-healthcheck.md)
+ [Optimalkan parameter pengurasan koneksi penyeimbang beban untuk Amazon ECS](load-balancer-connection-draining.md)

Pertimbangkan hal berikut saat menggunakan Application Load Balancers dengan Amazon ECS:
+ Amazon ECS memerlukan peran IAM terkait layanan yang menyediakan izin yang diperlukan untuk mendaftarkan dan membatalkan pendaftaran target dengan penyeimbang beban Anda saat tugas dibuat dan dihentikan. Untuk informasi selengkapnya, lihat [Menggunakan peran terkait layanan untuk Amazon ECS](using-service-linked-roles.md).
+ Untuk layanan dalam konfigurasi IPv6 -only, Anda harus menetapkan jenis alamat IP grup target Application Load Balancer `dualstack` ke atau. `dualstack-without-public-ipv4`
+ Untuk layanan dengan tugas menggunakan mode `awsvpc` jaringan, saat Anda membuat grup target untuk layanan Anda, Anda harus memilih `ip` sebagai jenis target, bukan`instance`. Ini karena tugas yang menggunakan mode `awsvpc` jaringan dikaitkan dengan elastic network interface, bukan instans Amazon EC2.
+ Jika layanan Anda memerlukan akses ke beberapa port yang seimbang beban, seperti port 80 dan port 443 untuk suatu HTTP/HTTPS layanan, Anda dapat mengonfigurasi dua pendengar. Satu listener bertanggung jawab untuk HTTPS yang meneruskan permintaan ke layanan, dan listener lainnya bertanggung jawab untuk mengarahkan permintaan HTTP ke port HTTPS yang sesuai. Untuk informasi selengkapnya, lihat [Membuat pendengar ke Application Load Balancer Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html) di *Panduan Pengguna untuk Penyeimbang Beban Aplikasi*.
+ Konfigurasi subnet penyeimbang beban Anda harus menyertakan semua Availability Zone tempat instans kontainer Anda berada.
+ Setelah Anda membuat layanan, konfigurasi penyeimbang beban tidak dapat diubah dari. Konsol Manajemen AWS Anda dapat menggunakan AWS Copilot, AWS CloudFormation, AWS CLI atau SDK untuk memodifikasi konfigurasi penyeimbang beban hanya untuk pengontrol penerapan `ECS` bergulir, bukan biru/hijau atau eksternal. AWS CodeDeploy Saat Anda menambahkan, memperbarui, atau menghapus konfigurasi penyeimbang beban, Amazon ECS memulai penerapan baru dengan konfigurasi Elastic Load Balancing yang diperbarui. Hal ini menyebabkan tugas mendaftar dan membatalkan pendaftaran dari penyeimbang beban. Kami menyarankan Anda memverifikasi ini di lingkungan pengujian sebelum memperbarui konfigurasi Elastic Load Balancing. Untuk informasi tentang cara mengubah konfigurasi, lihat [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)di *Referensi API Amazon Elastic Container Service*. 
+ Jika tugas layanan gagal dalam kriteria pemeriksaan kesehatan penyeimbang beban, tugas dihentikan dan dimulai ulang. Proses ini berlanjut hingga layanan Anda mencapai jumlah tugas berjalan yang diinginkan.
+ Jika Anda mengalami masalah dengan layanan yang diaktifkan penyeimbang beban, lihat [Memecahkan masalah penyeimbang beban layanan di Amazon ECS](troubleshoot-service-load-balancers.md).
+ Saat menggunakan tipe `instance` target, tugas dan penyeimbang beban Anda harus dalam VPC yang sama. Saat menggunakan tipe `ip` target, konektivitas lintas-VPC didukung.
+ Gunakan grup target unik untuk setiap layanan. 

  Menggunakan grup target yang sama untuk beberapa layanan dapat menyebabkan masalah selama penerapan layanan.
+ Anda harus menentukan grup target yang terkait dengan Application Load Balancer.

*Untuk selengkapnya tentang cara membuat Application Load Balancer, lihat [Membuat Application Load Balancer di Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) Balancers*

# Menggunakan Network Load Balancer untuk Amazon ECS
<a name="nlb"></a>

Penyeimbang Beban Jaringan mengambil keputusan perutean di lapisan pengangkutan (TCP/SSL). Hal itu dapat menangani jutaan permintaan per detik. Setelah penyeimbang beban menerima koneksi, penyeimbang akan memilih target dari grup target untuk aturan default menggunakan algoritme perutean hash alur. Penyeimbang mencoba untuk membuka koneksi TCP ke target yang dipilih pada port yang ditentukan dalam konfigurasi listener. Ini meneruskan permintaan tanpa memodifikasi header. Network Load Balancers mendukung pemetaan port host dinamis. Misalnya, jika definisi kontainer tugas Anda menentukan port 80 untuk port kontainer NGINX, dan port 0 untuk port host, maka port host dipilih secara dinamis dari rentang port sementara instance kontainer (seperti 32768 hingga 61000 pada AMI Amazon ECS terbaru yang dioptimalkan). Ketika tugas diluncurkan, kontainer NGINX terdaftar dengan Network Load Balancer sebagai ID instance dan kombinasi port, dan lalu lintas didistribusikan ke ID instance dan port yang sesuai dengan container tersebut. Pemetaan dinamis ini mengizinkan Anda memiliki banyak tugas dari satu layanan pada instans kontainer yang sama. Untuk informasi selengkapnya, lihat [Panduan Pengguna untuk Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/).

Untuk informasi tentang praktik terbaik untuk menyetel parameter guna mempercepat penerapan Anda, lihat:
+ [Mengoptimalkan parameter pemeriksaan kondisi penyeimbang beban untuk Amazon ECS](load-balancer-healthcheck.md)
+ [Optimalkan parameter pengurasan koneksi penyeimbang beban untuk Amazon ECS](load-balancer-connection-draining.md)

Pertimbangkan hal berikut saat menggunakan Network Load Balancers dengan Amazon ECS:
+ Amazon ECS memerlukan peran IAM terkait layanan yang menyediakan izin yang diperlukan untuk mendaftarkan dan membatalkan pendaftaran target dengan penyeimbang beban Anda saat tugas dibuat dan dihentikan. Untuk informasi selengkapnya, lihat [Menggunakan peran terkait layanan untuk Amazon ECS](using-service-linked-roles.md).
+ Anda tidak dapat melampirkan lebih dari lima grup target ke layanan.
+ Untuk layanan dalam konfigurasi IPv6 -only, Anda harus mengatur tipe alamat IP grup target Network Load `dualstack` Balancer.
+ Untuk layanan dengan tugas menggunakan mode `awsvpc` jaringan, saat Anda membuat grup target untuk layanan Anda, Anda harus memilih `ip` sebagai jenis target, bukan`instance`. Ini karena tugas yang menggunakan mode `awsvpc` jaringan dikaitkan dengan elastic network interface, bukan instans Amazon EC2.
+ Konfigurasi subnet penyeimbang beban Anda harus menyertakan semua Availability Zone tempat instans kontainer Anda berada.
+ Setelah Anda membuat layanan, konfigurasi penyeimbang beban tidak dapat diubah dari. Konsol Manajemen AWS Anda dapat menggunakan AWS Copilot, AWS CloudFormation, AWS CLI atau SDK untuk memodifikasi konfigurasi penyeimbang beban hanya untuk pengontrol penerapan `ECS` bergulir, bukan biru/hijau atau eksternal. AWS CodeDeploy Saat Anda menambahkan, memperbarui, atau menghapus konfigurasi penyeimbang beban, Amazon ECS memulai penerapan baru dengan konfigurasi Elastic Load Balancing yang diperbarui. Hal ini menyebabkan tugas mendaftar dan membatalkan pendaftaran dari penyeimbang beban. Kami menyarankan Anda memverifikasi ini di lingkungan pengujian sebelum memperbarui konfigurasi Elastic Load Balancing. Untuk informasi tentang cara mengubah konfigurasi, lihat [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)di *Referensi API Amazon Elastic Container Service*. 
+ Jika tugas layanan gagal dalam kriteria pemeriksaan kesehatan penyeimbang beban, tugas dihentikan dan dimulai ulang. Proses ini berlanjut hingga layanan Anda mencapai jumlah tugas berjalan yang diinginkan.
+ Saat Anda menggunakan Load Balancer Gateway yang dikonfigurasi dengan alamat IP sebagai target dan Pelestarian IP Klien tidak aktif, permintaan akan terlihat berasal dari alamat IP pribadi Gateway Load Balancers. Ini berarti bahwa layanan di balik Load Balancer Gateway secara efektif terbuka untuk dunia segera setelah Anda mengizinkan permintaan masuk dan pemeriksaan kesehatan di grup keamanan target.
+ Untuk tugas Fargate, Anda harus menggunakan versi platform `1.4.0` (Linux) atau `1.0.0` (Windows).
+ Jika Anda mengalami masalah dengan layanan yang diaktifkan penyeimbang beban, lihat [Memecahkan masalah penyeimbang beban layanan di Amazon ECS](troubleshoot-service-load-balancers.md).
+ Saat menggunakan tipe `instance` target, tugas dan penyeimbang beban Anda harus dalam VPC yang sama. Saat menggunakan tipe `ip` target, konektivitas lintas-VPC didukung.
+ Pelestarian alamat IP klien Network Load Balancer kompatibel dengan target Fargate.
+ Gunakan grup target unik untuk setiap layanan. 

  Menggunakan grup target yang sama untuk beberapa layanan dapat menyebabkan masalah selama penerapan layanan.
+ Anda harus menentukan grup target yang terkait dengan Network Load Balancer.

*Untuk selengkapnya tentang cara membuat Network Load Balancer, lihat [Membuat Network Load Balancer di Network Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) Balancer*

**penting**  
Jika definisi tugas layanan Anda menggunakan mode `awsvpc` jaringan (yang diperlukan untuk Fargate), Anda harus memilih `ip` sebagai jenis target, bukan. `instance` Ini karena tugas yang menggunakan mode `awsvpc` jaringan dikaitkan dengan elastic network interface, bukan instans Amazon EC2.   
Anda tidak dapat mendaftarkan instans berdasarkan ID instans jika mereka memiliki jenis instance berikut: C1,,,,, CC1 CC2, G1 CG1 CG2, G2 CR1,,, M1, M2 HI1 HS1, M3, dan T1. Anda dapat mendaftarkan instans tipe ini berdasarkan alamat IP. 

# Menggunakan Load Balancer Gateway untuk Amazon ECS
<a name="glb"></a>

Penyeimbang Beban Gateway beroperasi pada lapisan ketiga model Open Systems Interconnection (OSI), yaitu lapisan jaringan. Penyeimbang Beban Gateway mendengarkan semua paket IP di semua port dan meneruskan lalu lintas ke grup target yang ditentukan dalam aturan listener. Ini mempertahankan kelengketan aliran ke alat target tertentu menggunakan 5-tuple (untuk aliran) atau 3-tuple (untuk TCP/UDP aliran non-TCP/UDP). Misalnya, jika definisi kontainer tugas Anda menentukan port 80 untuk port kontainer NGINX, dan port 0 untuk port host, maka port host dipilih secara dinamis dari rentang port sementara instance kontainer (seperti 32768 hingga 61000 pada AMI Amazon ECS terbaru yang dioptimalkan). Saat tugas diluncurkan, kontainer NGINX terdaftar dengan Load Balancer Gateway sebagai ID instance dan kombinasi port, dan lalu lintas didistribusikan ke ID instance dan port yang sesuai dengan container tersebut. Pemetaan dinamis ini mengizinkan Anda memiliki banyak tugas dari satu layanan pada instans kontainer yang sama. Untuk informasi selengkapnya, lihat [Apa itu Load Balancer Gateway di Gateway *Load Balancers*](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html).

Untuk informasi tentang praktik terbaik untuk menyetel parameter guna mempercepat penerapan Anda, lihat:
+ [Mengoptimalkan parameter pemeriksaan kondisi penyeimbang beban untuk Amazon ECS](load-balancer-healthcheck.md)
+ [Optimalkan parameter pengurasan koneksi penyeimbang beban untuk Amazon ECS](load-balancer-connection-draining.md)

Pertimbangkan hal berikut saat menggunakan Gateway Load Balancer dengan Amazon ECS:
+ Amazon ECS memerlukan peran IAM terkait layanan yang menyediakan izin yang diperlukan untuk mendaftarkan dan membatalkan pendaftaran target dengan penyeimbang beban Anda saat tugas dibuat dan dihentikan. Untuk informasi selengkapnya, lihat [Menggunakan peran terkait layanan untuk Amazon ECS](using-service-linked-roles.md).
+ Untuk layanan dalam konfigurasi IPv6 -only, Anda harus mengatur tipe alamat IP grup target dari Load `dualstack` Balancer Gateway ke.
+ Untuk layanan dengan tugas yang menggunakan mode jaringan selain`awsvpc`, Gateway Load Balancer tidak didukung.
+ Konfigurasi subnet penyeimbang beban Anda harus menyertakan semua Availability Zone tempat instans kontainer Anda berada.
+ Setelah Anda membuat layanan, konfigurasi penyeimbang beban tidak dapat diubah dari. Konsol Manajemen AWS Anda dapat menggunakan AWS Copilot, AWS CloudFormation, AWS CLI atau SDK untuk memodifikasi konfigurasi penyeimbang beban hanya untuk pengontrol penerapan `ECS` bergulir, bukan biru/hijau atau eksternal. AWS CodeDeploy Saat Anda menambahkan, memperbarui, atau menghapus konfigurasi penyeimbang beban, Amazon ECS memulai penerapan baru dengan konfigurasi Elastic Load Balancing yang diperbarui. Hal ini menyebabkan tugas mendaftar dan membatalkan pendaftaran dari penyeimbang beban. Kami menyarankan Anda memverifikasi ini di lingkungan pengujian sebelum memperbarui konfigurasi Elastic Load Balancing. Untuk informasi tentang cara mengubah konfigurasi, lihat [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)di *Referensi API Amazon Elastic Container Service*. 
+ Jika tugas layanan gagal dalam kriteria pemeriksaan kesehatan penyeimbang beban, tugas dihentikan dan dimulai ulang. Proses ini berlanjut hingga layanan Anda mencapai jumlah tugas berjalan yang diinginkan.
+ Saat Anda menggunakan Load Balancer Gateway yang dikonfigurasi dengan alamat IP sebagai target, permintaan akan terlihat berasal dari alamat IP pribadi Gateway Load Balancers. Ini berarti bahwa layanan di balik Load Balancer Gateway secara efektif terbuka untuk dunia segera setelah Anda mengizinkan permintaan masuk dan pemeriksaan kesehatan di grup keamanan target.
+ Untuk tugas Fargate, Anda harus menggunakan versi platform `1.4.0` (Linux) atau `1.0.0` (Windows).
+ Jika Anda mengalami masalah dengan layanan yang diaktifkan penyeimbang beban, lihat [Memecahkan masalah penyeimbang beban layanan di Amazon ECS](troubleshoot-service-load-balancers.md).
+ Saat menggunakan tipe `instance` target, tugas dan penyeimbang beban Anda harus dalam VPC yang sama. Saat menggunakan tipe `ip` target, konektivitas lintas-VPC didukung.
+ Gunakan grup target unik untuk setiap layanan. 

  Menggunakan grup target yang sama untuk beberapa layanan dapat menyebabkan masalah selama penerapan layanan.
+ Anda harus menentukan grup target yang terkait dengan Load Balancer Gateway.

*Untuk informasi tentang cara membuat Load Balancer Gateway, lihat [Memulai Gateway Load Balancers di Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html)*

**penting**  
Jika definisi tugas layanan Anda menggunakan mode `awsvpc` jaringan (yang diperlukan untuk Fargate), Anda harus memilih `ip` sebagai jenis target, bukan. `instance` Ini karena tugas yang menggunakan mode `awsvpc` jaringan dikaitkan dengan elastic network interface, bukan instans Amazon EC2.   
Anda tidak dapat mendaftarkan instans berdasarkan ID instans jika mereka memiliki jenis instance berikut: C1,,,,, CC1 CC2, G1 CG1 CG2, G2 CR1,,, M1, M2 HI1 HS1, M3, dan T1. Anda dapat mendaftarkan instans tipe ini berdasarkan alamat IP. 

# Mendaftarkan beberapa grup target dengan layanan Amazon ECS
<a name="register-multiple-targetgroups"></a>

Layanan Amazon ECS Anda dapat melayani lalu lintas dari beberapa penyeimbang beban dan mengekspos beberapa port seimbang beban saat Anda menentukan beberapa grup target dalam definisi layanan.

Untuk membuat layanan yang menentukan beberapa grup target, Anda harus membuat layanan menggunakan Amazon ECS API, SDK AWS CLI, atau templat. CloudFormation Setelah layanan dibuat, Anda dapat melihat layanan dan grup target yang terdaftar dengan Konsol Manajemen AWS. Anda harus menggunakan `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` untuk memodifikasi konfigurasi penyeimbang beban dari layanan yang ada.

Beberapa grup target dapat ditentukan dalam penentuan layanan menggunakan format berikut. Untuk sintaksis lengkap penentuan layanan, lihat [Templat definisi layanan](sd-template.md).

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"container_name",
      "containerPort":container_port
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"container_name",
      "containerPort":container_port
   }
]
```

## Pertimbangan-pertimbangan
<a name="multiple-targetgroups-considerations"></a>

Hal-hal berikut harus dipertimbangkan saat Anda menentukan beberapa grup target dalam penentuan layanan.
+ Untuk layanan yang menggunakan Application Load Balancer atau Penyeimbang Beban Jaringan, Anda tidak dapat melampirkan lebih dari lima grup target ke layanan.
+ Penentuan beberapa grup target dalam penentuan layanan hanya didukung dalam kondisi berikut:
  + Layanan harus menggunakan Application Load Balancer atau Network Load Balancer.
  + Layanan harus menggunakan (`ECS`) jenis pengontrol penyebaran. Ini bisa berupa penyebaran native/blue hijau Amazon ECS, atau penerapan pembaruan bergulir.
+ Menentukan beberapa grup target didukung untuk layanan yang berisi tugas menggunakan jenis peluncuran Fargate dan EC2.
+ Saat membuat layanan yang menentukan beberapa grup target, peran terkait layanan Amazon ECS harus dibuat. Peran dibuat dengan menghilangkan parameter `role` dalam permintaan API, atau properti `Role` di CloudFormation. Untuk informasi selengkapnya, lihat [Menggunakan peran terkait layanan untuk Amazon ECS](using-service-linked-roles.md).

## Contoh penentuan layanan
<a name="multiple-targetgroups-examples"></a>

Berikut adalah beberapa contoh kasus penggunaan untuk menentukan beberapa grup target dalam penentuan layanan. Untuk sintaksis penentuan layanan lengkap, lihat [Templat definisi layanan](sd-template.md).

### Memiliki penyeimbang beban terpisah untuk lalu lintas internal dan eksternal
<a name="multiple-targetgroups-example1"></a>

Dalam kasus penggunaan berikut, layanan menggunakan dua penyeimbang beban terpisah, satu untuk lalu lintas internal dan yang kedua untuk lalu lintas yang berhadapan dengan internet, untuk kontainer dan port yang sama.

```
"loadBalancers":[
   //Internal ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"nginx",
      "containerPort":8080
   },
   //Internet-facing ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"nginx",
      "containerPort":8080
   }
]
```

### Mengekspos beberapa port dari wadah yang sama
<a name="multiple-targetgroups-example1"></a>

Dalam kasus penggunaan berikut, layanan menggunakan satu penyeimbang beban, akan tetapi mengekspos beberapa port dari kontainer yang sama. Misalnya, kontainer Jenkins mungkin mengekspos port 8080 untuk antarmuka web Jenkins dan port 50000 untuk API.

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"jenkins",
      "containerPort":8080
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"jenkins",
      "containerPort":50000
   }
]
```

### Mengekspos port dari beberapa kontainer
<a name="multiple-targetgroups-example3"></a>

Dalam kasus penggunaan berikut, layanan menggunakan satu penyeimbang beban dan dua grup target untuk mengekspos port dari kontainer terpisah.

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"webserver",
      "containerPort":80
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"database",
      "containerPort":3306
   }
]
```

# Menskalakan layanan Amazon ECS secara otomatis
<a name="service-auto-scaling"></a>

*Penskalaan otomatis* adalah kemampuan untuk menambah atau mengurangi jumlah tugas yang diinginkan dalam layanan Amazon ECS Anda secara otomatis. Amazon ECS memanfaatkan layanan Application Auto Scaling untuk menyediakan fungsionalitas ini. Untuk informasi selengkapnya, lihat [Panduan Pengguna Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html).

Amazon ECS menerbitkan CloudWatch metrik dengan penggunaan CPU dan memori rata-rata layanan Anda. Untuk informasi selengkapnya, lihat [Metrik pemanfaatan layanan Amazon ECS](service_utilization.md). Anda dapat menggunakan metrik ini dan CloudWatch metrik lainnya untuk meningkatkan skala layanan Anda (menambahkan lebih banyak tugas) untuk menangani permintaan tinggi pada waktu puncak, dan untuk meningkatkan skala dalam layanan Anda (menjalankan lebih sedikit tugas) untuk mengurangi biaya selama periode pemanfaatan rendah. 

Amazon ECS Service Auto Scaling mendukung jenis penskalaan otomatis berikut:
+ [Gunakan metrik target untuk menskalakan layanan Amazon ECS](service-autoscaling-targettracking.md)— Menambah atau mengurangi jumlah tugas yang dijalankan layanan Anda berdasarkan nilai target untuk metrik tertentu. Hal ini mirip dengan cara termostat mempertahankan suhu di rumah Anda. Anda mengatur suhu dan termostat melakukan sisanya.
+ [Gunakan kenaikan yang telah ditentukan berdasarkan CloudWatch alarm untuk menskalakan layanan Amazon ECS](service-autoscaling-stepscaling.md)Meningkatkan atau mengurangi jumlah tugas yang dijalankan layanan Anda berdasarkan serangkaian penyesuaian penskalaan, yang dikenal sebagai penyesuaian langkah, yang bervariasi berdasarkan ukuran pelanggaran alarm. 
+ [Gunakan tindakan terjadwal untuk menskalakan layanan Amazon ECS](service-autoscaling-schedulescaling.md)Meningkatkan atau mengurangi jumlah tugas yang dijalankan layanan Anda berdasarkan tanggal dan waktu.
+ [Gunakan pola historis untuk menskalakan layanan Amazon ECS dengan penskalaan prediktif](predictive-auto-scaling.md)Meningkatkan atau mengurangi jumlah tugas yang dijalankan layanan Anda berdasarkan analitik data beban historis untuk mendeteksi pola harian atau mingguan dalam arus lalu lintas. 

   

## Pertimbangan-pertimbangan
<a name="auto-scaling-concepts"></a>

Saat menggunakan kebijakan penskalaan, pertimbangkan hal berikut:
+ Amazon ECS mengirimkan metrik dalam interval 1 menit ke. CloudWatch Metrik tidak tersedia sampai kluster dan layanan mengirimkan metrik CloudWatch, dan Anda tidak dapat membuat CloudWatch alarm untuk metrik yang tidak ada. 
+ Kebijakan penskalaan mendukung periode pendinginan. Ini adalah jumlah detik untuk menunggu hingga aktivitas penskalaan sebelumnya berlaku. 
  + Dengan kebijakan penskalaan, tujuannya adalah untuk terus menerus (tetapi tidak berlebihan) menskalakan naik. Setelah Service Auto Scaling berhasil diskalakan menggunakan kebijakan penskalaan, maka mulai menghitung waktu cooldown. Kebijakan penskalaan tidak akan meningkatkan kapasitas yang diinginkan lagi kecuali jika skala yang lebih besar dimulai atau periode cooldown berakhir. Selama periode pendinginan penskalaan keluar berlaku, kapasitas yang ditambahkan dengan cara memulai aktivitas penskalaan keluar dihitung sebagai bagian dari kapasitas yang diinginkan untuk aktivitas penskalaan keluar berikutnya. 
  + Untuk kejadian penskalaan kedalam, tujuannya adalah untuk melakukan penskalaan kedalam secara konservatif guna melindungi ketersediaan aplikasi Anda, sehingga aktivitas penskalaan kedalam diblokir hingga periode pendinginan berakhir. Namun, jika alarm lain memulai aktivitas scale-out selama periode cooldown scale-in, Service Auto Scaling segera menskalakan target. Dalam hal ini, periode pendinginan penskalaan kedalam berhenti dan tidak selesai. 
+ Penjadwal layanan menghormati jumlah yang diinginkan setiap saat, tetapi selama Anda memiliki kebijakan penskalaan aktif dan alarm pada layanan, Service Auto Scaling dapat mengubah hitungan yang diinginkan yang ditetapkan secara manual oleh Anda.
+ Jika jumlah yang diinginkan layanan ditetapkan di bawah nilai kapasitas minimumnya, dan alarm memulai aktivitas scale-out, Service Auto Scaling menskalakan jumlah yang diinginkan hingga nilai kapasitas minimum dan kemudian melanjutkan skala sesuai kebutuhan, berdasarkan kebijakan penskalaan yang terkait dengan alarm. Namun, kegiatan penskalaan kedalam tidak menyesuaikan jumlah yang diinginkan, karena sudah di bawah nilai kapasitas minimal.
+ Jika jumlah yang diinginkan layanan ditetapkan di atas nilai kapasitas maksimumnya, dan alarm memulai skala dalam aktivitas, Auto Scaling Service menskalakan hitungan yang diinginkan ke nilai kapasitas maksimum dan kemudian melanjutkan penskalaan sesuai kebutuhan, berdasarkan kebijakan penskalaan yang terkait dengan alarm. Namun, aktivitas penskalaan keluar tidak menyesuaikan jumlah yang diinginkan, karena sudah di atas nilai kapasitas maksimal.
+ Selama aktivitas penskalaan, jumlah tugas yang sebenarnya berjalan dalam layanan adalah nilai yang digunakan Service Auto Scaling sebagai titik awalnya, sebagai lawan dari hitungan yang diinginkan. Inilah yang seharusnya menjadi kapasitas pemrosesan. Ini mencegah penskalaan berlebihan (runaway) yang mungkin tidak terpenuhi, misalnya, jika tidak ada sumber daya instance kontainer yang cukup untuk menempatkan tugas tambahan. Jika nantinya kapasitas instans kontainer tersedia, maka aktivitas penskalaan yang tertunda kemungkinan akan berhasil, dan kemudian aktivitas penskalaan lebih lanjut dapat diteruskan setelah periode pendinginan.
+ Jika Anda ingin jumlah tugas Anda menjadi nol ketika tidak ada pekerjaan yang harus dilakukan, tetapkan kapasitas minimum 0. Dengan kebijakan penskalaan pelacakan target, ketika kapasitas aktual adalah 0 dan metrik menunjukkan bahwa ada permintaan beban kerja, Service Auto Scaling menunggu satu titik data dikirim sebelum penskalaan keluar. Dalam hal ini, penskalaan otomatis layanan akan menskalakan keluar berdasarkan jumlah minimal yang memungkinkan sebagai titik awal, dan kemudian melanjutkan penskalaan berdasarkan jumlah tugas berjalan yang aktual.
+ Application Auto Scaling menonaktifkan proses scale-in saat penerapan Amazon ECS sedang berlangsung. Namun, proses penskalaan keluar terus terjadi, kecuali ditangguhkan, selama deployment. Perilaku ini tidak berlaku untuk layanan Amazon ECS menggunakan pengontrol penerapan eksternal. Untuk informasi selengkapnya, lihat [penskalaan otomatis dan deployment layanan](#service-auto-scaling-deployments).
+ Anda memiliki beberapa opsi Application Auto Scaling untuk tugas Amazon ECS. Pelacakan target adalah mode termudah untuk digunakan. Dengan itu, yang perlu Anda lakukan adalah menetapkan nilai target untuk metrik, seperti pemanfaatan rata-rata CPU. Kemudian, auto scaler secara otomatis mengelola jumlah tugas yang diperlukan untuk mencapai nilai itu. Dengan penskalaan langkah, Anda dapat bereaksi lebih cepat terhadap perubahan permintaan, karena Anda menentukan ambang batas tertentu untuk metrik penskalaan Anda, dan berapa banyak tugas yang harus ditambahkan atau dihapus saat ambang batas dilintasi. Dan, yang lebih penting, Anda dapat bereaksi sangat cepat terhadap perubahan permintaan dengan meminimalkan jumlah waktu alarm ambang batas dilanggar.

Untuk informasi selengkapnya tentang praktik terbaik untuk penskalaan otomatis servis, lihat[Mengoptimalkan penskalaan otomatis layanan Amazon ECS](capacity-autoscaling-best-practice.md).

## penskalaan otomatis dan deployment layanan
<a name="service-auto-scaling-deployments"></a>

Application Auto Scaling menonaktifkan proses scale-in saat penerapan Amazon ECS sedang berlangsung. Namun, proses penskalaan keluar terus terjadi, kecuali ditangguhkan, selama deployment. Perilaku ini tidak berlaku untuk layanan Amazon ECS menggunakan pengontrol penerapan eksternal. Jika Anda ingin menangguhkan proses penskalaan keluar saat deployment dalam progres, lakukan langkah-langkah berikut.

1. Panggil [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html)perintah, tentukan ID sumber daya layanan yang terkait dengan target yang dapat diskalakan di Application Auto Scaling (Contoh:). `service/default/sample-webapp` Catat outputnya. Anda akan membutuhkannya saat memanggil perintah berikutnya.

1. Panggil [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)perintah, tentukan ID sumber daya, namespace, dan dimensi yang dapat diskalakan. Tentukan `true`, baik untuk `DynamicScalingInSuspended` maupun `DynamicScalingOutSuspended`.

1. Setelah penerapan selesai, Anda dapat memanggil [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)perintah untuk melanjutkan penskalaan.

Untuk informasi lebih lanjut, lihat [Menangguhkan dan melanjutkan penskalaan untuk Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html).

# Gunakan metrik target untuk menskalakan layanan Amazon ECS
<a name="service-autoscaling-targettracking"></a>

Dengan kebijakan penskalaan pelacakan target, Anda memilih metrik dan menetapkan nilai target. Auto Scaling Amazon ECS Service membuat dan mengelola CloudWatch alarm yang mengontrol kebijakan penskalaan dan menghitung penyesuaian penskalaan berdasarkan metrik dan nilai target. Kebijakan penskalaan menambahkan atau menghapus tugas layanan sebagaimana diperlukan untuk menjaga metrik pada, atau mendekati nilai target yang ditentukan. Selain menjaga agar metrik tetap mendekati nilai target, kebijakan penskalaan pelacakan target juga menyesuaikan dengan fluktuasi metrik akibat pola beban yang berfluktuasi, serta meminimalkan fluktuasi yang cepat dalam jumlah tugas yang berjalan di layanan Anda.

Kebijakan pelacakan target menghilangkan kebutuhan untuk menentukan CloudWatch alarm dan penyesuaian penskalaan secara manual. Amazon ECS menangani ini secara otomatis berdasarkan target yang Anda tetapkan.

Pertimbangkan hal berikut saat menggunakan kebijakan pelacakan target:
+ Kebijakan penskalaan pelacakan target mengasumsikan bahwa penskalaan ke luar harus dilakukan saat metrik yang ditentukan berada di atas nilai target. Anda tidak dapat menggunakan kebijakan penskalaan pelacakan target untuk menskalakan keluar jika metrik yang ditentukan berada di bawah nilai target.
+ Kebijakan penskalaan pelacakan target tidak melakukan penskalaan saat metrik yang ditentukan tidak memiliki data yang mencukupi. Kebijakan penskalaan pelacakan target tidak melakukan penskalaan ke dalam karena data yang tidak mencukupi tidak ditafsirkan sebagai pemanfaatan yang rendah.
+ Anda mungkin melihat kesenjangan antara nilai target dan titik data metrik yang aktual. Ini karena Service Auto Scaling selalu bertindak konservatif dengan membulatkan ke atas atau ke bawah ketika menentukan berapa banyak kapasitas untuk menambah atau menghapus. Hal ini mencegahnya menambahkan kapasitas yang tidak mencukupi atau membuang terlalu banyak kapasitas. 
+ Untuk memastikan ketersediaan aplikasi, layanan menskalakan keluar secara proporsional ke dalam metrik secepat mungkin, namun penskalaan kedalam meningkat secara bertahap.
+ Application Auto Scaling menonaktifkan proses scale-in saat penerapan Amazon ECS sedang berlangsung. Namun, proses penskalaan keluar terus terjadi, kecuali ditangguhkan, selama deployment. Perilaku ini tidak berlaku untuk layanan Amazon ECS menggunakan pengontrol penerapan eksternal. Untuk informasi selengkapnya, lihat [penskalaan otomatis dan deployment layanan](service-auto-scaling.md#service-auto-scaling-deployments).
+ Anda dapat memiliki beberapa kebijakan penskalaan pelacakan target untuk layanan Amazon ECS, asalkan masing-masing menggunakan metrik yang berbeda. Tujuan dari Service Auto Scaling adalah untuk selalu memprioritaskan ketersediaan, sehingga perilakunya berbeda tergantung pada apakah kebijakan pelacakan target siap untuk skala atau skala. Ini akan meningkatkan skala layanan jika ada kebijakan pelacakan target yang siap untuk diskalakan, tetapi akan menskalakan hanya jika semua kebijakan pelacakan target (dengan bagian penskalaan dihidupkan) siap untuk diskalakan. 
+ Jangan mengedit atau menghapus CloudWatch alarm yang dikelola Service Auto Scaling untuk kebijakan penskalaan pelacakan target. Service Auto Scaling akan menghapus alarm secara otomatis saat Anda menghapus kebijakan penskalaan.
+ `ALBRequestCountPerTarget`Metrik untuk kebijakan penskalaan pelacakan target tidak didukung untuk jenis blue/green penerapan. 

Untuk informasi lebih lanjut tentang kebijakan penskalaan pelacakan target, lihat [Kebijakan penskalaan pelacakan target](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) dalam *Panduan Pengguna Application Auto Scaling*.

# Membuat kebijakan penskalaan pelacakan target untuk penskalaan otomatis layanan Amazon ECS
<a name="target-tracking-create-policy"></a>

Buat kebijakan penskalaan pelacakan target agar Amazon ECS meningkatkan atau mengurangi jumlah tugas yang diinginkan di layanan Anda secara otomatis. Pelacakan target bekerja dari nilai metrik target.

## Konsol
<a name="target-tracking-create-policy-aws-console"></a>

1. Selain izin IAM standar untuk membuat dan memperbarui layanan, Anda memerlukan izin tambahan. Untuk informasi selengkapnya, lihat [Izin IAM diperlukan untuk penskalaan otomatis layanan Amazon ECS](auto-scaling-IAM.md).

1. Tentukan metrik yang akan digunakan untuk kebijakan. Metrik berikut tersedia:
   +  **ECSServiceRata-rata CPUUtilization** — Pemanfaatan CPU rata-rata yang harus digunakan layanan. 
   + **ECSServiceAverageMemoryUtilization**— Pemanfaatan memori rata-rata yang harus digunakan layanan. 
   + **ALBRequestCountPerTarget**— Jumlah rata-rata permintaan per menit yang idealnya diterima tugas itu.

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, dan kemudian pilih layanan.

   Halaman detail layanan muncul.

1. Pilih **Atur jumlah tugas**.

1. Di bawah **jumlah tugas layanan Amazon ECS**, pilih **Gunakan penskalaan otomatis**.

   **Bagian Penghitungan tugas** muncul.

   1. Untuk **Jumlah tugas minimum**, masukkan batas bawah jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan berada di bawah hitungan ini.

   1. Untuk **Maksimum**, masukkan batas atas jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan melebihi hitungan ini.

   1. Pilih **Simpan**.

      Halaman kebijakan muncul.

1. Pilih **Buat kebijakan penskalaan**.

   Halaman **Buat kebijakan** akan muncul.

1. Untuk **Jenis kebijakan penskalaan**, pilih **Pelacakan target**.

1. Untuk **nama Kebijakan**, masukkan nama kebijakan.

1. Untuk **jenis Metrik**, pilih metrik Anda dari daftar opsi.

1. Untuk **pemanfaatan Target**, masukkan nilai target untuk persentase tugas yang harus dipertahankan Amazon ECS. Service auto scaling meningkatkan kapasitas Anda hingga pemanfaatan rata-rata berada pada target pemanfaatan, atau hingga mencapai jumlah maksimum tugas yang Anda tentukan.

1. Di bawah **Pengaturan Tambahan**, lakukan hal berikut

   1. Untuk **periode cooldown Scale-in**, masukkan jumlah waktu dalam hitungan detik setelah aktivitas scale-in selesai sebelum aktivitas scale-in lainnya dapat dimulai. 

   1. Untuk **periode cooldown Scale-out**, masukkan jumlah waktu dalam hitungan detik untuk menunggu aktivitas scale-out sebelumnya diterapkan.

   1. Untuk hanya membuat kebijakan penskalaan, pilih **Nonaktifkan** penskalaan.

1. Pilih **Buat kebijakan penskalaan**.

## AWS CLI
<a name="target-tracking-create-policy-aws-cli"></a>

1. Daftarkan layanan Amazon ECS Anda sebagai target yang dapat diskalakan menggunakan perintah. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)

1. Buat kebijakan penskalaan menggunakan [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)perintah.

# Gunakan kenaikan yang telah ditentukan berdasarkan CloudWatch alarm untuk menskalakan layanan Amazon ECS
<a name="service-autoscaling-stepscaling"></a>

Dengan kebijakan penskalaan langkah, Anda membuat dan mengelola CloudWatch alarm yang menjalankan proses penskalaan. Saat alarm dilanggar, Amazon ECS memulai kebijakan penskalaan yang terkait dengan alarm tersebut. Kebijakan penskalaan langkah menskalakan tugas menggunakan serangkaian penyesuaian, yang dikenal sebagai penyesuaian langkah. Ukuran penyesuaian bervariasi berdasarkan besarnya pelanggaran alarm. 
+ Jika pelanggaran melebihi ambang batas pertama, Amazon ECS menerapkan penyesuaian langkah pertama. 
+ Jika pelanggaran melebihi ambang kedua, Amazon ECS menerapkan penyesuaian langkah kedua, dan seterusnya.

Kami sangat menyarankan agar Anda menggunakan kebijakan penskalaan pelacakan target untuk menskalakan metrik seperti penggunaan CPU rata-rata atau jumlah permintaan rata-rata per target. Metrik yang menurun ketika kapasitas meningkat dan meningkat ketika kapasitas menurun dapat digunakan untuk skala proporsional atau dalam jumlah tugas menggunakan pelacakan target. Ini membantu memastikan bahwa Amazon ECS mengikuti kurva permintaan untuk aplikasi Anda dengan cermat.

# Buat kebijakan penskalaan langkah untuk penskalaan otomatis layanan Amazon ECS
<a name="step-scaling-create-policy"></a>

Buat kebijakan penskalaan langkah agar Amazon ECS menambah atau mengurangi jumlah tugas yang diinginkan dalam layanan Anda secara otomatis. Penskalaan langkah berjalan berdasarkan serangkaian penyesuaian penskalaan, yang dikenal sebagai penyesuaian langkah, yang bervariasi berdasarkan ukuran pelanggaran alarm. 

## Konsol
<a name="step-scaling-create-policy-aws-console"></a>

1. Selain izin IAM standar untuk membuat dan memperbarui layanan, Anda memerlukan izin tambahan. Untuk informasi selengkapnya, lihat [Izin IAM diperlukan untuk penskalaan otomatis layanan Amazon ECS](auto-scaling-IAM.md).

1. Tentukan metrik yang akan digunakan untuk kebijakan. Metrik berikut tersedia:
   +  **ECSServiceRata-rata CPUUtilization** — Pemanfaatan CPU rata-rata yang harus digunakan layanan. 
   + **ECSServiceAverageMemoryUtilization**— Pemanfaatan memori rata-rata yang harus digunakan layanan. 
   + **ALBRequestCountPerTarget**— Jumlah rata-rata permintaan per menit yang idealnya diterima tugas itu.

1. Buat CloudWatch alarm untuk metrik. Untuk informasi selengkapnya, lihat [Membuat CloudWatch alarm berdasarkan ambang batas statis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) di *Panduan CloudWatch Pengguna Amazon*.

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, dan kemudian pilih layanan.

   Halaman detail layanan muncul.

1. Pilih **Atur jumlah tugas**.

1. Di bawah **jumlah tugas layanan Amazon ECS**, pilih **Gunakan penskalaan otomatis**.

   **Bagian Penghitungan tugas** muncul.

   1. Untuk **Jumlah tugas minimum**, masukkan batas bawah jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan berada di bawah hitungan ini.

   1. Untuk **Maksimum**, masukkan batas atas jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan melebihi hitungan ini.

   1. Pilih **Simpan**.

      Halaman kebijakan muncul.

1. Pilih **Buat kebijakan penskalaan**.

   Halaman **Buat kebijakan** akan muncul.

1. Untuk **jenis kebijakan Penskalaan**, pilih **Penskalaan Langkah**.

1. Konfigurasikan properti scaling-out. Di bawah **Langkah-langkah untuk menambahkan tugas** lakukan hal berikut:

   1. Untuk **nama Kebijakan**, masukkan nama kebijakan.

   1. Untuk **nama CloudWatch alarm**, pilih CloudWatch alarm.

   1. Untuk **jenis agregasi metrik**, pilih cara membandingkan metrik yang dipilih dengan ambang batas yang ditentukan.

   1. Untuk **tipe Djustment** A, pilih apakah penyesuaian didasarkan pada perubahan jumlah tugas, atau perubahan persentase tugas.

   1. **Untuk Tindakan yang harus diambil**, masukkan nilai untuk tindakan apa yang harus diambil.

      Pilih **Tambahkan langkah** untuk menambahkan tindakan tambahan.

1. Konfigurasikan properti penskalaan. Di bawah **Langkah-langkah untuk menghapus tugas**, lakukan hal berikut:

   1. Untuk **nama Kebijakan**, masukkan nama kebijakan.

   1. Untuk **nama CloudWatch alarm**, pilih CloudWatch alarm.

   1. Untuk **jenis agregasi metrik**, pilih cara membandingkan metrik yang dipilih dengan ambang batas yang ditentukan.

   1. Untuk **jenis Penyesuaian**, pilih apakah penyesuaian didasarkan pada perubahan jumlah tugas, atau perubahan persentase tugas.

   1. **Untuk Tindakan yang harus diambil**, masukkan nilai untuk tindakan apa yang harus diambil.

      Pilih **Tambahkan langkah** untuk menambahkan tindakan tambahan.

1. Untuk **periode Cooldown**, masukkan jumlah waktu, dalam detik, untuk menunggu aktivitas penskalaan sebelumnya diterapkan. Untuk kebijakan add, ini adalah waktu setelah aktivitas scale-out yang kebijakan penskalaan memblokir aktivitas scale-in dan membatasi berapa banyak tugas yang dapat diskalakan pada suatu waktu. Untuk kebijakan penghapusan, ini adalah waktu setelah aktivitas penskalaan yang harus diteruskan sebelum aktivitas penskalaan lainnya dapat dimulai. 

1. Pilih **Buat kebijakan penskalaan**.

## AWS CLI
<a name="step-scaling-create-policy-aws-cli"></a>

1. Daftarkan layanan Amazon ECS Anda sebagai target yang dapat diskalakan menggunakan perintah. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)

1. Buat kebijakan penskalaan menggunakan [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)perintah.

# Gunakan tindakan terjadwal untuk menskalakan layanan Amazon ECS
<a name="service-autoscaling-schedulescaling"></a>

Dengan penskalaan terjadwal, Anda dapat mengatur penskalaan otomatis untuk aplikasi berdasarkan perubahan beban yang dapat diprediksi dengan membuat tindakan terjadwal yang menambah atau mengurangi jumlah tugas pada waktu tertentu. Ini memungkinkan Anda menskalakan aplikasi secara proaktif agar sesuai dengan perubahan beban yang dapat diprediksi.

Tindakan penskalaan terjadwal ini memungkinkan Anda mengoptimalkan biaya dan kinerja. Aplikasi Anda memiliki jumlah tugas yang cukup untuk menangani puncak lalu lintas pertengahan minggu, tetapi tidak menyediakan jumlah tugas secara berlebihan di waktu lain. 

Anda dapat menggunakan kebijakan penskalaan dan penskalaan terjadwal bersama-sama untuk mendapatkan manfaat dari pendekatan proaktif dan reaktif untuk penskalaan. Setelah tindakan penskalaan terjadwal berjalan, kebijakan penskalaan dapat terus membuat keputusan tentang apakah akan menskalakan jumlah tugas lebih lanjut. Ini membantu Anda memastikan bahwa Anda memiliki cukup banyak tugas untuk menangani beban aplikasi Anda. Sementara skala aplikasi Anda sesuai dengan permintaan, kapasitas saat ini harus termasuk dalam jumlah tugas minimum dan maksimum yang ditetapkan oleh tindakan terjadwal Anda. 

Anda dapat mengonfigurasi penskalaan jadwal menggunakan. AWS CLI Untuk informasi selengkapnya tentang penskalaan terjadwal, lihat [Penskalaan Terjadwal di Panduan Pengguna *Application Auto Scaling*](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html).

# Buat tindakan terjadwal untuk penskalaan otomatis layanan Amazon ECS
<a name="scheduled-action-create-policy"></a>

Buat tindakan terjadwal agar Amazon ECS menambah atau mengurangi jumlah tugas yang dijalankan layanan Anda berdasarkan tanggal dan waktu. 

## Konsol
<a name="scheduled-action-policy-aws-console"></a>

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, pilih layanan.

   Halaman detail layanan muncul.

1. Pilih **Service auto scaling.**

   Halaman penskalaan otomatis layanan muncul.

1. Jika Anda belum mengonfigurasi penskalaan otomatis layanan, pilih **Setel jumlah tugas**.

   Bagian **penghitungan tugas layanan Amazon ECS** muncul.

   Di bawah **jumlah tugas layanan Amazon ECS**, pilih **Gunakan penskalaan otomatis layanan untuk menyesuaikan jumlah tugas yang diinginkan layanan Anda**.

   **Bagian Penghitungan tugas** muncul.

   1. Untuk **Jumlah tugas minimum**, masukkan batas bawah jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan berada di bawah hitungan ini.

   1. Untuk **Maksimum**, masukkan batas atas jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan melebihi hitungan ini.

   1. Pilih **Pilih Simpan**.

      Halaman kebijakan muncul.

1. Pilih **Tindakan terjadwal**, lalu pilih **Buat**.

   Halaman **tindakan Buat Terjadwal** muncul.

1. Untuk **nama Action**, masukkan nama unik.

1. Untuk **zona waktu**, pilih zona waktu.

   Semua zona waktu yang tercantum berasal dari database Zona Waktu IANA. Untuk informasi selengkapnya, lihat [Daftar zona waktu database tz](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

1. Untuk **Waktu mulai**, masukkan **Tanggal** dan **Waktu** tindakan dimulai.

   Jika Anda memilih jadwal berulang, waktu mulai menentukan kapan tindakan terjadwal pertama dalam seri berulang berjalan.

1. Untuk **Recurrence**, pilih salah satu opsi yang tersedia.
   + Untuk menskalakan jadwal berulang, pilih seberapa sering Amazon ECS menjalankan tindakan terjadwal.
     + Jika Anda memilih opsi yang dimulai dengan **Rate**, ekspresi cron dibuat untuk Anda.
     + Jika Anda memilih **Cron**, masukkan ekspresi cron yang menentukan kapan harus melakukan tindakan. 
   + Untuk skala hanya sekali, pilih **Sekali**.

1. Di bawah **Penyesuaian tugas**, lakukan hal berikut:
   + Untuk **Minimum**, masukkan jumlah tugas minimum yang harus dijalankan oleh layanan.
   + Untuk **Maksimum**, masukkan jumlah tugas maksimum yang harus dijalankan layanan.

1. Pilih **Buat tindakan terjadwal**.

## CLI
<a name="scheduled-action-aws-cli"></a>

Gunakan AWS CLI sebagai berikut untuk mengonfigurasi kebijakan penskalaan terjadwal untuk layanan Anda. Ganti masing-masing *user input placeholder* dengan informasi Anda sendiri.

**Contoh: Untuk skala satu kali saja**  
Gunakan [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html)perintah berikut dengan `--start-time "YYYY-MM-DDThh:mm:ssZ"` dan dan salah satu atau keduanya `--MaxCapacity` opsi `--MinCapacity` dan. 

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-one-time-schedule \
  --start-time 2021-01-30T12:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

**Contoh: Untuk menjadwalkan penskalaan pada jadwal berulang**  
Gunakan perintah berikut [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html). Ganti *user input* dengan nilai-nilai Anda.

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-recurring-action \
  --schedule "rate(5 hours)" \
  --start-time 2021-01-30T12:00:00 \
  --end-time 2021-01-31T22:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

Jadwal pengulangan yang ditentukan berjalan berdasarkan zona waktu UTC. Untuk menentukan zona waktu yang berbeda, sertakan `--time-zone` opsi dan nama zona waktu IANA, seperti pada contoh berikut.

```
--time-zone "America/New_York"
```

Untuk informasi selengkapnya, lihat [Daftar zona waktu database tz](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

# Gunakan pola historis untuk menskalakan layanan Amazon ECS dengan penskalaan prediktif
<a name="predictive-auto-scaling"></a>

Penskalaan prediktif melihat data beban masa lalu lintas dari arus lalu lintas untuk menganalisis pola harian atau mingguan. Kemudian menggunakan analisis ini untuk mengantisipasi kebutuhan masa depan dan secara proaktif meningkatkan tugas dalam layanan Anda sesuai kebutuhan.

Penskalaan otomatis prediktif paling berguna dalam situasi berikut.
+ Lalu lintas siklus - Peningkatan penggunaan sumber daya selama jam kerja reguler, dan penurunan penggunaan sumber daya selama malam hari dan akhir pekan.
+ Pola on-and-off beban kerja berulang - Contohnya termasuk pemrosesan batch, pengujian, atau analisis data berkala.
+ Aplikasi dengan waktu inisialisasi yang lama - Ini dapat memengaruhi kinerja aplikasi selama peristiwa penskalaan yang menyebabkan latensi yang nyata.

Jika aplikasi Anda membutuhkan waktu lama untuk diinisialisasi dan lalu lintas meningkat dalam pola reguler, Anda harus mempertimbangkan untuk menggunakan penskalaan prediktif. Ini membantu Anda menskalakan lebih cepat dengan secara proaktif meningkatkan jumlah tugas untuk beban yang diperkirakan, alih-alih menggunakan kebijakan penskalaan dinamis, seperti Pelacakan Target atau Penskalaan Langkah saja. Dengan membantu Anda menghindari kemungkinan penyediaan berlebihan jumlah tugas, penskalaan prediktif juga berpotensi menghemat uang Anda.

Misalnya, pertimbangkan aplikasi yang memiliki penggunaan tinggi selama jam kerja dan penggunaan rendah dalam semalam. Pada awal setiap hari kerja, penskalaan prediktif dapat meningkatkan tugas sebelum masuknya lalu lintas pertama. Ini membantu aplikasi Anda mempertahankan ketersediaan dan kinerja tinggi saat beralih dari periode pemanfaatan yang lebih rendah ke periode pemanfaatan yang lebih tinggi. Anda tidak perlu menunggu penskalaan dinamis untuk bereaksi terhadap perubahan lalu lintas. Anda juga tidak perlu menghabiskan waktu meninjau pola pemuatan aplikasi Anda dan mencoba menjadwalkan jumlah tugas yang tepat menggunakan penskalaan terjadwal.

Penskalaan prediktif adalah kemampuan tingkat layanan yang menskalakan tugas layanan Anda secara independen dari penskalaan kapasitas komputasi yang mendasarinya (misalnya, EC2 atau Fargate). Untuk Fargate, AWS mengelola dan secara otomatis menskalakan kapasitas yang mendasarinya berdasarkan persyaratan tugas. Untuk kapasitas EC2, Anda dapat menggunakan penyedia kapasitas grup Auto Scaling untuk secara otomatis menskalakan instans EC2 yang mendasari berdasarkan persyaratan penskalaan tugas Anda.

**Topics**
+ [Ikhtisar penskalaan prediktif](#predictive-auto-scaling-overview)
+ [Buat kebijakan penskalaan prediktif](predictive-scaling-create-policy.md)
+ [Evaluasi kebijakan penskalaan prediktif Anda](predictive-scaling-graphs.md)
+ [Ganti perkiraan](predictive-scaling-overriding-forecast-capacity.md)
+ [Gunakan metrik khusus](predictive-scaling-custom-metrics.md)

## Cara kerja penskalaan prediktif di Amazon ECS
<a name="predictive-auto-scaling-overview"></a>

Di sini Anda dapat mempelajari tentang pertimbangan untuk menggunakan penskalaan prediktif, cara kerjanya, dan apa batasannya.

### Pertimbangan untuk menggunakan penskalaan prediktif
<a name="predictive-auto-scaling-considerations"></a>
+ Anda ingin memastikan penskalaan prediktif cocok untuk beban kerja Anda. Anda dapat memeriksanya dengan mengonfigurasi kebijakan penskalaan dalam mode **perkiraan saja** dan melihat apa yang direkomendasikan konsol. Anda harus mengevaluasi perkiraan dan rekomendasi sebelum mulai menggunakan penskalaan prediktif.
+ Sebelum penskalaan prediktif dapat memulai peramalan, dibutuhkan setidaknya 24 jam data historis. Semakin banyak data historis yang tersedia, semakin efektif ramalannya, dengan dua minggu ideal. Anda juga harus menunggu 24 jam sebelum penskalaan prediktif dapat menghasilkan perkiraan baru saat Anda menghapus layanan Amazon ECS dan membuat yang baru. Salah satu cara untuk mempercepat ini adalah dengan menggunakan metrik khusus untuk menggabungkan metrik di seluruh layanan Amazon ECS lama dan baru.
+ Pilih metrik pemuatan yang secara akurat mewakili beban penuh pada aplikasi Anda dan merupakan aspek aplikasi Anda yang paling penting untuk diskalakan.
+ Penskalaan dinamis dengan penskalaan prediktif membantu Anda mengikuti permintaan aplikasi dengan cermat, sehingga Anda dapat menskalakan selama jeda dan meningkatkan skala selama peningkatan lalu lintas yang tidak terduga. Ketika beberapa kebijakan penskalaan aktif, setiap kebijakan menentukan jumlah tugas yang diinginkan secara independen, dan jumlah tugas yang diinginkan diatur ke maksimum tugas tersebut.
+ Anda dapat menggunakan penskalaan prediktif di samping kebijakan penskalaan dinamis Anda, seperti pelacakan target atau penskalaan langkah, sehingga aplikasi Anda menskalakan berdasarkan pola real-time dan historis. Dengan sendirinya, penskalaan prediktif tidak menskalakan tugas Anda. 
+ Jika Anda menggunakan peran khusus saat memanggil `register-scalable-target` API, Anda mungkin mendapatkan kesalahan yang mengatakan kebijakan penskalaan prediktif hanya dapat berfungsi dengan SLR diaktifkan. Dalam hal ini Anda harus menelepon `register-scalable-target` lagi tetapi tanpa role-arn. Gunakan SLR saat mendaftarkan target yang dapat diskalakan dan panggil API. `put-scaling-policy`

### Cara kerja penskalaan prediktif
<a name="predictive-auto-scaling-details"></a>

Anda menggunakan penskalaan prediktif dengan membuat kebijakan penskalaan prediktif yang menentukan CloudWatch metrik untuk dipantau dan dianalisis. Penskalaan prediktif harus memiliki setidaknya 24 jam data untuk mulai memperkirakan nilai masa depan.

Setelah Anda membuat kebijakan, penskalaan prediktif mulai menganalisis data metrik hingga 14 hari terakhir untuk mengidentifikasi pola. Analisis ini digunakan untuk menghasilkan 48 jam perkiraan persyaratan per jam berikutnya. CloudWatch Data terbaru digunakan untuk memperbarui perkiraan setiap enam jam. Saat data baru masuk, penskalaan prediktif terus meningkatkan akurasi prakiraan masa depan.

Saat Anda pertama kali mengaktifkan penskalaan prediktif, penskalaan ini berjalan dalam mode *perkiraan saja*. Ini menghasilkan perkiraan dalam mode ini, tetapi tidak menskalakan layanan Amazon ECS Anda berdasarkan perkiraan tersebut. Ini berarti Anda dapat mengevaluasi keakuratan dan kesesuaian ramalan. Anda melihat data perkiraan dengan menggunakan operasi `GetPredictiveScalingForecast` API atau Konsol Manajemen AWS.

Saat Anda memutuskan untuk mulai menggunakan penskalaan prediktif, alihkan kebijakan penskalaan ke mode *perkiraan dan* skala. Berikut ini terjadi saat dalam mode ini.

Layanan Amazon ECS Anda diskalakan pada awal setiap jam berdasarkan perkiraan untuk jam itu, secara default. Anda dapat memilih untuk memulai lebih awal dengan menggunakan `SchedulingBufferTime` properti dalam operasi `PutScalingPolicy` API. Ini membuat tugas baru diluncurkan di depan permintaan yang diperkirakan dan memberi mereka waktu untuk boot dan siap menangani lalu lintas.

### Batas tugas maksimum
<a name="predictive-scaling-maximum-tasks-limit"></a>

Saat Anda mendaftarkan layanan Amazon ECS untuk penskalaan, Anda menentukan jumlah tugas maksimum yang dapat diluncurkan per layanan. Secara default, ketika kebijakan penskalaan ditetapkan, mereka tidak dapat meningkatkan jumlah tugas yang lebih tinggi dari batas maksimumnya.

Atau, Anda dapat mengizinkan jumlah tugas maksimum layanan ditingkatkan secara otomatis jika perkiraan mendekati atau melebihi jumlah tugas maksimum layanan Amazon ECS.

**Awas**  
Berhati-hatilah saat memungkinkan jumlah tugas maksimum ditingkatkan secara otomatis. Hal ini dapat menyebabkan lebih banyak tugas yang diluncurkan daripada yang dimaksudkan, jika peningkatan jumlah tugas maksimum tidak dipantau dan dikelola. Peningkatan jumlah tugas maksimum kemudian menjadi jumlah tugas maksimum normal baru untuk layanan Amazon ECS hingga Anda memperbaruinya secara manual. Jumlah tugas maksimum tidak secara otomatis berkurang kembali ke maksimum semula.

### Wilayah yang didukung
<a name="predictive-auto-scaling-supported-regions"></a>
+ Timur AS (N. Virginia)
+ AS Timur (Ohio)
+ AS Barat (California Utara)
+ AS Barat (Oregon)
+ Afrika (Cape Town)
+ Asia Pasifik (Hong Kong)
+ Asia Pasifik (Jakarta)
+ Asia Pasifik (Mumbai)
+ Asia Pasifik (Osaka)
+ Asia Pasifik (Seoul)
+ Asia Pasifik (Singapura)
+ Asia Pasifik (Sydney)
+ Asia Pasifik (Tokyo)
+ Kanada (Pusat)
+ Tiongkok (Beijing)
+ Tiongkok (Ningxia)
+ Eropa (Frankfurt)
+ Eropa (Irlandia)
+ Eropa (London)
+ Eropa (Milan)
+ Eropa (Paris)
+ Eropa (Stockholm)
+ Timur Tengah (Bahrain)
+ Amerika Selatan (Sao Paulo)
+ AWS GovCloud (AS-Timur)
+ AWS GovCloud (AS-Barat)

# Membuat kebijakan penskalaan prediktif untuk penskalaan otomatis layanan Amazon ECS
<a name="predictive-scaling-create-policy"></a>

Buat kebijakan penskalaan prediktif agar Amazon ECS menambah atau mengurangi jumlah tugas yang dijalankan layanan Anda berdasarkan data historis. 

**catatan**  
Layanan baru perlu menyediakan setidaknya 24 jam data sebelum perkiraan dapat dihasilkan.

## Konsol
<a name="predictive-scaling-policy-aws-console"></a>

1. Selain izin IAM standar untuk membuat dan memperbarui layanan, Anda memerlukan izin tambahan. Untuk informasi selengkapnya, lihat [Izin IAM diperlukan untuk penskalaan otomatis layanan Amazon ECS](auto-scaling-IAM.md).

1. Tentukan metrik yang akan digunakan untuk kebijakan. Metrik berikut tersedia:
   +  **ECSServiceRata-rata CPUUtilization** — Pemanfaatan CPU rata-rata yang harus digunakan layanan. 
   + **ECSServiceAverageMemoryUtilization**— Pemanfaatan memori rata-rata yang harus digunakan layanan. 
   + **ALBRequestCountPerTarget**— Jumlah rata-rata permintaan per menit yang idealnya diterima tugas itu.

   Anda dapat menggunakan metrik khusus. Anda perlu menentukan nilai-nilai berikut:
   + Load - metrik yang secara akurat mewakili beban penuh pada aplikasi Anda dan merupakan aspek aplikasi Anda yang paling penting untuk diskalakan.
   + Metrik penskalaan - prediktor terbaik untuk seberapa banyak pemanfaatan yang ideal untuk aplikasi Anda.

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, pilih layanan.

   Halaman detail layanan muncul.

1. Pilih **Service auto scaling** dan kemudian pilih **Atur jumlah tugas**.

1. Di bawah **jumlah tugas layanan Amazon ECS**, pilih **Gunakan penskalaan otomatis**.

   **Bagian Penghitungan tugas** muncul.

   1. Untuk **Jumlah tugas minimum**, masukkan batas bawah jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan berada di bawah hitungan ini.

   1. Untuk **Maksimum**, masukkan batas atas jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan melebihi hitungan ini.

   1. Pilih **Simpan**.

      Halaman kebijakan muncul.

1. Pilih **Buat kebijakan penskalaan**.

   Halaman **Buat kebijakan** akan muncul.

1. Untuk **jenis kebijakan Penskalaan**, pilih **Penskalaan Prediktif**.

1. Untuk **nama Kebijakan**, masukkan nama kebijakan.

1. Untuk **pasangan Metrik**, pilih metrik Anda dari daftar opsi.

   Jika Anda memilih **jumlah permintaan Application Load Balancer per target**, maka pilih grup target di grup **Target**. **Jumlah permintaan Application Load Balancer per target** hanya didukung jika Anda telah melampirkan grup target Application Load Balancer untuk layanan Anda. 

   Jika Anda memilih **Pasangan metrik kustom**, pilih metrik individual dari daftar untuk Metrik **beban dan metrik** **Penskalaan.** 

1. Untuk **pemanfaatan Target**, masukkan nilai target untuk persentase tugas yang harus dipertahankan Amazon ECS. Service auto scaling meningkatkan kapasitas Anda hingga pemanfaatan rata-rata berada pada target pemanfaatan, atau hingga mencapai jumlah maksimum tugas yang Anda tentukan.

1. Pilih **Buat kebijakan penskalaan**.

## AWS CLI
<a name="predictive-scaling-policy-aws-cli"></a>

Gunakan AWS CLI sebagai berikut untuk mengonfigurasi kebijakan penskalaan prediktif untuk layanan Amazon ECS Anda. Ganti masing-masing *user input placeholder* dengan informasi Anda sendiri.

Untuk informasi selengkapnya tentang CloudWatch metrik yang dapat Anda tentukan, lihat [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)di Referensi API *Amazon EC2 Auto* Scaling.

### Contoh 1: Kebijakan penskalaan prediktif dengan memori yang telah ditentukan sebelumnya.
<a name="predictive-scaling-cli-example-one"></a>

Berikut ini adalah contoh kebijakan dengan konfigurasi memori yang telah ditentukan.

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 40,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceMemoryUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

Contoh berikut mengilustrasikan pembuatan kebijakan dengan menjalankan [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)perintah dengan file konfigurasi yang ditentukan.

```
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

Jika berhasil, perintah ini mengembalikan ARN kebijakan.

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

### Contoh 2: Kebijakan penskalaan prediktif dengan CPU yang telah ditentukan sebelumnya.
<a name="predictive-scaling-cli-example-two"></a>

Berikut ini adalah contoh kebijakan dengan konfigurasi CPU yang telah ditentukan.

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 0.00000004,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceCPUUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

Contoh berikut mengilustrasikan pembuatan kebijakan dengan menjalankan [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)perintah dengan file konfigurasi yang ditentukan.

```
aws aas put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

Jika berhasil, perintah ini mengembalikan ARN kebijakan.

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

# Evaluasi kebijakan penskalaan prediktif Anda untuk Amazon ECS
<a name="predictive-scaling-graphs"></a>

Sebelum Anda menggunakan kebijakan penskalaan prediktif untuk menskalakan layanan Anda, tinjau rekomendasi dan data lain untuk kebijakan Anda di konsol Amazon ECS. Ini penting karena Anda tidak ingin kebijakan penskalaan prediktif untuk menskalakan kapasitas aktual Anda sampai Anda tahu bahwa prediksinya akurat.

Jika layanan ini baru, biarkan 24 jam untuk membuat perkiraan pertama.

Saat AWS membuat perkiraan, ia menggunakan data historis. Jika layanan Anda belum memiliki banyak data historis terbaru, penskalaan prediktif mungkin mengisi ulang perkiraan sementara dengan agregat yang dibuat dari agregat historis yang tersedia saat ini. Prakiraan diisi kembali hingga dua minggu sebelum tanggal pembuatan kebijakan.

## Lihat rekomendasi penskalaan prediktif Anda
<a name="view-predictive-scaling-recommendations"></a>

Untuk analisis yang efektif, penskalaan otomatis servis harus memiliki setidaknya dua kebijakan penskalaan prediktif untuk dibandingkan. (Namun, Anda masih dapat meninjau temuan untuk satu kebijakan.) Saat membuat beberapa kebijakan, Anda dapat mengevaluasi kebijakan yang menggunakan satu metrik terhadap kebijakan yang menggunakan metrik berbeda. Anda juga dapat mengevaluasi dampak dari nilai target dan kombinasi metrik yang berbeda. Setelah kebijakan penskalaan prediktif dibuat, Amazon ECS segera mulai mengevaluasi kebijakan mana yang akan melakukan pekerjaan yang lebih baik untuk menskalakan grup Anda.

**Untuk melihat rekomendasi Anda di konsol Amazon ECS**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, pilih layanan.

   Halaman detail layanan muncul.

1. Pilih **Service auto scaling.**

1. **Pilih kebijakan penskalaan prediktif, lalu pilih **Tindakan**, **Penskalaan Prediktif**, Lihat rekomendasi.**

   Anda dapat melihat detail tentang kebijakan bersama dengan rekomendasi kami. Rekomendasi memberi tahu Anda apakah kebijakan penskalaan prediktif melakukan pekerjaan yang lebih baik daripada tidak menggunakannya. 

   Jika Anda tidak yakin apakah kebijakan penskalaan prediktif sesuai untuk grup Anda, tinjau kolom **Dampak ketersediaan dan dampak** **Biaya** untuk memilih kebijakan yang tepat. Informasi untuk setiap kolom memberi tahu Anda apa dampak kebijakan tersebut. 
   + **Dampak ketersediaan**: Menjelaskan apakah kebijakan akan menghindari dampak negatif terhadap ketersediaan dengan menyediakan tugas yang cukup untuk menangani beban kerja, dibandingkan dengan tidak menggunakan kebijakan.
   + **Dampak biaya**: Menjelaskan apakah kebijakan akan menghindari dampak negatif pada biaya Anda dengan tidak menyediakan tugas yang berlebihan, dibandingkan dengan tidak menggunakan kebijakan. Dengan terlalu banyak penyediaan, layanan Anda kurang dimanfaatkan atau tidak digunakan, yang hanya menambah dampak biaya.

   Jika Anda memiliki beberapa kebijakan, maka tag **prediksi terbaik** akan ditampilkan di samping nama kebijakan yang memberikan manfaat ketersediaan terbanyak dengan biaya lebih rendah. Lebih banyak bobot diberikan untuk dampak ketersediaan. 

1. (Opsional) Untuk memilih periode waktu yang diinginkan untuk hasil rekomendasi, pilih nilai yang Anda inginkan dari dropdown **periode Evaluasi**: **2 hari**, **1 minggu**, atau **2** minggu. Secara default, periode evaluasi adalah dua minggu terakhir. Periode evaluasi yang lebih lama memberikan lebih banyak poin data ke hasil rekomendasi. Namun, menambahkan lebih banyak titik data mungkin tidak meningkatkan hasil jika pola beban Anda telah berubah, seperti setelah periode permintaan yang luar biasa. Dalam hal ini, Anda bisa mendapatkan rekomendasi yang lebih fokus dengan melihat data yang lebih baru.

**catatan**  
Rekomendasi dibuat hanya untuk kebijakan yang **hanya dalam mode Forecast**. Fitur rekomendasi bekerja lebih baik ketika kebijakan berada dalam mode **Forecast only** selama periode evaluasi. Jika Anda memulai kebijakan dalam mode **Forecast dan skala** dan beralih ke mode **Forecast only** nanti, temuan untuk kebijakan tersebut cenderung bias. Ini karena kebijakan telah berkontribusi terhadap kapasitas aktual.

## Tinjau grafik pemantauan penskalaan prediktif
<a name="review-predictive-scaling-monitoring-graphs"></a>

Di konsol, Anda dapat meninjau perkiraan hari, minggu, atau bulan sebelumnya untuk memvisualisasikan seberapa baik kinerja kebijakan dari waktu ke waktu. Anda juga dapat menggunakan informasi ini untuk mengevaluasi keakuratan prediksi saat memutuskan apakah akan membiarkan kebijakan menskalakan jumlah tugas Anda yang sebenarnya.

**Untuk meninjau grafik pemantauan penskalaan prediktif di konsol Amazon ECS**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, pilih layanan.

   Halaman detail layanan muncul.

1. Pilih **Service auto scaling.**

1. **Pilih kebijakan penskalaan prediktif, lalu pilih **Tindakan**, **Penskalaan Prediktif**, Lihat Grafik.**

1. Di bagian **Pemantauan**, Anda dapat melihat perkiraan masa lalu dan masa depan kebijakan Anda untuk beban dan kapasitas terhadap nilai aktual. Grafik **beban** menunjukkan perkiraan beban dan nilai aktual untuk metrik beban yang Anda pilih. Grafik **Kapasitas** menunjukkan jumlah tugas yang diprediksi oleh kebijakan. Ini juga mencakup jumlah tugas aktual yang diluncurkan. Garis vertikal memisahkan nilai historis dari perkiraan masa depan. Grafik ini tersedia segera setelah kebijakan dibuat. 

1. (Opsional) Untuk mengubah jumlah data historis yang ditampilkan dalam bagan, pilih nilai yang Anda inginkan dari dropdown **periode Evaluasi** di bagian atas halaman. Periode evaluasi tidak mengubah data di halaman ini dengan cara apa pun. Itu hanya mengubah jumlah data historis yang ditampilkan.

**Bandingkan data dalam grafik **Load****  
Setiap garis horizontal mewakili serangkaian titik data berbeda yang dilaporkan dalam interval satu jam:

1. **Beban yang diamati aktual** menggunakan statistik SUM untuk metrik beban yang Anda pilih untuk menunjukkan total beban per jam di masa lalu.

1. **Beban yang diprediksi oleh kebijakan** menunjukkan prediksi beban per jam. Prediksi ini didasarkan pada dua minggu sebelumnya dari pengamatan beban aktual.

**Bandingkan data dalam grafik **Kapasitas****  
Setiap garis horizontal mewakili serangkaian titik data berbeda yang dilaporkan dalam interval satu jam:

1. **Jumlah tugas yang diamati secara aktual** menunjukkan kapasitas aktual layanan Amazon ECS Anda di masa lalu, yang bergantung pada kebijakan penskalaan Anda yang lain dan ukuran grup minimum yang berlaku untuk periode waktu yang dipilih.

1. **Kapasitas yang diprediksi oleh kebijakan** menunjukkan kapasitas dasar yang dapat Anda harapkan pada awal setiap jam ketika kebijakan dalam mode **Forecast dan skala**.

1. **Jumlah tugas yang diperlukan yang disimpulkan** menunjukkan jumlah tugas ideal dalam layanan Anda untuk mempertahankan metrik penskalaan pada nilai target yang Anda pilih.

1. **Jumlah tugas minimum** menunjukkan jumlah tugas minimum dalam layanan Anda.

1. **Kapasitas maksimum** menunjukkan jumlah tugas maksimum dalam layanan Anda.

Untuk tujuan menghitung kapasitas yang diperlukan yang disimpulkan, kita mulai dengan mengasumsikan bahwa setiap tugas sama-sama digunakan pada nilai target yang ditentukan. Dalam praktiknya, jumlah tugas tidak digunakan secara merata. Dengan mengasumsikan bahwa pemanfaatan tersebar secara seragam antar tugas, bagaimanapun, kita dapat membuat perkiraan kemungkinan jumlah kapasitas yang dibutuhkan. Persyaratan untuk jumlah tugas kemudian dihitung berbanding terbalik dengan metrik penskalaan yang Anda gunakan untuk kebijakan penskalaan prediktif Anda. Dengan kata lain, ketika jumlah tugas meningkat, metrik penskalaan menurun pada tingkat yang sama. Misalnya, jika jumlah tugas berlipat ganda, metrik penskalaan harus berkurang setengahnya. 

Rumus untuk kapasitas yang dibutuhkan yang disimpulkan:

 `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)`

Sebagai contoh, kita mengambil `actualServiceUnits` (`10`) dan `scalingMetricValue` (`30`) untuk satu jam tertentu. Kami kemudian mengambil `targetUtilization` yang Anda tentukan dalam kebijakan penskalaan prediktif Anda (`60`) dan menghitung kapasitas yang diperlukan yang disimpulkan untuk jam yang sama. Ini mengembalikan nilai`5`. Ini berarti bahwa lima adalah jumlah kapasitas yang disimpulkan yang diperlukan untuk mempertahankan kapasitas dalam proporsi terbalik langsung dengan nilai target metrik penskalaan.

**catatan**  
Berbagai tuas tersedia bagi Anda untuk menyesuaikan dan meningkatkan penghematan biaya dan ketersediaan aplikasi Anda.  
Anda menggunakan penskalaan prediktif untuk kapasitas dasar dan penskalaan dinamis untuk menangani kapasitas tambahan. Penskalaan dinamis bekerja secara independen dari penskalaan prediktif, penskalaan masuk dan keluar berdasarkan pemanfaatan saat ini. Pertama, Amazon ECS menghitung jumlah tugas yang disarankan untuk setiap kebijakan penskalaan yang tidak dijadwalkan. Kemudian, skala berdasarkan kebijakan yang menyediakan jumlah tugas terbesar.
Agar penskalaan masuk terjadi saat beban berkurang, layanan Anda harus selalu memiliki setidaknya satu kebijakan penskalaan dinamis dengan bagian penskalaan diaktifkan.
Anda dapat meningkatkan kinerja penskalaan dengan memastikan bahwa kapasitas minimum dan maksimum Anda tidak terlalu membatasi. Kebijakan dengan jumlah tugas yang disarankan yang tidak termasuk dalam rentang kapasitas minimum dan maksimum akan dicegah dari penskalaan masuk dan keluar.

# Pantau metrik penskalaan prediktif untuk Amazon ECS dengan CloudWatch
<a name="predictive-scaling-monitoring"></a>

Anda dapat menggunakan Amazon CloudWatch untuk memantau data Anda untuk penskalaan prediktif. Kebijakan penskalaan prediktif mengumpulkan data yang digunakan untuk memperkirakan beban masa depan Anda. Data yang dikumpulkan secara otomatis disimpan secara CloudWatch berkala dan dapat digunakan untuk memvisualisasikan seberapa baik kinerja kebijakan dari waktu ke waktu. Anda juga dapat membuat CloudWatch alarm untuk memberi tahu Anda ketika indikator kinerja berubah melampaui batas yang Anda tetapkan.

## Visualisasikan data perkiraan historis
<a name="visualize-historical-forecast-data"></a>

Data perkiraan beban untuk kebijakan penskalaan prediktif dapat dilihat CloudWatch dan dapat berguna saat memvisualisasikan prakiraan terhadap CloudWatch metrik lain dalam satu grafik. Anda juga dapat melihat tren dari waktu ke waktu dengan melihat rentang waktu yang lebih luas. Anda dapat mengakses metrik historis hingga 15 bulan untuk mendapatkan perspektif yang lebih baik tentang kinerja kebijakan Anda.

**Untuk melihat data perkiraan historis menggunakan CloudWatch konsol**

1. Buka CloudWatch konsol di [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Di panel navigasi, pilih **Metrik**, lalu **Semua metrik**.

1. Pilih namespace metrik **Application Auto Scaling**.

1. Pilih **Prakiraan Beban Penskalaan Prediktif**.

1. Di bidang pencarian, masukkan nama kebijakan penskalaan prediktif atau nama grup layanan Amazon ECS, lalu tekan Enter untuk memfilter hasilnya. 

1. Untuk membuat grafik sebuah metrik, pilih kotak centang di sebelah metrik. Untuk mengubah nama grafik, pilih ikon pensil. Untuk mengubah rentang waktu, pilih salah satu nilai yang telah ditentukan sebelumnya atau pilih **kustom**. Untuk informasi selengkapnya, lihat [Membuat grafik metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html) di *Panduan CloudWatch Pengguna Amazon*.

1. Untuk mengubah statistik, pilih tab **Metrik bergrafik**. Pilih judul kolom atau nilai individual, lalu pilih statistik yang berbeda. Meskipun Anda dapat memilih statistik apa pun untuk setiap metrik, tidak semua statistik berguna untuk **PredictiveScalingLoadForecast**metrik. Misalnya, statistik **Rata-rata**, **Minimum**, dan **Maksimum** berguna, tetapi statistik **Jumlah** tidak.

1. Untuk menambahkan metrik lain ke grafik, di bawah **Browse**, pilih **Semua**, temukan metrik tertentu, lalu pilih kotak centang di sebelahnya. Anda dapat menambahkan hingga 10 metrik.

1. (Opsional) Untuk menambahkan grafik ke CloudWatch dasbor, pilih **Tindakan**, **Tambahkan ke dasbor**.

## Buat metrik akurasi menggunakan matematika metrik
<a name="create-accuracy-metrics"></a>

Dengan matematika metrik, Anda dapat menanyakan beberapa CloudWatch metrik dan menggunakan ekspresi matematika untuk membuat deret waktu baru berdasarkan metrik ini. Anda dapat memvisualisasikan deret waktu yang dihasilkan di CloudWatch konsol dan menambahkannya ke dasbor. Untuk informasi selengkapnya tentang matematika [metrik, lihat Menggunakan matematika metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) di *Panduan CloudWatch Pengguna Amazon*.

Dengan menggunakan matematika metrik, Anda dapat membuat grafik data yang dihasilkan oleh penskalaan otomatis servis untuk penskalaan prediktif dengan berbagai cara. Ini membantu Anda memantau kinerja kebijakan dari waktu ke waktu, dan membantu Anda memahami apakah kombinasi metrik Anda dapat ditingkatkan.

Misalnya, Anda dapat menggunakan ekspresi matematika metrik untuk memantau [kesalahan persentase absolut rata-rata](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE). Metrik MAPE membantu memantau perbedaan antara nilai yang diperkirakan dan nilai aktual yang diamati selama jendela perkiraan tertentu. Perubahan nilai MAPE dapat menunjukkan apakah kinerja kebijakan menurun seiring waktu karena sifat aplikasi Anda berubah. Peningkatan MAPE menandakan kesenjangan yang lebih luas antara nilai yang diperkirakan dan nilai aktual. 

**Contoh: Ekspresi matematika metrik**

Untuk memulai dengan jenis grafik ini, Anda dapat membuat ekspresi matematika metrik seperti yang ditunjukkan pada contoh berikut.



Alih-alih metrik tunggal, ada array struktur kueri data metrik untuk`MetricDataQueries`. Setiap item `MetricDataQueries` mendapat metrik atau melakukan ekspresi matematika. Item pertama,`e1`, adalah ekspresi matematika. Ekspresi yang ditunjuk menetapkan `ReturnData` parameter ke`true`, yang pada akhirnya menghasilkan deret waktu tunggal. Untuk semua metrik lainnya, `ReturnData` nilainya adalah`false`. 

Dalam contoh, ekspresi yang ditunjuk menggunakan nilai aktual dan yang diperkirakan sebagai input dan mengembalikan metrik baru (MAPE). `m1`adalah CloudWatch metrik yang berisi nilai beban aktual (dengan asumsi pemanfaatan CPU adalah metrik beban yang awalnya ditentukan untuk kebijakan bernama`my-predictive-scaling-policy`). `m2`adalah CloudWatch metrik yang berisi nilai beban yang diperkirakan. Sintaks matematika untuk metrik MAPE adalah sebagai berikut:

*Rata-rata (abs ((Actual - Forecast)/(Aktual)))*

### Visualisasikan metrik akurasi Anda dan atur alarm
<a name="visualize-accuracy-metrics-set-alarms"></a>

Untuk memvisualisasikan data metrik akurasi, pilih tab **Metrik** di konsol. CloudWatch Anda dapat membuat grafik data dari sana. Untuk informasi selengkapnya, lihat [Menambahkan ekspresi matematika ke CloudWatch grafik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console) di *Panduan CloudWatch Pengguna Amazon*.

Anda juga dapat mengatur alarm pada metrik yang Anda pantau dari bagian **Metrik**. Saat berada di tab **Graphed metrics**, pilih ikon **Create alarm** di bawah kolom **Actions**. Ikon **Create alarm** direpresentasikan sebagai bel kecil. Untuk informasi selengkapnya dan opsi notifikasi, lihat [Membuat CloudWatch alarm berdasarkan ekspresi matematika metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) dan [Memberi tahu pengguna tentang perubahan alarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html) di *Panduan CloudWatch Pengguna Amazon*.

Atau, Anda dapat menggunakan [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)dan [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)melakukan perhitungan menggunakan matematika metrik dan membuat alarm berdasarkan output.

# Menggunakan tindakan terjadwal untuk mengganti nilai perkiraan untuk Amazon ECS
<a name="predictive-scaling-overriding-forecast-capacity"></a>

Terkadang, Anda mungkin memiliki informasi tambahan tentang persyaratan aplikasi future Anda yang tidak dapat diperhitungkan oleh perhitungan perkiraan. Misalnya, perhitungan perkiraan mungkin meremehkan tugas yang diperlukan untuk acara pemasaran yang akan datang. Anda dapat menggunakan tindakan terjadwal untuk mengganti perkiraan sementara selama periode waktu mendatang. Tindakan terjadwal dapat berjalan secara berulang, atau pada tanggal dan waktu tertentu ketika ada fluktuasi permintaan satu kali. 

Misalnya, Anda dapat membuat tindakan terjadwal dengan jumlah tugas yang lebih tinggi daripada yang diperkirakan. Saat runtime, Amazon ECS memperbarui jumlah tugas minimum dalam layanan Anda. Karena penskalaan prediktif mengoptimalkan jumlah tugas, tindakan terjadwal dengan jumlah tugas minimum yang lebih tinggi dari nilai perkiraan akan dihormati. Ini mencegah jumlah tugas menjadi kurang dari yang diharapkan. Untuk berhenti mengesampingkan perkiraan, gunakan tindakan terjadwal kedua untuk mengembalikan jumlah tugas minimum ke pengaturan aslinya.

Prosedur berikut menguraikan langkah-langkah untuk mengesampingkan perkiraan selama periode waktu mendatang. 

**Topics**
+ [

## Langkah 1: (Opsional) Analisis data deret waktu
](#analyzing-time-series-data)
+ [

## Langkah 2: Buat dua tindakan terjadwal
](#scheduling-capacity)

**penting**  
Topik ini mengasumsikan bahwa Anda mencoba mengesampingkan perkiraan untuk skala ke kapasitas yang lebih tinggi daripada yang diperkirakan. Jika Anda perlu mengurangi jumlah tugas sementara tanpa gangguan dari kebijakan penskalaan prediktif, gunakan mode *hanya perkiraan*. Sementara dalam mode perkiraan saja, penskalaan prediktif akan terus menghasilkan perkiraan, tetapi tidak akan secara otomatis meningkatkan jumlah tugas. Anda kemudian dapat memantau pemanfaatan sumber daya dan secara manual mengurangi jumlah tugas sesuai kebutuhan. 

## Langkah 1: (Opsional) Analisis data deret waktu
<a name="analyzing-time-series-data"></a>

Mulailah dengan menganalisis data deret waktu perkiraan. Ini adalah langkah opsional, tetapi akan sangat membantu jika Anda ingin memahami detail perkiraan.

1. **Ambil ramalan**

   Setelah perkiraan dibuat, Anda dapat menanyakan periode waktu tertentu dalam perkiraan. Tujuan dari kueri ini adalah untuk mendapatkan tampilan lengkap dari data deret waktu untuk periode waktu tertentu. 

   Kueri Anda dapat mencakup hingga dua hari data perkiraan masa depan. Jika Anda telah menggunakan penskalaan prediktif untuk sementara waktu, Anda juga dapat mengakses data perkiraan sebelumnya. Namun, durasi waktu maksimum antara waktu mulai dan akhir adalah 30 hari. 

   Untuk mendapatkan perkiraan menggunakan [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI perintah, berikan parameter berikut dalam perintah: 
   + Masukkan nama nama cluster dalam `resource-id` parameter. 
   + Masukkan nama kebijakan dalam `--policy-name` parameter. 
   + Masukkan waktu mulai dalam `--start-time` parameter untuk mengembalikan hanya data perkiraan setelah atau pada waktu yang ditentukan.
   + Masukkan waktu akhir dalam `--end-time` parameter untuk mengembalikan hanya data perkiraan sebelum waktu yang ditentukan. 

   ```
   aws application-autoscaling get-predictive-scaling-forecast \
       --service-namespace ecs \
       --resource-id service/MyCluster/test \
       --policy-name cpu40-predictive-scaling-policy \
       --scalable-dimension ecs:service:DesiredCount \
       --start-time "2021-05-19T17:00:00Z" \
       --end-time "2021-05-19T23:00:00Z"
   ```

   Jika berhasil, perintah mengembalikan data yang mirip dengan contoh berikut. 

   ```
   {
       "LoadForecast": [
           {
               "Timestamps": [
                   "2021-05-19T17:00:00+00:00",
                   "2021-05-19T18:00:00+00:00",
                   "2021-05-19T19:00:00+00:00",
                   "2021-05-19T20:00:00+00:00",
                   "2021-05-19T21:00:00+00:00",
                   "2021-05-19T22:00:00+00:00",
                   "2021-05-19T23:00:00+00:00"
               ],
               "Values": [
                   153.0655799339254,
                   128.8288551285919,
                   107.1179447150675,
                   197.3601844551528,
                   626.4039934516954,
                   596.9441277518481,
                   677.9675713779869
               ],
               "MetricSpecification": {
                   "TargetValue": 40.0,
                   "PredefinedMetricPairSpecification": {
                       "PredefinedMetricType": "ASGCPUUtilization"
                   }
               }
           }
       ],
       "CapacityForecast": {
           "Timestamps": [
               "2021-05-19T17:00:00+00:00",
               "2021-05-19T18:00:00+00:00",
               "2021-05-19T19:00:00+00:00",
               "2021-05-19T20:00:00+00:00",
               "2021-05-19T21:00:00+00:00",
               "2021-05-19T22:00:00+00:00",
               "2021-05-19T23:00:00+00:00"
           ],
           "Values": [
               2.0,
               2.0,
               2.0,
               2.0,
               4.0,
               4.0,
               4.0
           ]
       },
       "UpdateTime": "2021-05-19T01:52:50.118000+00:00"
   }
   ```

   Tanggapan tersebut mencakup dua prakiraan: `LoadForecast` dan`CapacityForecast`. `LoadForecast`menunjukkan perkiraan beban per jam. `CapacityForecast`menunjukkan nilai perkiraan untuk kapasitas yang dibutuhkan setiap jam untuk menangani beban yang diperkirakan sambil mempertahankan 40,0 (`TargetValue`pemanfaatan CPU rata-rata 40%).

1. **Identifikasi periode waktu target**

   Identifikasi jam atau jam ketika fluktuasi permintaan satu kali harus terjadi. Ingat bahwa tanggal dan waktu yang ditunjukkan dalam perkiraan ada di UTC.

## Langkah 2: Buat dua tindakan terjadwal
<a name="scheduling-capacity"></a>

Selanjutnya, buat dua tindakan terjadwal untuk periode waktu tertentu ketika aplikasi Anda akan memiliki beban yang lebih tinggi dari perkiraan. Misalnya, jika Anda memiliki acara pemasaran yang akan mengarahkan lalu lintas ke situs Anda untuk jangka waktu terbatas, Anda dapat menjadwalkan tindakan satu kali untuk memperbarui kapasitas minimum saat dimulai. Kemudian, jadwalkan tindakan lain untuk mengembalikan kapasitas minimum ke pengaturan asli saat acara berakhir. 

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail cluster, di bagian **Layanan**, dan kemudian pilih layanan.

   Halaman detail layanan muncul.

1. Pilih **Service Auto Scaling**.

   Halaman kebijakan muncul.

1. Pilih **Tindakan terjadwal**, lalu pilih **Buat**.

   Halaman **tindakan Create Schedule** muncul.

1. Untuk **nama Action**, masukkan nama unik.

1. Untuk **zona waktu**, pilih zona waktu.

   Semua zona waktu yang tercantum berasal dari database Zona Waktu IANA. Untuk informasi selengkapnya, lihat [Daftar zona waktu database tz](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

1. Untuk **Waktu mulai**, masukkan **Tanggal** dan **Waktu** tindakan dimulai.

1. Untuk **Perulangan**, pilih **Sekali**.

1. Di bawah **Penyesuaian tugas**, Untuk Minimum, masukkan nilai kurang dari atau sama dengan jumlah tugas maksimum..

1. Pilih **Buat tindakan terjadwal**.

   Halaman kebijakan muncul.

1. Konfigurasikan tindakan terjadwal kedua untuk mengembalikan jumlah tugas minimum ke pengaturan asli di akhir acara. Penskalaan prediktif dapat menskalakan jumlah tugas hanya jika nilai yang Anda tetapkan untuk **Minimum** lebih rendah dari nilai perkiraan.

**Untuk membuat dua tindakan terjadwal untuk acara satu kali ()AWS CLI**  
Untuk menggunakan AWS CLI untuk membuat tindakan terjadwal, gunakan perintah [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html). 

Sebagai contoh, mari kita tentukan jadwal yang mempertahankan kapasitas minimum tiga instance pada 19 Mei pukul 17:00 selama delapan jam. Perintah berikut menunjukkan bagaimana menerapkan skenario ini.

Perintah [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) pertama menginstruksikan Amazon EC2 Auto Scaling untuk memperbarui kapasitas minimum grup Auto Scaling yang ditentukan pada pukul 17:00 UTC pada 19 Mei 2021. 

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
  --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```

Perintah kedua menginstruksikan Amazon EC2 Auto Scaling untuk mengatur kapasitas minimum grup menjadi satu pada 1:00 UTC pada 20 Mei 2021. 

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
  --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```

Setelah Anda menambahkan tindakan terjadwal ini ke grup Auto Scaling, Amazon EC2 Auto Scaling melakukan hal berikut: 
+ Pada pukul 17:00 UTC pada 19 Mei 2021, aksi terjadwal pertama berjalan. Jika grup saat ini memiliki kurang dari tiga instance, grup tersebut menskalakan menjadi tiga instance. Selama waktu ini dan selama delapan jam ke depan, Amazon EC2 Auto Scaling dapat terus ditingkatkan jika kapasitas yang diprediksi lebih tinggi dari kapasitas aktual atau jika ada kebijakan penskalaan dinamis yang berlaku. 
+ Pukul 1:00 UTC pada 20 Mei 2021, aksi terjadwal kedua berjalan. Ini mengembalikan kapasitas minimum ke pengaturan aslinya di akhir acara.

### Penskalaan berdasarkan jadwal berulang
<a name="scheduling-recurring-actions"></a>

Untuk mengganti perkiraan untuk periode waktu yang sama setiap minggu, buat dua tindakan terjadwal dan berikan logika waktu dan tanggal menggunakan ekspresi cron. 

Format ekspresi cron terdiri dari lima bidang yang dipisahkan oleh spasi: [Minute] [Hour] [Day\$1of\$1month] [Month\$1of\$1year] [day\$1of\$1week]. Bidang dapat berisi nilai apa pun yang diizinkan, termasuk karakter khusus. 

Misalnya, ekspresi cron berikut menjalankan aksi setiap hari Selasa pukul 6:30 pagi. Tanda bintang digunakan sebagai wildcard untuk mencocokkan semua nilai untuk bidang.

```
30 6 * * 2
```

### Lihat juga
<a name="scheduling-scaling-see-also"></a>

Untuk informasi selengkapnya tentang cara mengelola tindakan terjadwal, lihat[Gunakan tindakan terjadwal untuk menskalakan layanan Amazon ECS](service-autoscaling-schedulescaling.md).

# Kebijakan penskalaan prediktif lanjutan menggunakan metrik khusus untuk Amazon ECS
<a name="predictive-scaling-custom-metrics"></a>

Anda dapat menggunakan metrik yang telah ditentukan atau kustom dalam kebijakan penskalaan prediktif. Metrik kustom berguna ketika metrik yang telah ditentukan sebelumnya, seperti CPU, memori, dll) tidak cukup untuk menggambarkan beban aplikasi Anda secara memadai.

Saat membuat kebijakan penskalaan prediktif dengan metrik khusus, Anda dapat menentukan metrik lain CloudWatch yang disediakan oleh. AWS Atau, Anda dapat menentukan metrik yang Anda tentukan dan publikasikan sendiri. Anda juga dapat menggunakan matematika metrik untuk menggabungkan dan mengubah metrik yang ada menjadi deret waktu baru yang AWS tidak dilacak secara otomatis. *Contohnya adalah menggabungkan nilai dalam data Anda dengan menghitung jumlah atau rata-rata baru yang disebut agregasi.* Data yang dihasilkan disebut *agregat*.

Bagian berikut berisi praktik terbaik dan contoh bagaimana membangun struktur JSON untuk kebijakan tersebut.

## Prasyarat
<a name="predictive-scaling-custom-metrics-prerequisites"></a>

Untuk menambahkan metrik kustom ke kebijakan penskalaan prediktif, Anda harus memiliki izin. `cloudwatch:GetMetricData`

Untuk menentukan metrik Anda sendiri, bukan metrik yang AWS disediakan, Anda harus terlebih dahulu mempublikasikan metrik Anda. CloudWatch Untuk informasi selengkapnya, lihat [Menerbitkan metrik kustom](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) di *Panduan CloudWatch Pengguna Amazon*. 

Jika Anda mempublikasikan metrik Anda sendiri, pastikan untuk mempublikasikan titik data pada frekuensi minimum lima menit. Titik data diambil dari CloudWatch berdasarkan lamanya periode yang dibutuhkannya. Misalnya, spesifikasi metrik beban menggunakan metrik per jam untuk mengukur beban pada aplikasi Anda. CloudWatch menggunakan data metrik yang Anda publikasikan untuk memberikan nilai data tunggal untuk periode satu jam dengan menggabungkan semua titik data dengan stempel waktu yang termasuk dalam setiap periode satu jam.

## Praktik terbaik
<a name="predictive-scaling-custom-metrics-best-practices"></a>

Praktik terbaik berikut dapat membantu Anda menggunakan metrik kustom secara lebih efektif:
+ Metrik yang paling berguna untuk spesifikasi metrik beban adalah metrik yang mewakili beban pada grup Auto Scaling secara keseluruhan.
+ Metrik yang paling berguna untuk spesifikasi metrik penskalaan untuk diskalakan adalah throughput rata-rata atau pemanfaatan per metrik tugas.
+ Pemanfaatan target harus sesuai dengan jenis metrik penskalaan. Untuk konfigurasi kebijakan yang menggunakan pemanfaatan CPU, ini adalah persentase target, misalnya.
+ Jika rekomendasi ini tidak diikuti, nilai future yang diperkirakan dari deret waktu mungkin akan salah. Untuk memvalidasi bahwa data sudah benar, Anda dapat melihat nilai yang diperkirakan di konsol. Atau, setelah Anda membuat kebijakan penskalaan prediktif, periksa `LoadForecast` objek yang ditampilkan oleh panggilan ke API. [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html)
+ Kami sangat menyarankan Anda mengonfigurasi penskalaan prediktif dalam mode hanya perkiraan sehingga Anda dapat mengevaluasi perkiraan sebelum penskalaan prediktif mulai aktif penskalaan.

## Batasan
<a name="predicitve-scaling-custom-metrics-limitations"></a>
+ Anda dapat menanyakan titik data hingga 10 metrik dalam satu spesifikasi metrik.
+ Untuk tujuan batas ini, satu ekspresi dihitung sebagai satu metrik.

## Memecahkan masalah kebijakan penskalaan prediktif dengan metrik khusus
<a name="predictive-scaling-custom-metrics-troubleshooting"></a>

Jika terjadi masalah saat menggunakan metrik kustom, kami sarankan Anda melakukan hal berikut:
+ Jika Anda mengalami masalah dalam blue/green penerapan saat menggunakan ekspresi penelusuran, pastikan Anda membuat ekspresi penelusuran yang mencari kecocokan sebagian dan bukan kecocokan persis. Anda juga harus memeriksa apakah kueri hanya menemukan grup Auto Scaling yang berjalan di aplikasi tertentu. Untuk informasi selengkapnya tentang sintaks ekspresi penelusuran, lihat [sintaks ekspresi CloudWatch penelusuran](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html) di * CloudWatch Panduan Pengguna Amazon*.
+ [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)Perintah memvalidasi ekspresi saat Anda membuat kebijakan penskalaan. Namun, ada kemungkinan bahwa perintah ini mungkin gagal mengidentifikasi penyebab pasti dari kesalahan yang terdeteksi. Untuk memperbaiki masalah, pecahkan masalah kesalahan yang Anda terima dalam respons dari permintaan ke perintah. [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) Anda juga dapat memecahkan masalah ekspresi dari konsol. CloudWatch
+ Anda harus menentukan `false` `ReturnData` jika `MetricDataQueries` menentukan fungsi SEARCH () sendiri tanpa fungsi matematika seperti SUM (). Ini karena ekspresi pencarian mungkin mengembalikan beberapa deret waktu, dan spesifikasi metrik berdasarkan ekspresi hanya dapat mengembalikan satu deret waktu.
+ Semua metrik yang terlibat dalam ekspresi pencarian harus memiliki resolusi yang sama.

# Membangun JSON untuk metrik kustom penskalaan prediktif dengan Amazon ECS
<a name="predictive-scaling-custom-metrics-example"></a>

Bagian berikut berisi contoh cara mengonfigurasi penskalaan prediktif ke data kueri dari. CloudWatch Ada dua metode berbeda untuk mengonfigurasi opsi ini, dan metode yang Anda pilih memengaruhi format mana yang Anda gunakan untuk membuat JSON untuk kebijakan penskalaan prediktif Anda. Saat Anda menggunakan matematika metrik, format JSON bervariasi lebih lanjut berdasarkan matematika metrik yang dilakukan.

1. Untuk membuat kebijakan yang mendapatkan data langsung dari CloudWatch metrik lain yang disediakan oleh AWS atau metrik yang Anda publikasikan CloudWatch, lihat. [Contoh kebijakan penskalaan prediktif dengan metrik pemuatan dan penskalaan khusus menggunakan AWS CLI](#predictive-scaling-custom-metrics-example1)

## Contoh kebijakan penskalaan prediktif dengan metrik pemuatan dan penskalaan khusus menggunakan AWS CLI
<a name="predictive-scaling-custom-metrics-example1"></a>

Untuk membuat kebijakan penskalaan prediktif dengan metrik pemuatan dan penskalaan kustom dengan AWS CLI, simpan argumen `--predictive-scaling-configuration` dalam file JSON bernama. `config.json`

Anda mulai menambahkan metrik khusus dengan mengganti nilai yang dapat diganti dalam contoh berikut dengan metrik dan pemanfaatan target Anda.

```
{
  "MetricSpecifications": [
    {
      "TargetValue": 50,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "scaling_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyUtilizationMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Average"
            }
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyLoadMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Sum"
            }
          }
        ]
      }
    }
  ]
}
```

Untuk informasi lebih lanjut, lihat [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html) dalam *Referensi API Amazon EC2 Auto Scaling*.

**catatan**  
Berikut adalah beberapa sumber daya tambahan yang dapat membantu Anda menemukan nama metrik, ruang nama, dimensi, dan statistik untuk CloudWatch metrik:   
Untuk informasi tentang metrik yang tersedia untuk AWS layanan, lihat [AWS layanan yang memublikasikan CloudWatch metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html) di * CloudWatch Panduan Pengguna Amazon*.
[Untuk mendapatkan nama metrik, namespace, dan dimensi yang tepat (jika ada) untuk CloudWatch metrik dengan metrik AWS CLI, lihat daftar-metrik.](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) 

Untuk membuat kebijakan ini, jalankan [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)perintah menggunakan file JSON sebagai input, seperti yang ditunjukkan dalam contoh berikut.

```
aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \
  --auto-scaling-group-name my-asg --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
```

Jika berhasil, perintah ini mengembalikan Amazon Resource Name (ARN) kebijakan.

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
  "Alarms": []
}
```

# Gunakan ekspresi matematika metrik
<a name="predictive-scaling-math-expression"></a>

Bagian berikut memberikan informasi tentang penggunaan matematika metrik dengan kebijakan penskalaan prediktif dalam kebijakan Anda. 

## Memahami matematika metrik
<a name="predictive-scaling-custom-metrics-math"></a>

Jika yang ingin Anda lakukan hanyalah mengumpulkan data metrik yang ada, matematika CloudWatch metrik menghemat upaya dan biaya penerbitan metrik lain. CloudWatch Anda dapat menggunakan metrik apa pun yang AWS menyediakan, dan Anda juga dapat menggunakan metrik yang Anda tetapkan sebagai bagian dari aplikasi Anda.

Untuk informasi selengkapnya, lihat [Menggunakan matematika metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) di *Panduan CloudWatch Pengguna Amazon*. 

Jika Anda memilih untuk menggunakan ekspresi matematika metrik dalam kebijakan penskalaan prediktif Anda, pertimbangkan poin-poin berikut:
+ Operasi matematika metrik menggunakan titik data dari kombinasi unik nama metrik, namespace, dan keys/value pasangan dimensi metrik. 
+ Anda dapat menggunakan operator aritmatika (\$1 - \$1/^), fungsi statistik (seperti AVG atau SUM), atau fungsi lain yang mendukung. CloudWatch 
+ Anda dapat menggunakan metrik dan hasil ekspresi matematika lainnya dalam rumus ekspresi matematika. 
+ Ekspresi matematika metrik Anda dapat terdiri dari agregasi yang berbeda. Namun, ini adalah praktik terbaik untuk hasil agregasi akhir yang digunakan `Average` untuk metrik penskalaan dan `Sum` untuk metrik beban.
+ Setiap ekspresi yang digunakan dalam spesifikasi metrik pada akhirnya harus mengembalikan satu deret waktu.

Untuk menggunakan matematika metrik, lakukan hal berikut:
+ Pilih satu atau beberapa CloudWatch metrik. Kemudian, buat ekspresi. Untuk informasi selengkapnya, lihat [Menggunakan matematika metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) di *Panduan CloudWatch Pengguna Amazon*. 
+ Verifikasi bahwa ekspresi matematika metrik valid dengan menggunakan CloudWatch konsol atau CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API.

## Contoh kebijakan penskalaan prediktif yang menggabungkan metrik menggunakan metrik matematika ()AWS CLI
<a name="custom-metrics-ex2"></a>

Terkadang, alih-alih menentukan metrik secara langsung, Anda mungkin perlu terlebih dahulu memproses datanya dengan cara tertentu. Misalnya, Anda mungkin memiliki aplikasi yang menarik pekerjaan dari antrean Amazon SQS, dan Anda mungkin ingin menggunakan jumlah item dalam antrian sebagai kriteria untuk penskalaan prediktif. Jumlah pesan dalam antrian tidak hanya menentukan jumlah instance yang Anda butuhkan. Oleh karena itu, lebih banyak pekerjaan diperlukan untuk membuat metrik yang dapat digunakan untuk menghitung backlog per instance.

Berikut ini adalah contoh kebijakan penskalaan prediktif untuk skenario ini. Ini menentukan metrik penskalaan dan pemuatan yang didasarkan pada metrik Amazon SQS`ApproximateNumberOfMessagesVisible`, yang merupakan jumlah pesan yang tersedia untuk diambil dari antrian. Ini juga menggunakan metrik Amazon EC2 `GroupInServiceInstances` Auto Scaling dan ekspresi matematika untuk menghitung backlog per instance untuk metrik penskalaan.

```
aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
  --service-namespace ecs \
  --resource-id service/MyCluster/test \
  "MetricSpecifications": [
    {
      "TargetValue": 100,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Label": "Get the queue size (the number of messages waiting to be processed)",
            "Id": "queue_size",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Get the group size (the number of running instances)",
            "Id": "running_capacity",
            "MetricStat": {
              "Metric": {
                "MetricName": "GroupInServiceInstances",
                "Namespace": "AWS/AutoScaling",
                "Dimensions": [
                  {
                    "Name": "AutoScalingGroupName",
                    "Value": "my-asg"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Calculate the backlog per instance",
            "Id": "scaling_metric",
            "Expression": "queue_size / running_capacity",
            "ReturnData": true
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ],
              },
              "Stat": "Sum"
            },
            "ReturnData": true
          }
        ]
      }
    }
  ]
}
```

Contoh mengembalikan ARN kebijakan.

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
  "Alarms": []
}
```

# Interkoneksi layanan Amazon ECS
<a name="interconnecting-services"></a>

Aplikasi yang berjalan dalam tugas Amazon ECS seringkali perlu menerima koneksi dari internet atau untuk terhubung ke aplikasi lain yang berjalan di layanan Amazon ECS. Jika Anda membutuhkan koneksi eksternal dari internet, sebaiknya gunakan Elastic Load Balancing. Untuk informasi selengkapnya tentang penyeimbangan beban terintegrasi, lihat[Menggunakan penyeimbangan beban untuk mendistribusikan lalu lintas layanan Amazon ECS](service-load-balancing.md).

Jika Anda memerlukan aplikasi untuk terhubung ke aplikasi lain yang berjalan di layanan Amazon ECS, Amazon ECS menyediakan cara-cara berikut untuk melakukan ini tanpa penyeimbang beban:
+ *Amazon ECS Service Connect*

  Kami merekomendasikan Service Connect, yang menyediakan konfigurasi Amazon ECS untuk penemuan layanan, konektivitas, dan pemantauan lalu lintas. Dengan Service Connect, aplikasi Anda dapat menggunakan nama pendek dan port standar untuk terhubung ke layanan Amazon ECS di cluster yang sama, klaster lain, termasuk di VPCs dalam yang sama. Wilayah AWS

  Saat Anda menggunakan Service Connect, Amazon ECS mengelola semua bagian penemuan layanan: membuat nama yang dapat ditemukan, mengelola entri secara dinamis untuk setiap tugas saat tugas dimulai dan dihentikan, menjalankan agen di setiap tugas yang dikonfigurasi untuk menemukan nama. Aplikasi Anda dapat mencari nama dengan menggunakan fungsionalitas standar untuk nama DNS dan membuat koneksi. Jika aplikasi Anda sudah melakukan ini, Anda tidak perlu memodifikasi aplikasi Anda untuk menggunakan Service Connect.

  Anda menyediakan konfigurasi lengkap di dalam setiap layanan dan definisi tugas. Amazon ECS mengelola perubahan pada konfigurasi ini di setiap penyebaran layanan, untuk memastikan bahwa semua tugas dalam penerapan berperilaku dengan cara yang sama. Misalnya, masalah umum dengan DNS sebagai penemuan layanan adalah mengendalikan migrasi. Jika Anda mengubah nama DNS untuk menunjuk ke alamat IP pengganti baru, mungkin diperlukan waktu TTL maksimum sebelum semua klien mulai menggunakan layanan baru. Dengan Service Connect, penyebaran klien memperbarui konfigurasi dengan mengganti tugas klien. Anda dapat mengonfigurasi pemutus sirkuit penyebaran dan konfigurasi penerapan lainnya untuk memengaruhi perubahan Service Connect dengan cara yang sama seperti penerapan lainnya.

  Untuk informasi selengkapnya, lihat [Menggunakan Service Connect untuk menghubungkan layanan Amazon ECS dengan nama pendek](service-connect.md).
+ *Penemuan layanan Amazon ECS*

  Pendekatan lain untuk service-to-service komunikasi adalah komunikasi langsung menggunakan penemuan layanan. Dalam pendekatan ini, Anda dapat menggunakan integrasi penemuan AWS Cloud Map layanan dengan Amazon ECS. Menggunakan penemuan layanan, Amazon ECS menyinkronkan daftar tugas yang diluncurkan ke AWS Cloud Map, yang mempertahankan nama host DNS yang menyelesaikan ke alamat IP internal dari satu atau lebih tugas dari layanan tertentu. Layanan lain di Amazon VPC dapat menggunakan nama host DNS ini untuk mengirim lalu lintas langsung ke wadah lain menggunakan alamat IP internalnya. 

  Pendekatan service-to-service komunikasi ini memberikan latensi rendah. Tidak ada komponen tambahan di antara wadah. Lalu lintas bergerak langsung dari satu kontainer ke kontainer lainnya.

  Pendekatan ini cocok saat menggunakan mode `awsvpc` jaringan, di mana setiap tugas memiliki alamat IP uniknya sendiri. Sebagian besar perangkat lunak hanya mendukung penggunaan `A` catatan DNS, yang menyelesaikan langsung ke alamat IP. Saat menggunakan mode `awsvpc` jaringan, alamat IP untuk setiap tugas adalah `A` catatan. Namun, jika Anda menggunakan mode `bridge` jaringan, beberapa kontainer dapat berbagi alamat IP yang sama. Selain itu, pemetaan port dinamis menyebabkan kontainer diberi nomor port secara acak pada alamat IP tunggal itu. Pada titik ini, `A` catatan tidak lagi cukup untuk penemuan layanan. Anda juga harus menggunakan `SRV` catatan. Jenis catatan ini dapat melacak alamat IP dan nomor port tetapi mengharuskan Anda mengonfigurasi aplikasi dengan tepat. Beberapa aplikasi bawaan yang Anda gunakan mungkin tidak mendukung `SRV` catatan.

  Keuntungan lain dari mode `awsvpc` jaringan adalah Anda memiliki grup keamanan unik untuk setiap layanan. Anda dapat mengonfigurasi grup keamanan ini untuk mengizinkan koneksi masuk hanya dari layanan hulu tertentu yang perlu berbicara dengan layanan tersebut.

  Kerugian utama dari service-to-service komunikasi langsung menggunakan penemuan layanan adalah Anda harus menerapkan logika tambahan untuk mencoba ulang dan menangani kegagalan koneksi. Catatan DNS memiliki periode time-to-live (TTL) yang mengontrol berapa lama mereka di-cache. Dibutuhkan beberapa waktu agar catatan DNS diperbarui dan cache kedaluwarsa sehingga aplikasi Anda dapat mengambil versi terbaru dari catatan DNS. Jadi, aplikasi Anda mungkin akan menyelesaikan catatan DNS untuk menunjuk ke wadah lain yang sudah tidak ada lagi. Aplikasi Anda perlu menangani percobaan ulang dan memiliki logika untuk mengabaikan backend yang buruk.

  Untuk informasi selengkapnya, lihat [Gunakan penemuan layanan untuk menghubungkan layanan Amazon ECS dengan nama DNS](service-discovery.md)
+ *Kisi VPC Amazon*

  Amazon VPC Lattice adalah layanan jaringan aplikasi terkelola yang digunakan pelanggan Amazon ECS untuk mengamati, mengamankan, dan memantau aplikasi yang dibangun di seluruh layanan AWS komputasi VPCs, dan akun tanpa harus mengubah kode mereka.

  VPC Lattice menggunakan kelompok target, yang merupakan kumpulan sumber daya komputasi. Target ini menjalankan aplikasi atau layanan Anda dan dapat berupa instans Amazon EC2, alamat IP, fungsi Lambda, dan Application Load Balancer. Dengan mengaitkan layanan Amazon ECS mereka dengan grup target VPC Lattice, pelanggan sekarang dapat mengaktifkan tugas Amazon ECS sebagai target IP di VPC Lattice. Amazon ECS secara otomatis mendaftarkan tugas ke grup target VPC Lattice saat tugas untuk layanan terdaftar diluncurkan.

  Untuk informasi selengkapnya, lihat [Gunakan Amazon VPC Lattice untuk menghubungkan, mengamati, dan mengamankan layanan Amazon ECS Anda](ecs-vpc-lattice.md).

## Tabel kompatibilitas mode jaringan
<a name="interconnect-network-mode-compatibility-table"></a>

Tabel berikut mencakup kompatibilitas antara opsi ini dan mode jaringan tugas. Dalam tabel, “klien” mengacu pada aplikasi yang membuat koneksi dari dalam tugas Amazon ECS.


****  

| Opsi Interkoneksi | Dijembatani | `awsvpc` | Host | 
| --- | --- | --- | --- | 
| Penemuan layanan | ya, tetapi mengharuskan klien mengetahui catatan SRV di DNS tanpa. hostPort | Ya | ya, tetapi mengharuskan klien mengetahui catatan SRV di DNS tanpa. hostPort | 
| Layanan Connect | Ya | ya | tidak | 
| Kisi VPC | Ya | Ya | Ya | 

# Menggunakan Service Connect untuk menghubungkan layanan Amazon ECS dengan nama pendek
<a name="service-connect"></a>

Amazon ECS Service Connect menyediakan manajemen service-to-service komunikasi sebagai konfigurasi Amazon ECS. Hal ini membangun penemuan layanan dan jala layanan di Amazon ECS. Ini menyediakan konfigurasi lengkap di dalam setiap layanan yang Anda kelola dengan deployment layanan, cara terpadu untuk merujuk ke layanan Anda dalam namespace yang tidak bergantung pada konfigurasi DNS VPC, dan metrik serta log standar untuk memantau semua aplikasi Anda. Service Connect hanya menghubungkan layanan satu sama lain.

Diagram berikut menunjukkan contoh jaringan Service Connect dengan 2 subnet di VPC dan 2 layanan. Layanan klien yang berjalan WordPress dengan 1 tugas di setiap subnet. Layanan server yang menjalankan MySQL dengan 1 tugas di setiap subnet. Kedua layanan sangat tersedia dan tahan terhadap masalah tugas dan Availability Zone karena setiap layanan menjalankan beberapa tugas yang tersebar di 2 subnet. Panah padat menunjukkan koneksi dari WordPress ke MySQL. Misalnya, perintah `mysql --host=mysql` CLI yang dijalankan dari dalam WordPress wadah dalam tugas dengan alamat IP. `172.31.16.1` Perintah menggunakan nama pendek `mysql` pada port default untuk MySQL. Nama dan port ini terhubung ke proxy Service Connect dalam tugas yang sama. Proxy dalam WordPress tugas menggunakan penyeimbangan beban round-robin dan informasi kegagalan sebelumnya dalam deteksi outlier untuk memilih tugas MySQL mana yang akan dihubungkan. Seperti yang ditunjukkan oleh panah padat dalam diagram, proxy terhubung ke proxy kedua dalam tugas MySQL dengan Alamat IP. `172.31.16.2` Proxy kedua terhubung ke server MySQL lokal dalam tugas yang sama. Kedua proxy melaporkan kinerja koneksi yang terlihat dalam grafik di Amazon ECS dan konsol CloudWatch Amazon sehingga Anda bisa mendapatkan metrik kinerja dari semua jenis aplikasi dengan cara yang sama.

![\[Contoh jaringan Service Connect yang menampilkan layanan HA minimal\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/images/serviceconnect.png)


Istilah berikut digunakan dengan Service Connect.

**nama port**  
Konfigurasi definisi tugas Amazon ECS yang memberikan nama ke pemetaan port tertentu. Konfigurasi ini hanya digunakan oleh Amazon ECS Service Connect.

**alias klien**  
Konfigurasi layanan Amazon ECS yang menetapkan nomor port yang digunakan di titik akhir. Selain itu, alias klien dapat menetapkan nama DNS dari titik akhir, mengesampingkan nama penemuan. Jika nama penemuan tidak disediakan di layanan Amazon ECS, nama alias klien akan mengganti nama port sebagai nama titik akhir. Untuk contoh endpoint, lihat definisi *endpoint*. Beberapa alias klien dapat ditetapkan ke layanan Amazon ECS. Konfigurasi ini hanya digunakan oleh Amazon ECS Service Connect.

**nama penemuan**  
Nama perantara opsional yang dapat Anda buat untuk port tertentu dari definisi tugas. Nama ini digunakan untuk membuat AWS Cloud Map layanan. Jika nama ini tidak disediakan, nama port dari definisi tugas akan digunakan. Beberapa nama penemuan dapat ditetapkan ke port tertentu layanan Amazon ECS. Konfigurasi ini hanya digunakan oleh Amazon ECS Service Connect.  
AWS Cloud Map nama layanan harus unik dalam namespace. Karena batasan ini, Anda hanya dapat memiliki satu konfigurasi Service Connect tanpa nama penemuan untuk definisi tugas tertentu di setiap namespace.

**titik akhir**  
URL untuk terhubung ke API atau situs web. URL berisi protokol, nama DNS, dan port. Untuk informasi lebih lanjut tentang titik akhir secara umum, lihat [titik akhir](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint) dalam *AWS glosarium* di. Referensi Umum Amazon Web  
Service Connect membuat titik akhir yang terhubung ke layanan Amazon ECS dan mengonfigurasi tugas di layanan Amazon ECS untuk terhubung ke titik akhir. URL berisi protokol, nama DNS, dan port. Anda memilih protokol dan nama port dalam definisi tugas, karena port harus cocok dengan aplikasi yang ada di dalam gambar kontainer. Dalam layanan, Anda memilih setiap port dengan nama dan dapat menetapkan nama DNS. Jika Anda tidak menentukan nama DNS dalam konfigurasi layanan Amazon ECS, nama port dari definisi tugas akan digunakan secara default. Misalnya, titik akhir Service Connect dapat berupa`http://blog:80`,`grpc://checkout:8080`, atau`http://_db.production.internal:99`.

**Layanan Connect Service**  
Konfigurasi titik akhir tunggal dalam layanan Amazon ECS. Ini adalah bagian dari konfigurasi Service Connect, yang terdiri dari satu baris dalam **konfigurasi Service Connect dan discovery name** di konsol, atau satu objek dalam `services` daftar dalam konfigurasi JSON dari layanan Amazon ECS. Konfigurasi ini hanya digunakan oleh Amazon ECS Service Connect.  
Untuk informasi selengkapnya, lihat [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)di Referensi API Amazon Elastic Container Service.

**namespace**  
Nama pendek atau nama sumber daya Amazon lengkap (ARN) dari AWS Cloud Map namespace untuk digunakan dengan Service Connect. Namespace harus Wilayah AWS sama dengan layanan Amazon ECS dan cluster. Jenis namespace di AWS Cloud Map tidak memengaruhi Service Connect. Namespace dapat berupa salah satu yang dibagikan dengan Akun AWS using AWS Resource Access Manager (AWS RAM) Anda Wilayah AWS yang AWS RAM tersedia di. *Untuk informasi selengkapnya tentang ruang nama bersama, lihat [Berbagi AWS Cloud Map namespace lintas akun](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) di Panduan Pengembang.AWS Cloud Map *  
Service Connect menggunakan AWS Cloud Map namespace sebagai pengelompokan logis tugas Amazon ECS yang berbicara satu sama lain. Setiap layanan Amazon ECS hanya dapat dimiliki oleh satu namespace. Layanan dalam namespace dapat tersebar di berbagai kluster Amazon ECS dalam hal yang sama. Wilayah AWS Jika namespace adalah namespace bersama, layanan dapat tersebar di seluruh pemilik namespace dan konsumen namespace. Akun AWS Anda dapat dengan bebas mengatur layanan berdasarkan kriteria apa pun.

**layanan klien**  
Layanan yang menjalankan aplikasi klien jaringan. Layanan ini harus memiliki namespace yang dikonfigurasi. Setiap tugas dalam layanan dapat menemukan dan terhubung ke semua titik akhir di namespace melalui container proxy Service Connect.  
Jika salah satu kontainer Anda dalam tugas perlu terhubung ke titik akhir dari layanan di namespace, pilih layanan klien. Jika aplikasi frontend, reverse proxy, atau load balancer menerima lalu lintas eksternal melalui metode lain seperti dari Elastic Load Balancing, itu bisa menggunakan konfigurasi Service Connect jenis ini.

**layanan client-server**  
Layanan Amazon ECS yang menjalankan aplikasi jaringan atau layanan web. Layanan ini harus memiliki namespace dan setidaknya satu titik akhir yang dikonfigurasi. Setiap tugas dalam layanan dapat dijangkau dengan menggunakan titik akhir. Container proxy Service Connect mendengarkan nama endpoint dan port untuk mengarahkan lalu lintas ke container aplikasi dalam tugas.  
Jika salah satu kontainer mengekspos dan mendengarkan pada port untuk lalu lintas jaringan, pilih layanan client-server. Aplikasi ini tidak perlu terhubung ke layanan client-server lain di namespace yang sama, tetapi konfigurasi klien diperlukan. Backend, middleware, tingkat bisnis, atau sebagian besar layanan mikro dapat menggunakan konfigurasi Service Connect jenis ini. Jika Anda ingin aplikasi frontend, reverse proxy, atau load balancer menerima lalu lintas dari layanan lain yang dikonfigurasi dengan Service Connect di namespace yang sama, layanan ini harus menggunakan jenis konfigurasi Service Connect ini.

Fitur Service Connect menciptakan jaringan virtual layanan terkait. Konfigurasi layanan yang sama dapat digunakan di beberapa ruang nama yang berbeda untuk menjalankan set aplikasi yang independen namun identik. Service Connect mendefinisikan wadah proxy di layanan Amazon ECS. Dengan cara ini, definisi tugas yang sama dapat digunakan untuk menjalankan aplikasi identik di ruang nama yang berbeda dengan konfigurasi Service Connect yang berbeda. Setiap tugas yang dibuat oleh layanan menjalankan wadah proxy dalam tugas.

Service Connect cocok untuk koneksi antara layanan Amazon ECS dalam namespace yang sama. Untuk aplikasi berikut, Anda perlu menggunakan metode interkoneksi tambahan untuk menyambung ke layanan Amazon ECS yang dikonfigurasi dengan Service Connect:
+ Tugas yang dikonfigurasi di ruang nama lain
+ Tugas yang tidak dikonfigurasi untuk Service Connect
+ Aplikasi lain di luar Amazon ECS

Aplikasi ini dapat terhubung melalui proxy Service Connect tetapi tidak dapat menyelesaikan nama titik akhir Service Connect.

Agar aplikasi ini dapat menyelesaikan alamat IP tugas Amazon ECS, Anda perlu menggunakan metode interkoneksi lain. 

**Topics**
+ [

## Harga
](#service-connect-pricing)
+ [

# Komponen Amazon ECS Service Connect
](service-connect-concepts-deploy.md)
+ [

# Gambaran Umum Konfigurasi Amazon ECS Service Connect
](service-connect-concepts.md)
+ [

# Amazon ECS Service Connect dengan ruang nama bersama AWS Cloud Map
](service-connect-shared-namespaces.md)
+ [

# Log akses Amazon ECS Service Connect
](service-connect-envoy-access-logs.md)
+ [

# Enkripsi lalu lintas Amazon ECS Service Connect
](service-connect-tls.md)
+ [

# Mengonfigurasi Amazon ECS Service Connect dengan AWS CLI
](create-service-connect.md)

## Harga
<a name="service-connect-pricing"></a>
+ Harga Amazon ECS Service Connect bergantung pada apakah Anda menggunakan AWS Fargate atau infrastruktur Amazon EC2 untuk meng-host beban kerja kontainer Anda. Saat menggunakan Amazon ECS aktif AWS Outposts, harga mengikuti model yang sama yang digunakan saat Anda menggunakan Amazon EC2 secara langsung. Untuk informasi selengkapnya, lihat [Harga Amazon ECS](https://aws.amazon.com/ecs/pricing).
+ Tidak ada biaya tambahan untuk menggunakan Amazon ECS Service Connect.
+ Tidak ada biaya tambahan untuk AWS Cloud Map penggunaan saat digunakan oleh Service Connect.
+ Pelanggan membayar sumber daya komputasi yang digunakan oleh Amazon ECS Service Connect, termasuk vCPU dan Memori. Karena agen Amazon ECS Service Connect berjalan di dalam tugas pelanggan, tidak ada biaya tambahan untuk menjalankannya. Sumber daya tugas dibagi antara beban kerja pelanggan dan agen Amazon ECS Service Connect.
+ Saat menggunakan fungsionalitas enkripsi lalu lintas Amazon ECS Service Connect AWS Private CA, pelanggan membayar otoritas sertifikat pribadi yang mereka buat dan untuk setiap sertifikat TLS yang dikeluarkan. Untuk lebih jelasnya, lihat [AWS Private Certificate Authority harga](https://aws.amazon.com/private-ca/pricing/). Untuk memperkirakan biaya bulanan sertifikat TLS, pelanggan perlu mengetahui jumlah layanan Amazon ECS yang mengaktifkan TLS, kalikan dengan biaya sertifikat, dan kemudian kalikan dengan enam. Karena Amazon ECS Service Connect secara otomatis memutar sertifikat TLS setiap lima hari, ada enam sertifikat yang dikeluarkan per layanan Amazon ECS, rata-rata per bulan.

# Komponen Amazon ECS Service Connect
<a name="service-connect-concepts-deploy"></a>

Saat Anda menggunakan Amazon ECS Service Connect, Anda mengonfigurasi setiap layanan Amazon ECS untuk menjalankan aplikasi server yang menerima permintaan jaringan (layanan client-server) atau menjalankan aplikasi klien yang membuat permintaan (layanan klien).

Saat Anda bersiap untuk mulai menggunakan Service Connect, mulailah dengan layanan client-server. Anda dapat menambahkan konfigurasi Service Connect ke layanan baru atau layanan yang sudah ada. Amazon ECS membuat titik akhir Service Connect di namespace. Selain itu, Amazon ECS membuat penerapan baru di layanan untuk menggantikan tugas yang sedang berjalan.

Tugas yang ada dan aplikasi lain dapat terus terhubung ke titik akhir yang ada, dan aplikasi eksternal. Jika layanan client-server menambahkan tugas dengan skala keluar, koneksi baru dari klien akan seimbang di antara semua tugas. Jika layanan client-server diperbarui, koneksi baru dari klien akan seimbang antara tugas-tugas versi baru.

Tugas yang ada tidak dapat menyelesaikan dan terhubung ke titik akhir yang baru. Hanya tugas baru dengan konfigurasi Service Connect di namespace yang sama dan yang mulai berjalan setelah penerapan ini dapat menyelesaikan dan terhubung ke titik akhir ini. 

Ini berarti bahwa operator aplikasi klien menentukan kapan konfigurasi aplikasi mereka berubah, meskipun operator aplikasi server dapat mengubah konfigurasi mereka kapan saja. Daftar titik akhir di namespace dapat berubah setiap kali layanan apa pun di namespace diterapkan. Tugas yang ada dan tugas pengganti terus berperilaku sama seperti yang mereka lakukan setelah penerapan terbaru.

Pertimbangkan contoh berikut.

Pertama, asumsikan bahwa Anda membuat aplikasi yang tersedia untuk internet publik dalam satu AWS CloudFormation template dan CloudFormation tumpukan tunggal. Penemuan dan jangkauan publik harus dibuat terakhir oleh CloudFormation, termasuk layanan klien frontend. Layanan perlu dibuat dalam urutan ini untuk mencegah periode waktu ketika layanan klien frontend berjalan dan tersedia untuk umum, tetapi backend tidak. Ini menghilangkan pesan kesalahan agar tidak dikirim ke publik selama periode waktu tersebut. Di AWS CloudFormation, Anda harus menggunakan `dependsOn` untuk menunjukkan CloudFormation bahwa beberapa layanan Amazon ECS tidak dapat dibuat secara paralel atau bersamaan. Anda harus menambahkan `dependsOn` ke layanan klien frontend untuk setiap layanan client-server backend yang terhubung dengan tugas klien.

Kedua, asumsikan bahwa layanan frontend ada tanpa konfigurasi Service Connect. Tugas menghubungkan ke layanan backend yang ada. Tambahkan konfigurasi Service Connect client-server ke layanan backend terlebih dahulu, menggunakan nama yang sama di **DNS** atau `clientAlias` yang digunakan frontend. Ini menciptakan penerapan baru, sehingga semua deteksi rollback penerapan atau Konsol Manajemen AWS, AWS CLI, AWS SDKs dan metode lain untuk memutar kembali dan mengembalikan layanan backend ke penerapan dan konfigurasi sebelumnya. Jika Anda puas dengan kinerja dan perilaku layanan backend, tambahkan konfigurasi Service Connect klien atau client-server ke layanan frontend. Hanya tugas dalam penerapan baru yang menggunakan proxy Service Connect yang ditambahkan ke tugas baru tersebut. Jika Anda memiliki masalah dengan konfigurasi ini, Anda dapat memutar kembali dan kembali ke konfigurasi sebelumnya dengan menggunakan deteksi rollback penerapan atau Konsol Manajemen AWS, AWS CLI, AWS SDKs dan metode lain untuk memutar kembali dan mengembalikan layanan backend ke penerapan dan konfigurasi sebelumnya. Jika Anda menggunakan sistem penemuan layanan lain yang didasarkan pada DNS dan bukan Service Connect, aplikasi frontend atau klien apa pun mulai menggunakan titik akhir baru dan mengubah konfigurasi titik akhir setelah cache DNS lokal kedaluwarsa, biasanya memakan waktu beberapa jam.

## Jaringan
<a name="service-connect-concepts-network"></a>

Secara default, proxy Service Connect mendengarkan `containerPort` dari pemetaan port definisi tugas. Aturan grup keamanan Anda harus mengizinkan lalu lintas masuk (masuknya) ke port ini dari subnet tempat klien akan dijalankan.

Bahkan jika Anda menetapkan nomor port dalam konfigurasi layanan Service Connect, ini tidak mengubah port untuk layanan client-server yang didengarkan proxy Service Connect. Saat Anda menyetel nomor port ini, Amazon ECS mengubah port titik akhir yang terhubung dengan layanan klien, pada proxy Service Connect di dalam tugas tersebut. Proxy dalam layanan klien terhubung ke proxy di layanan client-server menggunakan file. `containerPort`

Jika Anda ingin mengubah port yang didengarkan proxy Service Connect, ubah konfigurasi Service Connect pada layanan client-server. `ingressPortOverride` Jika Anda mengubah nomor port ini, Anda harus mengizinkan lalu lintas masuk pada port ini yang digunakan oleh lalu lintas ke layanan ini.

Lalu lintas yang dikirim aplikasi Anda ke layanan Amazon ECS yang dikonfigurasi untuk Service Connect mengharuskan Amazon VPC dan subnet memiliki aturan tabel rute dan aturan ACL jaringan yang memungkinkan `containerPort` `ingressPortOverride` dan nomor port yang Anda gunakan.

 Anda dapat menggunakan Service Connect untuk mengirim lalu lintas di antaranya VPCs. Persyaratan yang sama untuk aturan tabel rute, jaringan ACLs, dan grup keamanan berlaku untuk keduanya VPCs.

Misalnya, dua cluster membuat tugas yang berbeda VPCs. Layanan di setiap cluster dikonfigurasi untuk menggunakan namespace yang sama. Aplikasi dalam dua layanan ini dapat menyelesaikan setiap titik akhir di namespace tanpa konfigurasi DNS VPC apa pun. Namun, proxy tidak dapat terhubung kecuali VPC peering, VPC, atau tabel rute subnet, dan jaringan VPC memungkinkan lalu lintas pada dan nomor port. ACLs `containerPort` `ingressPortOverride`

Untuk tugas yang menggunakan mode `bridge` jaringan, Anda harus membuat grup keamanan dengan aturan masuk yang memungkinkan lalu lintas pada rentang port dinamis atas. Kemudian, tetapkan grup keamanan ke semua instans EC2 di kluster Service Connect.

## Proksi Service Connect
<a name="service-connect-concepts-proxy"></a>

Jika Anda membuat atau memperbarui layanan dengan konfigurasi Service Connect, Amazon ECS menambahkan wadah baru ke setiap tugas baru saat dimulai. Pola penggunaan wadah terpisah ini disebut a`sidecar`. Wadah ini tidak ada dalam definisi tugas dan Anda tidak dapat mengonfigurasinya. Amazon ECS mengelola konfigurasi Container dalam layanan. Ini memungkinkan Anda untuk menggunakan kembali definisi tugas yang sama antara beberapa layanan, ruang nama, dan tugas tanpa Service Connect.

**Sumber daya proxy**
+ Untuk definisi tugas, Anda harus mengatur parameter CPU dan memori. 

  Sebaiknya tambahkan 256 unit CPU tambahan dan setidaknya 64 MiB memori ke CPU tugas dan memori Anda untuk wadah proxy Service Connect. Di AWS Fargate, jumlah memori terendah yang dapat Anda atur adalah memori 512 MiB. Di Amazon EC2, memori definisi tugas diperlukan.
+ Untuk layanan, Anda mengatur konfigurasi log dalam konfigurasi Service Connect.
+ Jika Anda mengharapkan tugas dalam layanan ini menerima lebih dari 500 permintaan per detik pada beban puncaknya, sebaiknya tambahkan 512 unit CPU ke CPU tugas Anda dalam definisi tugas ini untuk container proxy Service Connect.
+ Jika Anda berharap untuk membuat lebih dari 100 layanan Service Connect di namespace atau 2000 tugas secara total di semua layanan Amazon ECS dalam namespace, sebaiknya tambahkan 128 MiB memori ke memori tugas Anda untuk container proxy Service Connect. Anda harus melakukan ini di setiap definisi tugas yang digunakan oleh semua layanan Amazon ECS di namespace.

**Konfigurasi proxy**  
Aplikasi Anda terhubung ke proxy di wadah sespan dalam tugas yang sama dengan aplikasi. Amazon ECS mengonfigurasi tugas dan kontainer sehingga aplikasi hanya terhubung ke proxy saat aplikasi terhubung ke nama titik akhir di namespace yang sama. Semua lalu lintas lainnya tidak menggunakan proxy. Lalu lintas lainnya termasuk alamat IP di VPC yang sama, titik akhir AWS layanan, dan lalu lintas eksternal.

**Penyeimbangan beban**  
Service Connect mengonfigurasi proxy untuk menggunakan strategi round-robin untuk load balancing antara tugas di titik akhir Service Connect. Proxy lokal yang ada dalam tugas dari mana koneksi berasal, memilih salah satu tugas dalam layanan client-server yang menyediakan titik akhir.  
*Misalnya, pertimbangkan tugas yang berjalan WordPress di layanan yang dikonfigurasi sebagai *layanan klien* di namespace yang disebut lokal.* Ada layanan lain dengan 2 tugas yang menjalankan database MySQL. Layanan ini dikonfigurasi untuk menyediakan titik akhir yang dipanggil `mysql` melalui Service Connect di namespace yang sama. Dalam WordPress tugas, WordPress aplikasi terhubung ke database menggunakan nama endpoint. Koneksi ke nama ini masuk ke proxy yang berjalan dalam wadah sespan dalam tugas yang sama. Kemudian, proxy dapat terhubung ke salah satu tugas MySQL menggunakan strategi round-robin.  
Strategi penyeimbangan beban: round-robin

**Deteksi outlier**  
Fitur ini menggunakan data yang dimiliki proxy tentang koneksi gagal sebelumnya untuk menghindari pengiriman koneksi baru ke host yang memiliki koneksi gagal. Service Connect mengonfigurasi fitur deteksi outlier dari proxy untuk memberikan pemeriksaan kesehatan pasif.  
Menggunakan contoh sebelumnya, proxy dapat terhubung ke salah satu tugas MySQL. Jika proxy membuat beberapa koneksi ke tugas MySQL tertentu, dan 5 atau lebih koneksi gagal dalam 30 detik terakhir, maka proxy menghindari tugas MySQL itu selama 30 hingga 300 detik.

**Percobaan ulang**  
Service Connect mengonfigurasi proxy untuk mencoba lagi koneksi yang melewati proxy dan gagal, dan upaya kedua menghindari penggunaan host dari koneksi sebelumnya. Ini memastikan bahwa setiap koneksi melalui Service Connect tidak gagal karena alasan satu kali.  
Jumlah percobaan ulang: 2

**Waktu habis**  
Service Connect mengonfigurasi proxy untuk menunggu waktu maksimum agar aplikasi client-server Anda merespons. Nilai batas waktu default adalah 15 detik, tetapi dapat diperbarui.  
Parameter opsional:  
**IdleTimeout** - Jumlah waktu dalam detik koneksi tetap aktif saat idle. Nilai `0` menonaktifkan `idleTimeout`.  
`idleTimeout`Default untuk`HTTP`/`HTTP2`/`GRPC`adalah 5 menit.  
`idleTimeout`Default untuk `TCP` adalah 1 jam.  
**perRequestTimeout**- Jumlah waktu menunggu hulu untuk merespons dengan respons lengkap per permintaan. Nilai `0` dimatikan`perRequestTimeout`. Ini hanya dapat diatur ketika wadah `appProtocol` untuk aplikasi adalah`HTTP`/`HTTP2`/`GRPC`. Defaultnya adalah 15 detik.  
Jika `idleTimeout` diatur ke waktu kurang dari `perRequestTimeout`, koneksi akan ditutup ketika `idleTimeout` tercapai dan bukannya `perRequestTimeout`.

## Pertimbangan-pertimbangan
<a name="service-connect-considerations"></a>

Pertimbangkan hal berikut saat menggunakan Service Connect:
+ Tugas yang berjalan di Fargate harus menggunakan versi platform Fargate Linux `1.4.0` atau lebih tinggi untuk menggunakan Service Connect.
+ Versi agen Amazon ECS pada instance container harus `1.67.2` atau lebih tinggi.
+ Instans penampung harus menjalankan Amazon ECS yang dioptimalkan Amazon Linux 2023 versi AMI atau yang lebih baru, atau `20230428` versi Amazon Linux 2 AMI Amazon ECS yang dioptimalkan untuk menggunakan Service Connect. `2.0.20221115` Versi ini memiliki agen Service Connect selain agen kontainer Amazon ECS. Untuk informasi selengkapnya tentang agen Service Connect, lihat Agen [Amazon ECS Service Connect](https://github.com/aws/amazon-ecs-service-connect-agent) di GitHub.
+ Instance kontainer harus memiliki `ecs:Poll` izin untuk sumber `arn:aws:ecs:region:0123456789012:task-set/cluster/*` daya. Jika Anda menggunakan`ecsInstanceRole`, Anda tidak perlu menambahkan izin tambahan. Kebijakan `AmazonEC2ContainerServiceforEC2Role` terkelola memiliki izin yang diperlukan. Untuk informasi selengkapnya, lihat [Peran IAM instans kontainer Amazon ECS](instance_IAM_role.md).
+ Tugas yang menggunakan mode `bridge` jaringan dan menggunakan Service Connect tidak mendukung parameter definisi `hostname` kontainer.
+ Definisi tugas harus menetapkan batas memori tugas untuk menggunakan Service Connect. Untuk informasi selengkapnya, lihat [Proksi Service Connect](#service-connect-concepts-proxy).
+ Definisi tugas yang menetapkan batas memori kontainer tidak didukung.

  Anda dapat mengatur batas memori kontainer pada kontainer Anda, tetapi Anda harus mengatur batas memori tugas ke angka yang lebih besar dari jumlah batas memori kontainer. CPU dan memori tambahan dalam batas tugas yang tidak dialokasikan dalam batas kontainer digunakan oleh kontainer proxy Service Connect dan wadah lain yang tidak menetapkan batas kontainer. Untuk informasi selengkapnya, lihat [Proksi Service Connect](#service-connect-concepts-proxy).
+ Anda dapat mengonfigurasi Service Connect untuk menggunakan AWS Cloud Map namespace apa pun di Wilayah yang sama yang sama Akun AWS atau dibagikan dengan penggunaan Anda Akun AWS . AWS Resource Access Manager Untuk informasi selengkapnya tentang menggunakan ruang nama bersama, lihat. [Amazon ECS Service Connect dengan ruang nama bersama AWS Cloud Map](service-connect-shared-namespaces.md)
+ Setiap layanan hanya dapat dimiliki oleh satu namespace.
+ Hanya tugas yang dibuat layanan yang didukung. 
+ Semua titik akhir harus unik dalam namespace.
+ Semua nama penemuan harus unik dalam namespace.
+ Anda harus menerapkan ulang layanan yang ada sebelum aplikasi dapat menyelesaikan titik akhir baru. Titik akhir baru yang ditambahkan ke namespace setelah penerapan terbaru tidak akan ditambahkan ke konfigurasi tugas. Untuk informasi selengkapnya, lihat [Komponen Amazon ECS Service Connect](#service-connect-concepts-deploy).
+ Service Connect tidak menghapus ruang nama saat kluster dihapus. Anda harus menghapus ruang nama di. AWS Cloud Map
+ Lalu lintas Application Load Balancer default ke routing melalui agen Service Connect dalam mode jaringan. `awsvpc` Jika Anda ingin lalu lintas non-layanan melewati agen Service Connect, gunakan `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` parameter dalam konfigurasi layanan Service Connect Anda.
+ Service Connect with TLS tidak mendukung mode `bridge` jaringan. Hanya mode `awsvpc` jaringan yang didukung.
+ Dalam `awsvpc` mode, proxy Service Connect meneruskan lalu lintas ke IPv4 localhost `127.0.0.1` untuk layanan dalam konfigurasi IPv4 -only dan dualstack. Untuk layanan dalam konfigurasi IPv6 -only, proxy meneruskan lalu lintas ke localhost. IPv6 `::1` Sebaiknya konfigurasi aplikasi Anda untuk mendengarkan kedua localhosts untuk pengalaman yang mulus saat layanan diperbarui dari konfigurasi IPv4 -only atau dualstack ke -only. IPv6 Untuk informasi selengkapnya, lihat [Opsi Jaringan Tugas Amazon ECS untuk EC2](task-networking.md) dan [Opsi jaringan tugas Amazon ECS untuk Fargate](fargate-task-networking.md).

**Service Connect tidak mendukung hal berikut:**
+ Kontainer Windows
+ HTTP 1.0
+ Tugas mandiri
+ Layanan yang menggunakan jenis penyebaran yang blue/green didukung oleh CodeDeploy dan eksternal
+ `External`instance container untuk Amazon ECS Anywhere tidak didukung dengan Service Connect.
+ PPv2
+ Modus FIPS

# Gambaran Umum Konfigurasi Amazon ECS Service Connect
<a name="service-connect-concepts"></a>

Saat Anda menggunakan Service Connect, ada parameter yang perlu Anda konfigurasikan di sumber daya Anda. 

Tabel berikut menjelaskan parameter konfigurasi untuk sumber daya Amazon ECS.


| Parameter lokasi | Jenis aplikasi | Deskripsi | Diperlukan | 
| --- | --- | --- | --- | 
| Definisi tugas | Klien | Tidak ada perubahan yang tersedia untuk Service Connect dalam definisi tugas klien. | N/A | 
| Definisi tugas | Server klien | Server harus menambahkan name bidang ke port di portMappings wadah. Untuk informasi selengkapnya, lihat [portMappings](task_definition_parameters.md#ContainerDefinition-portMappings) | Ya | 
| Definisi tugas | Server klien | Server secara opsional dapat menyediakan protokol aplikasi (misalnya, HTTP) untuk menerima metrik spesifik protokol untuk aplikasi server mereka (misalnya,). HTTP 5xx | Tidak | 
| Definisi layanan | Klien | Layanan klien harus menambahkan a serviceConnectConfiguration untuk mengkonfigurasi namespace untuk bergabung. Namespace ini harus berisi semua layanan server yang perlu ditemukan oleh layanan ini. Untuk informasi selengkapnya, lihat [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Ya | 
| Definisi layanan | Server klien | Layanan server harus menambahkan a serviceConnectConfiguration untuk mengonfigurasi nama DNS, nomor port, dan namespace tempat layanan tersedia. Untuk informasi selengkapnya, lihat [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Ya | 
| Kluster | Klien | Cluster dapat menambahkan namespace Service Connect default. Layanan baru di cluster mewarisi namespace saat Service Connect dikonfigurasi dalam layanan.  | Tidak | 
| Kluster | Server klien | Tidak ada perubahan yang tersedia untuk Service Connect di cluster yang berlaku untuk layanan server. Definisi tugas server dan layanan harus mengatur konfigurasi masing-masing. | N/A | 

**Ikhtisar langkah-langkah untuk mengkonfigurasi Service Connect**  
Langkah-langkah berikut memberikan gambaran umum tentang cara mengkonfigurasi Service Connect.

**penting**  
 Service Connect membuat AWS Cloud Map layanan di akun Anda. Memodifikasi AWS Cloud Map sumber daya ini dengan registering/deregistering instance secara manual, mengubah atribut instance, atau menghapus layanan dapat menyebabkan perilaku tak terduga untuk lalu lintas aplikasi Anda atau penerapan berikutnya.
 Service Connect tidak mendukung link dalam definisi tugas.

1. Tambahkan nama port ke pemetaan port dalam definisi tugas Anda. Selain itu, Anda dapat mengidentifikasi protokol lapisan 7 aplikasi, untuk mendapatkan metrik tambahan.

1. Buat cluster dengan AWS Cloud Map namespace, gunakan namespace bersama, atau buat namespace secara terpisah. Untuk organisasi sederhana, buat cluster dengan nama yang Anda inginkan untuk namespace dan tentukan nama yang identik untuk namespace. Dalam hal ini, Amazon ECS membuat namespace HTTP baru dengan konfigurasi yang diperlukan. Service Connect tidak menggunakan atau membuat zona yang dihosting DNS di Amazon Route 53.

1. Konfigurasikan layanan untuk membuat titik akhir Service Connect di dalam namespace.

1. Menyebarkan layanan untuk membuat titik akhir. Amazon ECS menambahkan container proxy Service Connect ke setiap tugas, dan membuat titik akhir Service Connect. AWS Cloud Map Wadah ini tidak dikonfigurasi dalam definisi tugas, dan definisi tugas dapat digunakan kembali tanpa modifikasi untuk membuat beberapa layanan di namespace yang sama atau di beberapa ruang nama.

1. Menerapkan aplikasi klien sebagai layanan untuk terhubung ke titik akhir. Amazon ECS menghubungkannya ke titik akhir Service Connect melalui proxy Service Connect di setiap tugas.

   Aplikasi hanya menggunakan proxy untuk terhubung ke titik akhir Service Connect. Tidak ada konfigurasi tambahan untuk menggunakan proxy. Proxy melakukan penyeimbangan beban round-robin, deteksi outlier, dan percobaan ulang. Untuk informasi selengkapnya tentang proxy, lihat[Proksi Service Connect](service-connect-concepts-deploy.md#service-connect-concepts-proxy).

1. Pantau lalu lintas melalui proxy Service Connect di Amazon CloudWatch.

## Konfigurasi klaster
<a name="service-connect-concepts-cluster-defaults"></a>

Anda dapat mengatur namespace default untuk Service Connect saat membuat atau memperbarui klaster. Nama namespace yang Anda tentukan sebagai default dapat berada di akun yang sama, atau sama Wilayah AWS Wilayah AWS dan dibagikan oleh penggunaan lain Akun AWS . AWS Resource Access Manager

Jika Anda membuat klaster dan menentukan namespace Service Connect default, klaster menunggu dalam status `PROVISIONING` sementara Amazon ECS membuat namespace. Anda dapat melihat status klaster yang menunjukkan status namespace. `attachment` Lampiran tidak ditampilkan secara default di AWS CLI, Anda harus menambahkan `--include ATTACHMENTS` untuk melihatnya.

Jika Anda ingin menggunakan namespace yang dibagikan dengan Akun AWS penggunaan Anda AWS RAM, tentukan Amazon Resource Name (ARN) dari namespace dalam konfigurasi cluster. Untuk informasi selengkapnya tentang AWS Cloud Map ruang nama bersama, lihat. [Amazon ECS Service Connect dengan ruang nama bersama AWS Cloud Map](service-connect-shared-namespaces.md)

## Konfigurasi layanan
<a name="service-connect-concepts-config"></a>

Service Connect dirancang untuk memerlukan konfigurasi minimum. Anda perlu menetapkan nama untuk setiap pemetaan port yang ingin Anda gunakan dengan Service Connect dalam definisi tugas. Dalam layanan, Anda perlu mengaktifkan Service Connect dan memilih namespace di namespace Anda Akun AWS atau bersama untuk membuat layanan klien. Untuk membuat layanan client-server, Anda perlu menambahkan satu konfigurasi layanan Service Connect yang cocok dengan nama salah satu pemetaan port. Amazon ECS menggunakan kembali nomor port dan nama port dari definisi tugas untuk menentukan layanan dan titik akhir Service Connect. Untuk mengganti nilai tersebut, Anda dapat menggunakan parameter lain **Discovery**, **DNS**, dan **Port** di konsol, atau `discoveryName` dan`clientAliases`, masing-masing di Amazon ECS API.

## Konfigurasi Pemeriksaan Kesehatan Awal
<a name="service-connect-concepts-health-check"></a>

Service Connect memastikan tugas sehat sebelum merutekan lalu lintas ke tugas tersebut. Saat tugas diluncurkan (selama penerapan, penskalaan, atau penggantian), Service Connect memantau kesehatan tugas Anda untuk memastikannya siap menerima lalu lintas. Anda harus menentukan pemeriksaan kesehatan untuk wadah penting dalam definisi tugas Anda untuk mengaktifkan perilaku ini.

Perilaku pemeriksaan kesehatan awal menyumbang potensi penundaan dengan mencapai keadaan ketika tugas siap menerima lalu lintas:
+ Jika ada tugas`HEALTHY`, itu segera tersedia untuk lalu lintas.
+ Jika kesehatan tugas`UNKNOWN`, Service Connect mengikuti konfigurasi pemeriksaan kesehatan kontainer (lihat[Pemeriksaan kondisi](task_definition_parameters.md#container_definition_healthcheck)) wadah penting tugas untuk menghitung batas waktu, hingga`8 minutes`, sebelum membuatnya tersedia untuk lalu lintas, meskipun masih ada`UNKNOWN`.
+ Jika ada tugas`UNHEALTHY`, Amazon ECS dapat meluncurkan tugas pengganti. Jika tidak ada tugas sehat yang tersedia, penerapan Anda mungkin akan dibatalkan berdasarkan konfigurasi layanan Anda.

Untuk semua lalu lintas yang sedang berlangsung, Service Connect menggunakan pemeriksaan kesehatan pasif berdasarkan deteksi outlier untuk merutekan lalu lintas secara efisien.

# Amazon ECS Service Connect dengan ruang nama bersama AWS Cloud Map
<a name="service-connect-shared-namespaces"></a>

Amazon ECS Service Connect mendukung penggunaan AWS Cloud Map ruang nama bersama Akun AWS di beberapa ruang yang sama. Wilayah AWS Kemampuan ini memungkinkan Anda membuat aplikasi terdistribusi di mana layanan yang berjalan berbeda Akun AWS dapat menemukan dan berkomunikasi satu sama lain melalui Service Connect. Ruang nama bersama dikelola menggunakan AWS Resource Access Manager (AWS RAM), yang memungkinkan berbagi sumber daya lintas akun yang aman. *Untuk informasi selengkapnya tentang ruang nama bersama, lihat [Berbagi AWS Cloud Map namespace lintas akun](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) di Panduan Pengembang.AWS Cloud Map *

**penting**  
Anda harus menggunakan izin `AWSRAMPermissionCloudMapECSFullPermission` terkelola untuk berbagi namespace agar Service Connect berfungsi dengan baik dengan namespace.

Bila Anda menggunakan AWS Cloud Map ruang nama bersama dengan Service Connect, layanan dari beberapa Akun AWS dapat berpartisipasi dalam namespace layanan yang sama. Ini sangat berguna untuk organisasi dengan banyak Akun AWS yang perlu menjaga service-to-service komunikasi lintas batas akun sambil menjaga keamanan dan isolasi.

**catatan**  
Untuk berkomunikasi dengan layanan yang berbeda VPCs, Anda perlu mengkonfigurasi konektivitas antar-VPC. Ini dapat dicapai dengan menggunakan koneksi VPC Peering. Untuk informasi selengkapnya, lihat [Membuat atau menghapus koneksi Peering VPC di panduan Peering](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) *VPC Amazon Virtual Private Cloud*.

# Menggunakan AWS Cloud Map ruang nama bersama dengan Amazon ECS Service Connect
<a name="service-connect-shared-namespaces-setup"></a>

Menyiapkan AWS Cloud Map ruang nama bersama untuk Service Connect melibatkan langkah-langkah berikut: Pemilik namespace membuat namespace, pemilik membagikannya melalui AWS Resource Access Manager (AWS RAM), konsumen menerima pembagian sumber daya, dan konsumen mengonfigurasi Service Connect untuk menggunakan namespace bersama.

## Langkah 1: Buat AWS Cloud Map namespace
<a name="service-connect-shared-namespaces-create"></a>

Pemilik namespace membuat AWS Cloud Map namespace yang akan dibagikan dengan akun lain.

**Untuk membuat namespace untuk berbagi menggunakan Konsol Manajemen AWS**

1. Buka AWS Cloud Map konsol di [https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/).

1. Pilih **Buat namespace**.

1. Masukkan **nama Namespace**. Nama ini akan digunakan oleh layanan di semua akun yang berpartisipasi.

1. Untuk jenis **Namespace, pilih jenis** yang sesuai untuk kasus penggunaan Anda:
   + **Panggilan API** - ruang nama HTTP untuk penemuan layanan tanpa fungsionalitas DNS.
   + **Panggilan API dan kueri DNS di VPCs** - Ruang nama DNS pribadi untuk penemuan layanan dengan kueri DNS pribadi di VPC.
   + **Panggilan API dan kueri DNS publik** - Ruang nama DNS publik untuk penemuan layanan dengan kueri DNS publik.

1.  Pilih **Buat namespace**.

## Langkah 2: Bagikan namespace menggunakan AWS RAM
<a name="service-connect-shared-namespaces-share"></a>

Pemilik namespace menggunakan AWS RAM untuk berbagi namespace dengan yang lain. Akun AWS

**Untuk berbagi namespace menggunakan konsol AWS RAM**

1. Buka AWS RAM konsol di [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/).

1. Pilih **Buat berbagi sumber daya**.

1. Untuk **Nama**, masukkan nama deskriptif untuk berbagi sumber daya.

1. Di bagian **Sumber Daya**:

   1. Untuk **jenis Resource**, pilih **Cloud Map Namespaces**.

   1. Pilih namespace yang Anda buat pada langkah sebelumnya.

1. Di bagian **Izin terkelola**, tentukan **AWSRAMPermissionCloudMapECSFullIzin**.
**penting**  
Anda harus menggunakan izin `AWSRAMPermissionCloudMapECSFullPermission` terkelola untuk berbagi namespace agar Service Connect berfungsi dengan baik dengan namespace.

1. Di bagian **Prinsipal**, tentukan namespace yang ingin Akun AWS Anda bagikan. Anda dapat memasukkan akun IDs atau unit organisasi IDs.

1. Pilih **Buat berbagi sumber daya**.

## Langkah 3: Terima pembagian sumber daya
<a name="service-connect-shared-namespaces-accept"></a>

Akun konsumen namespace harus menerima undangan berbagi sumber daya untuk menggunakan namespace bersama.

**Untuk menerima undangan berbagi sumber daya menggunakan AWS RAM konsol**

1. Di akun konsumen, buka AWS RAM konsol di [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/).

1. Di panel navigasi, pilih **Dibagikan dengan saya**, lalu pilih **Pembagian sumber daya**.

1. Pilih undangan berbagi sumber daya dan pilih **Terima berbagi sumber daya**.

1. Setelah menerima, perhatikan ARN namespace bersama dari detail sumber daya. Anda akan menggunakan ARN ini saat mengonfigurasi layanan Service Connect.

## Langkah 4: Konfigurasikan layanan Amazon ECS dengan namespace bersama
<a name="service-connect-shared-namespaces-configure"></a>

Setelah menerima namespace bersama, konsumen namespace dapat mengonfigurasi layanan Amazon ECS untuk menggunakan namespace bersama. Konfigurasi ini mirip dengan menggunakan namespace biasa, tetapi Anda harus menentukan namespace ARN bukan nama. Untuk prosedur pembuatan layanan terperinci, lihat[Membuat penyebaran pembaruan bergulir Amazon ECS](create-service-console-v2.md).

**Untuk membuat layanan dengan namespace bersama menggunakan Konsol Manajemen AWS**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster tempat Anda ingin membuat layanan.

1. Di bawah **Layanan**, pilih **Buat**.

1. Setelah mengisi detail lainnya tergantung pada beban kerja Anda, di bagian **Service Connect**, pilih **Use Service Connect**.

1. Untuk **Namespace**, masukkan ARN lengkap dari namespace bersama.

   Format ARN adalah: `arn:aws:servicediscovery:region:account-id:namespace/namespace-id`

1. Konfigurasikan setelan Service Connect yang tersisa sesuai kebutuhan untuk jenis layanan Anda (klien atau client-server).

1. Selesaikan proses pembuatan layanan.

Anda juga dapat mengkonfigurasi layanan menggunakan AWS CLI atau AWS SDKs dengan menentukan namespace bersama ARN dalam `namespace` parameter. `serviceConnectConfiguration`

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }]
    }'
```

## Pertimbangan-pertimbangan
<a name="service-connect-shared-namespaces-considerations"></a>

Pertimbangkan hal berikut saat menggunakan AWS Cloud Map ruang nama bersama dengan Service Connect:
+ AWS RAM harus tersedia di Wilayah AWS tempat Anda ingin menggunakan namespace bersama.
+ Namespace bersama harus Wilayah AWS sama dengan layanan dan cluster Amazon ECS Anda.
+ Anda harus menggunakan namespace ARN, bukan ID, saat mengonfigurasi Service Connect dengan namespace bersama.
+ Semua jenis namespace didukung: HTTP, Private DNS, dan Public DNS namespace.
+ Jika akses ke namespace bersama dicabut, operasi Amazon ECS yang memerlukan interaksi dengan namespace (seperti`CreateService`,, `UpdateService` dan) akan gagal. `ListServicesByNamespace` Untuk informasi selengkapnya tentang masalah izin pemecahan masalah dengan ruang nama bersama, lihat. [Memecahkan masalah Amazon ECS Service Connect dengan ruang nama bersama AWS Cloud Map](service-connect-shared-namespaces-troubleshooting.md)
+ Untuk penemuan layanan menggunakan kueri DNS di namespace DNS pribadi bersama:
  + Pemilik namespace perlu menelepon `create-vpc-association-authorization` dengan ID zona host pribadi yang terkait dengan namespace, dan VPC konsumen.

    ```
    aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
  + Konsumen namespace perlu menelepon `associate-vpc-with-hosted-zone` dengan ID zona host pribadi.

    ```
    aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
+ Hanya pemilik namespace yang dapat mengelola pembagian sumber daya.
+ Konsumen namespace dapat membuat dan mengelola layanan dalam namespace bersama tetapi tidak dapat memodifikasi namespace itu sendiri.
+ Nama penemuan harus unik dalam namespace bersama, terlepas dari akun mana yang membuat layanan.
+ Layanan di namespace bersama dapat menemukan dan terhubung ke layanan dari AWS akun lain yang memiliki akses ke namespace.
+ Saat mengaktifkan TLS untuk Service Connect dan menggunakan namespace bersama, AWS Private CA Certificate Authority (CA) dicakup ke namespace. Ketika akses ke namespace bersama dicabut, akses ke CA dihentikan.
+ Saat bekerja dengan namespace bersama, pemilik namespace dan konsumen tidak memiliki akses ke metrik Amazon lintas akun secara default. CloudWatch Metrik target dipublikasikan hanya ke akun yang memiliki layanan klien. Akun yang memiliki layanan klien tidak memiliki akses ke metrik yang diterima oleh akun yang memiliki layanan client-server, dan sebaliknya. Untuk memungkinkan akses lintas akun ke metrik, siapkan observabilitas CloudWatch lintas akun. *Untuk informasi selengkapnya tentang mengonfigurasi observabilitas lintas akun, lihat observabilitas [CloudWatch lintas akun di Panduan Pengguna Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html). CloudWatch * Untuk informasi selengkapnya tentang CloudWatch metrik untuk Service Connect, lihat[Metrik Amazon ECS CloudWatch](available-metrics.md).

# Memecahkan masalah Amazon ECS Service Connect dengan ruang nama bersama AWS Cloud Map
<a name="service-connect-shared-namespaces-troubleshooting"></a>

Gunakan informasi berikut untuk memecahkan masalah dengan AWS Cloud Map ruang nama bersama dan Service Connect. Untuk informasi selengkapnya tentang menemukan pesan galat, lihat pemecahan masalah [Amazon ECS.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html)

Pesan kesalahan yang terkait dengan masalah izin muncul karena izin yang hilang, atau jika akses ke namespace dicabut. 

**penting**  
Anda harus menggunakan izin `AWSRAMPermissionCloudMapECSFullPermission` terkelola untuk berbagi namespace agar Service Connect berfungsi dengan baik dengan namespace.

Pesan kesalahan muncul dalam salah satu format berikut:

Terjadi kesalahan (ClientException) saat memanggil < OperationName > operation: User: arn:aws:iam: ::user/ is not authorized to perform: < > ActionName on resource: < > ResourceArn karena tidak ada kebijakan berbasis sumber daya yang mengizinkan tindakan < > ActionName <account-id><user-name>

Skenario berikut dapat menghasilkan pesan kesalahan dalam format ini:

**Pembuatan klaster atau kegagalan pembaruan**  
Masalah ini terjadi ketika operasi Amazon ECS seperti `CreateCluster` atau `UpdateCluster` gagal karena AWS Cloud Map izin yang hilang. Operasi memerlukan izin untuk AWS Cloud Map tindakan berikut:  
+ `servicediscovery:GetNamespace`
Pastikan bahwa undangan berbagi sumber daya telah diterima di akun konsumen dan bahwa ARN namespace yang benar digunakan dalam konfigurasi Service Connect.

**Pembuatan layanan atau kegagalan pembaruan**  
Masalah ini terjadi ketika operasi Amazon ECS seperti `CreateService` atau `UpdateService` gagal karena AWS Cloud Map izin yang hilang. Operasi memerlukan izin untuk AWS Cloud Map tindakan berikut:  
+ `servicediscovery:CreateService`
+ `servicediscovery:GetNamespace`
+ `servicediscovery:GetOperation`(untuk membuat AWS Cloud Map layanan baru)
+ `servicediscovery:GetService`(untuk ketika AWS Cloud Map layanan sudah ada)
Pastikan bahwa undangan berbagi sumber daya telah diterima di akun konsumen dan bahwa ARN namespace yang benar digunakan dalam konfigurasi Service Connect.

**`ListServicesByNamespace`operasi gagal**  
Masalah ini terjadi ketika `ListServicesByNamespace` operasi Amazon ECS gagal. Operasi memerlukan izin untuk AWS Cloud Map tindakan berikut:  
+ `servicediscovery:GetNamespace`
Untuk menyelesaikan masalah ini:  
+ Verifikasi bahwa akun konsumen memiliki `servicediscovery:GetNamespace` izin.
+ Gunakan namespace ARN saat memanggil API, bukan namanya.
+ Pastikan pembagian sumber daya aktif dan undangan telah diterima.

User: tidak diizinkan untuk melakukan: < ActionName > on resource: < ResourceArn > dengan penolakan eksplisit dalam kebijakan berbasis identitas. <iam-user>

Skenario berikut dapat menghasilkan pesan kesalahan dalam format ini:

**Penghapusan layanan gagal dan macet dalam status `DRAINING`**  
Masalah ini terjadi ketika `DeleteService` operasi Amazon ECS gagal karena `servicediscovery:DeleteService` izin yang hilang saat akses ke namespace dicabut. Layanan mungkin tampak berhasil dihapus pada awalnya tetapi akan macet di `DRAINING` negara bagian. Pesan kesalahan muncul sebagai acara layanan Amazon ECS.  
Untuk mengatasi masalah ini, pemilik namespace harus membagikan namespace dengan akun konsumen agar penghapusan layanan selesai.

**Tugas dalam layanan gagal dijalankan**  
Masalah ini terjadi ketika tugas gagal dimulai karena izin yang hilang. Pesan kesalahan muncul sebagai kesalahan tugas yang dihentikan. Untuk informasi selengkapnya, lihat [Mengatasi kesalahan tugas Amazon ECS yang dihentikan](resolve-stopped-errors.md).  
 AWS Cloud Map Tindakan berikut diperlukan untuk menjalankan tugas:  
+ `servicediscovery:GetOperation`
+ `servicediscovery:RegisterInstance`
Pastikan akun konsumen memiliki izin yang diperlukan dan namespace bersama dapat diakses.

**Tugas gagal berhenti dengan bersih atau terjebak dalam `DEACTIVATING` atau keadaan `DEPROVISIONING`**  
Masalah ini terjadi ketika tugas gagal membatalkan pendaftaran dari AWS Cloud Map layanan selama shutdown karena izin yang hilang. Kesalahan muncul sebagai lampiran tugas `statusReason` yang dapat di-retreived menggunakan API. `DescribeTasks` Untuk informasi selengkapnya, lihat [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)di *Referensi API Amazon Elastic Container Service*.  
 AWS Cloud Map Tindakan berikut diperlukan untuk menghentikan tugas:  
+ `servicediscovery:DeregisterInstance`
+ `servicediscovery:GetOperation`
Jika akses ke namespace bersama dicabut, tugas mungkin tetap dalam `DEPROVISIONING` status `DEACTIVATING` atau sampai akses namespace dipulihkan. Minta pemilik namespace untuk memulihkan akses ke namespace.

# Log akses Amazon ECS Service Connect
<a name="service-connect-envoy-access-logs"></a>

Amazon ECS Service Connect mendukung log akses untuk menyediakan telemetri terperinci tentang permintaan individual yang diproses oleh proxy Service Connect. Log akses melengkapi log aplikasi yang ada dengan menangkap metadata lalu lintas per permintaan seperti metode HTTP, jalur, kode respons, bendera, dan informasi waktu. Hal ini memungkinkan pengamatan yang lebih dalam ke dalam pola lalu lintas tingkat permintaan dan interaksi layanan untuk pemecahan masalah dan pemantauan yang efektif.

Untuk mengaktifkan log akses, tentukan `accessLogConfiguration` objek `logConfiguration` dan objek dalam `serviceConnectConfiguration` objek. Anda dapat mengonfigurasi format log dan apakah log harus menyertakan parameter kueri di file`accessLogConfiguration`. Log dikirim ke grup log tujuan oleh driver log yang ditentukan dalam file. `logConfiguration`

```
{
    "serviceConnectConfiguration": {
        "enabled": true,
        "namespace": "myapp.namespace",
        "services": [
            ...
        ],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }
}
```

## Pertimbangan-pertimbangan
<a name="service-connect-envoy-access-logs-considerations"></a>

Pertimbangkan hal berikut ketika Anda mengaktifkan akses ke log akses
+ Log akses dan log aplikasi keduanya ditulis untuk`/dev/stdout`. Untuk memisahkan log akses dari log aplikasi, sebaiknya gunakan driver `awsfirelens` log dengan kustom Fluent Bit atau Fluentd konfigurasi.
+  Sebaiknya gunakan driver `awslogs` log untuk mengirim aplikasi dan mengakses log ke CloudWatch tujuan yang sama.
+ log akses didukung pada layanan Fargate yang menggunakan versi platform `1.4.0` dan yang lebih tinggi.
+ Parameter kueri seperti id permintaan dan token dikecualikan dari log akses secara default. Untuk menyertakan parameter kueri dalam log akses, setel `includeQueryParameters` ke`"ENABLED"`.

## Akses format log
<a name="service-connect-envoy-access-logs-formats"></a>

log akses dapat diformat dalam kamus format JSON atau string format Teks, dengan perbedaan operator perintah yang didukung untuk berbagai jenis log akses.

### Log akses HTTP
<a name="service-connect-envoy-access-logs-formats-http"></a>

Operator perintah berikut disertakan secara default untuk log HTTP:

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration_ms": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%"
}
```

------

### HTTP2 log akses
<a name="service-connect-envoy-access-logs-formats-http2"></a>

Selain operator perintah yang disertakan untuk log HTTP, HTTP2 log menyertakan `%STREAM_ID%` operator secara default.

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### log akses gRPC
<a name="service-connect-envoy-access-logs-formats-grpc"></a>

Selain operator perintah yang disertakan untuk log HTTP, log akses gRPC menyertakan `%STREAM_ID%` dan `%GRPC_STATUS()%` operator secara default.

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %GRPC_STATUS()% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "grpc_status": "%GRPC_STATUS()%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### Log akses TCP
<a name="service-connect-envoy-access-logs-formats-tcp"></a>

Operator perintah berikut disertakan secara default dalam log akses TCP:

------
#### [ Text ]

```
[%START_TIME%] %DOWNSTREAM_REMOTE_ADDRESS% %DOWNSTREAM_REMOTE_PORT% 
%BYTES_RECEIVED% %BYTES_SENT% %DURATION%  
%CONNECTION_TERMINATION_DETAILS% %CONNECTION_ID%\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
  "downstream_remote_port": "%DOWNSTREAM_REMOTE_PORT%",s
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "connection_termination_details": "%CONNECTION_TERMINATION_DETAILS%",
  "connection_id": %CONNECTION_ID%
}
```

------

Untuk informasi selengkapnya tentang operator perintah ini, lihat [Operator Perintah](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) dalam dokumentasi Utusan.

# Mengaktifkan log akses untuk Amazon ECS Service Connect
<a name="service-connect-access-logs-configuration"></a>

Log akses tidak diaktifkan secara default untuk layanan Amazon ECS yang menggunakan Service Connect. Anda dapat mengaktifkan log akses dengan cara berikut.

## Aktifkan log akses menggunakan AWS CLI
<a name="service-connect-access-logs-configure-cli"></a>

Perintah berikut menunjukkan bagaimana Anda dapat mengaktifkan log akses untuk layanan Amazon ECS menggunakan AWS CLI dengan menentukan `accessLogConfiguration` saat Anda membuat layanan:

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }'
```

## Aktifkan log akses menggunakan konsol
<a name="service-connect-access-logs-configure-console"></a>

Untuk prosedur pembuatan layanan terperinci, lihat[Membuat penyebaran pembaruan bergulir Amazon ECS](create-service-console-v2.md).

**Untuk membuat layanan dengan namespace bersama menggunakan Konsol Manajemen AWS**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster tempat Anda ingin membuat layanan.

1. Di bawah **Layanan**, pilih **Buat**.

1. Setelah mengisi detail lainnya tergantung pada beban kerja Anda, di bagian **Service Connect**, pilih **Use Service Connect**.

1. Konfigurasikan pengaturan Service Connect sesuai kebutuhan untuk jenis layanan Anda (klien atau client-server).

1. Perluas **konfigurasi log Access**. Untuk **Format**, pilih **JSON** atau`TEXT`.

1. Untuk menyertakan parameter kueri dalam log akses, pilih **Sertakan parameter kueri**.

1. Selesaikan proses pembuatan layanan.

# Enkripsi lalu lintas Amazon ECS Service Connect
<a name="service-connect-tls"></a>

Amazon ECS Service Connect mendukung enkripsi lalu lintas otomatis dengan sertifikat Transport Layer Security (TLS) untuk layanan Amazon ECS. Saat Anda mengarahkan layanan Amazon ECS ke [AWS Private Certificate Authority (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html), Amazon ECS secara otomatis menyediakan sertifikat TLS untuk mengenkripsi lalu lintas antara layanan Amazon ECS Service Connect Anda. Amazon ECS menghasilkan, memutar, dan mendistribusikan sertifikat TLS yang digunakan untuk enkripsi lalu lintas.

Enkripsi lalu lintas otomatis dengan Service Connect menggunakan kemampuan enkripsi terdepan di industri untuk mengamankan komunikasi antar-layanan Anda yang membantu Anda memenuhi persyaratan keamanan. Ini mendukung sertifikat AWS Private Certificate Authority TLS dengan `256-bit ECDSA` dan `2048-bit RSA` enkripsi. Anda juga memiliki kontrol penuh atas sertifikat pribadi dan kunci penandatanganan untuk membantu Anda memenuhi persyaratan kepatuhan. Secara default, TLS 1.3 didukung, tetapi TLS 1.0 - 1.2 tidak didukung. Service Connect mendukung TLS 1.3 dengan cipher berikut:
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`

**catatan**  
Untuk menggunakan TLS 1.3, Anda harus mengaktifkannya pada pendengar pada target.  
Hanya lalu lintas masuk dan keluar yang lewat melalui agen Amazon ECS dienkripsi.

## Pemeriksaan kesehatan Service Connect dan Application Load Balancer
<a name="service-connect-tls-alb-healthchecks"></a>

Anda dapat menggunakan Service Connect dengan pemeriksaan kesehatan Application Load Balancer dan enkripsi TLS 1.3. 

### Konfigurasi Application Load Balancer
<a name="service-connect-tls-alb-config"></a>

Konfigurasikan Application Load Balancer dengan pengaturan berikut:
+ Konfigurasikan pendengar TLS dengan kebijakan keamanan TLS 1.3 (seperti `ELBSecurityPolicy- TLS13 -1-2-2021-06`). Untuk informasi selengkapnya, lihat [Kebijakan keamanan untuk Application Load Balancer Anda](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html). 
+ Buat grup target dengan pengaturan berikut:
  + Atur protokol ke HTTPS
  + Lampirkan grup target ke pendengar TLS
  + Konfigurasikan port pemeriksaan kesehatan agar sesuai dengan port kontainer layanan Service Connect

### Konfigurasi Service Connect
<a name="service-connect-tls-sc-config"></a>

Konfigurasikan layanan dengan pengaturan berikut:
+ Konfigurasikan layanan untuk menggunakan mode `awsvpc` jaringan, karena mode `bridge` jaringan tidak didukung.
+ Aktifkan Service Connect untuk layanan.
+ Siapkan konfigurasi penyeimbang beban dengan pengaturan berikut:
  + Tentukan grup target yang Anda konfigurasikan untuk Application Load Balancer
  + Atur port kontainer agar sesuai dengan port kontainer layanan Service Connect TLS
+ Hindari pengaturan `ingressPortOverride` untuk layanan. Untuk informasi selengkapnya, lihat [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)di *Referensi API Amazon Elastic Container Service*.

### Pertimbangan-pertimbangan
<a name="service-connect-tls-alb-considerations"></a>

Pertimbangkan hal berikut saat menggunakan Application Load Balancer, TLS dan Service Connect:
+ Gunakan mode `awsvpc` jaringan alih-alih mode `bridge` jaringan untuk pemeriksaan kesehatan HTTPS saat menggunakan enkripsi Service Connect dengan TLS. Pemeriksaan kesehatan HTTP akan terus bekerja dengan `bridge` mode.
+ Konfigurasikan port pemeriksaan kesehatan grup target agar sesuai dengan port kontainer layanan Service Connect, bukan port HTTPS default (443).

## AWS Private Certificate Authority sertifikat dan Service Connect
<a name="service-connect-tls-certificates"></a>

Anda harus memiliki peran IAM infrastruktur. Untuk informasi selengkapnya tentang peran ini, lihat peran [IAM infrastruktur Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     ).

**AWS Private Certificate Authority mode untuk Service Connect**

AWS Private Certificate Authority dapat berjalan dalam dua mode: tujuan umum dan berumur pendek.
+ Tujuan umum - Sertifikat yang dapat dikonfigurasi dengan tanggal kedaluwarsa apa pun.
+ Berumur pendek - Sertifikat dengan validitas maksimum tujuh hari.

Meskipun Amazon ECS mendukung kedua mode, kami sarankan untuk menggunakan sertifikat berumur pendek. Secara default, sertifikat berputar setiap lima hari, dan berjalan dalam mode berumur pendek menawarkan penghematan biaya yang signifikan dibandingkan tujuan umum.

Service Connect tidak mendukung pencabutan sertifikat dan sebaliknya memanfaatkan sertifikat berumur pendek dengan rotasi sertifikat yang sering. Anda memiliki wewenang untuk memodifikasi frekuensi rotasi, menonaktifkan, atau menghapus rahasia menggunakan [rotasi terkelola](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_managed.html) di [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), tetapi hal itu dapat disertai dengan konsekuensi yang mungkin berikut.
+ Frekuensi Rotasi Lebih Pendek - Frekuensi rotasi yang lebih pendek menimbulkan biaya yang lebih tinggi karena AWS Private CA, AWS KMS dan Secrets Manager, dan Auto Scaling mengalami peningkatan beban kerja untuk rotasi.
+ Frekuensi Rotasi Lebih Panjang - Komunikasi aplikasi Anda gagal jika frekuensi rotasi melebihi **tujuh hari**.
+ Penghapusan Rahasia - Menghapus rahasia menghasilkan kegagalan rotasi dan berdampak pada komunikasi aplikasi pelanggan.

Jika rotasi rahasia Anda gagal, sebuah `RotationFailed` acara dipublikasikan di [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Anda juga dapat mengatur [CloudWatchAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) untuk`RotationFailed`.

**penting**  
Jangan menambahkan replika Regions ke rahasia. Melakukannya mencegah Amazon ECS menghapus rahasia, karena Amazon ECS tidak memiliki izin untuk menghapus Wilayah dari replikasi. Jika Anda sudah menambahkan replikasi, jalankan perintah berikut.  

```
aws secretsmanager remove-regions-from-replication \
 --secret-id SecretId \
 --remove-replica-regions region-name
```

**Otoritas Sertifikat Bawahan**  
Anda dapat membawa apa saja AWS Private CA, root atau bawahan, ke Service Connect TLS untuk menerbitkan sertifikat entitas akhir untuk layanan. Penerbit yang disediakan diperlakukan sebagai penandatangan dan akar kepercayaan di mana-mana. Anda dapat menerbitkan sertifikat entitas akhir untuk berbagai bagian aplikasi Anda dari bawahan yang berbeda. CAs Saat menggunakan AWS CLI, berikan Nama Sumber Daya Amazon (ARN) CA untuk membangun rantai kepercayaan.

**Otoritas Sertifikat Lokal**  
Untuk menggunakan CA lokal, Anda membuat dan mengonfigurasi CA bawahan. AWS Private Certificate Authority Ini memastikan semua sertifikat TLS yang dikeluarkan untuk beban kerja Amazon ECS Anda berbagi rantai kepercayaan dengan beban kerja yang Anda jalankan di tempat dan dapat terhubung dengan aman.

**penting**  
Tambahkan tag **yang diperlukan** `AmazonECSManaged : true` di AWS Private CA. 

**Infrastruktur sebagai kode**  
Saat menggunakan alat Service Connect TLS dengan Infrastructure as Code (IAc), penting untuk mengonfigurasi dependensi Anda dengan benar untuk menghindari masalah, seperti layanan yang macet dalam pengurasan. AWS KMS Kunci Anda, jika disediakan, peran IAM, dan AWS Private CA dependensi harus dihapus setelah layanan Amazon ECS Anda.

Jika namespace yang digunakan untuk Service Connect adalah namespace bersama, Anda dapat memilih untuk menggunakan sumber daya bersama. AWS Private CA Untuk informasi selengkapnya, lihat [Melampirkan kebijakan untuk akses lintas akun](https://docs.aws.amazon.com/privateca/latest/userguide/pca-ram.html) di *Panduan AWS Private Certificate Authority Pengguna*.

## Service Connect dan Secrets Manager
<a name="service-connect-asm"></a>

**Saat menggunakan Amazon ECS Service Connect dengan enkripsi TLS, layanan berinteraksi dengan Secrets Manager dengan cara berikut:**  
Service Connect menggunakan peran infrastruktur yang disediakan untuk membuat rahasia dalam Secrets Manager. Rahasia ini digunakan untuk menyimpan kunci pribadi terkait untuk sertifikat TLS Anda untuk mengenkripsi lalu lintas antara layanan Service Connect Anda.

**Awas**  
Pembuatan dan pengelolaan rahasia ini secara otomatis oleh Service Connect menyederhanakan proses penerapan enkripsi TLS untuk layanan Anda. Namun, penting untuk menyadari potensi implikasi keamanan. Peran IAM lain yang memiliki akses baca ke Secrets Manager mungkin dapat mengakses rahasia yang dibuat secara otomatis ini. Ini dapat mengekspos materi kriptografi sensitif kepada pihak yang tidak berwenang, jika kontrol akses tidak dikonfigurasi dengan benar.  
Untuk mengurangi risiko ini, ikuti praktik terbaik berikut:  
Kelola dan batasi akses ke Secrets Manager dengan hati-hati, terutama untuk rahasia yang dibuat oleh Service Connect.
Secara teratur mengaudit peran IAM dan izinnya untuk memastikan prinsip hak istimewa paling sedikit dipertahankan.

Saat memberikan akses baca ke Secrets Manager, pertimbangkan untuk mengecualikan kunci pribadi TLS yang dibuat oleh Service Connect. Anda dapat melakukan ini dengan menggunakan kondisi dalam kebijakan IAM Anda untuk mengecualikan rahasia ARNs yang cocok dengan pola:

```
"arn:aws:secretsmanager:::secret:ecs-sc!"
```

Contoh kebijakan IAM yang menyangkal `GetSecretValue` tindakan untuk semua rahasia dengan awalan: `ecs-sc!`

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:*:*:secret:ecs-sc!*"
        }
    ]
}
```

------

**catatan**  
Ini adalah contoh umum dan mungkin perlu disesuaikan berdasarkan kasus penggunaan spesifik dan konfigurasi AWS akun Anda. Selalu uji kebijakan IAM Anda secara menyeluruh untuk memastikan mereka menyediakan akses yang diinginkan sambil menjaga keamanan.

Dengan memahami bagaimana Service Connect berinteraksi dengan Secrets Manager, Anda dapat mengelola keamanan layanan Amazon ECS dengan lebih baik sambil memanfaatkan manfaat enkripsi TLS otomatis.

## Service Connect dan AWS Key Management Service
<a name="service-connect-kms"></a>

Anda dapat menggunakan [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)untuk mengenkripsi dan mendekripsi sumber daya Service Connect Anda. AWS KMS adalah layanan yang dikelola oleh AWS tempat Anda dapat membuat dan mengelola kunci kriptografi yang melindungi data Anda.

Saat menggunakan AWS KMS Service Connect, Anda dapat memilih untuk menggunakan kunci AWS milik yang AWS mengelola untuk Anda, atau Anda dapat memilih AWS KMS kunci yang ada. Anda juga dapat [membuat AWS KMS kunci baru](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) untuk digunakan.

**Menyediakan kunci enkripsi Anda sendiri**  
Anda dapat menyediakan materi utama Anda sendiri, atau Anda dapat menggunakan penyimpanan kunci eksternal melalui AWS Key Management Service Impor kunci Anda sendiri AWS KMS, lalu tentukan Nama Sumber Daya Amazon (ARN) kunci tersebut di Amazon ECS Service Connect.

Berikut ini adalah contoh AWS KMS kebijakan. Ganti *user input* nilai dengan nilai Anda sendiri.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "id",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/role-name"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyPair"
      ],
      "Resource": "*"
    }
  ]
}
```

------

Untuk informasi selengkapnya tentang kebijakan utama, lihat [Membuat kebijakan kunci](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) di *Panduan AWS Key Management Service Pengembang*.

**catatan**  
Service Connect hanya mendukung AWS KMS kunci enkripsi simetris. Anda tidak dapat menggunakan jenis AWS KMS kunci lain untuk mengenkripsi sumber daya Service Connect. Untuk bantuan menentukan apakah AWS KMS kunci adalah kunci enkripsi simetris, lihat [Mengidentifikasi kunci KMS asimetris](https://docs.aws.amazon.com/kms/latest/developerguide/identify-key-types.html#identify-asymm-keys).

Untuk informasi selengkapnya tentang kunci enkripsi AWS Key Management Service simetris, lihat [AWS KMS Kunci enkripsi simetris](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks) di Panduan *AWS Key Management Service Pengembang*.

# Mengaktifkan TLS untuk Amazon ECS Service Connect
<a name="enable-service-connect-tls"></a>

Anda mengaktifkan enkripsi lalu lintas saat membuat atau memperbarui layanan Service Connect.

**Untuk mengaktifkan enkripsi lalu lintas untuk layanan di namespace yang ada menggunakan Konsol Manajemen AWS**

1. Anda harus memiliki peran IAM infrastruktur. Untuk informasi selengkapnya tentang peran ini, lihat peran [IAM infrastruktur Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     ).

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Di panel navigasi, pilih **Namespace**.

1. Pilih **Namespace** dengan **Layanan** yang ingin Anda aktifkan enkripsi lalu lintas.

1. Pilih **Layanan** yang ingin Anda aktifkan enkripsi lalu lintas.

1. Pilih **Perbarui Layanan** di sudut kanan atas dan gulir ke bawah ke bagian Service Connect.

1. Pilih **Aktifkan enkripsi lalu lintas** di bawah informasi layanan Anda untuk mengaktifkan TLS.

1. Untuk peran **Service Connect TLS, pilih peran** IAM infrastruktur yang ada atau buat yang baru.

1. Untuk **otoritas sertifikat Penandatangan**, pilih otoritas sertifikat yang ada atau buat yang baru.

   Untuk informasi lebih lanjut, lihat[AWS Private Certificate Authority sertifikat dan Service Connect](service-connect-tls.md#service-connect-tls-certificates).

1. Untuk **Pilih AWS KMS key**, pilih kunci yang AWS dimiliki dan dikelola atau Anda dapat memilih kunci yang berbeda. Anda juga dapat memilih untuk membuat yang baru.

Untuk contoh menggunakan AWS CLI untuk mengkonfigurasi TLS untuk layanan Anda,[Mengonfigurasi Amazon ECS Service Connect dengan AWS CLI](create-service-connect.md).

# Memverifikasi TLS diaktifkan untuk Amazon ECS Service Connect
<a name="verify-tls-enabled"></a>

Service Connect memulai TLS di agen Service Connect dan menghentikannya di agen tujuan. Akibatnya, kode aplikasi tidak pernah melihat interaksi TLS. Gunakan langkah-langkah berikut untuk memverifikasi bahwa TLS diaktifkan.

1. Sertakan `openssl` CLI dalam gambar aplikasi Anda.

1. Aktifkan [ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) pada layanan Anda untuk terhubung ke tugas Anda melalui SSM. Sebagai alternatif, Anda dapat meluncurkan instans Amazon EC2 di VPC Amazon yang sama dengan layanan.

1. Ambil IP dan port tugas dari layanan yang ingin Anda verifikasi. Anda dapat mengambil alamat IP tugas di AWS Cloud Map konsol. Informasi ada di halaman detail layanan untuk namespace. 

1. Masuk ke salah satu tugas Anda menggunakan `execute-command` seperti pada contoh berikut. **Sebagai alternatif, masuk ke instans Amazon EC2 yang dibuat di Langkah 2.**

   ```
   $ aws ecs execute-command --cluster cluster-name \
       --task task-id  \
       --container container-name \
       --interactive \
       --command "/bin/sh"
   ```
**catatan**  
Memanggil nama DNS secara langsung tidak mengungkapkan sertifikat.

1. Di shell yang terhubung, gunakan `openssl` CLI untuk memverifikasi dan melihat sertifikat yang dilampirkan pada tugas.

   Contoh:

   ```
   openssl s_client -connect 10.0.147.43:6379 < /dev/null 2> /dev/null \ 
   | openssl x509 -noout -text
   ```

   Contoh respons:

   ```
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number:
               <serial-number>
           Signature Algorithm: ecdsa-with-SHA256
           Issuer: <issuer>
           Validity
               Not Before: Jan 23 21:38:12 2024 GMT
               Not After : Jan 30 22:38:12 2024 GMT
           Subject: <subject>
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
                   pub:
                       <pub>
                   ASN1 OID: prime256v1
                   NIST CURVE: P-256
           X509v3 extensions:
               X509v3 Subject Alternative Name:
                   DNS:redis.yelb-cftc
               X509v3 Basic Constraints:
                   CA:FALSE
               X509v3 Authority Key Identifier:
                   keyid:<key-id>
   
               X509v3 Subject Key Identifier:
                   1D:<id>
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication, TLS Web Client Authentication
       Signature Algorithm: ecdsa-with-SHA256
           <hash>
   ```

# Mengonfigurasi Amazon ECS Service Connect dengan AWS CLI
<a name="create-service-connect"></a>

Anda dapat membuat layanan Amazon ECS untuk tugas Fargate yang menggunakan Service Connect dengan. AWS CLI

**catatan**  
Anda dapat menggunakan titik akhir layanan dual-stack untuk berinteraksi dengan Amazon ECS dari AWS CLI, SDKs dan Amazon ECS API melalui keduanya dan. IPv4 IPv6 Untuk informasi selengkapnya, lihat [Menggunakan titik akhir tumpukan ganda Amazon ECS](dual-stack-endpoint.md).

## Prasyarat
<a name="create-service-connect-prereqs"></a>

Berikut ini adalah prasyarat Service Connect:
+ Verifikasi bahwa versi terbaru diinstal dan dikonfigurasi. AWS CLI Untuk informasi selengkapnya, lihat [Menginstal atau memperbarui ke versi terbaru AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ Pengguna IAM Anda memiliki izin yang diperlukan yang ditentukan dalam contoh kebijakan [Amazonecs\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM.
+ Anda memiliki VPC, subnet, tabel rute, dan grup keamanan yang dibuat untuk digunakan. Untuk informasi selengkapnya, lihat [Buat virtual private cloud](get-set-up-for-amazon-ecs.md#create-a-vpc).
+ Anda memiliki peran eksekusi tugas dengan nama `ecsTaskExecutionRole` dan kebijakan `AmazonECSTaskExecutionRolePolicy` terkelola dilampirkan ke peran. Peran ini memungkinkan Fargate untuk menulis log aplikasi NGINX dan log proxy Service Connect ke Amazon Logs. CloudWatch Untuk informasi selengkapnya, lihat [Membuat peran eksekusi tugas](task_execution_IAM_role.md#create-task-execution-role).

## Langkah 1: Buat cluster
<a name="create-service-connect-cluster"></a>

Gunakan langkah-langkah berikut untuk membuat cluster dan namespace Amazon ECS Anda.

**Untuk membuat cluster dan namespace Amazon ECS AWS Cloud Map**

1. Buat klaster Amazon ECS bernama `tutorial` untuk digunakan. Parameter `--service-connect-defaults` menetapkan namespace default cluster. Dalam contoh output, AWS Cloud Map namespace nama `service-connect` tidak ada di akun ini dan Wilayah AWS, sehingga namespace dibuat oleh Amazon ECS. Namespace dibuat AWS Cloud Map di akun, dan terlihat dengan semua ruang nama lainnya, jadi gunakan nama yang menunjukkan tujuannya.

   ```
   aws ecs create-cluster --cluster-name tutorial --service-connect-defaults namespace=service-connect
   ```

   Output:

   ```
   {
       "cluster": {
           "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
           "clusterName": "tutorial",
           "serviceConnectDefaults": {
               "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
           },
           "status": "PROVISIONING",
           "registeredContainerInstancesCount": 0,
           "runningTasksCount": 0,
           "pendingTasksCount": 0,
           "activeServicesCount": 0,
           "statistics": [],
           "tags": [],
           "settings": [
               {
                   "name": "containerInsights",
                   "value": "disabled"
               }
           ],
           "capacityProviders": [],
           "defaultCapacityProviderStrategy": [],
           "attachments": [
               {
                   "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
                   "type": "sc",
                   "status": "ATTACHING",
                   "details": []
               }
           ],
           "attachmentsStatus": "UPDATE_IN_PROGRESS"
       }
   }
   }
   ```

1. Verifikasi bahwa cluster dibuat:

   ```
   aws ecs describe-clusters --clusters tutorial
   ```

   Output:

   ```
   {
       "clusters": [
           {
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
               "clusterName": "tutorial",
               "serviceConnectDefaults": {
                   "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
               },
               "status": "ACTIVE",
               "registeredContainerInstancesCount": 0,
               "runningTasksCount": 0,
               "pendingTasksCount": 0,
               "activeServicesCount": 0,
               "statistics": [],
               "tags": [],
               "settings": [],
               "capacityProviders": [],
               "defaultCapacityProviderStrategy": []
           }
       ],
       "failures": []
   }
   ```

1. (Opsional) Verifikasi bahwa namespace dibuat di. AWS Cloud Map Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI konfigurasi normal saat ini dibuat AWS Cloud Map.

   Misalnya, gunakan AWS CLI:

   ```
   aws servicediscovery get-namespace --id ns-EXAMPLE
   ```

   Output:

   ```
   {
       "Namespace": {
           "Id": "ns-EXAMPLE",
           "Arn": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE",
           "Name": "service-connect",
           "Type": "HTTP",
           "Properties": {
               "DnsProperties": {
                   "SOA": {}
               },
               "HttpProperties": {
                   "HttpName": "service-connect"
               }
           },
           "CreateDate": 1661749852.422,
           "CreatorRequestId": "service-connect"
       }
   }
   ```

## Langkah 2: Buat layanan untuk server
<a name="create-service-connect-nginx-server"></a>

Fitur Service Connect ditujukan untuk menghubungkan beberapa aplikasi di Amazon ECS. Setidaknya salah satu dari aplikasi tersebut perlu menyediakan layanan web untuk terhubung. Pada langkah ini, Anda membuat:
+ Definisi tugas yang menggunakan image kontainer NGINX resmi yang tidak dimodifikasi dan menyertakan konfigurasi Service Connect.
+ Definisi layanan Amazon ECS yang mengonfigurasi Service Connect untuk menyediakan penemuan layanan dan proxy mesh layanan untuk lalu lintas ke layanan ini. Konfigurasi menggunakan kembali namespace default dari konfigurasi cluster untuk mengurangi jumlah konfigurasi layanan yang Anda buat untuk setiap layanan.
+ Layanan Amazon ECS. Ini menjalankan satu tugas menggunakan definisi tugas, dan menyisipkan wadah tambahan untuk proxy Service Connect. Proxy mendengarkan port dari pemetaan port kontainer dari definisi tugas. Dalam aplikasi klien yang berjalan di Amazon ECS, proxy dalam tugas klien mendengarkan koneksi keluar ke nama port definisi tugas, nama penemuan layanan atau nama alias klien layanan, dan nomor port dari alias klien.

**Untuk membuat layanan web dengan Service Connect**

1. Daftarkan definisi tugas yang kompatibel dengan Fargate dan gunakan mode `awsvpc` jaringan. Ikuti langkah-langkah ini:

   1. Buat file yang diberi nama `service-connect-nginx.json` dengan isi definisi tugas berikut.

      Definisi tugas ini mengonfigurasi Service Connect dengan menambahkan `name` dan `appProtocol` parameter ke pemetaan port. Nama port membuat port ini lebih dapat diidentifikasi dalam konfigurasi layanan ketika beberapa port digunakan. Nama port juga digunakan secara default sebagai nama yang dapat ditemukan untuk digunakan oleh aplikasi lain di namespace.

      Definisi tugas berisi peran IAM tugas karena layanan mengaktifkan ECS Exec.
**penting**  
Definisi tugas ini menggunakan a `logConfiguration` untuk mengirim output nginx dari `stdout` dan `stderr` ke Amazon Logs. CloudWatch Peran eksekusi tugas ini tidak memiliki izin tambahan yang diperlukan untuk membuat grup CloudWatch log Log. Buat grup log di CloudWatch Log menggunakan Konsol Manajemen AWS or AWS CLI. Jika Anda tidak ingin mengirim log nginx ke Log, Anda CloudWatch dapat menghapus file. `logConfiguration`  
Ganti Akun AWS id dalam peran eksekusi tugas dengan Akun AWS id Anda.

      ```
      {
          "family": "service-connect-nginx",
          "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
          "taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole",
          "networkMode": "awsvpc",
          "containerDefinitions": [
              {
              "name": "webserver",
              "image": "public.ecr.aws/docker/library/nginx:latest",
              "cpu": 100,
              "portMappings": [
                  {
                      "name": "nginx",
                      "containerPort": 80,
                      "protocol": "tcp", 
                      "appProtocol": "http"
                  }
              ],
              "essential": true,
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-nginx",
                      "awslogs-region": "region", 
                      "awslogs-stream-prefix": "nginx"
                  }
              }
              }
          ],
          "cpu": "256",
          "memory": "512"
      }
      ```

   1. Daftarkan definisi tugas menggunakan `service-connect-nginx.json` file:

      ```
      aws ecs register-task-definition --cli-input-json file://service-connect-nginx.json
      ```

1. Buat layanan:

   1. Buat file yang diberi nama `service-connect-nginx-service.json` dengan konten layanan Amazon ECS yang Anda buat. Contoh ini menggunakan definisi tugas yang dibuat pada langkah sebelumnya. `awsvpcConfiguration` diperlukan karena ketentuan tugas contoh menggunakan mode jaringan `awsvpc`.

      Saat Anda membuat layanan ECS, tentukan Fargate, dan versi platform `LATEST` yang mendukung Service Connect. Itu `securityGroups` dan `subnets` harus milik VPC yang memiliki persyaratan untuk menggunakan Amazon ECS. Anda dapat memperoleh grup keamanan dan subnet IDs dari Konsol VPC Amazon. 

      Layanan ini mengkonfigurasi Service Connect dengan menambahkan `serviceConnectConfiguration` parameter. Namespace tidak diperlukan karena cluster memiliki namespace default yang dikonfigurasi. Aplikasi klien yang berjalan di ECS di namespace terhubung ke layanan ini dengan menggunakan `portName` dan port di. `clientAliases` Misalnya, layanan ini dapat dijangkau menggunakan`http://nginx:80/`, karena nginx menyediakan halaman selamat datang di lokasi root. `/` Aplikasi eksternal yang tidak berjalan di Amazon ECS atau tidak berada di namespace yang sama dapat mencapai aplikasi ini melalui proxy Service Connect dengan menggunakan alamat IP tugas dan nomor port dari definisi tugas. Untuk `tls` konfigurasi Anda, tambahkan sertifikat `arn` untuk peran IAM Anda `awsPcaAuthorityArn``kmsKey`, Anda, dan `roleArn` Anda.

      Layanan ini menggunakan a `logConfiguration` untuk mengirim layanan menghubungkan output proxy dari `stdout` dan `stderr` ke Amazon CloudWatch Logs. Peran eksekusi tugas ini tidak memiliki izin tambahan yang diperlukan untuk membuat grup CloudWatch log Log. Buat grup log di CloudWatch Log menggunakan Konsol Manajemen AWS or AWS CLI. Kami menyarankan Anda membuat grup log ini dan menyimpan log proxy di CloudWatch Log. Jika Anda tidak ingin mengirim log proxy ke CloudWatch Log, Anda dapat menghapus`logConfiguration`.

      ```
      {
          "cluster": "tutorial",
          "deploymentConfiguration": {
              "maximumPercent": 200,
              "minimumHealthyPercent": 0
          },
          "deploymentController": {
              "type": "ECS"
          },
          "desiredCount": 1,
          "enableECSManagedTags": true,
          "enableExecuteCommand": true,
          "launchType": "FARGATE",
          "networkConfiguration": {
              "awsvpcConfiguration": {
                  "assignPublicIp": "ENABLED",
                  "securityGroups": [
                      "sg-EXAMPLE"
                  ],
                  "subnets": [
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE"
                  ]
                 }
          },
          "platformVersion": "LATEST",
          "propagateTags": "SERVICE",
          "serviceName": "service-connect-nginx-service",
          "serviceConnectConfiguration": {
              "enabled": true,
              "services": [
                  {
                      "portName": "nginx",
                      "clientAliases": [
                          {
                              "port": 80
                          }
                      ],
                      "tls": {
                         "issuerCertificateAuthority": {
                            "awsPcaAuthorityArn": "certificateArn"
                         }, 
                         "kmsKey": "kmsKey", 
                         "roleArn": "iamRoleArn"
                      }
                  }
              ],
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-proxy",
                      "awslogs-region": "region",
                      "awslogs-stream-prefix": "service-connect-proxy"
                  }
              }
          },
          "taskDefinition": "service-connect-nginx"
      }
      ```

   1. Buat layanan menggunakan `service-connect-nginx-service.json` file:

      ```
      aws ecs create-service --cluster tutorial --cli-input-json file://service-connect-nginx-service.json
      ```

      Output:

      ```
      {
          "service": {
              "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/tutorial/service-connect-nginx-service",
              "serviceName": "service-connect-nginx-service",
              "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
              "loadBalancers": [],
              "serviceRegistries": [],
              "status": "ACTIVE",
              "desiredCount": 1,
              "runningCount": 0,
              "pendingCount": 0,
              "launchType": "FARGATE",
              "platformVersion": "LATEST",
              "platformFamily": "Linux",
              "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
              "deploymentConfiguration": {
                  "deploymentCircuitBreaker": {
                      "enable": false,
                      "rollback": false
                  },
                  "maximumPercent": 200,
                  "minimumHealthyPercent": 0
              },
              "deployments": [
                  {
                      "id": "ecs-svc/3763308422771520962",
                      "status": "PRIMARY",
                      "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
                      "desiredCount": 1,
                      "pendingCount": 0,
                      "runningCount": 0,
                      "failedTasks": 0,
                      "createdAt": 1661210032.602,
                      "updatedAt": 1661210032.602,
                      "launchType": "FARGATE",
                      "platformVersion": "1.4.0",
                      "platformFamily": "Linux",
                      "networkConfiguration": {
                          "awsvpcConfiguration": {
                              "assignPublicIp": "ENABLED",
                              "securityGroups": [
                                  "sg-EXAMPLE"
                              ],
                              "subnets": [
                                  "subnet-EXAMPLEf",
                                  "subnet-EXAMPLE",
                                  "subnet-EXAMPLE"
                              ]
                          }
                      },
                      "rolloutState": "IN_PROGRESS",
                      "rolloutStateReason": "ECS deployment ecs-svc/3763308422771520962 in progress.",
                      "failedLaunchTaskCount": 0,
                      "replacedTaskCount": 0,
                      "serviceConnectConfiguration": {
                          "enabled": true,
                          "namespace": "service-connect",
                          "services": [
                              {
                                  "portName": "nginx",
                                  "clientAliases": [
                                      {
                                          "port": 80
                                      }
                                  ]
                              }
                          ],
                          "logConfiguration": {
                              "logDriver": "awslogs",
                              "options": {
                                  "awslogs-group": "/ecs/service-connect-proxy",
                                  "awslogs-region": "us-west-2",
                                  "awslogs-stream-prefix": "service-connect-proxy"
                              },
                              "secretOptions": []
                          }
                      },
                      "serviceConnectResources": [
                          {
                              "discoveryName": "nginx",
                              "discoveryArn": "arn:aws:servicediscovery:us-west-2:123456789012:service/srv-EXAMPLE"
                          }
                      ]
                  }
              ],
              "roleArn": "arn:aws:iam::123456789012:role/aws-service-role/ecs.amazonaws.com/AWSServiceRoleForECS",
              "version": 0,
              "events": [],
              "createdAt": 1661210032.602,
              "placementConstraints": [],
              "placementStrategy": [],
              "networkConfiguration": {
                  "awsvpcConfiguration": {
                      "assignPublicIp": "ENABLED",
                      "securityGroups": [
                          "sg-EXAMPLE"
                      ],
                      "subnets": [
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE"
                      ]
                  }
              },
              "schedulingStrategy": "REPLICA",
              "enableECSManagedTags": true,
              "propagateTags": "SERVICE",
              "enableExecuteCommand": true
          }
      }
      ```

      `serviceConnectConfiguration`Yang Anda berikan muncul di dalam *penyebaran* pertama output. Saat Anda membuat perubahan pada layanan ECS dengan cara yang perlu membuat perubahan pada tugas, penerapan baru dibuat oleh Amazon ECS.

## Langkah 3: Verifikasi bahwa Anda dapat terhubung
<a name="create-service-connect-verify"></a>

Untuk memverifikasi bahwa Service Connect dikonfigurasi dan berfungsi, ikuti langkah-langkah berikut untuk menyambung ke layanan web dari aplikasi eksternal. Kemudian, lihat metrik tambahan dalam CloudWatch proxy Service Connect yang dibuat.

**Untuk terhubung ke layanan web dari aplikasi eksternal**
+ Connect ke alamat IP tugas dan port kontainer menggunakan alamat IP tugas

  Gunakan AWS CLI untuk mendapatkan ID tugas, menggunakan file`aws ecs list-tasks --cluster tutorial`.

  Jika subnet dan grup keamanan Anda mengizinkan lalu lintas dari internet publik di port dari definisi tugas, Anda dapat terhubung ke IP publik dari komputer Anda. IP publik tidak tersedia dari `describe-tasks`, jadi langkah-langkahnya melibatkan pergi ke Amazon EC2 Konsol Manajemen AWS atau AWS CLI untuk mendapatkan detail dari elastic network interface.

  Dalam contoh ini, instans Amazon EC2 di VPC yang sama menggunakan IP pribadi tugas tersebut. Aplikasi ini nginx, tetapi `server: envoy` header menunjukkan bahwa proxy Service Connect digunakan. Proxy Service Connect mendengarkan pada port kontainer dari definisi tugas.

  ```
  $ curl -v 10.0.19.50:80/
  *   Trying 10.0.19.50:80...
  * Connected to 10.0.19.50 (10.0.19.50) port 80 (#0)
  > GET / HTTP/1.1
  > Host: 10.0.19.50
  > User-Agent: curl/7.79.1
  > Accept: */*
  >
  * Mark bundle as not supporting multiuse
  < HTTP/1.1 200 OK
  < server: envoy
  < date: Tue, 23 Aug 2022 03:53:06 GMT
  < content-type: text/html
  < content-length: 612
  < last-modified: Tue, 16 Apr 2019 13:08:19 GMT
  < etag: "5cb5d3c3-264"
  < accept-ranges: bytes
  < x-envoy-upstream-service-time: 0
  <
  <!DOCTYPE html>
  <html>
  <head>
  <title>Welcome to nginx!</title>
  <style>
      body {
          width: 35em;
          margin: 0 auto;
          font-family: Tahoma, Verdana, Arial, sans-serif;
      }
  </style>
  </head>
  <body>
  <h1>Welcome to nginx!</h1>
  <p>If you see this page, the nginx web server is successfully installed and
  working. Further configuration is required.</p>
  
  <p>For online documentation and support please refer to
  <a href="http://nginx.org/">nginx.org</a>.<br/>
  Commercial support is available at
  <a href="http://nginx.com/">nginx.com</a>.</p>
  
  <p><em>Thank you for using nginx.</em></p>
  </body>
  </html>
  ```

**Untuk melihat metrik Service Connect**  
Proxy Service Connect membuat metrik aplikasi (HTTP, HTTP2, gRPC, atau koneksi TCP) dalam metrik. CloudWatch Saat Anda menggunakan CloudWatch konsol, lihat dimensi metrik tambahan **DiscoveryName**, (DiscoveryName,, ClusterName) ** ServiceName,** dan (**TargetDiscoveryName**, **TargetDiscoveryName ServiceName, ClusterName**) di bawah namespace Amazon ECS. Untuk informasi selengkapnya tentang metrik dan dimensi ini, lihat [Melihat Metrik yang Tersedia](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html) di Panduan Pengguna CloudWatch Log Amazon.

# Gunakan penemuan layanan untuk menghubungkan layanan Amazon ECS dengan nama DNS
<a name="service-discovery"></a>

Layanan Amazon ECS Anda secara opsional dapat dikonfigurasi untuk menggunakan penemuan layanan Amazon ECS. Penemuan layanan menggunakan tindakan AWS Cloud Map API untuk mengelola ruang nama HTTP dan DNS untuk layanan Amazon ECS Anda. Untuk informasi selengkapnya, lihat [Apa yang AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html) Ada di *Panduan AWS Cloud Map Pengembang*.

Penemuan layanan tersedia di AWS Wilayah berikut:


| Nama Wilayah | Region | 
| --- | --- | 
|  AS Timur (Virginia Utara)  |  us-east-1  | 
|  US East (Ohio)  |  us-east-2  | 
|  AS Barat (California Utara)  |  us-west-1  | 
|  US West (Oregon)  |  as-barat-2  | 
|  Afrika (Cape Town)  |  af-selatan-1  | 
|  Asia Pasifik (Hong Kong)  |  ap-east-1  | 
|  Asia Pasifik (Taipei)  |  ap-timur-2  | 
|  Asia Pasifik (Mumbai)  |  ap-south-1  | 
|  Asia Pasifik (Hyderabad)  |  ap-south-2  | 
|  Asia Pasifik (Tokyo)  |  ap-northeast-1  | 
|  Asia Pasifik (Seoul)  |  ap-northeast-2  | 
|  Asia Pacific (Osaka)  |  ap-northeast-3  | 
|  Asia Pasifik (Singapura)  |  ap-southeast-1  | 
|  Asia Pacific (Sydney)  |  ap-southeast-2  | 
|  Asia Pasifik (Jakarta)  |  ap-southeast-3  | 
|  Asia Pacific (Melbourne)  |  ap-southeast-4  | 
|  Asia Pasifik (Malaysia)  |  ap-southeast-5  | 
|  Asia Pasifik (Selandia Baru)  |  ap-tenggara 6  | 
|  Asia Pasifik (Thailand)  |  ap-tenggara 7  | 
|  Kanada (Pusat)  |  ca-central-1  | 
|  Kanada Barat (Calgary)  |  ca-west-1  | 
|  Tiongkok (Beijing)  |  cn-north-1  | 
|  China (Ningxia)  |  cn-northwest-1  | 
|  Europe (Frankfurt)  |  eu-central-1  | 
|  Europe (Zurich)  |  eu-central-2  | 
|  Eropa (Irlandia)  |  eu-west-1  | 
|  Europe (London)  |  eu-west-2  | 
|  Europe (Paris)  |  eu-west-3  | 
|  Europe (Milan)  |  eu-south-1  | 
|  Eropa (Stockholm)  |  eu-north-1  | 
|  Israel (Tel Aviv)  |  il-central-1  | 
|  Eropa (Spanyol)  |  eu-south-2  | 
|  Timur Tengah (UAE)  |  me-central-1  | 
|  Meksiko (Tengah)  |  mx-pusat-1  | 
|  Timur Tengah (Bahrain)  |  me-selatan-1  | 
|  Amerika Selatan (São Paulo)  |  sa-east-1  | 
|  AWS GovCloud (AS-Timur)  |  us-gov-east-1  | 
|  AWS GovCloud (AS-Barat)  |  us-gov-west-1  | 

## Konsep Penemuan Layanan
<a name="service-discovery-concepts"></a>

Penemuan layanan terdiri dari komponen-komponen berikut:
+ **Ruang nama penemuan layanan**: Grup logis layanan penemuan layanan yang berbagi nama domain yang sama, seperti`example.com`, tempat Anda ingin merutekan lalu lintas. Anda dapat membuat namespace dengan panggilan ke `aws servicediscovery create-private-dns-namespace` perintah atau di konsol Amazon ECS. Anda dapat menggunakan `aws servicediscovery list-namespaces` perintah untuk melihat informasi ringkasan tentang ruang nama yang dibuat oleh akun saat ini. Untuk informasi selengkapnya tentang perintah penemuan layanan, lihat `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)` dan `[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)` di *Panduan AWS CLI Referensi AWS Cloud Map (penemuan layanan)*.
+ **Layanan penemuan layanan**: Ada dalam namespace penemuan layanan dan terdiri dari nama layanan dan konfigurasi DNS untuk namespace. Layanan tersebut menyediakan komponen inti berikut:
  + **Registri layanan**: Memungkinkan Anda mencari layanan melalui tindakan DNS atau AWS Cloud Map API dan mendapatkan kembali satu atau lebih titik akhir yang tersedia yang dapat digunakan untuk terhubung ke layanan.
+ **Contoh penemuan layanan**: Ada dalam layanan penemuan layanan dan terdiri dari atribut yang terkait dengan setiap layanan Amazon ECS di direktori layanan.
  + **Atribut instans**: Metadata berikut ditambahkan sebagai atribut khusus untuk setiap layanan Amazon ECS yang dikonfigurasi untuk menggunakan penemuan layanan:
    + **`AWS_INSTANCE_IPV4`**— Sebagai `A` catatan, IPv4 alamat yang dikembalikan Route 53 sebagai respons terhadap kueri DNS dan ditampilkan AWS Cloud Map saat menemukan detail instance, misalnya,. `192.0.2.44`
    + **`AWS_INSTANCE_IPV6`**— Sebagai `AAAA` catatan, IPv6 alamat yang dikembalikan Route 53 sebagai respons terhadap kueri DNS dan ditampilkan AWS Cloud Map saat menemukan detail instance, misalnya,. ` 2001:0db8:85a3:0000:0000:abcd:0001:2345` Keduanya `AWS_INSTANCE_IPv4` dan `AWS_INSTANCE_IPv6` ditambahkan untuk layanan dualstack Amazon ECS. Hanya `AWS_INSTANCE_IPv6` ditambahkan untuk layanan khusus Amazon IPv6 ECS.
    + **`AWS_INSTANCE_PORT`**— Nilai port yang terkait dengan layanan penemuan layanan.
    + **`AVAILABILITY_ZONE`**— Zona Ketersediaan tempat tugas diluncurkan. Untuk tugas yang menggunakan EC2, ini adalah Availability Zone di mana instance container ada. Untuk tugas yang menggunakan Fargate, ini adalah Availability Zone di mana elastic network interface ada.
    + **`REGION`**— Wilayah di mana tugas itu ada.
    + **`ECS_SERVICE_NAME`**— Nama layanan Amazon ECS tempat tugas tersebut berada.
    + **`ECS_CLUSTER_NAME`**— Nama cluster Amazon ECS tempat tugas tersebut berada.
    + **`EC2_INSTANCE_ID`**— ID dari instance kontainer tempat tugas ditempatkan. Atribut kustom ini tidak ditambahkan jika tugas menggunakan Fargate.
    + **`ECS_TASK_DEFINITION_FAMILY`**— Keluarga definisi tugas yang digunakan tugas.
    + **`ECS_TASK_SET_EXTERNAL_ID`**— Jika set tugas dibuat untuk penyebaran eksternal dan dikaitkan dengan registri penemuan layanan, maka `ECS_TASK_SET_EXTERNAL_ID` atribut akan berisi ID eksternal dari set tugas.
+ **Pemeriksaan kesehatan Amazon ECS: Amazon ECS melakukan pemeriksaan kesehatan** tingkat kontainer berkala. Jika titik akhir tidak lulus pemeriksaan kondisi, maka titik akhir akan dihapus dari perutean DNS dan ditandai dengan kondisi tidak baik.

## Pertimbangan penemuan layanan
<a name="service-discovery-considerations"></a>

Berikut ini harus dipertimbangkan saat menggunakan penemuan layanan:
+ Penemuan layanan didukung untuk tugas di Fargate yang menggunakan platform versi 1.1.0 atau yang lebih baru. Untuk informasi selengkapnya, lihat [Versi platform Fargate untuk Amazon ECS](platform-fargate.md).
+ Layanan yang dikonfigurasi untuk menggunakan penemuan layanan memiliki batas 1.000 tugas per layanan. Hal ini dikarenakan kuota layanan Route 53.
+ Alur kerja Create Service di konsol Amazon ECS hanya mendukung pendaftaran layanan ke ruang nama DNS pribadi. Ketika namespace DNS AWS Cloud Map pribadi dibuat, zona host pribadi Route 53 akan dibuat secara otomatis.
+ Atribut DNS VPC harus dikonfigurasi agar resolusi DNS berhasil. Untuk informasi tentang cara mengonfigurasi atribut, lihat [Dukungan DNS di VPC Anda di](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support) Panduan Pengguna *Amazon VPC*.
+ Amazon ECS tidak mendukung pendaftaran layanan ke ruang AWS Cloud Map nama bersama.
+ Catatan DNS yang dibuat untuk layanan penemuan layanan selalu mendaftar dengan alamat IP pribadi untuk tugas tersebut, bukan alamat IP publik, bahkan ketika ruang nama publik digunakan.
+ Penemuan layanan mengharuskan tugas menentukan mode `awsvpc``bridge`,, atau `host` jaringan (`none`tidak didukung).
+ Jika definisi tugas layanan menggunakan mode `awsvpc` jaringan, Anda dapat membuat kombinasi `A` atau `SRV` catatan apa pun untuk setiap tugas layanan. Jika Anda menggunakan `SRV` catatan, port diperlukan. Anda juga dapat membuat `AAAA` catatan jika layanan menggunakan subnet dualstack. Jika layanan menggunakan subnet IPv6 -only, Anda tidak dapat membuat `A` catatan.
+ Jika definisi tugas layanan menggunakan mode `host` jaringan `bridge` atau, catatan SRV adalah satu-satunya jenis catatan DNS yang didukung. Buat catatan SRV untuk setiap tugas layanan. Catatan SRV harus menentukan kombinasi nama kontainer dan port kontainer dari penentuan tugas.
+ Catatan DNS untuk layanan penemuan layanan dapat ditanyakan dalam VPC Anda. Mereka menggunakan format berikut: `<service-discovery-service-name>.<service-discovery-namespace>`.
+ Saat melakukan kueri DNS pada nama layanan, `A` dan `AAAA` catatan mengembalikan satu set alamat IP yang sesuai dengan tugas Anda. `SRV`catatan mengembalikan satu set alamat IP dan port untuk setiap tugas.
+ Jika Anda memiliki delapan atau kurang catatan sehat, Route 53 merespons semua kueri DNS dengan semua catatan sehat.
+ Saat semua catatan tidak sehat, Route 53 akan merespons kueri DNS dengan hingga delapan catatan yang tidak sehat.
+ Anda dapat mengonfigurasi penemuan layanan untuk layanan yang berada di belakang penyeimbang beban, tetapi lalu lintas penemuan layanan selalu diarahkan ke tugas dan bukan penyeimbang beban.
+ Penemuan layanan tidak mendukung penggunaan Classic Load Balancer.
+ Kami menyarankan Anda menggunakan pemeriksaan kesehatan tingkat kontainer yang dikelola oleh Amazon ECS untuk layanan penemuan layanan Anda.
  + **HealthCheckCustomConfig**Amazon ECS mengelola pemeriksaan kesehatan atas nama Anda. Amazon ECS menggunakan informasi dari wadah dan pemeriksaan kesehatan, dan status tugas Anda, untuk memperbarui kesehatan. AWS Cloud Map Ini ditentukan menggunakan `--health-check-custom-config` parameter saat membuat layanan penemuan layanan Anda. Untuk informasi selengkapnya, lihat [HealthCheckCustomConfig](https://docs.aws.amazon.com/cloud-map/latest/api/API_HealthCheckCustomConfig.html) di dalam *Referensi API AWS Cloud Map *. 
+ Sumber AWS Cloud Map daya yang dibuat saat penemuan layanan digunakan harus dibersihkan secara manual.
+ Tugas dan instance didaftarkan `UNHEALTHY` sampai pemeriksaan kesehatan kontainer mengembalikan nilai. Jika pemeriksaan kesehatan lulus, status diperbarui ke`HEALTHY`. Jika pemeriksaan kesehatan kontainer gagal, instance penemuan layanan dideregistrasi.

## Harga penemuan layanan
<a name="service-discovery-pricing"></a>

Pelanggan yang menggunakan penemuan layanan Amazon ECS dikenakan biaya untuk sumber daya Route 53 dan operasi API AWS Cloud Map penemuan. Ini melibatkan biaya untuk membuat zona yang dihosting Route 53 dan kueri ke registri layanan. Untuk informasi selengkapnya, lihat [AWS Cloud Map Harga](https://docs.aws.amazon.com/cloud-map/latest/dg/cloud-map-pricing.html) di *Panduan AWS Cloud Map Pengembang*.

Amazon ECS melakukan pemeriksaan kesehatan tingkat kontainer dan memaparkannya ke operasi API pemeriksaan kesehatan AWS Cloud Map khusus. Layanan tersebut saat ini tersedia untuk pelanggan tanpa biaya tambahan. Jika Anda mengonfigurasi pemeriksaan kesehatan jaringan tambahan untuk tugas yang terpapar publik, Anda dikenakan biaya untuk pemeriksaan kesehatan tersebut.

# Membuat layanan Amazon ECS yang menggunakan Service Discovery
<a name="create-service-discovery"></a>

Pelajari cara membuat layanan yang berisi tugas Fargate yang menggunakan penemuan layanan dengan. AWS CLI

Untuk daftar penemuan layanan dukungan Wilayah AWS tersebut, lihat[Gunakan penemuan layanan untuk menghubungkan layanan Amazon ECS dengan nama DNS](service-discovery.md).

Untuk informasi tentang Daerah yang mendukung Fargate, lihat. [Wilayah yang Didukung untuk Amazon ECS di Fargate AWS](AWS_Fargate-Regions.md)

**catatan**  
Anda dapat menggunakan titik akhir layanan dual-stack untuk berinteraksi dengan Amazon ECS dari AWS CLI, SDKs dan Amazon ECS API melalui keduanya dan. IPv4 IPv6 Untuk informasi selengkapnya, lihat [Menggunakan titik akhir tumpukan ganda Amazon ECS](dual-stack-endpoint.md).

## Prasyarat
<a name="create-service-discovery-prereqs"></a>

Sebelum Anda memulai tutorial ini, pastikan bahwa prasyarat berikut terpenuhi:
+ Versi terbaru diinstal dan dikonfigurasi. AWS CLI Untuk informasi selengkapnya, lihat [Menginstal atau memperbarui ke versi terbaru AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ Langkah-langkah yang dijelaskan di dalamnya [Siapkan untuk menggunakan Amazon ECS](get-set-up-for-amazon-ecs.md) sudah lengkap.
+ Pengguna IAM Anda memiliki izin yang diperlukan yang ditentukan dalam contoh kebijakan [Amazonecs\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM.
+ Anda telah membuat setidaknya satu VPC dan satu grup keamanan. Untuk informasi selengkapnya, lihat [Buat virtual private cloud](get-set-up-for-amazon-ecs.md#create-a-vpc).

## Langkah 1: Buat sumber daya Penemuan Layanan di AWS Cloud Map
<a name="create-service-discovery-namespace"></a>

Ikuti langkah-langkah berikut untuk membuat namespace penemuan layanan dan layanan penemuan layanan Anda:

1. Buat namespace penemuan layanan Cloud Map pribadi. Contoh ini menciptakan namespace yang disebut. `tutorial` Ganti *vpc-abcd1234* dengan ID salah satu yang sudah ada VPCs. 

   ```
   aws servicediscovery create-private-dns-namespace \
         --name tutorial \
         --vpc vpc-abcd1234
   ```

   Output dari perintah ini adalah sebagai berikut.

   ```
   {
       "OperationId": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e"
   }
   ```

1. Menggunakan `OperationId` dari output dari langkah sebelumnya, verifikasi bahwa namespace pribadi berhasil dibuat. Catat ID namespace karena Anda menggunakannya dalam perintah berikutnya.

   ```
   aws servicediscovery get-operation \
         --operation-id h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e
   ```

   Outputnya adalah sebagai berikut.

   ```
   {
       "Operation": {
           "Id": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e",
           "Type": "CREATE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1519777852.502,
           "UpdateDate": 1519777856.086,
           "Targets": {
              "NAMESPACE": "ns-uejictsjen2i4eeg"
           }
       }
   }
   ```

1. Menggunakan `NAMESPACE` ID dari output dari langkah sebelumnya, buat layanan penemuan layanan. Contoh ini menciptakan layanan bernama`myapplication`. Catat ID layanan dan ARN karena Anda menggunakannya dalam perintah berikutnya.

   ```
   aws servicediscovery create-service \
         --name myapplication \
         --dns-config "NamespaceId="ns-uejictsjen2i4eeg",DnsRecords=[{Type="A",TTL="300"}]" \
         --health-check-custom-config FailureThreshold=1
   ```

   Outputnya adalah sebagai berikut.

   ```
   {
       "Service": {
          "Id": "srv-utcrh6wavdkggqtk",
           "Arn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk",
           "Name": "myapplication",
           "DnsConfig": {
               "NamespaceId": "ns-uejictsjen2i4eeg",
               "DnsRecords": [
                   {
                       "Type": "A",
                       "TTL": 300
                   }
               ]
           },
           "HealthCheckCustomConfig": {
               "FailureThreshold": 1
           },
           "CreatorRequestId": "e49a8797-b735-481b-a657-b74d1d6734eb"
       }
   }
   ```

## Langkah 2: Buat sumber daya Amazon ECS
<a name="create-service-discovery-cluster"></a>

Ikuti langkah-langkah berikut untuk membuat klaster Amazon ECS, definisi tugas, dan layanan:

1. Buat cluster Amazon ECS. Contoh ini menciptakan sebuah cluster yang diberi nama`tutorial`. 

   ```
   aws ecs create-cluster \
         --cluster-name tutorial
   ```

1. Daftarkan definisi tugas yang kompatibel dengan Fargate dan gunakan mode `awsvpc` jaringan. Ikuti langkah-langkah ini:

   1. Buat file yang diberi nama `fargate-task.json` dengan isi definisi tugas berikut.

      ```
      {
          "family": "tutorial-task-def",
              "networkMode": "awsvpc",
              "containerDefinitions": [
                  {
                      "name": "sample-app",
                      "image": "public.ecr.aws/docker/library/httpd:2.4",
                      "portMappings": [
                          {
                              "containerPort": 80,
                              "hostPort": 80,
                              "protocol": "tcp"
                          }
                      ],
                      "essential": true,
                      "entryPoint": [
                          "sh",
                          "-c"
                      ],
                      "command": [
                          "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
                      ]
                  }
              ],
              "requiresCompatibilities": [
                  "FARGATE"
              ],
              "cpu": "256",
              "memory": "512"
      }
      ```

   1. Daftarkan definisi tugas menggunakan`fargate-task.json`.

      ```
      aws ecs register-task-definition \
            --cli-input-json file://fargate-task.json
      ```

1. Buat layanan ECS dengan mengikuti langkah-langkah berikut:

   1. Buat file yang diberi nama `ecs-service-discovery.json` dengan konten layanan ECS yang Anda buat. Contoh ini menggunakan definisi tugas yang dibuat pada langkah sebelumnya. `awsvpcConfiguration` diperlukan karena ketentuan tugas contoh menggunakan mode jaringan `awsvpc`. 

      Saat Anda membuat layanan ECS, tentukan Fargate dan versi platform `LATEST` yang mendukung penemuan layanan. Ketika layanan penemuan layanan dibuat di AWS Cloud Map , `registryArn` adalah ARN dikembalikan. Itu `securityGroups` dan `subnets` harus milik VPC yang digunakan untuk membuat namespace Cloud Map. Anda dapat memperoleh grup keamanan dan subnet IDs dari Konsol VPC Amazon.

      ```
      {
          "cluster": "tutorial",
          "serviceName": "ecs-service-discovery",
          "taskDefinition": "tutorial-task-def",
          "serviceRegistries": [
             {
                "registryArn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk"
             }
          ],
          "launchType": "FARGATE",
          "platformVersion": "LATEST",
          "networkConfiguration": {
             "awsvpcConfiguration": {
                "assignPublicIp": "ENABLED",
                "securityGroups": [ "sg-abcd1234" ],
                "subnets": [ "subnet-abcd1234" ]
             }
          },
          "desiredCount": 1
      }
      ```

   1. Buat layanan ECS Anda menggunakan`ecs-service-discovery.json`.

      ```
      aws ecs create-service \
            --cli-input-json file://ecs-service-discovery.json
      ```

## Langkah 3: Verifikasi Penemuan Layanan di AWS Cloud Map
<a name="create-service-discovery-verify"></a>

Anda dapat memverifikasi bahwa semuanya dibuat dengan benar dengan menanyakan informasi penemuan layanan Anda. Setelah penemuan layanan dikonfigurasi, Anda dapat menggunakan operasi AWS Cloud Map API, atau menelepon `dig` dari instance dalam VPC Anda. Ikuti langkah-langkah ini:

1. Dengan menggunakan ID layanan penemuan layanan, cantumkan instance penemuan layanan. Catat ID instance (ditandai dengan huruf tebal) untuk pembersihan sumber daya. 

   ```
    aws servicediscovery list-instances \
          --service-id srv-utcrh6wavdkggqtk
   ```

   Outputnya adalah sebagai berikut.

   ```
   {
       "Instances": [
           {
               "Id": "16becc26-8558-4af1-9fbd-f81be062a266",
               "Attributes": {
                   "AWS_INSTANCE_IPV4": "172.31.87.2"
                   "AWS_INSTANCE_PORT": "80", 
                   "AVAILABILITY_ZONE": "us-east-1a", 
                   "REGION": "us-east-1", 
                   "ECS_SERVICE_NAME": "ecs-service-discovery", 
                   "ECS_CLUSTER_NAME": "tutorial", 
                   "ECS_TASK_DEFINITION_FAMILY": "tutorial-task-def"
               }
           }
       ]
   }
   ```

1. Gunakan namespace penemuan layanan, layanan, dan parameter tambahan seperti nama cluster ECS untuk menanyakan detail tentang instance penemuan layanan.

   ```
   aws servicediscovery discover-instances \
         --namespace-name tutorial \
         --service-name myapplication \
         --query-parameters ECS_CLUSTER_NAME=tutorial
   ```

1. Catatan DNS yang dibuat di zona host Route 53 untuk layanan penemuan layanan dapat ditanyakan dengan perintah berikut: AWS CLI 

   1. Menggunakan ID namespace, dapatkan informasi tentang namespace, yang mencakup ID zona yang dihosting Route 53.

      ```
      aws servicediscovery \
            get-namespace --id ns-uejictsjen2i4eeg
      ```

      Outputnya adalah sebagai berikut.

      ```
      {
          "Namespace": {
              "Id": "ns-uejictsjen2i4eeg",
              "Arn": "arn:aws:servicediscovery:region:aws_account_id:namespace/ns-uejictsjen2i4eeg",
              "Name": "tutorial",
              "Type": "DNS_PRIVATE",
              "Properties": {
                   "DnsProperties": {
                      "HostedZoneId": "Z35JQ4ZFDRYPLV"
                  }
              },
              "CreateDate": 1519777852.502,
              "CreatorRequestId": "9049a1d5-25e4-4115-8625-96dbda9a6093"
          }
      }
      ```

   1. Menggunakan ID zona yang dihosting Route 53 dari langkah sebelumnya (lihat teks dalam huruf tebal), dapatkan catatan sumber daya yang ditetapkan untuk zona yang dihosting. 

      ```
      aws route53 list-resource-record-sets \
            --hosted-zone-id Z35JQ4ZFDRYPLV
      ```

1. Anda juga dapat menanyakan DNS dari instance dalam `dig` VPC Anda menggunakan.

   ```
   dig +short myapplication.tutorial
   ```

## Langkah 4: Membersihkan
<a name="create-service-discovery-cleanup"></a>

Setelah selesai dengan tutorial ini, bersihkan sumber daya terkait untuk menghindari biaya untuk sumber daya yang tidak digunakan. Ikuti langkah-langkah ini:

1. Batalkan pendaftaran instance layanan penemuan layanan menggunakan ID layanan dan ID instans yang Anda catat sebelumnya.

   ```
   aws servicediscovery deregister-instance \
         --service-id srv-utcrh6wavdkggqtk \
         --instance-id 16becc26-8558-4af1-9fbd-f81be062a266
   ```

   Outputnya adalah sebagai berikut.

   ```
   {
       "OperationId": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv"
   }
   ```

1. Menggunakan `OperationId` dari output dari langkah sebelumnya, verifikasi bahwa instance layanan penemuan layanan berhasil dideregistrasi.

   ```
   aws servicediscovery get-operation \ 
         --operation-id xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv
   ```

   ```
   {
     "Operation": {
           "Id": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv",
           "Type": "DEREGISTER_INSTANCE",
           "Status": "SUCCESS",
           "CreateDate": 1525984073.707,
           "UpdateDate": 1525984076.426,
           "Targets": {
               "INSTANCE": "16becc26-8558-4af1-9fbd-f81be062a266",
               "ROUTE_53_CHANGE_ID": "C5NSRG1J4I1FH",
               "SERVICE": "srv-utcrh6wavdkggqtk"
           }
       }
   }
   ```

1. Hapus layanan penemuan layanan menggunakan ID layanan.

   ```
   aws servicediscovery delete-service \ 
         --id srv-utcrh6wavdkggqtk
   ```

1. Hapus namespace penemuan layanan menggunakan ID namespace.

   ```
   aws servicediscovery delete-namespace \ 
         --id ns-uejictsjen2i4eeg
   ```

   Outputnya adalah sebagai berikut.

   ```
   {
       "OperationId": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj"
   }
   ```

1. Menggunakan `OperationId` dari output dari langkah sebelumnya, verifikasi bahwa namespace penemuan layanan berhasil dihapus.

   ```
   aws servicediscovery get-operation \ 
         --operation-id c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj
   ```

   Outputnya adalah sebagai berikut.

   ```
   {
       "Operation": {
           "Id": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj",
           "Type": "DELETE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1525984602.211,
           "UpdateDate": 1525984602.558,
           "Targets": {
               "NAMESPACE": "ns-rymlehshst7hhukh",
               "ROUTE_53_CHANGE_ID": "CJP2A2M86XW3O"
           }
       }
   }
   ```

1. Perbarui hitungan yang diinginkan untuk layanan Amazon ECS ke`0`. Anda harus melakukan ini untuk menghapus layanan di langkah berikutnya.

   ```
   aws ecs update-service \
         --cluster tutorial \
         --service ecs-service-discovery \
         --desired-count 0
   ```

1. Hapus layanan Amazon ECS.

   ```
   aws ecs delete-service \
         --cluster tutorial \
         --service ecs-service-discovery
   ```

1. Hapus cluster Amazon ECS.

   ```
   aws ecs delete-cluster \
         --cluster tutorial
   ```

# Gunakan Amazon VPC Lattice untuk menghubungkan, mengamati, dan mengamankan layanan Amazon ECS Anda
<a name="ecs-vpc-lattice"></a>

Amazon VPC Lattice adalah layanan jaringan aplikasi yang dikelola sepenuhnya yang memungkinkan pelanggan Amazon ECS untuk mengamati, mengamankan, dan memantau aplikasi yang dibangun di seluruh layanan AWS komputasi, VPCs, dan akun — tanpa memerlukan perubahan kode apa pun.

VPC Lattice menggunakan kelompok target, yang merupakan kumpulan sumber daya komputasi. Target ini menjalankan aplikasi atau layanan Anda dan dapat berupa instans Amazon EC2, alamat IP, fungsi Lambda, dan Application Load Balancer. Dengan mengaitkan layanan Amazon ECS mereka dengan grup target VPC Lattice, pelanggan sekarang dapat mengaktifkan tugas Amazon ECS sebagai target IP di VPC Lattice. Amazon ECS secara otomatis mendaftarkan tugas ke grup target VPC Lattice saat tugas untuk layanan terdaftar diluncurkan.

**catatan**  
Saat menggunakan lima konfigurasi VPC Lattice, waktu penerapan Anda mungkin sedikit lebih lama daripada saat menggunakan konfigurasi yang lebih sedikit.

Aturan pendengar digunakan untuk meneruskan lalu lintas ke grup target tertentu saat kondisi terpenuhi. Pendengar memeriksa permintaan koneksi menggunakan protokol pada port yang Anda konfigurasikan. Layanan merutekan permintaan ke target terdaftar berdasarkan aturan yang Anda tentukan saat mengonfigurasi listener Anda.

Amazon ECS juga secara otomatis menggantikan tugas jika menjadi tidak sehat menurut pemeriksaan kesehatan VPC Lattice. Setelah dikaitkan dengan VPC Lattice, pelanggan Amazon ECS juga dapat memanfaatkan banyak fitur konektivitas, keamanan, dan observabilitas lintas komputasi lainnya di VPC Lattice seperti menghubungkan ke layanan di seluruh cluster,, dan akun dengan, integrasi IAM untuk otorisasi dan otentikasi VPCs, dan fitur manajemen AWS Resource Access Manager lalu lintas lanjutan.

Pelanggan Amazon ECS dapat memanfaatkan VPC Lattice dengan cara berikut.
+ Peningkatan produktivitas pengembang - VPC Lattice meningkatkan produktivitas pengembang dengan membiarkan Anda fokus pada membangun fitur, sementara VPC Lattice menangani tantangan jaringan, keamanan, dan pengamatan secara seragam di semua platform komputasi.
+ Postur keamanan yang lebih baik - VPC Lattice memungkinkan pengembang Anda untuk dengan mudah mengautentikasi dan mengamankan komunikasi di seluruh aplikasi dan platform komputasi, menegakkan enkripsi dalam perjalanan, dan menerapkan kontrol akses granular dengan kebijakan VPC Lattice Auth. Ini memungkinkan Anda untuk mengadopsi postur keamanan yang lebih kuat yang memenuhi persyaratan peraturan dan kepatuhan terkemuka di industri.
+ Peningkatan skalabilitas dan ketahanan aplikasi - VPC Lattice memungkinkan Anda membuat jaringan aplikasi yang digunakan dengan fitur seperti path, header, dan routing berbasis metode, otentikasi, otorisasi, dan pemantauan. Manfaat ini diberikan tanpa overhead sumber daya pada beban kerja dan dapat mendukung penerapan multi-cluster yang menghasilkan jutaan permintaan per detik tanpa menambahkan latensi yang signifikan.
+ Fleksibilitas penerapan dengan infrastruktur heterogen - VPC Lattice menyediakan fitur yang konsisten di semua layanan komputasi seperti Amazon ECS, Fargate, Amazon EC2, Amazon EKS, dan Lambda dan memungkinkan organisasi Anda fleksibilitas untuk memilih infrastruktur yang sesuai untuk setiap aplikasi.

## Bagaimana VPC Lattice bekerja dengan layanan Amazon ECS lainnya
<a name="ecs-lattice-compatibility"></a>

Menggunakan VPC Lattice dengan Amazon ECS dapat mengubah cara Anda menggunakan layanan Amazon ECS lainnya, sementara yang lain tetap sama.

**Application Load Balancer**  
Anda tidak perlu lagi membuat Application Load Balancer tertentu untuk digunakan dengan tipe grup target Application Load Balancer di VPC Lattice yang kemudian ditautkan ke layanan Amazon ECS. Anda hanya perlu mengonfigurasi layanan Amazon ECS Anda dengan grup target VPC Lattice sebagai gantinya. Anda juga dapat memilih untuk menggunakan Application Load Balancer dengan Amazon ECS secara bersamaan.

**Penerapan bergulir Amazon ECS**  
Hanya penerapan bergulir Amazon ECS yang berfungsi dengan VPC Lattice, dan Amazon ECS dengan aman membawa tugas ke dalam dan menghapusnya dari layanan selama penerapan. Blue/Green Penyebaran dan penerapan kode tidak didukung.

Untuk mempelajari selengkapnya tentang VPC Lattice, lihat Panduan Pengguna Amazon [VPC](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) Lattice.

# Buat layanan yang menggunakan VPC Lattice
<a name="ecs-vpc-lattice-create-service"></a>

Anda dapat menggunakan salah satu Konsol Manajemen AWS atau AWS CLI untuk membuat layanan dengan VPC Lattice.

## Prasyarat
<a name="create-ecs-vpc-lattice-prereqs"></a>

Sebelum Anda memulai tutorial ini, pastikan bahwa prasyarat berikut terpenuhi:
+ Versi terbaru diinstal dan dikonfigurasi. AWS CLI Untuk informasi selengkapnya, silakan lihat [ Menginstal AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html).
**catatan**  
Anda dapat menggunakan titik akhir layanan dual-stack untuk berinteraksi dengan Amazon ECS dari AWS CLI, SDKs dan Amazon ECS API melalui keduanya dan. IPv4 IPv6 Untuk informasi selengkapnya, lihat [Menggunakan titik akhir tumpukan ganda Amazon ECS](dual-stack-endpoint.md).
+ Langkah-langkah yang dijelaskan di dalamnya [Siapkan untuk menggunakan Amazon ECS](get-set-up-for-amazon-ecs.md) sudah lengkap.
+ Pengguna IAM Anda memiliki izin yang diperlukan yang ditentukan dalam contoh kebijakan [Amazonecs\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM.

## Buat layanan yang menggunakan VPC Lattice dengan Konsol Manajemen AWS
<a name="ecs-lattice-create-console"></a>

Ikuti langkah-langkah ini untuk membuat layanan dengan VPC Lattice menggunakan. Konsol Manajemen AWS

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Di halaman navigasi, pilih **Cluster**.

1. Pada halaman **Clusters**, pilih cluster untuk membuat layanan di.

1. Dari tab **Layanan**, pilih **Buat**.

   Jika Anda belum pernah membuat layanan sebelumnya, ikuti langkah-langkah yang ditemukan di [Membuat layanan Amazon ECS menggunakan konsol](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html), lalu lanjutkan dengan langkah-langkah ini saat Anda mencapai bagian Kisi VPC.

1. Pilih untuk **Menghidupkan Kisi VPC** dengan mencentang tombol.

1. Untuk menggunakan peran yang ada, untuk **peran infrastruktur ECS untuk Amazon ECS**, pilih salah satu yang telah Anda buat untuk digunakan saat membuat grup target VPC Lattice. Untuk membuat peran baru, **Buat peran infrastruktur ECS**.

1. Pilih **VPC**.

   **VPC** tergantung pada mode jaringan yang Anda pilih saat Anda mendaftarkan definisi tugas Anda. Jika Anda menggunakan `network` mode `host` or dengan EC2, pilih VPC Anda. 

   Untuk `awsvpc` mode, VPC dipilih secara otomatis berdasarkan VPC yang Anda pilih di bawah **Jaringan** dan tidak dapat diubah.

1. Di bawah **Grup Target** pilih grup target atau grup. Anda harus memilih setidaknya satu kelompok sasaran dan dapat memiliki maksimal lima. Pilih **Tambahkan grup target** untuk menambahkan grup target tambahan. Pilih **nama Port**, **Protokol**, dan **Port** untuk setiap grup target yang Anda pilih. Untuk menghapus grup target, pilih **Hapus**.
**catatan**  
Jika Anda ingin menambahkan grup target yang ada, Anda perlu menggunakan AWS CLI. *Untuk petunjuk tentang cara menambahkan grup target menggunakan AWS CLI, lihat [daftar target di Referensi](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html). AWS Command Line Interface *
Meskipun layanan VPC Lattice dapat memiliki beberapa grup target, setiap grup target hanya dapat ditambahkan ke satu layanan.
Untuk membuat layanan dalam konfigurasi IPv6 -only, pilih grup target dengan jenis `IPv6` alamat IP.

1. Pada titik ini, Anda menavigasi ke konsol VPC Lattice untuk melanjutkan pengaturan. Di sinilah Anda menyertakan grup target baru dalam tindakan default listener atau dalam aturan layanan VPC Lattice yang ada. 

   Untuk informasi selengkapnya, lihat [Aturan pendengar untuk layanan Kisi VPC Anda](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html).

**penting**  
Anda harus mengizinkan `vpc-lattice` awalan aturan masuk ke grup keamanan atau tugas Anda dan pemeriksaan kesehatan dapat gagal. 

## Buat layanan yang menggunakan VPC Lattice dengan AWS CLI
<a name="ecs-lattice-create-cli"></a>

Gunakan AWS CLI untuk membuat layanan dengan VPC Lattice. Ganti masing-masing *user input placeholder* dengan informasi Anda sendiri.

1. Buat file konfigurasi grup target. Contoh berikut diberi nama `tg-config.json`

   ```
   {
       "ipAddressType": "IPV4",
       "port": 443,
       "protocol": "HTTPS",
       "protocolVersion": "HTTP1",
       "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
   }
   ```

1. Gunakan perintah berikut untuk membuat grup target VPC Lattice.

   ```
   aws vpc-lattice create-target-group \
       --name my-lattice-target-group-ip \
       --type IP \
       --config file://tg-config.json
   ```
**catatan**  
Untuk membuat layanan dalam konfigurasi IPv6 -only, buat grup target dengan jenis `IPv6` alamat IP. Untuk informasi selengkapnya, lihat [create-target-group](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/create-target-group.html) dalam *AWS CLI Referensi Perintah*.

   Contoh output:

   ```
   {
       "arn": "arn:aws:vpc-lattice:us-east-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
       "config": {
           "healthCheck": {
               "enabled": true,
               "healthCheckIntervalSeconds": 30,
               "healthCheckTimeoutSeconds": 5,
               "healthyThresholdCount": 5,
               "matcher": {
                   "httpCode": "200"
               },
               "path": "/",
               "protocol": "HTTPS",
               "protocolVersion": "HTTP1",
               "unhealthyThresholdCount": 2
           },
           "ipAddressType": "IPV4",
           "port": 443,
           "protocol": "HTTPS",
           "protocolVersion": "HTTP1",
           "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
       },
       "id": "tg-0eaa4b9ab4EXAMPLE",
       "name": "my-lattice-target-group-ip",
       "status": "CREATE_IN_PROGRESS",
       "type": "IP"
   }
   ```

1. File JSON berikut bernama *ecs-service-vpc-lattice.json* adalah contoh yang digunakan untuk melampirkan layanan Amazon ECS ke grup target VPC Lattice. Contoh `portName` di bawah ini sama dengan yang Anda tentukan di `name` bidang `portMappings` properti definisi tugas Anda.

   ```
   {
       "serviceName": "ecs-service-vpc-lattice",
       "taskDefinition": "ecs-task-def",
           "vpcLatticeConfigurations": [
           {
               "targetGroupArn": "arn:aws:vpc-lattice:us-west-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
               "portName": "testvpclattice",
               "roleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRoleVpcLattice"
           }
       ],
       "desiredCount": 5,
       "role": "ecsServiceRole"
   }
   ```

   Gunakan perintah berikut untuk membuat layanan Amazon ECS dan melampirkannya ke grup target VPC Lattice menggunakan contoh json di atas.

   ```
   aws ecs create-service \
       --cluster clusterName \
       --serviceName ecs-service-vpc-lattice \
       --cli-input-json file://ecs-service-vpc-lattice.json
   ```

**catatan**  
VPC Lattice tidak didukung di Amazon ECS Anywhere.

# Lindungi tugas Amazon ECS Anda agar tidak dihentikan oleh peristiwa penskalaan
<a name="task-scale-in-protection"></a>

Anda dapat menggunakan perlindungan penskalaan tugas Amazon ECS untuk melindungi tugas agar tidak dihentikan oleh peristiwa penskalaan dari penskalaan otomatis layanan atau penerapan.

Aplikasi tertentu memerlukan mekanisme untuk melindungi tugas-tugas penting misi dari penghentian oleh peristiwa penskalaan selama masa pemanfaatan rendah atau selama penerapan layanan. Contoh:
+ Anda memiliki aplikasi asinkron pemrosesan antrian seperti pekerjaan transcoding video di mana beberapa tugas perlu dijalankan selama berjam-jam bahkan ketika pemanfaatan layanan kumulatif rendah.
+ Anda memiliki aplikasi game yang menjalankan server game sebagai tugas Amazon ECS yang perlu terus berjalan bahkan jika semua pengguna telah logged-out untuk mengurangi latensi start-up dari reboot server.
+ Saat Anda menerapkan versi kode baru, Anda memerlukan tugas untuk terus berjalan karena akan mahal untuk diproses ulang.

Untuk melindungi tugas yang termasuk dalam layanan Anda agar tidak dihentikan dalam peristiwa scale-in, setel atribut ke`ProtectionEnabled`. `true` Bila Anda menyetel `ProtectionEnabled` ke true, tugas dilindungi selama 2 jam secara default. Anda kemudian dapat menyesuaikan periode perlindungan dengan menggunakan `ExpiresInMinutes` atribut. Anda dapat melindungi tugas Anda selama minimal 1 menit dan hingga maksimum 2880 menit (48 jam). Jika Anda menggunakan AWS CLI, Anda dapat menentukan `--protection-enabled` opsi.

Setelah tugas menyelesaikan pekerjaan yang dipersyaratkan, Anda dapat mengatur `ProtectionEnabled` atribut ke`false`, memungkinkan tugas dihentikan oleh peristiwa skala berikutnya. Jika Anda menggunakan AWS CLI, Anda dapat menentukan `--no-protection-enabled` opsi.

## Mekanisme perlindungan skala tugas
<a name="task-scale-in-protection-mechanisms"></a>

Anda dapat mengatur dan mendapatkan perlindungan skala tugas menggunakan titik akhir agen penampung Amazon ECS atau Amazon ECS API.
+ **Titik akhir agen kontainer Amazon ECS**

  Sebaiknya gunakan titik akhir agen penampung Amazon ECS untuk tugas yang dapat menentukan sendiri kebutuhan untuk dilindungi. Gunakan pendekatan ini untuk beban kerja berbasis antrian atau pemrosesan pekerjaan.

  Saat wadah mulai memproses pekerjaan, misalnya dengan menggunakan pesan SQS, Anda dapat mengatur `ProtectionEnabled` atribut melalui jalur titik akhir perlindungan skala tugas `$ECS_AGENT_URI/task-protection/v1/state` dari dalam wadah. Amazon ECS tidak akan menghentikan tugas ini selama acara scale-in. Setelah tugas Anda selesai, Anda dapat menghapus `ProtectionEnabled` atribut menggunakan titik akhir yang sama, membuat tugas memenuhi syarat untuk penghentian selama peristiwa penskalaan berikutnya.

  Untuk informasi selengkapnya tentang titik akhir agen penampung Amazon ECS, lihat. [Titik akhir perlindungan skala tugas Amazon ECS](task-scale-in-protection-endpoint.md)
+ **Amazon ECS API**

  Anda dapat menggunakan Amazon ECS API untuk menyetel dan mengambil perlindungan skala tugas jika aplikasi Anda memiliki komponen yang melacak status tugas aktif. Gunakan `UpdateTaskProtection` untuk menandai satu atau lebih tugas sebagai dilindungi. Gunakan `GetTaskProtection` untuk mengambil status perlindungan.

  Contoh dari pendekatan ini adalah jika aplikasi Anda menghosting sesi server game sebagai tugas Amazon ECS. Saat pengguna masuk ke sesi di server (tugas), Anda dapat menandai tugas sebagai dilindungi. Setelah pengguna log out, Anda dapat menghapus perlindungan khusus untuk tugas ini atau secara berkala menghapus perlindungan untuk tugas serupa yang tidak lagi memiliki sesi aktif, tergantung pada kebutuhan Anda untuk menjaga server menganggur.

  Untuk informasi selengkapnya, lihat [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html)dan [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)di *Referensi API Amazon Elastic Container Service*.

Anda dapat menggabungkan kedua pendekatan. Misalnya, gunakan titik akhir agen Amazon ECS untuk mengatur perlindungan tugas dari dalam wadah dan gunakan Amazon ECS API untuk menghapus perlindungan tugas dari layanan pengontrol eksternal Anda.

## Pertimbangan-pertimbangan
<a name="task-scale-in-protection-considerations"></a>

Pertimbangkan poin-poin berikut sebelum menggunakan perlindungan skala tugas:
+ Perlindungan skala tugas hanya didukung dengan tugas yang diterapkan dari layanan.
+ Perlindungan skala tugas didukung dengan tugas yang diterapkan dari layanan yang berjalan di Instans Terkelola Amazon ECS.
+ Sebaiknya gunakan titik akhir agen penampung Amazon ECS karena agen Amazon ECS memiliki mekanisme coba ulang bawaan dan antarmuka yang lebih sederhana.
+ Anda dapat mengatur ulang periode kedaluwarsa perlindungan skala tugas dengan memanggil tugas `UpdateTaskProtection` yang telah mengaktifkan perlindungan.
+ Tentukan berapa lama tugas yang dibutuhkan untuk menyelesaikan pekerjaan yang diperlukan dan mengatur `expiresInMinutes` properti yang sesuai. Jika Anda mengatur kedaluwarsa perlindungan lebih lama dari yang diperlukan, maka Anda akan dikenakan biaya dan menghadapi keterlambatan dalam penyebaran tugas baru.
+ Perlindungan skala tugas didukung pada agen `1.65.0` kontainer Amazon ECS atau yang lebih baru. Anda dapat menambahkan dukungan untuk fitur ini di instans Amazon EC2 menggunakan versi lama agen penampung Amazon ECS dengan memperbarui agen ke versi terbaru. Untuk informasi selengkapnya, lihat [Memperbarui agen kontainer Amazon ECS](ecs-agent-update.md).
+ Pertimbangan penyebaran:
  + Jika layanan menggunakan pembaruan bergulir, tugas baru akan dibuat tetapi tugas yang menjalankan versi lama tidak akan dihentikan sampai dihapus atau `protectionEnabled` kedaluwarsa. Anda dapat menyesuaikan `maximumPercentage` parameter dalam konfigurasi penerapan ke nilai yang memungkinkan tugas baru dibuat saat tugas lama dilindungi.
  + Jika blue/green pembaruan diterapkan, penerapan biru dengan tugas yang dilindungi tidak akan dihapus jika tugas memiliki`protectionEnabled`. Lalu lintas akan dialihkan ke tugas baru yang muncul dan tugas lama hanya akan dihapus ketika dihapus atau `protectionEnabled` kedaluwarsa. Bergantung pada batas waktu CodeDeploy atau CloudFormation pembaruan, penerapan mungkin batas waktu dan tugas Biru yang lebih lama mungkin masih ada.
  + Jika Anda menggunakan CloudFormation, update-stack memiliki batas waktu 3 jam. Oleh karena itu, jika Anda mengatur perlindungan tugas Anda lebih dari 3 jam, maka CloudFormation penerapan Anda dapat mengakibatkan kegagalan dan kemunduran.

    Selama tugas lama Anda dilindungi, CloudFormation tumpukan ditampilkan`UPDATE_IN_PROGRESS`. Jika perlindungan skala tugas dihapus atau kedaluwarsa dalam jendela 3 jam, penerapan Anda akan berhasil dan pindah ke status. `UPDATE_COMPLETE` Jika penerapan macet `UPDATE_IN_PROGRESS` selama lebih dari 3 jam, itu akan gagal dan menunjukkan `UPDATE_FAILED` status, dan kemudian akan digulung kembali ke set tugas lama.
  + Amazon ECS mengirimkan peristiwa layanan saat tugas yang dilindungi menjaga penerapan (bergulir atau biru/hijau) agar tidak mencapai kondisi tunak, sehingga Anda dapat mengambil tindakan perbaikan. Saat mencoba memperbarui status perlindungan suatu tugas, jika Anda menerima pesan `DEPLOYMENT_BLOCKED` kesalahan, itu berarti layanan memiliki tugas yang lebih terlindungi daripada jumlah tugas yang diinginkan untuk layanan. Untuk mengatasi kesalahan ini, lakukan salah satu hal berikut:
    + Tunggu hingga perlindungan tugas saat ini kedaluwarsa. Kemudian atur perlindungan tugas.
    + Tentukan tugas mana yang bisa dihentikan. Kemudian gunakan `UpdateTaskProtection` dengan `protectionEnabled` opsi yang disetel `false` untuk tugas-tugas ini.
    + Tingkatkan jumlah tugas yang diinginkan dari layanan menjadi lebih dari jumlah tugas yang dilindungi.

## Izin IAM diperlukan untuk perlindungan skala tugas
<a name="task-scale-in-protection-iam"></a>

Tugas harus memiliki peran tugas Amazon ECS dengan izin berikut:
+ `ecs:GetTaskProtection`: Memungkinkan agen kontainer Amazon ECS untuk menelepon`GetTaskProtection`.
+ `ecs:UpdateTaskProtection`: Memungkinkan agen kontainer Amazon ECS untuk menelepon`UpdateTaskProtection`.

# Titik akhir perlindungan skala tugas Amazon ECS
<a name="task-scale-in-protection-endpoint"></a>

Agen penampung Amazon ECS secara otomatis menyuntikkan variabel `ECS_AGENT_URI` lingkungan ke dalam wadah tugas Amazon ECS untuk menyediakan metode untuk berinteraksi dengan titik akhir API agen penampung.

Sebaiknya gunakan titik akhir agen penampung Amazon ECS untuk tugas yang dapat menentukan sendiri kebutuhan untuk dilindungi. 

Saat kontainer mulai memproses pekerjaan, Anda dapat menyetel `protectionEnabled` atribut menggunakan jalur titik akhir perlindungan skala tugas `$ECS_AGENT_URI/task-protection/v1/state` dari dalam wadah. 

Gunakan permintaan PUT ke URI ini dari dalam wadah untuk mengatur perlindungan skala tugas. Permintaan GET ke URI ini mengembalikan status perlindungan tugas saat ini.

## Parameter permintaan perlindungan skala tugas
<a name="task-scale-in-protection-request"></a>

Anda dapat mengatur perlindungan skala tugas menggunakan `${ECS_AGENT_URI}/task-protection/v1/state` titik akhir dengan parameter permintaan berikut.

`ProtectionEnabled`  
Tentukan `true` untuk menandai tugas untuk perlindungan. Tentukan `false` untuk menghapus perlindungan dan membuat tugas memenuhi syarat untuk penghentian.  
Jenis: Boolean  
Wajib: Ya

`ExpiresInMinutes`  
Jumlah menit tugas dilindungi. Anda dapat menentukan minimal 1 menit hingga 2.880 menit (48 jam). Selama periode waktu ini, tugas Anda tidak akan dihentikan oleh peristiwa penskalaan dari Auto Scaling atau penerapan layanan. Setelah periode waktu ini berlalu, `protectionEnabled` parameter diatur ke`false`.  
Jika Anda tidak menentukan waktu, maka tugas secara otomatis dilindungi selama 120 menit (2 jam).  
Tipe: Integer  
Wajib: Tidak

Contoh berikut menunjukkan cara mengatur perlindungan tugas dengan durasi yang berbeda.

**Contoh cara melindungi tugas dengan periode waktu default**

Contoh ini menunjukkan cara melindungi tugas dengan periode waktu default 2 jam.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```

**Contoh cara melindungi tugas selama 60 menit**

Contoh ini menunjukkan cara melindungi tugas selama 60 menit menggunakan `expiresInMinutes` parameter.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'      
```

**Contoh cara melindungi tugas selama 24 jam**

Contoh ini menunjukkan cara melindungi tugas selama 24 jam menggunakan `expiresInMinutes` parameter.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'      
```

**Contoh untuk wadah Windows**

Untuk wadah Windows, Anda dapat menggunakan PowerShell `Invoke-RestMethod` cmdlet alih-alih curl. Contoh berikut menunjukkan PowerShell ekuivalen dari perintah curl sebelumnya.

**Contoh cara melindungi tugas penampung Windows dengan periode waktu default**

Contoh ini menunjukkan cara melindungi tugas dengan periode waktu default 2 jam menggunakan PowerShell.

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true}' -ContentType 'application/json'
```

**Contoh cara melindungi tugas penampung Windows selama 60 menit**

Contoh ini menunjukkan cara melindungi tugas selama 60 menit menggunakan `expiresInMinutes` parameter dengan PowerShell.

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":60}' -ContentType 'application/json'
```

**Contoh cara melindungi tugas penampung Windows selama 24 jam**

Contoh ini menunjukkan cara melindungi tugas selama 24 jam menggunakan `expiresInMinutes` parameter dengan PowerShell.

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}' -ContentType 'application/json'
```

Permintaan PUT mengembalikan respon berikut.

```
{
  "protection": {
    "ExpirationDate": "2023-12-20T21:57:44.837Z",
    "ProtectionEnabled": true,
    "TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
  }
}
```

## Parameter respons perlindungan skala tugas
<a name="task-scale-in-protection-response"></a>

Informasi berikut dikembalikan dari titik akhir perlindungan skala tugas dalam respons `${ECS_AGENT_URI}/task-protection/v1/state` JSON.

`ExpirationDate`  
Waktu zaman ketika perlindungan untuk tugas akan kedaluwarsa. Jika tugas tidak dilindungi, nilai ini adalah nol.

`ProtectionEnabled`  
Status perlindungan tugas. Jika perlindungan scale-in diaktifkan untuk tugas, nilainya adalah. `true` Kalau tidak, itu`false`.

`TaskArn`  
Nama lengkap Amazon Resource Name (ARN) dari tugas milik kontainer.

Contoh berikut menunjukkan detail yang dikembalikan untuk tugas yang dilindungi.

```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```

Untuk wadah Windows, gunakan PowerShell perintah berikut untuk mendapatkan status perlindungan:

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Get
```

```
{
    "protection":{
        "ExpirationDate":"2023-12-20T21:57:44Z",
        "ProtectionEnabled":true,
        "TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
    }
}
```

Informasi berikut dikembalikan ketika terjadi kegagalan.

`Arn`  
Nama Sumber Daya Amazon (ARN) lengkap dari tugas tersebut.

`Detail`  
Detail terkait dengan kegagalan.

`Reason`  
Sebab kegagalan.

Contoh berikut menunjukkan rincian yang dikembalikan untuk tugas yang tidak dilindungi.

```
{
    "failure":{
        "Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
        "Detail":null,
        "Reason":"TASK_NOT_VALID"
    }
}
```

Informasi berikut dikembalikan ketika pengecualian terjadi.

`requestID`  
ID AWS permintaan untuk panggilan Amazon ECS API yang menghasilkan pengecualian.

`Arn`  
Nama Sumber Daya Amazon (ARN) lengkap dari tugas atau layanan.

`Code`  
Kode kesalahan.

`Message`  
Pesan kesalahan.  
Jika `RequestTimeout` kesalahan `RequestError` atau muncul, kemungkinan itu adalah masalah jaringan. Coba gunakan titik akhir VPC untuk Amazon ECS.

Contoh berikut menunjukkan rincian yang dikembalikan ketika terjadi kesalahan.

```
{
    "requestID":"12345-abc-6789-0123-abc",
    "error":{
        "Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
        "Code":"AccessDeniedException",
        "Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
    }    
}
```

Kesalahan berikut muncul jika agen Amazon ECS tidak dapat mendapatkan respons dari titik akhir Amazon ECS karena alasan seperti masalah jaringan atau bidang kontrol Amazon ECS sedang down.

```
{
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "RequestCanceled",
    "Message": "Timed out calling Amazon ECS Task Protection API"
  }
}
```

Kesalahan berikut muncul ketika agen Amazon ECS mendapatkan pengecualian pelambatan dari Amazon ECS.

```
{
  "requestID": "12345-abc-6789-0123-abc",
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "ThrottlingException",
    "Message": "Rate exceeded"
  }
}
```

# Gunakan injeksi kesalahan dengan beban kerja Amazon ECS dan Fargate
<a name="fault-injection"></a>

Pelanggan dapat menggunakan injeksi kesalahan dengan Amazon ECS di Amazon EC2 dan Fargate untuk menguji bagaimana aplikasi mereka merespons skenario gangguan tertentu. Pengujian ini memberikan informasi yang dapat Anda gunakan untuk mengoptimalkan kinerja dan ketahanan aplikasi Anda.

Saat injeksi kesalahan diaktifkan, agen penampung Amazon ECS memungkinkan akses tugas ke titik akhir injeksi kesalahan baru. Anda perlu ikut serta untuk menggunakan injeksi kesalahan dengan menyetel nilai parameter definisi `enableFaultInjection` tugas ke`true`. Nilai default-nya adalah `false`. 

```
{
    ...
   "enableFaultInjection": true
}
```

**catatan**  
Injeksi kesalahan hanya berfungsi dengan tugas menggunakan mode `host` jaringan `awsvpc` atau.  
Injeksi kesalahan tidak tersedia di Windows.

Untuk informasi tentang cara mengaktifkan injeksi kesalahan di Konsol Manajemen AWS, lihat [Membuat definisi tugas Amazon ECS menggunakan konsol](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html).

Anda harus mengaktifkan fitur untuk pengujian di file AWS Fault Injection Service. Untuk informasi selengkapnya, lihat [Menggunakan tindakan AWS FIS aws:ecs:task](https://docs.aws.amazon.com/fis/latest/userguide/ecs-task-actions.html).

**catatan**  
Jika Anda tidak menggunakan Amazon ECS yang dioptimalkan AMIs, atau memiliki AMI khusus, instal dependensi berikut:  
`tc`
`sch_netem`modul kernel

# Titik akhir injeksi kesalahan Amazon ECS
<a name="fault-injection-endpoints"></a>

Agen penampung Amazon ECS secara otomatis menyuntikkan variabel `ECS_AGENT_URI` lingkungan ke dalam wadah tugas Amazon ECS untuk menyediakan metode untuk berinteraksi dengan titik akhir API agen penampung. Setiap titik akhir mencakup`/start`,`/stop`, dan titik `/status` akhir. Titik akhir hanya menerima permintaan dari tugas yang telah mengaktifkan injeksi kesalahan, dan setiap titik akhir memiliki batas laju **1** permintaan per **5 detik per kontainer**. Melebihi batas ini menghasilkan kesalahan.

**catatan**  
Agen Amazon ECS `version 1.88.0+` diperlukan untuk menggunakan titik akhir injeksi kesalahan.

Tiga titik akhir untuk digunakan dengan injeksi kesalahan adalah:
+ [Titik akhir port blackhole jaringan](#fis-endpoint-blackhole-ports)
+ [Titik akhir kehilangan paket jaringan](#fis-endpoint-packet-loss)
+ [Titik akhir latensi jaringan](#fis-endpoint-latency)

Permintaan yang berhasil menghasilkan kode respons `200` dengan pesan `running` saat Anda memanggil `/start` titik akhir, `stopped` untuk titik `/stop` akhir, dan `running` atau `not-running` untuk titik akhir. `/status`

```
{
    "Status": <string>
}
```

Permintaan yang gagal mengembalikan salah satu kode kesalahan berikut:
+ `400`- Permintaan buruk
+ `409`- Permintaan injeksi kesalahan bertentangan dengan kesalahan berjalan lainnya
+ `429`- Permintaan dibatasi
+ `500`- Server memiliki kesalahan yang tidak terduga

```
{
	"Error":  <string message> 
}
```

**catatan**  
Salah satu kesalahan latensi jaringan atau satu kesalahan kehilangan paket jaringan dapat disuntikkan pada suatu waktu. Mencoba menyuntikkan lebih dari satu mengakibatkan permintaan ditolak.

## Titik akhir port blackhole jaringan
<a name="fis-endpoint-blackhole-ports"></a>

`{ECS_AGENT_URI}/fault/v1/network-blackhole-port`Titik akhir menurunkan lalu lintas masuk atau keluar untuk port dan protokol tertentu dalam namespace jaringan tugas dan kompatibel dengan dua mode:
+ **awsvpc** - perubahan diterapkan ke namespace jaringan tugas
+ **host** - perubahan diterapkan ke instance kontainer namespace jaringan default

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/start
<a name="fis-endpoint-blackhole-ports-start"></a>

Titik akhir ini memulai injeksi kesalahan port blackhole jaringan dan memiliki parameter berikut:

**Port**  
Port yang ditentukan untuk digunakan untuk injeksi kesalahan port lubang hitam.

Jenis: Integer

Wajib: Ya

**Protokol**  
Protokol yang digunakan untuk injeksi kesalahan port lubang hitam.

Tipe: String

Nilai yang valid: `tcp | udp`

Wajib: Ya

**TrafficType**  
Jenis lalu lintas yang digunakan oleh injeksi kesalahan.

Tipe: String

Nilai yang valid: `ingress | egress`

Wajib: Ya

**SourcesToFilter**  
Sebuah array JSON IPv4 atau IPv6 alamat atau blok CIDR yang dilindungi dari kesalahan.

Tipe: Array string

Wajib: Tidak

Berikut ini adalah contoh permintaan untuk menggunakan `start` titik akhir (ganti *red* nilai dengan milik Anda sendiri):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/start

Http method:POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress"
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/stop
<a name="fis-endpoint-blackhole-ports-stop"></a>

Titik akhir ini menghentikan kesalahan yang ditentukan dalam permintaan. Titik akhir ini memiliki parameter berikut:

**Port**  
Port terkena dampak kesalahan yang harus dihentikan.

Jenis: Integer

Wajib: Ya

**Protokol**  
Protokol yang digunakan untuk menghentikan kesalahan.

Tipe: String

Nilai yang valid: `tcp | udp`

Wajib: Ya

**TrafficType**  
Jenis lalu lintas yang digunakan oleh injeksi kesalahan.

Tipe: String

Nilai yang valid: `ingress | egress`

Wajib: Ya

Berikut ini adalah contoh permintaan untuk menggunakan `stop` titik akhir (ganti *red* nilai dengan milik Anda sendiri):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/stop

Http method: POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress", 
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/status
<a name="fis-endpoint-blackhole-ports-status"></a>

Endpoint ini digunakan untuk memeriksa status injeksi kesalahan. Titik akhir ini memiliki parameter berikut:

**Port**  
Port yang terkena dampak untuk memeriksa status kesalahan.

Jenis: Integer

Wajib: Ya

**Protokol**  
Protokol yang digunakan saat memeriksa status kesalahan.

Tipe: String

Nilai yang valid: `tcp | udp`

Wajib: Ya

**TrafficType**  
Jenis lalu lintas yang digunakan oleh injeksi kesalahan.

Tipe: String

Nilai yang valid: `ingress | egress`

Wajib: Ya

Berikut ini adalah contoh permintaan untuk menggunakan `status` titik akhir (ganti *red* nilai dengan milik Anda sendiri):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/status

Http method: POST

Request payload: 
{
   "Port": 1234,
   "Protocol": "tcp|udp",
   "TrafficType": "ingress|egress",
}
```

## Titik akhir latensi jaringan
<a name="fis-endpoint-latency"></a>

`{ECS_AGENT_URI}/fault/v1/network-latency`Titik akhir menambahkan penundaan dan jitter ke antarmuka jaringan tugas untuk lalu lintas ke sumber tertentu. Titik akhir kompatibel dengan dua mode:
+ **awsvpc** - perubahan diterapkan ke antarmuka jaringan tugas
+ **host** - perubahan diterapkan ke antarmuka jaringan default

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/start
<a name="fis-endpoint-latency-start"></a>

`/start`Titik akhir ini memulai injeksi kesalahan latensi jaringan dan memiliki parameter berikut:

**DelayMilliseconds**  
Jumlah milidetik penundaan untuk ditambahkan ke antarmuka jaringan yang akan digunakan untuk injeksi kesalahan.

Jenis: Integer

Wajib: Ya

**JitterMilliseconds**  
Jumlah milidetik jitter untuk ditambahkan ke antarmuka jaringan yang akan digunakan untuk injeksi kesalahan.

Jenis: Integer

Wajib: Ya

**Sumber**  
Sebuah array JSON IPv4 atau IPv6 alamat atau blok CIDR yang tujuan untuk digunakan dengan injeksi kesalahan.

Tipe: Array string

Wajib: Ya

**SourcesToFilter**  
Sebuah array JSON IPv4 atau IPv6 alamat atau blok CIDR yang dilindungi dari kesalahan. `SourcesToFilter`mengambil prioritas di atas`Sources`.

Tipe: Array string

Wajib: Tidak

Berikut ini adalah contoh permintaan untuk menggunakan `/start` titik akhir (ganti *red* nilai dengan milik Anda sendiri):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/start

Http method: POST

Request payload: 
{
    "DelayMilliseconds": 123,
    "JitterMilliseconds": 123,
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/stop and /status
<a name="fis-endpoint-latency-stop-status"></a>

`{ECS_AGENT_URI}/fault/v1/network-latency/stop`Titik akhir menghentikan kesalahan, dan `{ECS_AGENT_URI}/fault/v1/network-latency/status` memeriksa status kesalahan.

Berikut ini adalah dua contoh permintaan untuk menggunakan `/stop` dan `/status` endpoint. Keduanya menggunakan `POST HTTP` metode ini.

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/stop
```

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/status
```

## Titik akhir kehilangan paket jaringan
<a name="fis-endpoint-packet-loss"></a>

`{ECS_AGENT_URI}/fault/v1/network-packet-loss`Endpoint menambahkan packet loss ke antarmuka jaringan yang diberikan. Endpoint ini kompatibel dengan dua mode:
+ **awsvpc** - perubahan diterapkan ke antarmuka jaringan tugas
+ **host** - perubahan diterapkan ke antarmuka jaringan default

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/start
<a name="fis-endpoint-packet-loss-start"></a>

`/start`Titik akhir ini memulai injeksi kesalahan kehilangan paket jaringan dan memiliki parameter berikut:

**LossPercent**  
Persentase kehilangan paket

Jenis: Integer

Wajib: Ya

**Sumber**  
Sebuah array JSON IPv4 atau IPv6 alamat atau blok CIDR untuk digunakan untuk tes injeksi kesalahan.

Tipe: Array string

Wajib: Ya

**SourcesToFilter**  
Sebuah array JSON IPv4 atau IPv6 alamat atau blok CIDR yang dilindungi dari kesalahan. `SourcesToFilter`mengambil prioritas di atas`Sources`.

Tipe: Array string

Wajib: Tidak

Berikut ini adalah contoh permintaan untuk menggunakan `start` titik akhir (ganti *red* nilai dengan milik Anda sendiri):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/start

Http method: POST

{
    "LossPercent": 6,  
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/stop and /status
<a name="fis-endpoint-packet-loss-stop-status"></a>

`{ECS_AGENT_URI}/fault/v1/network-packet-loss/stop`Titik akhir menghentikan kesalahan, dan `{ECS_AGENT_URI}/fault/v1/network-packet-loss/status` memeriksa status kesalahan. Hanya satu dari setiap jenis kesalahan yang didukung pada satu waktu.

Berikut ini adalah dua contoh permintaan untuk menggunakan `/stop` dan `/status` endpoint. Keduanya menggunakan `POST HTTP` metode ini.

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/stop
```

```
Endpoint: ${{ECS_AGENT_URI}/fault/v1/network-packet-loss/status
```

# Perbarui parameter layanan Amazon ECS
<a name="update-service-parameters"></a>

Setelah Anda membuat layanan, ada kalanya Anda mungkin perlu memperbarui parameter layanan, misalnya, jumlah tugas.

Ketika penjadwal layanan meluncurkan tugas baru, itu menentukan penempatan tugas di klaster Anda dengan logika berikut.
+ Tentukan instance kontainer mana di klaster Anda yang dapat mendukung definisi tugas layanan Anda. Misalnya, mereka memiliki atribut CPU, memori, port, dan instance container yang diperlukan.
+ Secara default, penjadwal layanan mencoba menyeimbangkan tugas di seluruh Availability Zone dengan cara ini meskipun Anda dapat memilih strategi penempatan yang berbeda.
  + Urutkan instance kontainer yang valid dengan jumlah tugas yang berjalan paling sedikit untuk layanan ini di Availability Zone yang sama dengan instance. Misalnya, jika zona A memiliki satu tugas layanan berjalan, sedangkan zona B dan C masing-masing tidak memliki tugas layanan berjalan, maka instans kontainer yang valid, baik di zona B ataupun C dianggap optimal untuk penempatan.
  + Tempatkan tugas layanan baru pada instans kontainer yang valid di Availability Zone yang optimal (berdasarkan langkah sebelumnya), dan pilih instans kontainer dengan jumlah tugas yang berjalan paling sedikit untuk layanan ini.

Ketika penjadwal layanan berhenti menjalankan tugas, ia mencoba untuk menjaga keseimbangan di seluruh Availability Zone di klaster Anda menggunakan logika berikut: 
+ Urutkan instance kontainer berdasarkan jumlah tugas yang berjalan terbesar untuk layanan ini di Availability Zone yang sama dengan instance. Misalnya, jika zona A memiliki satu tugas layanan yang berjalan, dan zona B serta C masing-masing memiliki dua, instans kontainer di zona B atau C dianggap optimal untuk penghentian.
+ Hentikan tugas pada instans kontainer di Availability Zone yang optimal (berdasarkan langkah sebelumnya), kemudian pilih instans kontainer dengan jumlah tugas yang berjalan paling banyak untuk layanan ini.

Gunakan daftar untuk menentukan apakah Anda dapat mengubah parameter layanan.

**Penyeimbangan kembali Zona Ketersediaan**  
Menunjukkan apakah akan menggunakan penyeimbangan kembali Availability Zone untuk layanan.  
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Strategi penyedia kapasitas**  
Detail strategi penyedia kapasitas. Anda dapat mengatur penyedia kapasitas saat membuat klaster, menjalankan tugas, atau memperbarui layanan.  
Ketika Anda menggunakan Fargate, penyedia kapasitas adalah `FARGATE` atau. `FARGATE_SPOT`  
Saat Anda menggunakan Amazon EC2, penyedia kapasitas adalah grup Auto Scaling.  
Anda dapat mengubah penyedia kapasitas untuk penerapan bergulir dan penerapan biru/hijau.  
Daftar berikut menyediakan transisi yang valid:  
+ Perbarui Fargate ke penyedia kapasitas grup Auto Scaling.
+ Perbarui EC2 ke penyedia kapasitas Fargate.
+ Perbarui penyedia kapasitas Fargate ke penyedia kapasitas grup Auto Scaling.
+ Perbarui penyedia kapasitas Amazon EC2 ke penyedia kapasitas Fargate. 
+ Perbarui grup Auto Scaling atau penyedia kapasitas Fargate kembali ke jenis peluncuran. Saat Anda menggunakan CLI, atau API, Anda meneruskan daftar kosong di parameter. `capacityProviderStrategy`

**Kluster**  
Anda tidak dapat mengubah nama cluster.

**Konfigurasi deployment**  
Konfigurasi penyebaran mencakup CloudWatch alarm, dan pemutus sirkuit yang digunakan untuk mendeteksi kegagalan dan konfigurasi yang diperlukan.  
Pemutus sirkuit deployment menentukan apakah deployment layanan akan gagal jika layanan tidak dapat mencapai status stabil. Jika Anda menggunakan pemutus sirkuit penyebaran, penyebaran layanan akan bertransisi ke status gagal dan berhenti meluncurkan tugas baru. Jika Anda menggunakan opsi rollback, ketika penerapan layanan gagal, layanan akan digulirkan kembali ke penerapan terakhir yang berhasil diselesaikan.  
Saat Anda memperbarui layanan yang menggunakan pemutus sirkuit Amazon ECS, Amazon ECS membuat penyebaran layanan dan revisi layanan. Sumber daya ini memungkinkan Anda untuk melihat informasi terperinci tentang riwayat layanan. Untuk informasi selengkapnya, lihat [Melihat riwayat layanan menggunakan deployment layanan Amazon ECS](service-deployment.md).  
Penjadwal layanan menggunakan parameter persentase minimum dan maksimum yang sehat (dalam konfigurasi deployment untuk layanan) untuk menentukan strategi deployment.  
Jika layanan menggunakan tipe penerapan rolling update (`ECS`), **persentase sehat minimum** mewakili batas bawah pada jumlah tugas dalam layanan yang harus tetap dalam `RUNNING` status selama penerapan, sebagai persentase dari jumlah tugas yang diinginkan (dibulatkan ke bilangan bulat terdekat). Parameter ini juga berlaku saat instance kontainer apa pun berada dalam `DRAINING` status jika layanan berisi tugas menggunakan EC2. Gunakan parameter ini untuk menyebarkan tanpa menggunakan kapasitas cluster tambahan. Misalnya, jika layanan Anda memiliki jumlah empat tugas yang diinginkan dan persentase sehat minimum 50 persen, penjadwal dapat menghentikan dua tugas yang ada untuk membebaskan kapasitas cluster sebelum memulai dua tugas baru. Layanan menganggap tugas sehat untuk layanan yang tidak menggunakan penyeimbang beban jika mereka berada di `RUNNING` negara bagian. Layanan menganggap tugas sehat untuk layanan yang menggunakan penyeimbang beban jika mereka berada di `RUNNING` negara bagian dan dilaporkan sehat oleh penyeimbang beban. Nilai default untuk persen sehat minimum adalah 100 persen.  
Jika layanan menggunakan tipe penerapan rolling update (`ECS`), parameter **persen maksimum** mewakili batas atas jumlah tugas dalam layanan yang diizinkan dalam,, atau `STOPPING` status selama penerapan `PENDING``RUNNING`, sebagai persentase dari jumlah tugas yang diinginkan (dibulatkan ke bilangan bulat terdekat). Parameter ini juga berlaku saat instance kontainer apa pun berada dalam `DRAINING` status jika layanan berisi tugas menggunakan EC2. Gunakan parameter ini untuk menentukan ukuran batch deployment. Misalnya, jika layanan Anda memiliki jumlah empat tugas yang diinginkan dan nilai persen maksimum 200 persen, penjadwal dapat memulai empat tugas baru sebelum menghentikan empat tugas lama. Ini asalkan sumber daya cluster yang diperlukan untuk melakukan ini tersedia. Nilai default untuk persen maksimum adalah 200 persen.  
Saat penjadwal layanan mengganti tugas selama pembaruan, maka layanan terlebih dahulu menghapus tugas dari penyeimbang beban (jika digunakan) dan menunggu koneksi dialihkan. Kemudian, **docker stop** yang setara dikeluarkan untuk kontainer yang berjalan dalam tugas. Hal ini menyebabkan sinyal `SIGTERM` dan waktu habis dalam 30 detik, setelah `SIGKILL` dikirim dan kontainer dihentikan secara paksa. Jika kontainer menangani sinyal `SIGTERM` dengan baik dan keluar dalam waktu 30 detik dari saat menerimanya, maka sinyal `SIGKILL` tidak dikirim. Penjadwal layanan memulai dan menghentikan tugas seperti yang ditentukan melalui pengaturan persentase minimum dan maksimum yang sehat.  
Penjadwal layanan juga menggantikan tugas yang ditentukan tidak sehat setelah pemeriksaan kesehatan kontainer atau pemeriksaan kesehatan kelompok sasaran penyeimbang beban gagal. Penggantian ini tergantung pada parameter definisi `maximumPercent` dan `desiredCount` layanan. Jika tugas ditandai tidak sehat, penjadwal layanan akan memulai tugas pengganti terlebih dahulu. Kemudian, hal berikut terjadi.  
+ Jika tugas penggantian memiliki status kesehatan`HEALTHY`, penjadwal layanan menghentikan tugas yang tidak sehat
+ Jika tugas penggantian memiliki status kesehatan`UNHEALTHY`, penjadwal akan menghentikan tugas penggantian yang tidak sehat atau tugas tidak sehat yang ada untuk mendapatkan jumlah tugas total yang sama`desiredCount`.
Jika `maximumPercent` parameter membatasi penjadwal untuk memulai tugas penggantian terlebih dahulu, penjadwal akan menghentikan tugas yang tidak sehat satu per satu secara acak untuk membebaskan kapasitas, dan kemudian memulai tugas pengganti. Proses start dan stop berlanjut sampai semua tugas yang tidak sehat diganti dengan tugas-tugas yang sehat. Setelah semua tugas yang tidak sehat telah diganti dan hanya tugas sehat yang berjalan, jika jumlah tugas total melebihi`desiredCount`, tugas sehat dihentikan secara acak hingga jumlah tugas total sama. `desiredCount` Untuk informasi selengkapnya tentang `maximumPercent` dan`desiredCount`, lihat [Parameter definisi layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html).

**Pengontrol penyebaran**  
Pengendali deployment yang bisa digunakan untuk layanan. Tersedia tiga tipe pengendali deployment:  
+ `ECS`
+ `EXTERNAL`
+ `CODE_DEPLOY`
Saat memperbarui layanan, Anda dapat memperbarui pengontrol penerapan yang digunakannya. Daftar berikut menyediakan transisi yang valid:  
+ Perbarui dari penerapan CodeDeploy biru/hijau (`CODE_DEPLOY`) ke ECS rolling atau deployments (). blue/green `ECS`
+ Perbarui dari penerapan CodeDeploy biru/hijau (`CODE_DEPLOY`) ke penerapan eksternal (). `EXTERNAL`
+ Pembaruan dari ECS rolling atau blue/green deployments (`ECS`) ke penerapan eksternal (). `EXTERNAL`
+ Pembaruan dari penerapan eksternal (`EXTERNAL`) ke ECS rolling atau blue/green deployments (). `ECS`
Pertimbangkan hal berikut saat Anda memperbarui pengontrol penerapan layanan:  
+ Anda tidak dapat memperbarui pengontrol penyebaran layanan dari pengontrol `ECS` penerapan ke pengontrol lain jika menggunakan VPC Lattice atau Amazon ECS Service Connect.
+ Anda tidak dapat memperbarui pengontrol penerapan layanan selama penerapan layanan yang sedang berlangsung.
+ Anda tidak dapat memperbarui pengontrol penerapan layanan `CODE_DEPLOY` jika tidak ada penyeimbang beban pada layanan.
+ Anda tidak dapat memperbarui pengontrol penyebaran layanan dari pengontrol lain `ECS` ke salah satu pengontrol lain jika `deploymentConfiguration` menyertakan alarm, pemutus sirkuit penyebaran, atau strategi penerapan. `BLUE_GREEN` Untuk informasi selengkapnya, lihat [Pengontrol dan strategi penyebaran layanan Amazon ECS](ecs_service-options.md).
+ Nilai yang Anda tentukan `versionConsistency` dalam definisi kontainer tidak akan digunakan oleh Amazon ECS jika Anda memperbarui pengontrol penerapan layanan dari `ECS` pengontrol lainnya. 
+ Jika Anda memperbarui pengontrol penerapan layanan dari pengontrol lain `ECS` ke pengontrol lain, respons `DescribeService` API `UpdateService` dan akan tetap kembali`deployments`. `taskSets` Untuk informasi selengkapnya tentang `UpdateService` dan`CreateService`, lihat [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)dan [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)di *Referensi API Amazon ECS*.
+ Jika layanan menggunakan strategi penyebaran pembaruan bergulir, memperbarui pengontrol penerapan dari pengontrol lain `ECS` ke pengontrol lain akan mengubah cara `maximumPercent` nilai dalam digunakan. `deploymentConfiguration` Alih-alih hanya digunakan sebagai batas pada total tugas dalam penerapan pembaruan bergulir, `maximumPercent` digunakan untuk mengganti tugas yang tidak sehat. Untuk informasi selengkapnya tentang cara penjadwal menggantikan tugas yang tidak sehat, lihat. [Layanan-layanan Amazon ECS](ecs_services.md)
+ Jika Anda memperbarui pengontrol penerapan layanan dari `ECS` pengontrol penerapan lainnya, semua `advancedConfiguration` yang Anda tentukan dengan konfigurasi penyeimbang beban Anda akan diabaikan. Untuk informasi selengkapnya, lihat [LoadBalancer](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LoadBalancer.html)dan [AdvancedConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AdvancedConfiguration.html)di *referensi Amazon ECS API*.
Saat memperbarui pengontrol penerapan untuk layanan yang digunakan CloudFormation, pertimbangkan hal berikut tergantung pada jenis migrasi yang Anda lakukan.  
+ Jika Anda memiliki CloudFormation template yang berisi informasi pengontrol `EXTERNAL` penerapan serta `TaskSet` `PrimaryTaskSet` sumber daya, dan Anda menghapus sumber daya set tugas dari templat saat memperbarui dari `EXTERNAL` ke`ECS`, panggilan `DeleteTaskSet` API `DescribeTaskSet` dan akan mengembalikan kesalahan 400 setelah pengontrol penerapan diperbarui. `ECS` Hal ini mengakibatkan kegagalan CloudFormation penghapusan pada sumber daya set tugas, meskipun CloudFormation tumpukan bertransisi ke `UPDATE_COMPLETE` status. Untuk informasi selengkapnya, lihat [Sumber daya dihapus dari tumpukan tetapi tidak dihapus](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted) di Panduan AWS CloudFormation Pengguna. Untuk memperbaiki masalah ini, hapus set tugas secara langsung menggunakan Amazon ECS `DeleteTaskSet` API. Untuk informasi selengkapnya tentang cara menghapus kumpulan tugas, lihat [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)di *Referensi API* *Amazon Elastic Container Service*.
+ Jika Anda bermigrasi dari `CODE_DEPLOY` ke `ECS` dengan definisi tugas baru dan CloudFormation melakukan operasi rollback, `UpdateService` permintaan Amazon ECS gagal dengan kesalahan berikut:

  ```
  Resource handler returned message: "Invalid request provided: Unable to update 
  task definition on services with a CODE_DEPLOY deployment controller. Use AWS 
  CodeDeploy to trigger a new deployment. (Service: Ecs, Status Code: 400, 
  Request ID: 0abda1e2-f7b3-4e96-b6e9-c8bc585181ac) (SDK Attempt Count: 1)" 
  (RequestToken: ba8767eb-c99e-efed-6ec8-25011d9473f0, HandlerErrorCode: InvalidRequest)
  ```
+ Setelah migrasi berhasil dari `ECS` ke pengontrol `EXTERNAL` penerapan, Anda perlu menghapus set `ACTIVE` tugas secara manual, karena Amazon ECS tidak lagi mengelola penerapan. Untuk informasi tentang cara menghapus set tugas, lihat [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)di *Referensi API* Amazon Elastic Container Service.

**Hitungan tugas yang diinginkan**  
Jumlah instantiasi tugas untuk ditempatkan dan terus berjalan di layanan Anda.  
Jika Anda ingin menghentikan sementara layanan Anda, tetapkan nilai ini ke 0. Kemudian, ketika Anda siap untuk memulai layanan, perbarui layanan dengan nilai aslinya.  
Anda dapat mengubah parameter ini untuk penerapan bergulir, dan penerapan biru/hijau.

**Aktifkan tag terkelola**  
Menentukan apakah akan mengaktifkan tag terkelola Amazon ECS untuk tugas dalam layanan.  
Hanya tugas yang diluncurkan setelah pembaruan yang akan mencerminkan pembaruan. Untuk memperbarui tag pada semua tugas, gunakan opsi penerapan paksa.  
Anda dapat mengubah parameter ini untuk penerapan bergulir, dan penerapan biru/hijau.

**Aktifkan ECS Exec**  
Menentukan apakah Amazon ECS Exec digunakan.  
Jika Anda tidak ingin mengganti nilai yang ditetapkan saat layanan dibuat, Anda dapat menyetelnya ke null saat melakukan tindakan ini.  
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Masa tenggang pemeriksaan kesehatan**  
Periode waktu, dalam hitungan detik, bahwa penjadwal layanan Amazon ECS mengabaikan Elastic Load Balancing, VPC Lattice, dan pemeriksaan kesehatan kontainer yang tidak sehat setelah tugas pertama kali dimulai. Jika Anda tidak menentukan nilai masa tenggang pemeriksaan kondisi, nilai default `0` digunakan. Jika Anda tidak menggunakan salah satu pemeriksaan kesehatan, maka tidak `healthCheckGracePeriodSeconds` digunakan.  
Jika tugas layanan Anda membutuhkan waktu cukup lama untuk memulai dan menanggapi pemeriksaan kesehatan, Anda dapat menentukan masa tenggang pemeriksaan kesehatan hingga 2.147.483.647 detik (sekitar 69 tahun). Selama waktu itu, penjadwal Layanan Amazon ECS mengabaikan status pemeriksaan kondisi. Masa tenggang ini dapat mencegah penjadwal layanan menandai tugas sebagai tidak sehat dan menghentikan mereka sebelum mereka memiliki waktu untuk muncul.  
Anda dapat mengubah parameter ini untuk penerapan bergulir dan penerapan biru/hijau.

**Penyeimbang beban**  
Anda harus menggunakan peran terkait layanan saat memperbarui penyeimbang beban.  
Daftar objek penyeimbang beban Elastic Load Balancing. Ini berisi nama penyeimbang beban, nama kontainer, dan port kontainer untuk mengakses dari penyeimbang beban. Nama kontainer adalah seperti yang muncul dalam definisi kontainer.  
Amazon ECS tidak secara otomatis memperbarui grup keamanan yang terkait dengan penyeimbang beban Elastic Load Balancing atau instans kontainer Amazon ECS.  
Saat Anda menambahkan, memperbarui, atau menghapus konfigurasi penyeimbang beban, Amazon ECS memulai tugas baru dengan konfigurasi Elastic Load Balancing yang diperbarui, dan kemudian menghentikan tugas lama saat tugas baru berjalan.  
Untuk layanan yang menggunakan pembaruan bergulir, Anda dapat menambahkan, memperbarui, atau menghapus grup target Elastic Load Balancing. Anda dapat memperbarui dari satu grup target ke beberapa grup target dan dari beberapa grup target ke satu grup target.  
Untuk layanan yang menggunakan blue/green penerapan, Anda dapat memperbarui grup target Elastic Load Balancing dengan menggunakannya. `[CreateDeployment](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_CreateDeployment.html)` CodeDeploy Perhatikan bahwa beberapa grup target tidak didukung untuk blue/green penerapan. Untuk informasi selengkapnya lihat [Mendaftarkan beberapa grup target dengan layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html).   
Untuk layanan yang menggunakan pengontrol penerapan eksternal, Anda dapat menambahkan, memperbarui, atau menghapus penyeimbang beban dengan menggunakan. [CreateTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateTaskSet.html) Perhatikan bahwa beberapa grup target tidak didukung untuk penerapan eksternal. Untuk informasi selengkapnya lihat [Mendaftarkan beberapa grup target dengan layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html).   
Lewati daftar kosong untuk menghapus penyeimbang beban.  
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Konfigurasi jaringan**  
Konfigurasi jaringan layanan.   
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Kendala penempatan**  
Array objek kendala penempatan tugas untuk memperbarui layanan yang akan digunakan. Jika tidak ada nilai yang ditentukan, batasan penempatan yang ada untuk layanan akan tetap tidak berubah. Jika nilai ini ditentukan, nilai ini akan mengganti batasan penempatan yang ada yang ditentukan untuk layanan. Untuk menghapus semua kendala penempatan yang ada, tentukan array kosong.  
Anda dapat menentukan maksimal 10 kendala untuk setiap tugas. Batas ini mencakup batasan dalam definisi tugas dan yang ditentukan saat runtime.  
Anda dapat mengubah parameter ini untuk penerapan bergulir, dan penerapan biru/hijau.

**Strategi penempatan**  
Strategi penempatan tugas keberatan untuk memperbarui layanan yang akan digunakan. Jika tidak ada nilai yang ditentukan, strategi penempatan yang ada untuk layanan akan tetap tidak berubah. Jika nilai ini ditentukan, itu akan mengesampingkan strategi penempatan yang ada yang ditentukan untuk layanan. Untuk menghapus strategi penempatan yang ada, tentukan objek kosong.  
Anda dapat mengubah parameter ini untuk penerapan bergulir, dan penerapan biru/hijau.

**Versi platform**  
Versi platform Fargate yang dijalankan layanan Anda.  
Layanan yang menggunakan versi platform Linux tidak dapat diperbarui untuk menggunakan versi platform Windows dan sebaliknya.  
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Menyebarkan tag**  
Menentukan apakah akan menyebarkan tag dari definisi tugas atau layanan ke tugas. Jika tidak ada nilai yang ditentukan, tanda tidak disebarkan.  
Hanya tugas yang diluncurkan setelah pembaruan yang akan mencerminkan pembaruan. Untuk memperbarui tag pada semua tugas, atur `forceNewDeployment` ke`true`, sehingga Amazon ECS memulai tugas baru dengan tag yang diperbarui.  
Anda dapat mengubah parameter ini untuk penerapan bergulir, dan penerapan biru/hijau.

**Konfigurasi Service Connect**  
Konfigurasi untuk Amazon ECS Service Connect. Parameter ini menentukan bagaimana layanan terhubung ke layanan lain dalam aplikasi Anda.  
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Registrasi layanan**  
Anda harus menggunakan peran terkait layanan saat memperbarui pendaftar layanan.  
Rincian untuk pendaftar penemuan layanan untuk ditetapkan ke layanan ini. Untuk informasi lebih lanjut, lihat [Penemuan Layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html).  
Saat Anda menambahkan, memperbarui, atau menghapus konfigurasi registrasi layanan, Amazon ECS memulai tugas baru dengan konfigurasi pendaftar layanan yang diperbarui, dan kemudian menghentikan tugas lama saat tugas baru berjalan.  
Lewati daftar kosong untuk menghapus pendaftar layanan.  
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Definisi tugas**  
Definisi tugas dan revisi yang digunakan untuk layanan.  
Jika Anda mengubah port yang digunakan oleh kontainer dalam definisi tugas, Anda mungkin perlu memperbarui grup keamanan agar instance kontainer berfungsi dengan port yang diperbarui.  
Jika Anda memperbarui definisi tugas untuk layanan, nama kontainer dan port kontainer yang ditentukan dalam konfigurasi penyeimbang beban harus tetap dalam definisi tugas.   
Perilaku tarik gambar kontainer berbeda untuk opsi komputasi. Untuk informasi selengkapnya, lihat salah satu dari berikut ini:  
+ [Arsitek AWS Fargate untuk Amazon ECS](AWS_Fargate.md)
+ [Arsitek untuk EC2 kapasitas Amazon ECS](launch-type-ec2.md)
+ [Eksternal (Amazon ECS Anywhere) untuk Amazon ECS](launch-type-external.md)
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Konfigurasi volume**  
Detail volume yang ada`configuredAtLaunch`. Bila `configuredAtLaunch` disetel ke `true` dalam definisi tugas, parameter layanan ini mengonfigurasi satu volume Amazon EBS untuk setiap tugas dalam layanan yang akan dibuat dan dilampirkan selama penerapan. [Anda dapat mengonfigurasi ukuran, VolumeType, IOPS, throughput, snapshot, dan enkripsi dalam Konfigurasi. ServiceManaged EBSVolume](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceManagedEBSVolumeConfiguration.html) Volume harus sesuai dengan `name` dari definisi tugas. `name` Jika disetel ke null, tidak ada penerapan baru yang dipicu. Jika tidak, jika konfigurasi ini berbeda dari yang sudah ada, itu memicu penerapan baru.  
Anda dapat mengubah parameter ini untuk penerapan bergulir.

**Konfigurasi Kisi VPC**  
Konfigurasi VPC Lattice untuk layanan Anda. Ini menentukan bagaimana layanan Anda terintegrasi dengan VPC Lattice untuk komunikasi. service-to-service  
Anda dapat mengubah parameter ini untuk penerapan bergulir.

## AWS CDK pertimbangan
<a name="cdk-considerations"></a>

 AWS CDK Tidak melacak status sumber daya. Ia tidak tahu apakah Anda membuat atau memperbarui layanan. Pelanggan harus menggunakan pintu keluar untuk mengakses konstruksi ecs `Service` L1 secara langsung. 

Untuk informasi tentang escape hatch, lihat [Menyesuaikan konstruksi dari AWS Construct Library di Panduan](https://docs.aws.amazon.com/cdk/v2/guide/cfn-layer.html#develop-customize-escape) Pengembang *AWS Cloud Development Kit (AWS CDK) v2*. 

Untuk memigrasikan layanan yang ada ke `ecs.Service` konstruksi, lakukan hal berikut:

1. Gunakan pintu keluar untuk mengakses konstruksi `Service` L1. 

1. Secara manual mengatur properti berikut dalam konstruksi `Service` L1. 

   Jika layanan Anda menggunakan kapasitas Amazon EC2:
   + `daemon?`
   + `placementConstraints?`
   + `placementStrategies?`
   + Jika Anda menggunakan mode `awsvpc` jaringan, Anda perlu mengatur `vpcSubnets?` dan `securityGroups?` konstruksi.

   Jika layanan Anda menggunakan Fargate:
   + `FargatePlatformVersion`
   + `vpcSubnets?`dan `securityGroups?` konstruksinya.

1. Atur `launchType` sebagai berikut:

   ```
   const cfnEcsService = service.node.findChild('Service') as ecs.CfnService;
   cfnEcsService.launchType = "FARGATE";
   ```

Untuk bermigrasi dari jenis peluncuran ke penyedia kapasitas, lakukan hal berikut:

1. Gunakan pintu keluar untuk mengakses konstruksi `Service` L1. 

1. Tambahkan `capacityProviderStrategies?` konstruksinya.

1. Menyebarkan layanan.

# Memperbarui layanan Amazon ECS
<a name="update-service-console-v2"></a>

Setelah Anda membuat layanan, ada kalanya Anda mungkin perlu memperbarui parameter layanan, misalnya jumlah tugas.

Saat Anda memperbarui layanan yang menggunakan pemutus sirkuit Amazon ECS, Amazon ECS membuat penyebaran layanan dan revisi layanan. Sumber daya ini memungkinkan Anda untuk melihat informasi terperinci tentang riwayat layanan. Untuk informasi selengkapnya, lihat [Melihat riwayat layanan menggunakan deployment layanan Amazon ECS](service-deployment.md).

## Prasyarat
<a name="update-service-prerequisites"></a>

Sebelum memperbarui layanan, verifikasi parameter layanan mana yang dapat diubah untuk jenis penerapan Anda. Untuk daftar lengkap parameter yang dapat diubah, lihat[Perbarui parameter layanan Amazon ECS](update-service-parameters.md).

## Prosedur
<a name="update-service-procedure"></a>

------
#### [ Console ]

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail klaster, di bagian **Layanan**, pilih kotak centang di sebelah layanan, lalu pilih **Perbarui**.

1. Agar layanan Anda memulai penerapan baru, pilih **Paksa penerapan baru**.

1. Untuk **definisi Tugas**, pilih keluarga definisi tugas dan revisi.
**penting**  
Konsol memvalidasi bahwa keluarga dan revisi definisi tugas yang dipilih kompatibel dengan konfigurasi komputasi yang ditentukan. Jika Anda menerima peringatan, verifikasi kompatibilitas definisi tugas dan konfigurasi komputasi yang Anda pilih.

1. Jika Anda memilih **Replika**, untuk **tugas yang diinginkan**, masukkan jumlah tugas yang akan diluncurkan dan dipelihara dalam layanan.

1. **Jika Anda memilih **Replika**, agar Amazon ECS memantau distribusi tugas di seluruh Availability Zone, dan mendistribusikannya kembali ketika ada ketidakseimbangan, di bawah penyeimbangan kembali layanan Availability Zone, pilih **Availability Zone service rebalancing**.**

1. Untuk **tugas yang menjalankan Min**, masukkan batas bawah pada jumlah tugas dalam layanan yang harus tetap dalam `RUNNING` status selama penerapan, sebagai persentase dari jumlah tugas yang diinginkan (dibulatkan ke bilangan bulat terdekat). Untuk informasi selengkapnya, lihat [Konfigurasi penerapan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration).

1. Untuk **tugas yang berjalan Max**, masukkan batas atas jumlah tugas dalam layanan yang diizinkan dalam `PENDING` status `RUNNING` atau selama penerapan, sebagai persentase dari jumlah tugas yang diinginkan (dibulatkan ke bilangan bulat terdekat).

1. Untuk mengonfigurasi cara tugas digunakan untuk layanan Anda, perluas opsi **Deployment, lalu konfigurasikan opsi** Anda.

   1. Untuk **jenis pengontrol Deployment**, tentukan pengontrol penyebaran layanan. Konsol Amazon ECS mendukung jenis pengontrol berikut:`ECS`.

   1. Untuk **strategi Deployment**, pilih strategi yang digunakan oleh Amazon ECS untuk menerapkan versi baru layanan.

   1. Bergantung pada pilihan **strategi Deployment**, lakukan hal berikut:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/update-service-console-v2.html)

   1. Untuk menjalankan fungsi Lambda untuk tahap siklus hidup, di bawah **Deployment lifecyce hooks** lakukan hal berikut untuk setiap fungsi Lambda yang unik:

      1. Pilih **Tambahkan**.

         Ulangi untuk setiap fungsi unik yang ingin Anda jalankan.

      1. Untuk **fungsi Lambda**, masukkan nama fungsi.

      1. Untuk **Peran**, pilih peran yang Anda buat dalam prasyarat dengan izin. blue/green 

         Untuk informasi selengkapnya, lihat [Izin diperlukan untuk fungsi Lambda di penerapan Amazon ECS blue/green](blue-green-permissions.md).

      1. Untuk tahapan **Siklus Hidup, pilih tahapan** yang dijalankan fungsi Lambda.

      1.  (Opsional) Untuk **detail Hook**, masukkan pasangan nilai kunci yang memberikan informasi tentang hook.

1. Untuk mengonfigurasi cara Amazon ECS mendeteksi dan menangani kegagalan penerapan, perluas **deteksi kegagalan Deployment**, lalu pilih opsi Anda. 

   1. Untuk menghentikan penerapan saat tugas tidak dapat dimulai, pilih **Gunakan pemutus sirkuit penyebaran Amazon ECS**.

      **Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat pemutus sirkuit penyebaran mengatur penerapan ke status gagal, pilih Rollback on failure.**

   1. Untuk menghentikan penerapan berdasarkan metrik aplikasi, pilih **Gunakan CloudWatch alarm.** Kemudian, dari **nama CloudWatch alarm**, pilih alarm. Untuk membuat alarm baru, buka CloudWatch konsol.

      Agar perangkat lunak secara otomatis memutar kembali penerapan ke status penerapan yang terakhir selesai saat CloudWatch alarm menyetel penerapan ke status gagal, pilih **Rollback on** failure.

1. Untuk mengubah opsi komputasi, perluas **konfigurasi Compute**, lalu lakukan hal berikut: 

   1. Untuk layanan di AWS Fargate, untuk **versi Platform**, pilih versi baru.

   1. Untuk layanan yang menggunakan strategi penyedia kapasitas, untuk **strategi penyedia Kapasitas**, lakukan hal berikut:
      + Untuk menambahkan penyedia kapasitas tambahan, pilih **Tambahkan lebih banyak**. Kemudian, untuk **penyedia Kapasitas**, pilih penyedia kapasitas.
      + Untuk menghapus penyedia kapasitas, di sebelah kanan penyedia kapasitas, pilih **Hapus**.

      Layanan yang menggunakan penyedia kapasitas grup Auto Scaling tidak dapat diperbarui untuk menggunakan penyedia kapasitas Fargate. Layanan yang menggunakan penyedia kapasitas Fargate tidak dapat diperbarui untuk menggunakan penyedia kapasitas grup Auto Scaling.

1. (Opsional) Untuk mengonfigurasi Auto Scaling layanan, perluas Service **auto scaling**, lalu tentukan parameter berikut.Untuk menggunakan predicte auto scaling, yang melihat data beban masa lalu dari arus lalu lintas, konfigurasikan setelah Anda membuat layanan. Untuk informasi selengkapnya, lihat [Gunakan pola historis untuk menskalakan layanan Amazon ECS dengan penskalaan prediktif](predictive-auto-scaling.md).

   1. Untuk menggunakan penskalaan otomatis servis, pilih **Penskalaan otomatis layanan**.

   1. Untuk **Jumlah tugas minimum**, masukkan batas bawah jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan berada di bawah hitungan ini.

   1. Untuk **Jumlah tugas maksimum**, masukkan batas atas jumlah tugas untuk penskalaan otomatis servis yang akan digunakan. Hitungan yang diinginkan tidak akan melebihi hitungan ini.

   1. Pilih jenis kebijakan. Di bawah **Jenis kebijakan penskalaan**, pilih salah satu opsi berikut.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (Opsional) Untuk menggunakan Service Connect, pilih **Aktifkan Service Connect**, lalu tentukan yang berikut ini:

   1. Di bawah **konfigurasi Service Connect**, tentukan mode klien.
      + Jika layanan Anda menjalankan aplikasi klien jaringan yang hanya perlu terhubung ke layanan lain di namespace, pilih **sisi Klien** saja.
      + Jika layanan Anda menjalankan aplikasi jaringan atau layanan web dan perlu menyediakan titik akhir untuk layanan ini, dan terhubung ke layanan lain di namespace, pilih **Klien** dan server.

   1. Untuk menggunakan namespace yang bukan namespace cluster default, untuk Namespace, pilih **namespace layanan**. Ini bisa berupa namespace yang dibuat secara terpisah di ruang nama Anda Akun AWS atau Wilayah AWS di Region yang sama yang dibagikan dengan akun Anda menggunakan (). AWS Resource Access Manager AWS RAM*Untuk informasi selengkapnya tentang AWS Cloud Map ruang nama bersama, lihat Berbagi [AWS Cloud Map namespace lintas akun](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) di Panduan Pengembang AWS Cloud Map *

   1. (Opsional) Tentukan konfigurasi log. Pilih **Gunakan koleksi log**. Opsi default mengirimkan log kontainer ke CloudWatch Log. Opsi driver log lainnya dikonfigurasi menggunakan AWS FireLens. Untuk informasi selengkapnya, lihat [Kirim log Amazon ECS ke AWS layanan atau AWS Partner](using_firelens.md).

      Berikut ini menjelaskan setiap tujuan log kontainer secara lebih rinci.
      + **Amazon CloudWatch** — Konfigurasikan tugas untuk mengirim log kontainer ke CloudWatch Log. Opsi driver log default disediakan, yang membuat grup CloudWatch log atas nama Anda. Untuk menentukan nama grup log yang berbeda, ubah nilai opsi driver.
      + **Amazon Data Firehose** — Konfigurasikan tugas untuk mengirim log kontainer ke Firehose. Opsi driver log default disediakan, yang mengirim log ke aliran pengiriman Firehose. Untuk menentukan nama aliran pengiriman yang berbeda, ubah nilai opsi driver.
      + **Amazon Kinesis Data** Streams — Konfigurasikan tugas untuk mengirim log kontainer ke Kinesis Data Streams. Opsi driver log default disediakan, yang mengirim log ke aliran Kinesis Data Streams. Untuk menentukan nama aliran yang berbeda, ubah nilai opsi driver.
      + **Amazon OpenSearch Service** - Konfigurasikan tugas untuk mengirim log kontainer ke domain OpenSearch Layanan. Opsi driver log harus disediakan. 
      + **Amazon S3** — Konfigurasikan tugas untuk mengirim log kontainer ke bucket Amazon S3. Opsi driver log default disediakan, tetapi Anda harus menentukan nama bucket Amazon S3 yang valid.

   1. Untuk mengaktifkan log akses, ikuti langkah-langkah berikut:

      1. Perluas **konfigurasi log Access**. Untuk **Format**, pilih **JSON** atau`TEXT`.

      1. Untuk menyertakan parameter kueri dalam log akses, pilih **Sertakan parameter kueri**.
**catatan**  
Untuk menonaktifkan log akses, untuk **Format**, pilih **Tidak Ada**.

1. Jika tugas Anda menggunakan volume data yang kompatibel dengan konfigurasi saat penerapan, Anda dapat mengonfigurasi volume dengan memperluas **Volume**.

   Nama volume dan jenis volume dikonfigurasi saat Anda membuat revisi definisi tugas dan tidak dapat diubah saat memperbarui layanan. Untuk memperbarui nama dan jenis volume, Anda harus membuat revisi definisi tugas baru dan memperbarui layanan dengan menggunakan revisi baru.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (Opsional) Untuk membantu mengidentifikasi layanan Anda, perluas bagian **Tag**, lalu konfigurasikan tag Anda.
   + [Tambahkan tag] Pilih **Tambah tag**, dan lakukan hal berikut:
     + Untuk **Kunci**, masukkan nama kunci.
     + Untuk **Nilai**, masukkan nilai kunci.
   + [Menghapus tanda] Di samping tanda, pilih **Hapus tanda**.

1. Pilih **Perbarui**.

------
#### [ AWS CLI ]
+ Jalankan `update-service`. Untuk informasi tentang menjalankan perintah, lihat [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) di Referensi. AWS Command Line Interface 

  `update-service`Contoh berikut memperbarui jumlah tugas yang diinginkan dari layanan `my-http-service` ke 2.

  Ganti *user-input* dengan nilai-nilai Anda.

  ```
  aws ecs update-service \
      --cluster MyCluster \
      --service my-http-service \
      --desired-count 2
  ```

------

## Langkah selanjutnya
<a name="update-service-next-steps"></a>

Lacak penyebaran Anda dan lihat riwayat layanan Anda untuk layanan yang merupakan pemutus sirkuit Amazon ECS. Untuk informasi selengkapnya, lihat [Melihat riwayat layanan menggunakan deployment layanan Amazon ECS](service-deployment.md).

# Memperbarui layanan Amazon ECS untuk menggunakan penyedia kapasitas
<a name="update-service-managed-instances"></a>

Jika Anda memiliki layanan yang sudah ada yang menggunakan jenis peluncuran Amazon EC2 atau Fargate dan ingin menggunakan Instans Terkelola Amazon ECS, Anda perlu memperbarui layanan untuk menggunakan penyedia kapasitas Instans Terkelola Amazon ECS.

## Prasyarat
<a name="update-service-managed-instances-prerequisites"></a>

Buat penyedia kapasitas untuk Instans Terkelola Amazon ECS Anda. Untuk informasi selengkapnya, lihat [Membuat penyedia kapasitas untuk Instans Terkelola Amazon ECS](create-capacity-provider-managed-instances.md).

## Prosedur
<a name="update-service-managed-instances-procedure"></a>

------
#### [ Console ]

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Pada halaman detail klaster, di bagian **Layanan**, pilih kotak centang di sebelah layanan, lalu pilih **Perbarui**.

1. Pilih **Paksa penyebaran baru**.

1. Di bawah **Konfigurasi komputasi**, pilih strategi penyedia Kapasitas. Kemudian, pilih salah satu dari berikut ini:
   + Jika penyedia kapasitas Instans Terkelola Amazon ECS Anda adalah penyedia kapasitas default, pilih **Gunakan klaster** default.
   + Jika penyedia kapasitas Instans Terkelola Amazon ECS Anda bukan penyedia kapasitas default, pilih **Gunakan kustom (Lanjutan)**. Pilih penyedia kapasitas Instans Terkelola Amazon ECS, lalu untuk **Berat** pilih 1.

1. Pilih **Perbarui**.

------
#### [ AWS CLI ]
+ Jalankan `update-service`. Untuk informasi tentang menjalankan perintah, lihat [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) di Referensi. AWS Command Line Interface 

  Ganti *user-input* dengan nilai-nilai Anda.

  ```
  aws ecs update-service \
      --cluster my-cluster \
      --service my-service \
      --capacity-provider-strategy capacityProvider=my-managed-instance-capacity-provider,weight=1 \
      --force-new-deployment
  ```

------

# Menghapus layanan Amazon ECS menggunakan konsol
<a name="delete-service-v2"></a>

Berikut ini adalah beberapa alasan Anda akan menghapus layanan:
+ Aplikasi tidak lagi diperlukan
+ Anda memigrasikan layanan ke lingkungan baru
+ Aplikasi ini tidak aktif digunakan
+ Aplikasi ini menggunakan lebih banyak sumber daya daripada yang dibutuhkan dan Anda mencoba untuk memilih biaya Anda

Layanan secara otomatis diperkecil menjadi nol sebelum dihapus. Sumber daya penyeimbang beban atau sumber daya penemuan layanan yang terkait dengan layanan tidak terpengaruh oleh penghapusan layanan. Untuk menghapus sumber daya Elastic Load Balancing Anda, lihat salah satu topik berikut, tergantung pada jenis penyeimbang beban Anda: [Hapus Application Load Balancer [atau](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-delete.html) Hapus Network Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-delete.html) Balancer. 

Saat Anda menghapus layanan, Amazon ECS menghapus semua penerapan layanan dan revisi layanan untuk layanan tersebut.

Saat Anda menghapus layanan, jika masih ada tugas yang berjalan yang memerlukan pembersihan, status layanan berpindah dari `ACTIVE` ke`DRAINING`, dan layanan tidak lagi terlihat di konsol atau dalam operasi `ListServices` API. Setelah semua tugas dialihkan, baik ke status `STOPPING` ataupun `STOPPED`, maka status layanan bergerak dari `DRAINING` ke `INACTIVE`. Layanan dalam `INACTIVE` status `DRAINING` atau masih dapat dilihat dengan operasi `DescribeServices` API. 

**penting**  
Jika Anda mencoba membuat layanan baru dengan nama yang sama dengan layanan yang ada di salah satu `ACTIVE` atau `DRAINING` status, Anda akan menerima kesalahan.

**Prosedur**

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster untuk layanan.

1. Pada halaman **Clusters**, pilih cluster.

1. Pada *name* halaman **Cluster:**, pilih tab **Layanan**. 

1. Pilih layanan, lalu pilih **Hapus**.

1. Untuk menghapus layanan meskipun tidak diperkecil menjadi nol tugas, pilih **Paksa hapus layanan**.

1. Pada prompt konfirmasi, masukkan **hapus**, lalu pilih **Hapus**. 

# Memigrasikan ARN layanan pendek Amazon ECS ke ARN panjang
<a name="service-arn-migration"></a>

Amazon ECS memberikan Nama Sumber Daya Amazon (ARN) unik untuk setiap layanan. Layanan yang dibuat sebelum 2021 memiliki format ARN pendek:

 `arn:aws:ecs:region:aws_account_id:service/service-name`

Amazon ECS mengubah format ARN untuk menyertakan nama cluster. Ini adalah format ARN yang panjang:

`arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

Layanan Anda harus memiliki format ARN panjang untuk memberikan tag ke layanan Anda. 

Anda dapat memigrasikan layanan dengan format ARN pendek ke format ARN yang panjang tanpa harus membuat ulang layanan. Anda dapat menggunakan API, CLI, atau konsol. Anda tidak dapat membatalkan operasi migrasi.

Proses migrasi berjalan lancar dan memastikan nol downtime untuk layanan Anda. Selama migrasi:
+ **Ketersediaan layanan**: Layanan Anda terus berjalan normal tanpa gangguan pada lalu lintas atau fungsionalitas.
+ **Menjalankan tugas**: Tugas yang ada terus berjalan tanpa gangguan. Tugas baru yang diluncurkan setelah migrasi akan menggunakan format ARN panjang jika pengaturan `taskLongArnFormat` akun diaktifkan.
+ **Instance kontainer**: Instance kontainer tidak terpengaruh oleh migrasi ARN layanan dan terus beroperasi secara normal.
+ **Konfigurasi layanan**: Semua pengaturan layanan, termasuk definisi tugas, jaringan, dan konfigurasi penyeimbang beban, tetap tidak berubah.

Jika Anda ingin menggunakan CloudFormation untuk menandai layanan dengan format ARN pendek, Anda harus memigrasikan layanan menggunakan API, CLI, atau konsol. Setelah migrasi selesai, Anda dapat menggunakan CloudFormation untuk menandai layanan.

Jika Anda ingin menggunakan Terraform untuk menandai layanan dengan format ARN pendek, Anda harus memigrasikan layanan menggunakan API, CLI, atau konsol. Setelah migrasi selesai, Anda dapat menggunakan Terraform untuk menandai layanan.

Setelah migrasi selesai, layanan memiliki perubahan berikut:
+ Format ARN yang panjang

  `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`
+ Saat Anda bermigrasi menggunakan konsol, Amazon ECS menambahkan tag ke layanan dengan kunci disetel ke “ecs: serviceArnMigrated At” dan nilai yang disetel ke stempel waktu migrasi (format UTC).

  Tag ini diperhitungkan dalam kuota tag Anda.
+ Ketika `PhysicalResourceId` dalam CloudFormation tumpukan mewakili ARN layanan, nilainya tidak berubah dan akan terus menjadi ARN layanan singkat. 

## Prasyarat
<a name="migrate-service-arn-prerequisite"></a>

Lakukan operasi berikut sebelum Anda memigrasikan layanan ARN.

1. Untuk melihat apakah Anda memiliki ARN layanan singkat, lihat detail layanan di konsol Amazon ECS (Anda melihat peringatan ketika layanan memiliki format ARN pendek), atau parameter pengembalian dari. `serviceARN` `describe-services` Ketika ARN tidak menyertakan nama cluster, Anda memiliki ARN pendek. Berikut ini adalah format ARN pendek:

    `arn:aws:ecs:region:aws_account_id:service/service-name`

1. Perhatikan yang dibuat pada tanggal.

1.  Jika Anda memiliki kebijakan IAM yang menggunakan format ARN pendek, perbarui ke format ARN yang panjang.

   Ganti masing-masing *user input placeholder* dengan informasi Anda sendiri.

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

   Untuk informasi selengkapnya, lihat [Mengedit kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html) di *Panduan AWS Identity and Access Management Pengguna*.

1.  Jika Anda memiliki alat yang menggunakan format ARN pendek, perbarui ke format ARN yang panjang.

   Ganti masing-masing *user input placeholder* dengan informasi Anda sendiri.

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

1. Aktifkan format ARN panjang layanan. Jalankan `put-account-setting` dengan `serviceLongArnFormat` opsi yang disetel ke`enabled`. Untuk informasi selengkapnya, lihat, [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)di *Referensi API Amazon Elastic Container Service*.

   Jalankan perintah sebagai pengguna root ketika layanan Anda memiliki `createdAt` tanggal yang tidak diketahui.

   ```
   aws ecs put-account-setting --name serviceLongArnFormat --value enabled
   ```

   Contoh Output

   ```
   {
       "setting": {
           "name": "serviceLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```

1. Aktifkan format ARN tugas yang panjang. Pengaturan akun ini mengontrol format ARN untuk tugas baru yang diluncurkan setelah migrasi layanan selesai. Jalankan `put-account-setting` dengan `taskLongArnFormat` opsi yang disetel ke`enabled`. Untuk informasi selengkapnya, lihat, [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)di *Referensi API Amazon Elastic Container Service*.

   Jalankan perintah sebagai pengguna root ketika layanan Anda memiliki `createdAt` tanggal yang tidak diketahui.

   ```
   aws ecs put-account-setting --name taskLongArnFormat --value enabled
   ```

   Contoh Output

   ```
   {
       "setting": {
           "name": "taskLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```
**catatan**  
`taskLongArnFormat`Pengaturan tidak secara langsung memigrasikan tugas yang ada. Ini hanya mempengaruhi format ARN dari tugas baru yang dibuat setelah pengaturan diaktifkan. Tugas berjalan yang ada mempertahankan format ARN mereka saat ini hingga diganti melalui operasi layanan normal (seperti penerapan atau aktivitas penskalaan).

## Prosedur
<a name="migrate-service-arn-procedure"></a>

Gunakan yang berikut ini untuk memigrasikan ARN layanan Anda.

### Konsol
<a name="migrate-service-arn-procedure-console"></a>

1. Buka konsol di [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Pada halaman **Clusters**, pilih cluster.

1. Di bagian **Layanan**, pilih layanan yang memiliki peringatan di kolom ARN.

   Halaman detail layanan muncul.

1. Pilih **Migrasi ke ARN panjang**.

   Kotak dialog Migrasi layanan muncul.

1. Pilih **Migrasikan**.

### CLI
<a name="migrate-service-arn-procedure-cli"></a>

Setelah Anda menyelesaikan prasyarat, Anda dapat menandai layanan Anda. Jalankan perintah berikut:

Amazon ECS mempertimbangkan untuk meneruskan format ARN panjang dalam `tag-resource` permintaan API untuk layanan dengan ARN pendek sebagai sinyal untuk memigrasikan layanan untuk menggunakan format ARN yang panjang.

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name
    --tags key=key1,value=value1
```

Contoh tag berikut MyService dengan tag yang memiliki kunci disetel ke "TestService" dan nilai yang disetel ke "WebServers:

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:us-east-1:123456789012:service/MyCluster/MyService
    --tags key=TestService1,value=WebServers
```

### Terraform
<a name="migrate-service-arn-procedure-terraform"></a>

Setelah Anda menyelesaikan prasyarat, Anda dapat menandai layanan Anda. Buat `aws_ecs_service` sumber daya dan atur `tags` referensi. Untuk informasi selengkapnya, lihat [Resource: aws\$1ecs\$1service](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_service) di dokumentasi Terraform.

```
resource "aws_ecs_service" "MyService" {
  name    = "example"
  cluster = aws_ecs_cluster.MyService.id

 tags = {
 "Name"  =  "MyService"
 "Environment"  =  "Production"
 "Department"  =  "QualityAssurance"
  }
}
```

### Langkah selanjutnya
<a name="tag-next-steps"></a>

Anda dapat menambahkan tag ke layanan. Untuk informasi selengkapnya, lihat [Menambahkan tag ke sumber daya Amazon ECS](tag-resources-console.md).

Jika Anda ingin Amazon ECS menyebarkan tag dari definisi tugas atau layanan ke tugas, jalankan `update-service` dengan parameter. `propagateTags` *Untuk informasi selengkapnya, lihat [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) di Referensi. AWS Command Line Interface *

## Pemecahan masalah
<a name="troubleshooting-arn-migration"></a>

 Beberapa pengguna mungkin mengalami kesalahan berikut saat mereka bermigrasi dari format ARN pendek ke format ARN yang panjang. 

`There was an error while migrating the ARN of service service-name. The specified account does not have serviceLongArnFormat or taskLongArnFormat account settings enabled. Add account settings in order to enable tagging.` 

 Jika Anda telah mengaktifkan pengaturan `serviceLongArnFormat` akun tetapi masih mengalami kesalahan ini, mungkin karena pengaturan akun untuk format ARN yang panjang belum diaktifkan untuk prinsipal IAM tertentu yang awalnya membuat layanan. 

1.  Identifikasi kepala sekolah yang menciptakan layanan.

   1. Di konsol, informasi tersedia di bidang **Dibuat oleh** di tab **Konfigurasi dan jaringan** pada halaman Detail layanan di konsol Amazon ECS. 

   1. Untuk AWS CLI, jalankan perintah berikut:

      Ganti *user-input* dengan nilai-nilai Anda.

      ```
      aws ecs describe-services --cluster cluster-name --services service-name --query 'services[0].{createdBy: createdBy}'
      ```

1. Aktifkan pengaturan akun yang diperlukan untuk prinsipal tertentu. Anda dapat melakukannya dengan salah satu cara berikut: 

   1.  Asumsikan pengguna IAM atau peran untuk prinsipal itu. Lalu lari`put-account-setting`. 

   1.  Gunakan pengguna root untuk menjalankan perintah sambil menentukan prinsip pembuatan dengan. `principal-arn` 

      Contoh

      Ganti *principal-arn* dengan nilai dari Langkah 1.

      ```
      aws ecs put-account-setting --name serviceLongArnFormat --value enabled --principal-arn arn:aws:iam::123456789012:role/jdoe
      ```

 Kedua metode mengaktifkan pengaturan `serviceLongArnFormat` akun yang diperlukan pada prinsipal yang membuat layanan, yang memungkinkan migrasi ARN untuk melanjutkan. 

# Logika throttle layanan Amazon ECS
<a name="service-throttle-logic"></a>

Penjadwal layanan Amazon ECS menyertakan logika pelindung yang membatasi peluncuran tugas ketika tugas berulang kali gagal dimulai. Ini membantu mencegah konsumsi sumber daya yang tidak perlu dan mengurangi biaya.

Ketika tugas dalam layanan gagal bertransisi dari `PENDING` ke `RUNNING` status dan sebagai gantinya pindah langsung ke`STOPPED`, penjadwal:
+ Secara bertahap meningkatkan waktu antara upaya restart
+ Terus meningkatkan penundaan hingga maksimal 27 menit di antara upaya
+ Menghasilkan pesan acara layanan untuk memberi tahu Anda tentang masalah tersebut

**catatan**  
Periode penundaan maksimum 27 menit dapat berubah di pembaruan di masa mendatang.

Ketika throttling diaktifkan, Anda menerima pesan acara layanan ini:

```
(service service-name) is unable to consistently start tasks successfully.
```

Karakteristik penting dari logika throttle:
+ Layanan melanjutkan upaya coba lagi tanpa batas waktu
+ Satu-satunya modifikasi adalah peningkatan waktu antara restart
+ Tidak ada parameter yang dapat dikonfigurasi pengguna

## Menyelesaikan masalah pelambatan
<a name="resolving-throttling"></a>

Untuk mengatasi pelambatan, Anda dapat:
+ Perbarui layanan untuk menggunakan definisi tugas baru, yang segera mengembalikan layanan ke operasi normal yang tidak dibatasi. Untuk informasi selengkapnya, lihat [Memperbarui layanan Amazon ECS](update-service-console-v2.md).
+ Mengatasi penyebab yang mendasari kegagalan tugas.

Penyebab umum kegagalan tugas yang memicu pelambatan meliputi:
+ Sumber daya cluster tidak mencukupi (port, memori, atau CPU)
  + Ditunjukkan oleh [pesan acara layanan sumber daya yang tidak memadai](service-event-messages-list.md#service-event-messages-1)
+ Kegagalan tarik gambar kontainer
  + Dapat disebabkan oleh nama gambar yang tidak valid, tag, atau izin yang tidak memadai
  + Hasil `CannotPullContainerError` dalam [Melihat Amazon ECS menghentikan kesalahan tugas](stopped-task-errors.md)
+ Ruang disk tak cukup
  + `CannotCreateContainerError`Menghasilkan [kesalahan tugas yang dihentikan](stopped-task-errors.md)
  + Untuk langkah-langkah resolusi, lihat [Memecahkan masalah Docker di Amazon `API error (500): devmapper` ECS](CannotCreateContainerError.md)

**penting**  
Skenario berikut TIDAK memicu logika throttle:  
Tugas yang berhenti setelah mencapai `RUNNING` status
Tugas dihentikan karena pemeriksaan kesehatan Elastic Load Balancing gagal
Tugas di mana perintah kontainer keluar dengan kode bukan nol setelah mencapai status `RUNNING`

# Parameter definisi layanan Amazon ECS
<a name="service_definition_parameters"></a>

Definisi layanan menentukan cara menjalankan layanan Amazon ECS Anda. Parameter berikut dapat ditetapkan dalam ketentuan layanan.

## Tipe peluncuran
<a name="sd-launchtype"></a>

`launchType`  
Tipe: String  
Nilai yang valid: `EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
Wajib: Tidak  
Jenis peluncuran untuk menjalankan layanan Anda. Jika jenis peluncuran tidak ditentukan, default `capacityProviderStrategy` digunakan secara default.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.  
Jika `launchType` ditentukan, parameter `capacityProviderStrategy` harus dihilangkan.

## Strategi penyedia kapasitas
<a name="sd-capacityproviderstrategy"></a>

`capacityProviderStrategy`  
Tipe: Array objek  
Wajib: Tidak  
Strategi penyedia kapasitas untuk digunakan untuk layanan.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.  
Strategi penyedia kapasitas terdiri dari satu penyedia kapasitas atau lebih bersama dengan `base` dan `weight` yang ditetapkan padanya. Penyedia kapasitas harus dikaitkan dengan klaster sebelum ditentukan dalam strategi penyedia kapasitas. PutClusterCapacityProviders API digunakan untuk mengaitkan penyedia kapasitas dengan cluster. Hanya penyedia kapasitas dengan status `ACTIVE` atau `UPDATING` yang dapat digunakan.  
Jika `capacityProviderStrategy` ditetapkan, parameter `launchType` harus dihilangkan. Jika tidak ada `capacityProviderStrategy` atau `launchType` ditentukan, `defaultCapacityProviderStrategy` untuk klaster digunakan.  
Jika Anda ingin menentukan penyedia kapasitas yang menggunakan grup Auto Scaling, penyedia kapasitas harus sudah dibuat. Penyedia kapasitas baru dapat dibuat dengan operasi CreateCapacityProvider API.  
Untuk menggunakan penyedia kapasitas AWS Fargate, tentukan penyedia `FARGATE_SPOT` kapasitas `FARGATE` atau penyedia. Penyedia kapasitas AWS Fargate tersedia untuk semua akun dan hanya perlu dikaitkan dengan cluster yang akan digunakan.  
Operasi PutClusterCapacityProviders API digunakan untuk memperbarui daftar penyedia kapasitas yang tersedia untuk klaster setelah cluster dibuat.    
`capacityProvider`  <a name="capacityProvider"></a>
Tipe: String  
Diperlukan: Ya  
Nama pendek atau nama sumber daya Amazon lengkap (ARN) dari penyedia kapasitas.  
`weight`  <a name="weight"></a>
Jenis: Integer  
Kisaran yang valid: Bilangan bulat antara 0 dan 1.000.  
Wajib: Tidak  
Nilai bobot menunjukkan persentase relatif dari jumlah total tugas yang diluncurkan yang menggunakan penyedia kapasitas yang ditentukan.  
Misalnya, asumsikan bahwa Anda memiliki strategi yang berisi dua penyedia kapasitas dan keduanya memiliki bobot satu. Ketika basis terpenuhi, tugas-tugas terbagi secara merata di dua penyedia kapasitas. *Menggunakan logika yang sama, asumsikan bahwa Anda menentukan bobot 1 untuk *CapacityProvidera* dan bobot 4 untuk CapacityProviderB.* *Kemudian, untuk setiap satu tugas yang dijalankan menggunakan *CapacityProvidera*, empat tugas menggunakan CapacityProviderB.*  
`base`  <a name="base"></a>
Jenis: Integer  
Kisaran valid: Bilangan bulat antara 0 dan 100.000.  
Wajib: Tidak  
Nilai dasar menunjuk berapa banyak tugas, minimal, yang akan berjalan di penyedia kapasitas yang ditentukan. Hanya satu penyedia kapasitas dalam strategi penyedia kapasitas dapat memiliki basis yang ditentukan.

## Ketentuan tugas
<a name="sd-taskdefinition"></a>

`taskDefinition`  
Tipe: String  
Wajib: Tidak  
Nama Sumber Daya Amazon `revision` (ARN`family:revision`) `family` dan () atau lengkap dari definisi tugas yang akan dijalankan di layanan Anda. Jika a `revision` tidak ditentukan, `ACTIVE` revisi terbaru dari keluarga yang ditentukan akan digunakan.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.  
Ketentuan tugas harus ditentukan ketika menggunakan pembaruan bergulir (`ECS`) pengendali deployment.

## Sistem operasi platform
<a name="platform-os"></a>

`platformFamily`  
Jenis: string  
Wajib: Bersyarat  
Standar: Linux  
Parameter ini diperlukan untuk layanan Amazon ECS yang dihosting di Fargate.  
Parameter ini diabaikan untuk layanan Amazon ECS yang dihosting di Amazon EC2.  
Sistem operasi pada kontainer yang menjalankan layanan. Nilai yang valid adalah`LINUX`,`WINDOWS_SERVER_2019_FULL`,`WINDOWS_SERVER_2019_CORE`,`WINDOWS_SERVER_2022_FULL`, dan`WINDOWS_SERVER_2022_CORE`.  
`platformFamily`Nilai untuk setiap tugas yang Anda tentukan untuk layanan harus sesuai dengan `platformFamily` nilai layanan. Misalnya, jika Anda mengatur `platformFamily` ke`WINDOWS_SERVER_2019_FULL`, `platformFamily` nilai untuk semua tugas harus`WINDOWS_SERVER_2019_FULL`.

## Versi Platform
<a name="sd-platformversion"></a>

`platformVersion`  
Tipe: String  
Wajib: Tidak  
Versi platform tempat tugas Anda dalam layanan berjalan. Versi platform hanya ditentukan untuk tugas yang menggunakan tipe peluncuran Fargate. Jika tidak ditentukan, versi terbaru (`LATEST`) digunakan secara default.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.  
AWS Versi platform Fargate digunakan untuk merujuk ke lingkungan runtime tertentu untuk infrastruktur tugas Fargate. Saat menentukan versi `LATEST` platform saat menjalankan tugas atau membuat layanan, Anda mendapatkan versi platform terbaru yang tersedia untuk tugas Anda. Saat Anda meningkatkan layanan Anda, tugas-tugas tersebut menerima versi platform yang ditentukan pada penerapan layanan saat ini. Untuk informasi selengkapnya, lihat [Versi platform Fargate untuk Amazon ECS](platform-fargate.md).  
Versi platform tidak ditentukan untuk tugas yang menggunakan tipe peluncuran EC2.

## Kluster
<a name="sd-cluster"></a>

`cluster`  
Tipe: String  
Wajib: Tidak  
Nama pendek atau Amazon Resource Name (ARN) lengkap dari klaster untuk menjalankan layanan Anda. Jika Anda tidak menentukan cluster, `default` cluster diasumsikan.

## Nama layanan
<a name="sd-servicename"></a>

`serviceName`  
Tipe: String  
Diperlukan: Ya  
Nama layanan Anda. Mengizinkan hingga 255 huruf (huruf besar dan huruf kecil), angka, tanda hubung, dan garis bawah. Nama layanan harus unik dalam sebuah klaster, tetapi Anda dapat memiliki layanan yang bernama sama di beberapa klaster dalam satu Wilayah atau lebih.

## Strategi penjadwalan
<a name="sd-schedulingstrategy"></a>

`schedulingStrategy`  
Tipe: String  
Nilai yang valid: `REPLICA` \$1 `DAEMON`  
Wajib: Tidak  
Strategi penjadwalan yang boleh digunakan. Jika strategi penjadwalan tidak ditentukan, maka strategi `REPLICA` digunakan. Untuk informasi selengkapnya, lihat [Layanan-layanan Amazon ECS](ecs_services.md).  
Ada dua strategi penjadwal layanan yang tersedia:  
+ `REPLICA`Strategi penjadwalan replika menempatkan dan mempertahankan jumlah tugas yang diinginkan di seluruh cluster Anda. Secara default tugas tersebar di seluruh Availability Zone. Anda dapat menggunakan strategi penempatan tugas dan kendala untuk menyesuaikan keputusan penempatan tugas. Untuk informasi selengkapnya, lihat [Strategi penjadwalan replika](ecs_service-options.md#service_scheduler_replica).
+ `DAEMON`—Strategi penjadwalan daemon menerapkan tepat satu tugas pada setiap instance kontainer aktif yang memenuhi semua batasan penempatan tugas yang Anda tentukan di cluster Anda. Saat menggunakan strategi ini, tidak perlu menentukan jumlah tugas yang diinginkan, strategi penempatan tugas, atau menggunakan kebijakan Auto Scaling Layanan. Untuk informasi selengkapnya, lihat [Strategi penjadwalan daemon](ecs_service-options.md#service_scheduler_daemon).
**catatan**  
Tugas Fargate tidak mendukung strategi `DAEMON` penjadwalan.

## Jumlah yang diinginkan
<a name="sd-desiredcount"></a>

`desiredCount`  
Tipe: Integer  
Wajib: Tidak  
Jumlah instantiasi dari definisi tugas yang ditentukan untuk ditempatkan dan terus berjalan di layanan Anda.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.  
Parameter ini diperlukan jika strategi penjadwalan `REPLICA` digunakan. Jika layanan menggunakan strategi penjadwalan `DAEMON`, parameter ini bersifat opsional.  
Saat Anda menggunakan penskalaan otomatis layanan, saat memperbarui layanan yang sedang berjalan dengan jumlah tugas yang sedang berjalan `desiredCount` kurang dari jumlah tugas yang sedang berjalan, layanan akan menurunkan skala ke yang ditentukan`desiredCount`. 

## Konfigurasi deployment
<a name="sd-deploymentconfiguration"></a>

`deploymentConfiguration`  
Tipe: Objek  
Wajib: Tidak  
Parameter deployment opsional yang mengendalikan berapa banyak tugas yang berjalan selama deployment dan pengurutan tugas berhenti dan memulai.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.    
`maximumPercent`  <a name="maximumPercent"></a>
Tipe: Integer  
Wajib: Tidak  
Jika layanan menggunakan tipe penerapan rolling update (`ECS`), `maximumPercent` parameter tersebut mewakili batas atas jumlah tugas layanan Anda yang diizinkan dalam `RUNNING``STOPPING`, atau `PENDING` status selama penerapan. Hal ini dinyatakan sebagai persentase dari `desiredCount` yang dibulatkan ke bawah ke bilangan bulat terdekat. Anda dapat menggunakan parameter ini untuk menentukan ukuran batch deployment. Misalnya, jika layanan Anda menggunakan penjadwal `REPLICA` layanan dan memiliki `desiredCount` empat tugas dan `maximumPercent` nilai 200%, penjadwal memulai empat tugas baru sebelum menghentikan empat tugas lama. Ini asalkan sumber daya cluster yang diperlukan untuk melakukan ini tersedia. Nilai `maximumPercent` default untuk layanan yang menggunakan penjadwal layanan `REPLICA` adalah 200%.  
Penjadwal Amazon ECS menggunakan parameter ini untuk mengganti tugas yang tidak sehat dengan memulai tugas pengganti terlebih dahulu dan kemudian menghentikan tugas yang tidak sehat, selama sumber daya cluster untuk memulai tugas pengganti tersedia. Untuk informasi selengkapnya tentang cara penjadwal menggantikan tugas yang tidak sehat, lihat. [Layanan-layanan Amazon ECS](ecs_services.md)  
Jika layanan Anda menggunakan jenis penjadwal `DAEMON` layanan, `maximumPercent` harus tetap pada 100%. Ini adalah nilai default.  
Jumlah maksimum tugas selama deployment adalah `desiredCount` dikalikan dengan `maximumPercent`/100, dibulatkan ke bawah ke nilai integer terdekat.  
Jika layanan menggunakan jenis dan tugas biru/hijau (`CODE_DEPLOY`) atau `EXTERNAL` penerapan yang menggunakan tipe peluncuran EC2, nilai **persen maksimum** disetel ke nilai default. Nilai digunakan untuk menentukan batas atas jumlah tugas dalam layanan yang tetap dalam `RUNNING` status saat instance kontainer berada dalam `DRAINING` status.  
Anda tidak dapat menentukan `maximumPercent` nilai kustom untuk layanan yang menggunakan jenis biru/hijau (`CODE_DEPLOY`) atau `EXTERNAL` penerapan dan memiliki tugas yang menggunakan EC2.
Jika layanan menggunakan jenis biru/hijau (`CODE_DEPLOY`) atau `EXTERNAL` penerapan, dan tugas dalam layanan menggunakan Fargate, nilai persen maksimum tidak digunakan. Nilai masih dikembalikan saat menjelaskan layanan Anda.  
`minimumHealthyPercent`  <a name="minimumHealthyPercent"></a>
Tipe: Integer  
Wajib: Tidak  
Jika layanan menggunakan tipe penerapan rolling update (`ECS`), layanan tersebut `minimumHealthyPercent` mewakili batas bawah jumlah tugas layanan Anda yang harus tetap berada dalam `RUNNING` status selama penerapan. Ini dinyatakan sebagai persentase dari `desiredCount` yang dibulatkan ke bilangan bulat terdekat. Anda dapat menggunakan parameter ini untuk menyebarkan tanpa menggunakan kapasitas cluster tambahan.  
Misalnya, jika layanan Anda memiliki `desiredCount` empat tugas, 50%, dan 100%, penjadwal layanan menghentikan dua tugas yang ada untuk membebaskan kapasitas cluster sebelum memulai dua tugas baru. `minimumHealthyPercent` `maximumPercent`   
 Jika ada tugas yang tidak sehat dan jika `maximumPercent` tidak memungkinkan penjadwal Amazon ECS untuk memulai tugas penggantian, penjadwal menghentikan tugas yang tidak sehat one-by-one — menggunakan `minimumHealthyPercent` sebagai kendala — untuk membersihkan kapasitas untuk meluncurkan tugas pengganti. Untuk informasi selengkapnya tentang cara penjadwal menggantikan tugas yang tidak sehat, lihat. [Layanan-layanan Amazon ECS](ecs_services.md)  
Untuk layanan yang *tidak* menggunakan penyeimbang beban, pertimbangkan hal berikut:  
+ Sebuah layanan dianggap baik jika semua kontainer penting dalam tugas dalam layanan lulus pemeriksaan kondisi.
+ Jika tugas tidak memiliki wadah penting dengan pemeriksaan kesehatan yang ditentukan, penjadwal layanan menunggu selama 40 detik setelah tugas mencapai `RUNNING` keadaan sebelum tugas dihitung terhadap total persen sehat minimum.
+ Jika suatu tugas memiliki satu atau lebih wadah penting dengan pemeriksaan kesehatan yang ditentukan, penjadwal layanan menunggu tugas mencapai status sehat sebelum menghitungnya ke total persen sehat minimum. Sebuah tugas dianggap baik ketika semua kontainer penting dalam tugas telah lulus pemeriksaan kondisi. Jumlah waktu tunggu penjadwal layanan ditentukan oleh pengaturan pemeriksaan kondisi kontainer. Untuk informasi selengkapnya, lihat [Pemeriksaan kondisi](task_definition_parameters.md#container_definition_healthcheck). 
Untuk layanan *yang* menggunakan load balancer, perhatikan hal berikut:  
+ Jika suatu tugas tidak memiliki wadah penting dengan pemeriksaan kesehatan yang ditentukan, penjadwal layanan menunggu pemeriksaan kesehatan kelompok sasaran penyeimbang beban untuk mengembalikan status sehat sebelum menghitung tugas menuju total persen sehat minimum.
+ Jika tugas memiliki wadah penting dengan pemeriksaan kesehatan yang ditentukan, penjadwal layanan menunggu tugas untuk mencapai status sehat dan pemeriksaan kesehatan kelompok target penyeimbang beban untuk mengembalikan status sehat sebelum menghitung tugas menuju total persen sehat minimum.
Nilai default untuk layanan replika untuk `minimumHealthyPercent` adalah 100%. `minimumHealthyPercent`Nilai default untuk layanan yang menggunakan jadwal `DAEMON` layanan adalah 0% untuk AWS CLI AWS SDKs, the, APIs dan 50% untuk Konsol Manajemen AWS.  
Jumlah minimal tugas sehat selama deployment adalah `desiredCount` dikalikan dengan `minimumHealthyPercent`/100, dibulatkan ke atas ke nilai bilangan bulat terdekat.  
Jika layanan menggunakan tipe biru/hijau (`CODE_DEPLOY`) atau `EXTERNAL` penerapan dan menjalankan tugas yang menggunakan EC2, nilai **persen sehat minimum** disetel ke nilai default. Nilai digunakan untuk menentukan batas bawah pada jumlah tugas dalam layanan yang tetap dalam `RUNNING` status saat instance kontainer berada dalam `DRAINING` status.  
Anda tidak dapat menentukan `maximumPercent` nilai kustom untuk layanan yang menggunakan jenis biru/hijau (`CODE_DEPLOY`) atau `EXTERNAL` penerapan dan memiliki tugas yang menggunakan EC2.
Jika layanan menggunakan jenis biru/hijau (`CODE_DEPLOY`) atau `EXTERNAL` penerapan dan menjalankan tugas yang menggunakan Fargate, nilai persen sehat minimum tidak digunakan, meskipun dikembalikan saat menjelaskan layanan Anda.

## Pengendali deployment
<a name="sd-deploymentcontroller"></a>

`deploymentController`  
Tipe: Objek  
Wajib: Tidak  
Pengendali deployment yang bisa digunakan untuk layanan. Jika pengendali deployment tidak ditentukan, maka digunakan pengendali `ECS`. Untuk informasi selengkapnya, lihat [Layanan-layanan Amazon ECS](ecs_services.md).  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.    
`type`  
Tipe: String  
Nilai yang valid: `ECS` \$1 `CODE_DEPLOY` \$1 `EXTERNAL`  
Wajib: ya  
Tipe pengendali deployment yang bisa digunakan. Tersedia tiga tipe pengendali deployment:    
`ECS`  
Pengontrol penyebaran Amazon ECS mendukung beberapa strategi penerapan: pembaruan bergulir, blue/green, linear, and canary. The rolling update deployment type involves replacing the current running version of the container with the latest version. Blue/green penerapan menciptakan lingkungan baru, dan mengalihkan lalu lintas sekaligus. Penerapan linier secara bertahap menggeser lalu lintas dalam peningkatan persentase yang sama. Penyebaran Canary menggeser sebagian kecil lalu lintas terlebih dahulu, kemudian menggeser lalu lintas yang tersisa. Jumlah kontainer Amazon ECS yang ditambahkan atau dihapus dari layanan selama pembaruan bergulir dikendalikan dengan menyesuaikan jumlah minimum dan maksimum tugas sehat yang diizinkan selama penerapan layanan, seperti yang ditentukan dalam. [deploymentConfiguration](#deploymentConfiguration)  
`CODE_DEPLOY`  
Jenis penyebaran blue/green (`CODE_DEPLOY`) menggunakan model blue/green penerapan yang didukung oleh CodeDeploy, yang memungkinkan Anda memverifikasi penerapan layanan baru sebelum mengirimkan lalu lintas produksi ke sana.  
`EXTERNAL`  
Gunakan jenis penerapan eksternal saat Anda ingin menggunakan pengontrol penerapan pihak ketiga untuk kontrol penuh atas proses penyebaran untuk layanan Amazon ECS.

## Penempatan Tugas
<a name="sd-taskplacement"></a>

`placementConstraints`  
Tipe: Array objek  
Wajib: Tidak  
Aray objek batasan penempatan yang digunakan untuk tugas dalam layanan Anda. Anda dapat menentukan maksimum 10 kendala per tugas. Batas ini mencakup kendala dalam definisi tugas dan yang ditentukan pada waktu berjalan. Jika Anda menggunakan Fargate, batasan penempatan tugas tidak didukung.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.    
`type`  
Tipe: String  
Wajib: Tidak  
Tipe batasan. Gunakan `distinctInstance` untuk memastikan bahwa setiap tugas dalam grup tertentu berjalan di instans kontainer yang berbeda. Gunakan `memberOf` untuk membatasi seleksi ke grup kandidat yang valid. Nilai `distinctInstance` tidak didukung dalam ketentuan tugas.  
`expression`  
Tipe: String  
Wajib: Tidak  
Ekspresi bahasa kueri klaster untuk diterapkan pada batasan. Ingat bahwa Anda tidak dapat menentukan ekspresi jika tipe kendalanya adalah `distinctInstance`. Untuk informasi selengkapnya, lihat [Buat ekspresi untuk menentukan instance kontainer untuk tugas Amazon ECS](cluster-query-language.md).

`placementStrategy`  
Tipe: Array objek  
Wajib: Tidak  
Objek strategi penempatan untuk digunakan untuk tugas di layanan Anda. Anda dapat menentukan maksimal empat aturan strategi per layanan.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.    
`type`  
Tipe: String  
Nilai yang valid: `random` \$1 `spread` \$1 `binpack`  
Wajib: Tidak  
Tipe strategi penempatan. Strategi penempatan `random` menempatkan tugas pada kandidat yang tersedia secara acak. Strategi penempatan `spread` menyebarkan penempatan di seluruh kandidat yang tersedia secara merata berdasarkan parameter `field`. `binpack`Strategi menempatkan tugas pada kandidat yang tersedia yang memiliki jumlah sumber daya paling sedikit yang tersedia yang ditentukan dengan `field` parameter. Misalnya, jika Anda binpack pada memori, tugas ditempatkan pada instance dengan jumlah memori yang tersisa paling sedikit tetapi masih cukup untuk menjalankan tugas.  
`field`  
Tipe: String  
Wajib: Tidak  
Bidang tempat menerapkan strategi penempatan. Untuk strategi `spread` penempatan, nilai yang valid adalah `instanceId` (atau`host`, yang memiliki efek yang sama), atau platform atau atribut khusus apa pun yang diterapkan ke instance container, seperti`attribute:ecs.availability-zone`. Untuk strategi penempatan `binpack`, nilai yang valid adalah `cpu` dan `memory`. Untuk strategi penempatan `random`, bidang ini tidak digunakan.

## Tanda
<a name="sd-tags"></a>

`tags`  
Tipe: Array objek   
Wajib: Tidak  
Metadata yang Anda terapkan ke layanan untuk membantu Anda mengkategorikan dan mengaturnya. Setiap tag terdiri atas sebuah kunci dan sebuah nilai opsional, dan Anda menentukan sendiri keduanya. Ketika layanan dihapus, tag akan dihapus juga. Maksimal 50 tag dapat diterapkan ke layanan. Untuk informasi selengkapnya, lihat [Menandai sumber daya Amazon ECS](ecs-using-tags.md).  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.    
`key`  
Tipe: String  
Batasan Panjang: Panjang minimum 1. Panjang maksimum 128.  
Wajib: Tidak  
Satu bagian dari pasangan nilai kunci yang membentuk tanda. Kunci adalah label umum yang bertindak seperti kategori untuk nilai tanda yang lebih spesifik.  
`value`  
Tipe: String  
Batasan Panjang: Panjang minimum 0. Panjang maksimum 256.  
Wajib: Tidak  
Bagian opsional pasangan nilai kunci yang membentuk tanda. Nilai bertindak sebagai deskriptor dalam kategori tanda (kunci).

`enableECSManagedTags`  
Jenis: Boolean  
Nilai yang valid: `true` \$1 `false`  
Wajib: Tidak  
Menentukan apakah akan menggunakan tag terkelola Amazon ECS untuk tugas dalam layanan. Jika tidak ada nilai yang ditentukan, nilai defaultnya adalah `false`. Untuk informasi selengkapnya, lihat [Gunakan tag untuk penagihan](ecs-using-tags.md#tag-resources-for-billing).  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.

`propagateTags`  
Tipe: String  
Nilai yang valid: `TASK_DEFINITION` \$1 `SERVICE`  
Wajib: Tidak  
Menentukan apakah akan menyalin tag dari definisi tugas atau layanan untuk tugas-tugas dalam layanan. Jika tidak ada nilai yang ditentukan, tag tidak disalin. Tag hanya dapat disalin ke tugas dalam layanan selama pembuatan layanan. Untuk menambahkan tag ke tugas setelah pembuatan layanan atau pembuatan tugas, gunakan tindakan `TagResource` API.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.

## Konfigurasi jaringan
<a name="sd-networkconfiguration"></a>

`networkConfiguration`  
Tipe: Objek  
Wajib: Tidak  
Konfigurasi jaringan untuk layanan. Parameter ini diperlukan untuk definisi tugas yang menggunakan mode `awsvpc` jaringan untuk menerima Antarmuka Jaringan Elastis mereka sendiri, dan tidak didukung untuk mode jaringan lainnya. Jika menggunakan Fargate, mode `awsvpc` jaringan diperlukan. Untuk informasi lebih lanjut tentang jaringan untuk EC2, lihat[Opsi Jaringan Tugas Amazon ECS untuk EC2](task-networking.md). Untuk informasi selengkapnya tentang jaringan untuk Fargate, lihat opsi [jaringan tugas Amazon ECS untuk](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) Fargate.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.    
`awsvpcConfiguration`  
Tipe: Objek  
Wajib: Tidak  
Sebuah objek yang menunjukkan subnet dan grup keamanan untuk tugas atau layanan.    
`subnets`  
Tipe: Array string  
Wajib: Ya  
Subnet yang terkait dengan tugas atau layanan. Ada batas 16 subnet yang dapat ditentukan sesuai dengan`awsvpcConfiguration`.  
`securityGroups`  
Tipe: Array string  
Wajib: Tidak  
Grup keamanan yang terkait dengan tugas atau layanan. Jika Anda tidak menentukan grup keamanan, grup keamanan default untuk VPC akan digunakan. Ada batas lima grup keamanan yang dapat ditentukan berdasarkan`awsvpcConfiguration`.  
`assignPublicIP`  
Tipe: String  
Nilai yang valid: `ENABLED` \$1 `DISABLED`  
Wajib: Tidak  
Apakah antarmuka jaringan elastis tugas menerima alamat IP publik. Jika nilai tidak ditentukan, maka digunakan nilai default `DISABLED`.

`healthCheckGracePeriodSeconds`  
Tipe: Integer  
Wajib: Tidak  
Periode waktu, dalam hitungan detik, bahwa penjadwal layanan Amazon ECS mengabaikan Elastic Load Balancing, VPC Lattice, dan pemeriksaan kesehatan kontainer yang tidak sehat setelah tugas pertama kali dimulai. Jika Anda tidak menentukan nilai periode tunggu pemeriksaan kondisi, nilai default 0 akan digunakan. Jika Anda tidak menggunakan salah satu pemeriksaan kondisi, maka `healthCheckGracePeriodSeconds` tidak digunakan.  
Jika tugas layanan Anda membutuhkan waktu beberapa saat untuk memulai dan merespons, Anda dapat menentukan periode tunggu pemeriksaan kondisi hingga 2.147.483.647 detik (sekitar 69 tahun). Selama waktu itu, penjadwal layanan Amazon ECS mengabaikan status pemeriksaan kesehatan. Masa tenggang ini dapat mencegah penjadwal layanan menandai tugas sebagai tidak sehat dan menghentikan mereka sebelum mereka memiliki waktu untuk muncul.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.

`loadBalancers`  
Tipe: Array objek   
Wajib: Tidak  
Sebuah objek penyeimbang beban menunjukkan penyeimbang beban untuk digunakan dengan layanan Anda. Untuk layanan yang menggunakan Application Load Balancer atau Network Load Balancer, ada batasan lima grup target yang dapat Anda lampirkan ke layanan.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.  
Setelah Anda membuat layanan, konfigurasi penyeimbang beban tidak dapat diubah dari. Konsol Manajemen AWS Anda dapat menggunakan AWS Copilot, AWS CloudFormation, AWS CLI atau SDK untuk memodifikasi konfigurasi penyeimbang beban hanya untuk pengontrol penerapan `ECS` bergulir, bukan biru/hijau atau eksternal. AWS CodeDeploy Saat Anda menambahkan, memperbarui, atau menghapus konfigurasi penyeimbang beban, Amazon ECS memulai penerapan baru dengan konfigurasi Elastic Load Balancing yang diperbarui. Hal ini menyebabkan tugas mendaftar dan membatalkan pendaftaran dari penyeimbang beban. Kami menyarankan Anda memverifikasi ini di lingkungan pengujian sebelum memperbarui konfigurasi Elastic Load Balancing. Untuk informasi tentang cara mengubah konfigurasi, lihat [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)di *Referensi API Amazon Elastic Container Service*.  
Untuk Application Load Balancers dan Network Load Balancers, objek ini harus berisi kelompok target load balancer ARN, nama kontainer (seperti yang muncul dalam definisi kontainer), dan port kontainer untuk mengakses dari penyeimbang beban. Ketika tugas dari layanan ini ditempatkan pada instance kontainer, instance kontainer dan kombinasi port terdaftar sebagai target dalam kelompok target yang ditentukan.    
`targetGroupArn`  
Tipe: String  
Wajib: Tidak  
Nama Sumber Daya Amazon (ARN) lengkap dari grup target Elastic Load Balancing yang terkait dengan layanan.  
ARN grup target hanya ditentukan saat menggunakan Application Load Balancer atau Penyeimbang Beban Jaringan.  
`loadBalancerName`  
Tipe: String  
Wajib: Tidak  
Nama penyeimbang beban untuk dikaitkan dengan layanan.  
Jika Anda menggunakan Application Load Balancer atau Network Load Balancer, hilangkan parameter nama load balancer.  
`containerName`  
Tipe: String  
Wajib: Tidak  
Nama kontainer (seperti yang muncul dalam ketentuan kontainer) untuk dikaitkan dengan penyeimbang beban.  
`containerPort`  
Tipe: Bilangan bulat  
Wajib: Tidak  
Port pada kontainer untuk dikaitkan dengan penyeimbang beban. Port ini harus sesuai dengan `containerPort` dalam ketentuan tugas yang digunakan oleh tugas dalam layanan. Untuk tugas yang menggunakan EC2, instance container harus mengizinkan lalu lintas masuk pada `hostPort` pemetaan port.

`role`  
Tipe: String  
Wajib: Tidak  
Nama pendek atau ARN lengkap dari peran IAM yang memungkinkan Amazon ECS melakukan panggilan ke penyeimbang beban Anda atas nama Anda. Parameter ini hanya diizinkan jika Anda menggunakan penyeimbang beban dengan satu grup target untuk layanan Anda, dan definisi tugas Anda tidak menggunakan mode `awsvpc` jaringan. Jika Anda menentukan `role` parameter, Anda juga harus menentukan objek penyeimbang beban dengan `loadBalancers` parameter.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.  
Jika peran yang Anda tentukan memiliki jalur selain `/`, maka Anda harus menentukan ARN peran penuh (dianjurkan) atau awalan nama peran dengan jalur. Misalnya, jika peran dengan nama `bar` memiliki jalur dari `/foo/` maka Anda akan menentukan `/foo/bar` sebagai nama peran. Untuk informasi selengkapnya, lihat [Nama dan Jalur Ramah](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) di *Panduan Pengguna IAM*.  
Jika akun Anda telah membuat peran terkait layanan Amazon ECS, peran tersebut digunakan secara default untuk layanan Anda kecuali Anda menentukan peran di sini. Peran terkait layanan diperlukan jika definisi tugas Anda menggunakan mode jaringan awsvpc, dalam hal ini Anda tidak boleh menentukan peran di sini. Untuk informasi selengkapnya, lihat [Menggunakan peran terkait layanan untuk Amazon ECS](using-service-linked-roles.md).

`serviceConnectConfiguration`  
Tipe: Objek  
Wajib: Tidak  
Konfigurasi untuk layanan ini untuk menemukan dan terhubung ke layanan, dan ditemukan oleh, dan terhubung dari, layanan lain dalam namespace.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.  
Untuk informasi selengkapnya, lihat [Menggunakan Service Connect untuk menghubungkan layanan Amazon ECS dengan nama pendek](service-connect.md).    
`enabled`  
Jenis: Boolean  
Wajib: Ya  
Menentukan apakah akan menggunakan Service Connect dengan layanan ini.   
`namespace`  
Tipe: String  
Wajib: Tidak  
Nama pendek atau nama sumber daya Amazon lengkap (ARN) dari AWS Cloud Map namespace untuk digunakan dengan Service Connect. Namespace harus berada di Wilayah AWS yang sama dengan layanan Amazon ECS dan klaster. Jenis namespace tidak memengaruhi Service Connect. Untuk informasi selengkapnya AWS Cloud Map, lihat [Bekerja dengan Layanan](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html) di *Panduan AWS Cloud Map Pengembang*.  
`services`  
Tipe: Array objek   
Wajib: Tidak  
Array objek layanan Service Connect. Ini adalah nama dan alias (juga dikenal sebagai titik akhir) yang digunakan oleh layanan Amazon ECS lainnya untuk terhubung ke layanan ini.  
Bidang ini tidak diperlukan untuk layanan Amazon ECS “klien” yang merupakan anggota namespace hanya untuk terhubung ke layanan lain di dalam namespace. Contohnya adalah aplikasi frontend yang menerima permintaan masuk dari penyeimbang beban yang dilampirkan ke layanan atau dengan cara lain.  
Objek memilih port dari definisi tugas, menetapkan nama untuk AWS Cloud Map layanan, dan array alias (juga dikenal sebagai titik akhir) dan port untuk aplikasi klien untuk merujuk ke layanan ini.    
`portName`  
Tipe: String  
Diperlukan: Ya  
`portName`Harus cocok dengan `name` salah satu `portMappings` dari semua wadah dalam definisi tugas layanan Amazon ECS ini.  
`discoveryName`  
Tipe: String  
Wajib: Tidak  
`discoveryName`Itu adalah nama AWS Cloud Map layanan baru yang dibuat Amazon ECS untuk layanan Amazon ECS ini. Ini harus unik di dalam AWS Cloud Map namespace.  
Jika bidang ini tidak ditentukan, `portName` digunakan.  
`clientAliases`  
Tipe: Array objek   
Wajib: Tidak  
Daftar alias klien untuk layanan koneksi layanan ini. Anda menggunakan ini untuk menetapkan nama yang dapat digunakan oleh aplikasi klien. Jumlah maksimum alias klien yang dapat Anda miliki dalam daftar ini adalah 1.  
Setiap alias (“endpoint”) adalah nama DNS dan nomor port yang dapat digunakan layanan Amazon ECS lainnya (“klien”) untuk terhubung ke layanan ini.  
Setiap kombinasi nama dan port harus unik di dalam namespace.  
Nama-nama ini dikonfigurasi dalam setiap tugas layanan klien, bukan di AWS Cloud Map. Permintaan DNS untuk menyelesaikan nama-nama ini tidak meninggalkan tugas, dan tidak dihitung terhadap kuota permintaan DNS per detik per elastic network interface.    
`port`  
Jenis: Integer  
Wajib: Ya  
Nomor port mendengarkan untuk proxy koneksi layanan. Port ini tersedia di dalam semua tugas dalam namespace yang sama.  
Untuk menghindari perubahan aplikasi Anda di layanan Amazon ECS klien, atur ini ke port yang sama yang digunakan aplikasi klien secara default.  
`dnsName`  
Tipe: String  
Wajib: Tidak  
Itu `dnsName` adalah nama yang Anda gunakan dalam aplikasi tugas klien untuk terhubung ke layanan ini. Nama harus berupa label DNS yang valid.  
Nilai default adalah `discoveryName.namespace` jika bidang ini tidak ditentukan. Jika `discoveryName` tidak ditentukan, definisi `portName` dari tugas digunakan.  
Untuk menghindari perubahan aplikasi Anda di layanan Amazon ECS klien, atur ini ke nama yang sama dengan yang digunakan aplikasi klien secara default. Misalnya, beberapa nama umum adalah`database`,`db`, atau nama huruf kecil dari database, seperti `mysql` atau. `redis`  
`ingressPortOverride`  
Tipe: Integer  
Wajib: Tidak  
(Opsional) Nomor port untuk proxy Service Connect untuk didengarkan.  
Gunakan nilai bidang ini untuk melewati proxy untuk lalu lintas pada nomor port yang ditentukan dalam nama `portMapping` dalam definisi tugas aplikasi ini, lalu gunakan di grup keamanan Amazon VPC Anda untuk mengizinkan lalu lintas ke proxy untuk layanan Amazon ECS ini.  
Dalam `awsvpc` mode, nilai default adalah nomor port kontainer yang ditentukan dalam nama `portMapping` dalam definisi tugas aplikasi ini. Dalam `bridge` mode, nilai default adalah port singkat dinamis dari proxy Service Connect.  
`logConfiguration`  
Jenis: [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)Objek  
Wajib: Tidak  
Ini menentukan di mana log proxy Service Connect dipublikasikan. Gunakan log untuk debugging selama kejadian tak terduga. Konfigurasi ini menetapkan `logConfiguration` parameter dalam wadah proxy Service Connect di setiap tugas di layanan Amazon ECS ini. Kontainer proxy tidak ditentukan dalam definisi tugas.  
Kami menyarankan Anda menggunakan konfigurasi log yang sama dengan wadah aplikasi definisi tugas untuk layanan Amazon ECS ini. Untuk FireLens, ini adalah konfigurasi log dari wadah aplikasi. Bukan wadah router FireLens log yang menggunakan gambar `fluent-bit` atau `fluentd ` kontainer.  
`accessLogConfiguration`  
Jenis: [ServiceConnectAccessLogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)Objek  
Wajib: Tidak  
Konfigurasi untuk pencatatan akses Service Connect termasuk format log dan apakah log harus menyertakan string kueri. Log akses menangkap informasi terperinci tentang permintaan yang dibuat ke layanan Anda, termasuk pola permintaan, kode respons, dan data waktu. Untuk mengaktifkan log akses, Anda juga harus menentukan a `logConfiguration` di`serviceConnectConfiguration`.

`serviceRegistries`  
Tipe: Array objek   
Wajib: Tidak  
Detail konfigurasi pencari layanan untuk layanan Anda. Untuk informasi selengkapnya, lihat [Gunakan penemuan layanan untuk menghubungkan layanan Amazon ECS dengan nama DNS](service-discovery.md).  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.    
`registryArn`  
Tipe: String  
Wajib: Tidak  
Nama Sumber Daya Amazon (ARN) dari registri layanan. Registri layanan yang saat ini didukung adalah AWS Cloud Map. Untuk informasi selengkapnya, lihat [Bekerja dengan Layanan](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html) di *Panduan AWS Cloud Map Pengembang*.  
`port`  
Tipe: Integer  
Wajib: Tidak  
Nilai port yang digunakan jika layanan penemuan layanan Anda menentukan catatan SRV. Kolom ini wajib diisi jika mode jaringan `awsvpc` dan catatan SRV digunakan.  
`containerName`  
Tipe: String  
Wajib: Tidak  
Nilai nama kontainer yang akan digunakan untuk layanan penemuan layanan Anda. Nilai ini ditentukan dalam definisi tugas. Jika ketentuan tugas yang menentukan tugas layanan Anda menggunakan mode jaringan `bridge` atau `host`, Anda harus menentukan kombinasi `containerName` dan `containerPort` dari ketentuan tugas. Jika ketentuan tugas yang ditentukan oleh tugas layanan Anda menggunakan mode jaringan `awsvpc` dan tipe catatan SRV DNS digunakan, Anda harus menentukan apakah akan menggunakan salah satu kombinasi `containerName` dan `containerPort` atau nilai `port`, tetapi tidak keduanya.  
`containerPort`  
Tipe: Integer  
Wajib: Tidak  
Nilai port yang akan digunakan untuk layanan penemuan layanan Anda. Nilai ini ditentukan dalam definisi tugas. Jika ketentuan tugas yang ditentukan oleh tugas layanan Anda menggunakan mode jaringan `bridge` atau `host`, Anda harus menentukan kombinasi `containerName` dan `containerPort` dari ketentuan tugas. Jika ketentuan tugas yang ditentukan oleh tugas layanan Anda menggunakan mode jaringan `awsvpc` dan tipe catatan SRV DNS digunakan, Anda harus menentukan apakah akan menggunakan salah satu kombinasi `containerName` dan `containerPort` atau nilai `port`, tetapi tidak keduanya.

## Token klien
<a name="sd-clienttoken"></a>

`clientToken`  
Tipe: String  
Wajib: Tidak  
Pengidentifikasi unik dan peka huruf besar/kecil yang Anda berikan untuk memastikan idempotensi permintaan. Panjangnya bisa mencapai 32 karakter ASCII.

## Penyeimbangan beban ulang Zona Ketersediaan
<a name="sd-availability-zone-rebalancing"></a>

`availabilityZoneRebalancing`  
Tipe: String  
Wajib: Tidak  
Menunjukkan apakah layanan menggunakan penyeimbangan kembali Availability Zone. Nilai yang valid adalah `ENABLED` dan `DISABLED`.  
Saat Anda memperbarui layanan, parameter ini tidak memicu penerapan layanan baru.  
Perilaku default:  
+ Untuk layanan baru: Jika tidak ada nilai yang ditentukan, defaultnya adalah`DISABLED`.
+ Untuk layanan yang ada: Jika tidak ada nilai yang ditentukan, Amazon ECS akan me-default nilainya ke nilai yang ada. Jika tidak ada nilai yang ditetapkan sebelumnya, Amazon ECS menetapkan nilainya. `DISABLED`
Untuk informasi selengkapnya tentang penyeimbangan kembali Availability Zone, lihat. [Menyeimbangkan Layanan Amazon ECS di Seluruh Zona Ketersediaan](service-rebalancing.md)

## Konfigurasi volume
<a name="sd-volumeConfigurations"></a>

`volumeConfigurations`  
Tipe: Objek  
Wajib: Tidak  
Konfigurasi yang akan digunakan untuk membuat volume untuk tugas-tugas yang dikelola oleh layanan. Hanya volume yang ditandai seperti `configuredAtLaunch` dalam definisi tugas yang dapat dikonfigurasi dengan menggunakan objek ini.  
Saat Anda memperbarui layanan, parameter ini memicu penerapan layanan baru.  
Objek ini diperlukan untuk melampirkan volume Amazon EBS ke tugas yang dikelola oleh layanan. Untuk informasi selengkapnya, lihat [Gunakan volume Amazon EBS dengan Amazon ECS](ebs-volumes.md).    
`name`  
Tipe: String  
Diperlukan: Ya  
Nama volume yang dikonfigurasi saat membuat atau memperbarui layanan. Hingga 255 huruf (huruf besar dan kecil), angka, garis bawah (), dan tanda hubung (`_`) diperbolehkan. `-` Nilai ini harus cocok dengan nama volume yang ditentukan dalam definisi tugas.  
`managedEBSVolume`  
Tipe: Objek  
Wajib: Tidak  
Konfigurasi volume yang digunakan untuk membuat volume Amazon EBS yang dilampirkan ke tugas yang dikelola oleh layanan saat layanan dibuat atau diperbarui. Satu volume dilampirkan per tugas.    
`encrypted`  
Tipe: Boolean  
Wajib: Tidak  
Nilai yang valid: `true` \$1 `false`  
Menentukan apakah akan mengenkripsi setiap volume Amazon EBS dibuat. Jika Anda telah mengaktifkan enkripsi Amazon EBS secara default untuk yang khusus Wilayah AWS untuk Anda Akun AWS tetapi menetapkan parameter ini`false`, parameter ini akan diganti, dan volume akan dienkripsi dengan kunci KMS yang ditentukan untuk enkripsi secara default. Untuk informasi selengkapnya tentang enkripsi Amazon EBS secara default, lihat [Mengaktifkan enkripsi Amazon EBS secara default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) di Panduan Pengguna *Amazon EBS*. Untuk informasi selengkapnya tentang mengenkripsi volume Amazon EBS yang dilampirkan ke tugas Amazon ECS, lihat. [Enkripsi data yang disimpan dalam volume Amazon EBS yang dilampirkan ke tugas Amazon ECS](ebs-kms-encryption.md)  
`kmsKeyId`  
Tipe: String  
Wajib: Tidak  
Pengenal kunci AWS Key Management Service (AWS KMS) yang akan digunakan untuk enkripsi Amazon EBS. Jika `kmsKeyId` ditentukan, status terenkripsi harus `true`.  
 Kunci yang ditentukan menggunakan parameter ini akan menggantikan default Amazon EBS atau kunci KMS tingkat cluster apa pun untuk enkripsi penyimpanan terkelola Amazon ECS yang mungkin telah Anda tentukan. Untuk informasi selengkapnya, lihat [Enkripsi data yang disimpan dalam volume Amazon EBS yang dilampirkan ke tugas Amazon ECS](ebs-kms-encryption.md).   
Anda dapat menentukan kunci KMS dengan menggunakan salah satu dari berikut ini:  
+ **ID Kunci** — Misalnya,`1234abcd-12ab-34cd-56ef-1234567890ab`.
+ **Alias kunci** — Misalnya,`alias/ExampleAlias`.
+ **ARN Kunci** — Misalnya,. `arn:aws:kms:us-east-1:012345678910:key/1234abcd-12ab-34cd-56ef-1234567890ab`
+ **Alias ARN** — Misalnya,. `arn:aws:kms:us-east-1:012345678910:alias/ExampleAlias`
AWS mengautentikasi kunci KMS secara asinkron. Oleh karena itu, jika Anda menentukan ID, alias, atau ARN yang tidak valid, tindakan dapat tampak berhasil, tetapi akhirnya gagal. Untuk informasi selengkapnya, lihat [Memecahkan masalah lampiran volume Amazon EBS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshoot-ebs-volumes.html).  
`volumeType`  
Tipe: String  
Wajib: Tidak  
Nilai yang valid: `gp2` `gp3` \$1 `io1` \$1 `io2` \$1 `sc1` \$1 `st1` \$1 `standard`  
Jenis volume Amazon EBS. Untuk informasi selengkapnya tentang jenis volume, lihat [Jenis volume Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) di *Panduan Pengguna Amazon EBS*. Jenis volume default adalah `gp3`.  
Jenis `standard` volume tidak didukung untuk tugas Fargate.  
`sizeInGiB`  
Tipe: Integer  
Wajib: Tidak  
Rentang yang valid: Bilangan bulat antara 1 dan 16.384   
Ukuran volume EBS dalam gibibytes (GiB). Jika Anda tidak memberikan ID snapshot untuk mengonfigurasi volume lampiran, Anda harus memberikan nilai ukuran. Jika Anda mengonfigurasi volume untuk lampiran menggunakan snapshot, nilai defaultnya adalah ukuran snapshot. Anda kemudian dapat menentukan ukuran yang lebih besar dari atau sama dengan ukuran snapshot.  
Untuk `gp2` dan jenis `gp3` volume, kisaran yang valid adalah 1-16.384.  
Untuk `io1` dan jenis `io2` volume, kisaran yang valid adalah 4-16.384.  
Untuk `st1` dan jenis `sc1` volume, kisaran yang valid adalah 125-16.384.  
Untuk jenis `standard` volume, kisaran yang valid adalah 1-1.024.  
`snapshotId`  
Tipe: String  
Wajib: Tidak  
ID snapshot volume Amazon EBS yang ada yang digunakan Amazon ECS untuk membuat volume baru untuk lampiran. Anda harus menentukan `snapshotId` atau `sizeInGiB`.  
`volumeInitializationRate`  
Tipe: Integer  
Wajib: Tidak  
Tingkat, dalam MIB/s, di mana data diambil dari snapshot volume Amazon EBS yang ada untuk membuat volume baru untuk lampiran. Properti ini dapat ditentukan hanya jika Anda menentukan`snapshotId`. Untuk informasi selengkapnya tentang tingkat inisialisasi volume ini, termasuk rentang tarif yang didukung untuk inisialisasi, lihat [Menginisialisasi volume Amazon EBS di Panduan](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html) Pengguna *Amazon* EBS.  
`iops`  
Tipe: Integer  
Wajib: Tidak  
Jumlah I/O operasi per detik (IOPS). Untuk volume `gp3`, `io1`, dan `io2`, ini mewakili jumlah IOPS yang disediakan untuk volume. Untuk `gp2` volume, nilai ini mewakili kinerja dasar volume dan tingkat di mana volume mengakumulasi I/O kredit untuk meledak. Parameter ini diperlukan untuk volume `io1` dan `io2`. Parameter ini tidak didukung untuk`gp2`,`st1`,`sc1`, atau `standard` volume.   
Untuk `gp3` volume, kisaran nilai yang valid adalah 3.000 hingga 16.000.  
Untuk `io1` volume, kisaran nilai yang valid adalah 100 hingga 64.000.  
Untuk `io2` volume, kisaran nilai yang valid adalah 100 hingga 64.000.  
`throughput`  
Tipe: Integer  
Wajib: Tidak  
Throughput untuk penyediaan volume yang melekat pada tugas-tugas yang dikelola oleh layanan.  
Parameter ini hanya didukung untuk `gp3` volume.  
`roleArn`  
Tipe: String  
Diperlukan: Ya  
Amazon Resource ARN (ARN) dari peran infrastruktur AWS Identity and Access Management (IAM) yang menyediakan izin Amazon ECS untuk mengelola sumber daya Amazon EBS untuk tugas Anda. Untuk informasi selengkapnya, lihat [Peran IAM Infrastruktur Amazon ECS](infrastructure_IAM_role.md).  
`tagSpecifications`  
Tipe: Objek  
Wajib: Tidak  
Spesifikasi tag yang akan diterapkan pada setiap volume Amazon EBS.    
`resourceType`  
Tipe: String  
Diperlukan: Ya  
Nilai yang valid: `volume`  
Jenis sumber daya untuk menandai pada penciptaan.  
`tags`  
Tipe: Array objek   
Wajib: Tidak  
Metadata yang Anda terapkan pada volume untuk membantu Anda mengkategorikan dan mengaturnya. Setiap tag terdiri dari kunci dan nilai opsional, yang keduanya Anda tentukan. `AmazonECSCreated`dan `AmazonECSManaged` merupakan tag cadangan yang ditambahkan oleh Amazon ECS atas nama Anda, sehingga Anda dapat menentukan maksimum 48 tag Anda sendiri. Ketika volume dihapus, tag dihapus juga. Untuk informasi selengkapnya, lihat [Menandai sumber daya Amazon ECS](ecs-using-tags.md).    
`key`  
Tipe: String  
Batasan Panjang: Panjang minimum 1. Panjang maksimum 128.  
Wajib: Tidak  
Salah satu bagian dari pasangan kunci-nilai yang membentuk tag. Kunci adalah label umum yang bertindak seperti kategori untuk nilai tanda yang lebih spesifik.  
`value`  
Tipe: String  
Batasan Panjang: Panjang minimum 0. Panjang maksimum 256.  
Wajib: Tidak  
Bagian opsional dari pasangan kunci-nilai yang membentuk tag. Nilai bertindak sebagai deskriptor dalam kategori tanda (kunci).  
`propagateTags`  
Tipe: String  
Nilai yang valid: `TASK_DEFINITION` \$1 `SERVICE` \$1 `NONE`  
Wajib: Tidak  
Menentukan apakah akan menyalin tag dari definisi tugas atau layanan ke volume. Jika `NONE` ditentukan atau tidak ada nilai yang ditentukan, tag tidak disalin.  
`fileSystemType`  
Tipe: String  
Wajib: Tidak  
Nilai yang valid: `xfs` \$1 `ext3` \$1 `ext4` \$1 `NTFS`  
Jenis sistem file pada volume. Jenis sistem file volume menentukan bagaimana data disimpan dan diambil dalam volume. Untuk volume yang dibuat dari snapshot, Anda harus menentukan tipe sistem file yang sama yang digunakan volume saat snapshot dibuat. Jika ada ketidakcocokan tipe sistem file, tugas akan gagal dimulai.   
Nilai yang valid untuk Linux adalah`xfs`, ext3`, and ext4`. Default untuk volume yang dilampirkan ke tugas Linux adalah`XFS`.  
Nilai yang valid untuk Windows adalah`NTFS`. Default untuk volume yang dilampirkan ke tugas Windows adalah`NTFS`.

# Templat definisi layanan
<a name="sd-template"></a>

Berikut ini menunjukkan representasi JSON dari definisi layanan Amazon ECS.

EC2

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "EC2", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementConstraints": [
        {
            "type": "distinctInstance", 
            "expression": ""
        }
    ], 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0,
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

Fargate

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "FARGATE", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "platformFamily": "",
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0   
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0, 
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

Anda dapat membuat templat ketentuan layanan ini menggunakan perintah AWS CLI berikut.

```
aws ecs create-service --generate-cli-skeleton
```