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

Memecahkan EC2 masalah/masalah penerapan di lokasi

CodeDeploy CommandPollerkesalahan kredensialnya hilang plugin

Jika Anda menerima kesalahan yang mirip denganInstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile, itu mungkin disebabkan oleh salah satu dari berikut ini:

Profil IAM instans memberikan izin CodeDeploy agen untuk berkomunikasi dengan CodeDeploy dan mengunduh revisi Anda dari Amazon S3. Untuk EC2 contoh, lihatIdentity and access management untuk AWS CodeDeploy. Untuk instance lokal, lihat. Working with On-Premises Instances

Penerapan gagal dengan pesan “Validasi pesan yang PKCS7 ditandatangani gagal”

Pesan kesalahan ini menunjukkan instance menjalankan versi CodeDeploy agen yang hanya mendukung algoritma hash SHA -1. Support untuk algoritma hash SHA -2 diperkenalkan dalam versi 1.0.1.854 dari CodeDeploy agen, dirilis pada November 2015. Efektif 17 Oktober 2016, penerapan gagal jika versi CodeDeploy agen lebih awal dari 1.0.1.854 diinstal. Untuk informasi selengkapnya, lihat AWS untuk beralih ke algoritma SHA256 hash untuk SSL Sertifikat, NOTICE: Menghentikan agen CodeDeploy host yang lebih lama dari versi 1.0.1.85, dan. Perbarui CodeDeploy agen

Penerapan atau pemindahan file yang sama ke lokasi instance yang sama gagal dengan kesalahan “Penerapan gagal karena file tertentu sudah ada di lokasi ini”

Saat CodeDeploy mencoba menyebarkan file ke instance tetapi file dengan nama yang sama sudah ada di lokasi target yang ditentukan, penerapan ke instance itu mungkin gagal. Anda mungkin menerima pesan galat “Penerapan gagal karena file tertentu sudah ada di lokasi ini: location-name.” Ini karena, selama setiap penerapan, CodeDeploy pertama-tama menghapus semua file dari penerapan sebelumnya, yang tercantum dalam file log pembersihan. Jika ada file di folder instalasi target yang tidak tercantum dalam file pembersihan ini, CodeDeploy agen secara default menafsirkan ini sebagai kesalahan dan gagal penerapan.

Cara termudah untuk menghindari kesalahan ini adalah dengan menentukan opsi selain perilaku default untuk gagal penerapan. Untuk setiap penerapan, Anda dapat memilih apakah akan gagal penerapan, menimpa file yang tidak tercantum dalam file pembersihan, atau untuk menyimpan file yang sudah ada di instance.

Opsi overwrite berguna ketika, misalnya, Anda secara manual menempatkan file pada instance setelah penerapan terakhir, tetapi kemudian menambahkan file dengan nama yang sama ke revisi aplikasi berikutnya.

Anda dapat memilih opsi pertahankan untuk file yang Anda tempatkan pada instance yang Anda inginkan untuk menjadi bagian dari penerapan berikutnya tanpa harus menambahkannya ke paket revisi aplikasi. Opsi pertahankan juga berguna jika file aplikasi Anda sudah ada di lingkungan produksi Anda dan Anda ingin menerapkan menggunakan CodeDeploy untuk pertama kalinya. Untuk informasi selengkapnya, silakan lihat Membuat penerapan Platform Komputasi EC2 /Lokal (konsol) dan Perilaku rollback dengan konten yang ada.

Memecahkan masalah kesalahan penerapan The deployment failed because a specified file already exists at this location

Jika Anda memilih untuk tidak menentukan opsi untuk menimpa atau mempertahankan konten yang CodeDeploy mendeteksi di lokasi penyebaran target Anda (atau jika Anda tidak menentukan opsi penerapan apa pun untuk menangani konten yang ada dalam perintah terprogram), Anda dapat memilih untuk memecahkan masalah kesalahan.

Informasi berikut hanya berlaku jika Anda memilih untuk tidak menyimpan atau menimpa konten.

Jika Anda mencoba menerapkan ulang file dengan nama dan lokasi yang sama, pemindahan akan lebih mungkin berhasil jika Anda menentukan nama aplikasi dan grup penyebaran dengan ID grup penyebaran dasar yang sama yang Anda gunakan sebelumnya. CodeDeploy menggunakan ID grup penyebaran yang mendasari untuk mengidentifikasi file yang akan dihapus sebelum pemindahan.

Menyebarkan file baru atau memindahkan file yang sama ke lokasi yang sama pada instance dapat gagal karena alasan berikut:

Untuk mengatasi situasi ini, lakukan salah satu hal berikut:

Jalur file yang panjang menyebabkan kesalahan “Tidak ada file atau direktori seperti itu”

Untuk penerapan ke instance Windows, jika Anda memiliki jalur file yang lebih besar dari 260 karakter di bagian file file appspec.yl Anda, Anda mungkin melihat penerapan gagal dengan kesalahan yang mirip dengan berikut ini:

No such file or directory @ dir_s_mkdir - C:\your-long-file-path

Kesalahan ini terjadi karena Windows secara default tidak mengizinkan jalur file lebih dari 260 karakter, seperti yang dijelaskan dalam dokumentasi Microsoft.

Untuk versi CodeDeploy agen 1.4.0 atau yang lebih baru, Anda dapat mengaktifkan jalur file panjang dengan dua cara, tergantung pada proses instalasi agen:

Jika CodeDeploy agen belum diinstal:

Jika CodeDeploy agen telah diinstal:

Proses yang berjalan lama dapat menyebabkan penerapan gagal

Untuk penerapan ke Amazon Linux, Ubuntu Server, dan RHEL instance, jika Anda memiliki skrip penerapan yang memulai proses yang berjalan lama, CodeDeploy mungkin menghabiskan waktu lama menunggu dalam peristiwa siklus hidup penerapan dan kemudian gagal penerapan. Ini karena jika proses berjalan lebih lama dari proses latar depan dan latar belakang dalam peristiwa itu diharapkan untuk mengambil, CodeDeploy menghentikan dan gagal penerapan, bahkan jika proses masih berjalan seperti yang diharapkan.

Misalnya, revisi aplikasi berisi dua file di akarnya, after-install.sh dansleep.sh. AppSpec File-nya berisi instruksi berikut:

version: 0.0
os: linux
files:
  - source: ./sleep.sh
    destination: /tmp
hooks:
  AfterInstall:
    - location: after-install.sh
      timeout: 60

after-install.shFile berjalan selama acara siklus hidup AfterInstall aplikasi. Berikut isinya:

#!/bin/bash
/tmp/sleep.sh

sleep.shFile berisi berikut ini, yang menangguhkan eksekusi program selama tiga menit (180 detik), mensimulasikan beberapa proses yang berjalan lama:

#!/bin/bash
sleep 180

Ketika after-install.sh panggilansleep.sh, sleep.sh mulai dan berjalan selama tiga menit (180 detik), yaitu dua menit (120 detik) melewati waktu yang CodeDeploy diharapkan sleep.sh (dan, menurut hubungan,after-install.sh) untuk berhenti berjalan. Setelah batas waktu satu menit (60 detik), CodeDeploy berhenti dan gagal penerapan pada acara siklus hidup AfterInstall aplikasi, meskipun sleep.sh terus berjalan seperti yang diharapkan. Kesalahan berikut ditampilkan:

Script at specified location: after-install.sh failed to complete in 60 seconds.

Anda tidak bisa begitu saja menambahkan ampersand (&) after-install.sh untuk dijalankan sleep.sh di latar belakang.

#!/bin/bash
# Do not do this.
/tmp/sleep.sh &

Melakukannya dapat membuat penerapan dalam status tertunda hingga periode batas waktu peristiwa siklus hidup penerapan satu jam default, setelah itu CodeDeploy menghentikan dan gagal penerapan pada acara siklus hidup aplikasi seperti sebelumnya. AfterInstall

Dalamafter-install.sh, panggil sleep.sh sebagai berikut, yang memungkinkan CodeDeploy untuk melanjutkan setelah proses mulai berjalan:

#!/bin/bash
/tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null &

Pada panggilan sebelumnya, sleep.sh adalah nama proses yang ingin Anda mulai jalankan di latar belakang, mengarahkan stdout, stderr, dan stdin ke. /dev/null

Memecahkan masalah peristiwa AllowTraffic siklus hidup yang gagal tanpa kesalahan yang dilaporkan dalam log penerapan

Dalam beberapa kasus, penerapan biru/hijau gagal selama peristiwa AllowTraffic siklus hidup, tetapi log penerapan tidak menunjukkan penyebab kegagalan.

Kegagalan ini biasanya disebabkan oleh pemeriksaan kesehatan yang tidak dikonfigurasi dengan benar di Elastic Load Balancing untuk Classic Load Balancer, Application Load Balancer, atau Network Load Balancer yang digunakan untuk mengelola lalu lintas untuk grup penyebaran.

Untuk mengatasi masalah ini, tinjau dan perbaiki kesalahan apa pun dalam konfigurasi pemeriksaan kesehatan untuk penyeimbang beban.

Untuk Classic Load Balancer, lihat Mengkonfigurasi Pemeriksaan Kesehatan di Panduan Pengguna untuk Penyeimbang Beban Klasik dan ConfigureHealthCheckdi Referensi Elastic Load Balancing versi 2012-06-01. API

Untuk Application Load Balancers, lihat Health Check for Your Target Groups di Panduan Pengguna untuk Application Load Balancers.

Untuk Network Load Balancer, lihat Pemeriksaan Kesehatan untuk Grup Target Anda di Panduan Pengguna Network Load Balancer.

Memecahkan masalah peristiwa siklus hidup yang gagal ApplicationStop BeforeBlockTraffic, atau AfterBlockTraffic penerapan

Selama penerapan, CodeDeploy agen menjalankan skrip yang ditentukan untuk ApplicationStop, BeforeBlockTraffic, dan AfterBlockTraffic dalam AppSpec file dari penerapan yang berhasil sebelumnya. (Semua skrip lain dijalankan dari AppSpec file dalam penerapan saat ini.) Jika salah satu skrip ini berisi kesalahan dan tidak berhasil berjalan, deployment dapat gagal.

Kemungkinan alasan kegagalan ini meliputi:

Gunakan CodeDeploy konsol untuk menyelidiki mengapa penerapan mungkin gagal selama salah satu peristiwa ini. Pada halaman detail untuk penerapan, pilih Lihat peristiwa. Pada halaman detail untuk instance, di AfterBlockTrafficbaris ApplicationStopBeforeBlockTraffic, atau, pilih Lihat log. Atau gunakan AWS CLI untuk memanggil get-deployment-instanceperintah.

Jika penyebab kegagalan adalah skrip dari penerapan terakhir yang berhasil yang tidak pernah berjalan dengan sukses, buat penerapan dan tentukan bahwa ApplicationStop, BeforeBlockTraffic, dan AfterBlockTraffic kegagalan harus diabaikan. Ada dua cara untuk melakukan hal ini:

Saat Anda menerapkan revisi aplikasi lagi, penerapan berlanjut meskipun salah satu dari tiga peristiwa siklus hidup ini gagal. Jika revisi baru menyertakan skrip tetap untuk peristiwa siklus hidup tersebut, penerapan masa depan dapat berhasil tanpa menerapkan perbaikan ini.

Memecahkan masalah peristiwa siklus hidup DownloadBundle penerapan yang gagal dengan UnknownError: tidak dibuka untuk dibaca

Jika Anda mencoba menerapkan revisi aplikasi dari Amazon S3, dan penerapan gagal selama peristiwa siklus hidup penerapan DownloadBundle dengan kesalahan: UnknownError: not opened for reading

Pada halaman detail acara untuk penerapan, di baris bundel Unduh, pilih Lihat log. Atau gunakan AWS CLI untuk memanggil get-deployment-instanceperintah. Jika kesalahan ini terjadi, harus ada kesalahan dalam output dengan kode kesalahan UnknownError dan pesan kesalahannot opened for reading.

Untuk menentukan alasan kesalahan ini:

Untuk informasi tentang cara menemukan file wire logging dan mengaktifkan dan menonaktifkan wire logging, lihat :log_aws_wire: di referensi konfigurasi CodeDeploy agen.

Memecahkan masalah semua peristiwa siklus hidup yang dilewati kesalahan

Jika semua peristiwa siklus hidup dari penerapan EC2 atau lokal dilewati, Anda mungkin menerima kesalahan yang mirip dengan. The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH_CONSTRAINTS) Berikut adalah beberapa kemungkinan penyebab dan solusi:

PowerShell Skrip Windows gagal menggunakan versi Windows 64-bit PowerShell secara default

Jika PowerShell skrip Windows yang berjalan sebagai bagian dari penerapan bergantung pada fungsionalitas 64-bit (misalnya, karena menghabiskan lebih banyak memori daripada aplikasi 32-bit yang memungkinkan atau memanggil pustaka yang ditawarkan hanya dalam versi 64-bit), skrip mungkin macet atau tidak berjalan seperti yang diharapkan. Ini karena, secara default, CodeDeploy menggunakan versi Windows 32-bit PowerShell untuk menjalankan PowerShell skrip Windows yang merupakan bagian dari revisi aplikasi.

Tambahkan kode seperti berikut ini ke awal skrip apa pun yang harus dijalankan dengan Windows versi 64-bit PowerShell:

# Are you running in 32-bit mode?
#   (\SysWOW64\ = 32-bit mode)

if ($PSHOME -like "*SysWOW64*")
{
  Write-Warning "Restarting this script under 64-bit Windows PowerShell."

  # Restart this script under 64-bit Windows PowerShell.
  #   (\SysNative\ redirects to \System32\ for 64-bit mode)

  & (Join-Path ($PSHOME -replace "SysWOW64", "SysNative") powershell.exe) -File `
    (Join-Path $PSScriptRoot $MyInvocation.MyCommand) @args

  # Exit 32-bit script.

  Exit $LastExitCode
}

# Was restart successful?
Write-Warning "Hello from $PSHOME"
Write-Warning "  (\SysWOW64\ = 32-bit mode, \System32\ = 64-bit mode)"
Write-Warning "Original arguments (if any): $args"

# Your 64-bit script code follows here...
# ...

Meskipun informasi jalur file dalam kode ini mungkin tampak berlawanan dengan intuisi, Windows 32-bit PowerShell menggunakan jalur seperti:

c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

Windows 64-bit PowerShell menggunakan jalur seperti:

c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe