Buat penerapan rilis kenari - APIGerbang Amazon

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

Buat penerapan rilis kenari

Anda membuat penerapan rilis kenari saat menerapkan API dengan setelan canary sebagai input tambahan untuk operasi pembuatan penerapan.

Anda juga dapat membuat penerapan rilis kenari dari penerapan non-canary yang ada dengan membuat stage:updatepermintaan untuk menambahkan pengaturan kenari di panggung.

Saat membuat penyebaran rilis non-canary, Anda dapat menentukan nama panggung yang tidak ada. API Gateway membuat satu jika tahap yang ditentukan tidak ada. Namun, Anda tidak dapat menentukan nama panggung yang tidak ada saat membuat penerapan rilis kenari. Anda akan mendapatkan kesalahan dan API Gateway tidak akan membuat penerapan rilis kenari apa pun.

Anda dapat membuat penerapan rilis canary di API Gateway menggunakan konsol API Gateway, theAWS CLI, atau SDK. AWS

Buat penerapan canary menggunakan konsol API Gateway

Untuk menggunakan konsol API Gateway untuk membuat penerapan rilis canary, ikuti petunjuk di bawah ini:

Untuk membuat penerapan rilis kenari awal
  1. Masuk ke konsol API Gateway.

  2. Pilih REST API yang ada atau buat REST API baru.

  3. Di panel navigasi utama, pilih Resources, lalu pilih Deploy API. Ikuti petunjuk di layar di Deploy API untuk menerapkan API ke tahap baru.

    Sejauh ini, Anda telah menerapkan API ke tahap rilis produksi. Selanjutnya, Anda mengonfigurasi pengaturan kenari di panggung dan, jika perlu, juga mengaktifkan caching, mengatur variabel tahap, atau mengonfigurasi eksekusi API atau log akses.

  4. Untuk mengaktifkan caching API atau mengaitkan ACL AWS WAF web dengan stage, di bagian Detail tahap, pilih Edit. Untuk informasi selengkapnya, lihat Pengaturan cache untuk REST API di API Gateway atau Untuk mengaitkan ACL AWS WAF web dengan tahap API Gateway API menggunakan konsol API Gateway.

  5. Untuk mengonfigurasi eksekusi atau mengakses logging, di bagian Log dan penelusuran, pilih Edit dan ikuti petunjuk di layar. Untuk informasi selengkapnya, lihat Siapkan CloudWatch logging untuk REST API di API Gateway.

  6. Untuk mengatur variabel tahap, pilih tab variabel Tahap dan ikuti petunjuk di layar untuk menambah atau memodifikasi variabel tahap. Untuk informasi selengkapnya, lihat Gunakan variabel panggung untuk REST API di API Gateway.

  7. Pilih tab Canary, lalu pilih Create canary. Anda mungkin perlu memilih tombol panah kanan untuk menampilkan tab Canary.

  8. Di bawah pengaturan Canary, untuk Canary, masukkan persentase permintaan yang akan dialihkan ke kenari.

  9. Jika diinginkan, pilih Cache tahap untuk mengaktifkan caching untuk rilis kenari. Cache tidak tersedia untuk rilis canary sampai caching API diaktifkan.

  10. Untuk mengganti variabel tahap yang ada, untuk penggantian Canary, masukkan nilai variabel tahap baru.

Setelah rilis canary diinisialisasi pada tahap penerapan, Anda mengubah API dan ingin menguji perubahannya. Anda dapat menerapkan ulang API ke tahap yang sama sehingga versi yang diperbarui dan versi dasar dapat diakses melalui tahap yang sama. Langkah-langkah berikut menjelaskan cara melakukannya.

Untuk menerapkan versi API terbaru ke kenari
  1. Dengan setiap pembaruan API, pilih Deploy API.

  2. Di Deploy API, pilih tahap yang berisi kenari dari daftar dropdown tahap Deployment.

  3. (Opsional) Masukkan deskripsi untuk deskripsi Deployment.

  4. Pilih Deploy untuk mendorong versi API terbaru ke rilis canary.

  5. Jika diinginkan, konfigurasikan ulang pengaturan panggung, log, atau pengaturan kenari, seperti yang dijelaskan dalam. Untuk membuat penerapan rilis kenari awal

Akibatnya, rilis kenari menunjuk ke versi terbaru sementara rilis produksi masih menunjuk ke versi awal API. CanarySettings sekarang memiliki nilai deploymentID baru, sedangkan stage masih memiliki nilai DeployMentID awal. Di belakang layar, konsol memanggil stage:update.

Buat penerapan kenari menggunakan AWS CLI

Pertama buat penerapan dasar dengan dua variabel tahap, tetapi tanpa kenari apa pun:

aws apigateway create-deployment \ --variables sv0=val0,sv1=val1 \ --rest-api-id abcd1234 \ --stage-name 'prod' \

Perintah mengembalikan representasi yang dihasilkan Deployment, mirip dengan yang berikut:

{ "id": "du4ot1", "createdDate": 1511379050 }

Penerapan yang dihasilkan id mengidentifikasi snapshot (atau versi) API.

Sekarang buat penyebaran kenari di atas panggung: prod

aws apigateway create-deployment --rest-api-id abcd1234 \ --canary-settings \ '{ "percentTraffic":10.5, "useStageCache":false, "stageVariableOverrides":{ "sv1":"val2", "sv2":"val3" } }' \ --stage-name 'prod'

Jika tahap tertentu (prod) tidak ada, perintah sebelumnya mengembalikan kesalahan. Jika tidak, ia mengembalikan representasi sumber daya penerapan yang baru dibuat mirip dengan yang berikut ini:

{ "id": "a6rox0", "createdDate": 1511379433 }

Penerapan yang dihasilkan id mengidentifikasi versi uji API untuk rilis canary. Akibatnya, tahap terkait diaktifkan kenari. Anda dapat melihat representasi tahap ini dengan memanggil get-stage perintah, mirip dengan yang berikut ini:

aws apigateway get-stage --rest-api-id acbd1234 --stage-name prod

Berikut ini menunjukkan representasi dari Stage sebagai output dari perintah:

{ "stageName": "prod", "variables": { "sv0": "val0", "sv1": "val1" }, "cacheClusterEnabled": false, "cacheClusterStatus": "NOT_AVAILABLE", "deploymentId": "du4ot1", "lastUpdatedDate": 1511379433, "createdDate": 1511379050, "canarySettings": { "percentTraffic": 10.5, "deploymentId": "a6rox0", "useStageCache": false, "stageVariableOverrides": { "sv2": "val3", "sv1": "val2" } }, "methodSettings": {} }

Dalam contoh ini, versi dasar API akan menggunakan variabel tahap{"sv0":val0", "sv1":val1"}, sedangkan versi pengujian menggunakan variabel tahap{"sv1":val2", "sv2":val3"}. Baik rilis produksi dan rilis kenari menggunakan variabel tahap yang samasv1, tetapi dengan nilai yang berbeda, val1 danval2, masing-masing. Variabel tahap sv0 digunakan hanya dalam rilis produksi dan variabel tahap sv2 digunakan hanya dalam pelepasan kenari.

Anda dapat membuat penerapan rilis kenari dari penerapan reguler yang ada dengan memperbarui tahapan untuk mengaktifkan kenari. Untuk mendemonstrasikannya, buat penerapan reguler terlebih dahulu:

aws apigateway create-deployment \ --variables sv0=val0,sv1=val1 \ --rest-api-id abcd1234 \ --stage-name 'beta'

Perintah mengembalikan representasi penerapan versi dasar:

{ "id": "cifeiw", "createdDate": 1511380879 }

Tahap beta terkait tidak memiliki pengaturan kenari:

{ "stageName": "beta", "variables": { "sv0": "val0", "sv1": "val1" }, "cacheClusterEnabled": false, "cacheClusterStatus": "NOT_AVAILABLE", "deploymentId": "cifeiw", "lastUpdatedDate": 1511380879, "createdDate": 1511380879, "methodSettings": {} }

Sekarang, buat penyebaran rilis kenari baru dengan melampirkan kenari di atas panggung:

aws apigateway update-stage \ --rest-api-id abcd1234 \ --stage-name 'beta' \ --patch-operations '[{ "op": "replace", "value": "0.0", "path": "/canarySettings/percentTraffic" }, { "op": "copy", "from": "/canarySettings/stageVariableOverrides", "path": "/variables" }, { "op": "copy", "from": "/canarySettings/deploymentId", "path": "/deploymentId" }]'

Representasi dari tahap yang diperbarui terlihat seperti ini:

{ "stageName": "beta", "variables": { "sv0": "val0", "sv1": "val1" }, "cacheClusterEnabled": false, "cacheClusterStatus": "NOT_AVAILABLE", "deploymentId": "cifeiw", "lastUpdatedDate": 1511381930, "createdDate": 1511380879, "canarySettings": { "percentTraffic": 10.5, "deploymentId": "cifeiw", "useStageCache": false, "stageVariableOverrides": { "sv2": "val3", "sv1": "val2" } }, "methodSettings": {} }

Karena kami baru saja mengaktifkan kenari pada versi API yang ada, baik production release (Stage) dan canary release (canarySettings) menunjuk ke penerapan yang sama, yaitu versi (deploymentId) API yang sama. Setelah Anda mengubah API dan menerapkannya ke tahap ini lagi, versi baru akan berada di rilis canary, sementara versi dasar tetap dalam rilis produksi. Ini dimanifestasikan dalam evolusi tahap ketika rilis deploymentId dalam kenari diperbarui ke penerapan baru id dan rilis produksi tetap tidak berubah. deploymentId