Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemecahan Masalah Tumpukan OpsWorks
**penting**
AWS OpsWorks Stacks Layanan ini mencapai akhir masa pakai pada 26 Mei 2024 dan telah dinonaktifkan untuk pelanggan baru dan yang sudah ada. Kami sangat menyarankan pelanggan untuk memindahkan beban kerja mereka ke solusi lain sesegera mungkin. Jika Anda memiliki pertanyaan tentang migrasi, hubungi AWS Dukungan Tim di [AWS re:Post](https://repost.aws/) atau melalui [AWS Dukungan](https://aws.amazon.com/support) Premium.
Bagian ini berisi beberapa masalah OpsWorks Stacks yang umum ditemui dan solusinya.
**Topics**
+ [Tidak Dapat Mengelola Instance](#w2ab1c14c77c17b9b9)
+ [Setelah Chef Run, Instance Tidak Akan Boot](#w2ab1c14c77c17b9c11)
+ [Contoh Lapisan Semua Gagal Pemeriksaan Kesehatan Elastic Load Balancing](#common-issues-troubleshoot-health)
+ [Tidak Dapat Berkomunikasi dengan Load Balancer Elastic Load Balancing](#w2ab1c14c77c17b9c15)
+ [Instance Lokal yang Diimpor Gagal Menyelesaikan Pengaturan Volume Setelah Mulai Ulang](#w2ab1c14c77c17b9c17)
+ [Volume EBS Tidak Terpasang Kembali Setelah Reboot](#common-issues-troubleshoot-ebs)
+ [Tidak Dapat Menghapus OpsWorks Grup Keamanan Stacks](#common-issues-troubleshoot-booting-secgroup)
+ [Tidak Sengaja Menghapus Grup Keamanan OpsWorks Stacks](#common-issues-troubleshoot-booting-secgroup-delete)
+ [Chef Log Berakhir Tiba-tiba](#common-issues-troubleshoot-log-terminates)
+ [Cookbook Tidak Diperbarui](#common-issues-troubleshoot-update)
+ [Instance Terjebak di Status Booting](#common-issues-troubleshoot-booting)
+ [Instans Secara Tak Terduga Mulai Ulang](#common-issues-troubleshoot-restart)
+ [`opsworks-agent`Proses Berjalan pada Instance](#common-issues-troubleshoot-agent)
+ [Perintah execute\$1recipes yang tidak terduga](#common-issues-troubleshoot-unexpected)
## Tidak Dapat Mengelola Instance
**Masalah:** Anda tidak lagi dapat mengelola instance yang telah dikelola di masa lalu. Dalam beberapa kasus, log dapat menunjukkan kesalahan yang mirip dengan yang berikut ini.
```
Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.
```
**Penyebab:** Ini dapat terjadi jika sumber daya OpsWorks di luar tempat instance bergantung telah diedit atau dihapus. Berikut ini adalah contoh perubahan sumber daya yang dapat memutus komunikasi dengan sebuah instance.
+ Pengguna IAM atau peran yang terkait dengan instance telah dihapus secara tidak sengaja, di luar OpsWorks Stacks. Hal ini menyebabkan kegagalan komunikasi antara OpsWorks agen yang diinstal pada instance, dan layanan OpsWorks Stacks. Pengguna yang terkait dengan instance diperlukan sepanjang umur instance.
+ Mengedit konfigurasi volume atau penyimpanan saat instance offline dapat membuat instance tidak dapat dikelola.
+ Menambahkan EC2 instance ke ELB secara manual. OpsWorks mengonfigurasi ulang penyeimbang beban Elastic Load Balancing yang ditetapkan setiap kali instance masuk atau keluar dari status online. OpsWorks hanya menganggap contoh yang diketahuinya akan menjadi anggota yang valid; contoh yang ditambahkan di luar OpsWorks, atau oleh beberapa proses lain, dihapus. Setiap contoh lainnya dihapus.
**Solusi:** Jangan hapus pengguna IAM atau peran yang menjadi sandaran instans Anda. Jika memungkinkan, edit konfigurasi volume atau penyimpanan hanya saat instance dependen sedang berjalan. Gunakan OpsWorks untuk mengelola load balancer atau keanggotaan EIP instance. OpsWorks Saat Anda mendaftarkan instance, untuk membantu mencegah masalah dalam mengelola instance terdaftar jika pengguna terhapus secara tidak sengaja, tambahkan `--use-instance-profile` parameter ke `register` perintah Anda untuk menggunakan profil instans bawaan instans sebagai gantinya.
## Setelah Chef Run, Instance Tidak Akan Boot
**Masalah:** Pada Chef 11.10 atau tumpukan yang lebih lama yang dikonfigurasi untuk menggunakan buku masak khusus, setelah Chef menjalankan yang menggunakan buku masak komunitas, instance tidak akan boot. Pesan log dapat menyatakan bahwa resep gagal dikompilasi (“Kesalahan Kompilasi Resep”), atau tidak dapat dimuat karena tidak dapat menemukan ketergantungan.
**Penyebab: Penyebab** yang paling mungkin adalah buku masak kustom atau komunitas tidak mendukung versi Chef yang digunakan tumpukan Anda. Beberapa buku masak komunitas populer, seperti `[apt](https://supermarket.chef.io/cookbooks/apt)` dan`[build-essential](https://supermarket.chef.io/cookbooks/build-essential/versions/3.2.0)`, telah mengetahui masalah kompatibilitas dengan Chef 11.10.
**Solusi:** Pada OpsWorks tumpukan Tumpukan yang mengaktifkan pengaturan **Gunakan buku masak Chef kustom, buku masak** khusus atau komunitas harus selalu mendukung versi Chef yang digunakan tumpukan Anda. Sematkan buku masak komunitas ke versi (yaitu, atur nomor versi buku masak ke versi tertentu) yang kompatibel dengan versi Chef yang dikonfigurasi dalam pengaturan tumpukan Anda. Untuk menemukan versi buku masak komunitas yang didukung, lihat changelog untuk buku masak yang gagal dikompilasi, dan gunakan hanya versi terbaru dari buku masak yang akan didukung oleh tumpukan Anda. Untuk menyematkan versi buku masak, tentukan nomor versi yang tepat di Berksfile repositori buku masak kustom Anda. Misalnya, `cookbook 'build-essential', '= 3.2.0'`.
## Contoh Lapisan Semua Gagal Pemeriksaan Kesehatan Elastic Load Balancing
**Masalah:** Anda melampirkan penyeimbang beban Elastic Load Balancing ke lapisan server aplikasi, tetapi semua instance gagal dalam pemeriksaan kesehatan.
**Penyebab:** Saat membuat penyeimbang beban Elastic Load Balancing, Anda harus menentukan jalur ping yang dipanggil penyeimbang beban untuk menentukan apakah instans tersebut sehat. Pastikan untuk menentukan jalur ping yang sesuai untuk aplikasi Anda; nilai default adalah /index.html. Jika aplikasi Anda tidak termasuk`index.html`, Anda harus menentukan jalur yang sesuai atau pemeriksaan kesehatan akan gagal. Misalnya, PHPApp aplikasi Simple yang digunakan [Memulai dengan Chef 11 Linux Stacks](gettingstarted.md) tidak menggunakan index.html; jalur ping yang sesuai untuk server tersebut adalah /.
**Solusi:** Edit jalur ping penyeimbang beban. Untuk informasi selengkapnya, lihat [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/gs-ec2classic.html)
## Tidak Dapat Berkomunikasi dengan Load Balancer Elastic Load Balancing
**Masalah:** Anda membuat penyeimbang beban Elastic Load Balancing dan melampirkannya ke lapisan server aplikasi, tetapi ketika Anda mengklik nama DNS atau alamat IP penyeimbang beban untuk menjalankan aplikasi, Anda mendapatkan kesalahan berikut: “Server jarak jauh tidak merespons”.
**Penyebab:** Jika tumpukan Anda berjalan di VPC default, saat Anda membuat penyeimbang beban Elastic Load Balancing di wilayah tersebut, Anda harus menentukan grup keamanan. Grup keamanan harus memiliki aturan masuk yang memungkinkan lalu lintas masuk dari alamat IP Anda. Jika Anda menentukan **grup keamanan VPC default**, aturan masuk default tidak menerima lalu lintas masuk apa pun.
**Solusi:** Edit aturan masuk grup keamanan untuk menerima lalu lintas masuk dari alamat IP yang sesuai.
1. Klik **Grup Keamanan** di panel navigasi [ EC2 konsol Amazon](https://console.aws.amazon.com/ec2/).
1. Pilih grup keamanan load balancer.
1. Klik **Edit** pada tab **Inbound**.
1. Tambahkan aturan masuk dengan **Sumber** disetel ke CIDR yang sesuai.
Misalnya, menentukan **Anywhere** menetapkan CIDR ke 0.0.0.0/0, yang mengarahkan penyeimbang beban untuk menerima lalu lintas masuk dari alamat IP apa pun.
## Instance Lokal yang Diimpor Gagal Menyelesaikan Pengaturan Volume Setelah Mulai Ulang
**Masalah:** Anda memulai ulang EC2 instance yang telah diimpor ke OpsWorks Stacks, dan tampilan konsol OpsWorks Stacks **gagal sebagai status** instans. Ini dapat terjadi pada contoh Chef 11 atau Chef 12.
**Penyebab:**OpsWorks Tumpukan mungkin tidak dapat melampirkan volume ke instance Anda selama proses penyiapan. Salah satu kemungkinan penyebabnya adalah OpsWorks Stacks menimpa konfigurasi volume Anda pada instance Anda saat Anda menjalankan perintah. `setup`
**Solusi:** Buka halaman **Detail** untuk instance, dan periksa konfigurasi volume Anda di area **Volume**. Perhatikan bahwa Anda dapat mengubah konfigurasi volume hanya jika instans Anda berada dalam status **berhenti**. Pastikan bahwa setiap volume memiliki titik pemasangan dan nama yang ditentukan. Konfirmasikan bahwa Anda memberikan titik pemasangan yang benar dalam konfigurasi di OpsWorks Stacks sebelum memulai ulang instance.
## Volume EBS Tidak Terpasang Kembali Setelah Reboot
**Masalah:** Anda menggunakan EC2 konsol Amazon untuk melampirkan volume Amazon EBS ke instans tetapi ketika Anda me-reboot instance, volume tidak lagi terpasang.
**Penyebab:** OpsWorks Tumpukan hanya dapat memasang kembali volume Amazon EBS yang disadarinya, yang terbatas pada hal-hal berikut:
+ Volume yang dibuat oleh OpsWorks Stacks.
+ Volume dari akun Anda yang telah Anda daftarkan secara eksplisit dengan tumpukan menggunakan halaman **Resources**.
**Solusi:** Kelola volume Amazon EBS Anda hanya dengan menggunakan konsol OpsWorks Stacks, API, atau CLI. Jika Anda ingin menggunakan salah satu volume Amazon EBS akun Anda dengan tumpukan, gunakan halaman **Sumber Daya** tumpukan untuk mendaftarkan volume dan melampirkannya ke sebuah instance. Untuk informasi selengkapnya, lihat [Manajemen Sumber Daya](resources.md).
## Tidak Dapat Menghapus OpsWorks Grup Keamanan Stacks
**Masalah:** Setelah Anda menghapus tumpukan, ada sejumlah grup keamanan OpsWorks Stacks yang tertinggal yang tidak dapat dihapus.
**Penyebab:** Grup keamanan harus dihapus dalam urutan tertentu.
**Solusi:** Pertama, pastikan tidak ada instance yang menggunakan grup keamanan. Kemudian, hapus salah satu grup keamanan berikut, jika ada, dengan urutan sebagai berikut:
1. AWS- OpsWorks -Server Kosong
1. AWS- OpsWorks -Monitoring-Master-Server
1. AWS- OpsWorks -DB-Master-Server
1. AWS- OpsWorks -Memcached-Server
1. AWS- OpsWorks -Server Khusus
1. AWS- OpsWorks -NodeJS-App-Server
1. AWS- OpsWorks -PHP-APP-Server
1. AWS- OpsWorks -Rails-App-Server
1. AWS- OpsWorks -Server Web
1. AWS- OpsWorks -Server Default
1. AWS- OpsWorks -LB-Server
## Tidak Sengaja Menghapus Grup Keamanan OpsWorks Stacks
**Masalah:** Anda menghapus salah satu grup keamanan OpsWorks Stacks dan perlu membuatnya kembali.
**Penyebab:** Grup keamanan ini biasanya dihapus secara tidak sengaja.
**Solusi:** Grup yang dibuat ulang harus duplikat persis dari aslinya, termasuk kapitalisasi yang sama untuk nama grup. Alih-alih membuat ulang grup secara manual, pendekatan yang lebih disukai adalah meminta OpsWorks Stacks melakukan tugas untuk Anda. Cukup buat tumpukan baru di wilayah AWS yang sama—dan VPC, jika OpsWorks ada—dan Stacks akan secara otomatis membuat ulang semua grup keamanan bawaan, termasuk yang Anda hapus. Anda kemudian dapat menghapus tumpukan jika Anda tidak memiliki penggunaan lebih lanjut untuk itu; grup keamanan akan tetap ada.
## Chef Log Berakhir Tiba-tiba
**Masalah:** Log Chef berakhir secara tiba-tiba; akhir log tidak menunjukkan keberhasilan menjalankan atau menampilkan pengecualian dan jejak tumpukan.
**Penyebab:** Perilaku ini biasanya disebabkan oleh memori yang tidak memadai.
**Solusi:** Buat instance yang lebih besar dan gunakan `run_command` perintah CLI agen untuk menjalankan resep lagi. Untuk informasi selengkapnya, lihat [Mengeksekusi Resep](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes).
## Cookbook Tidak Diperbarui
**Masalah:** Anda memperbarui buku masak Anda tetapi instance tumpukan masih menjalankan resep lama.
**Penyebab:** OpsWorks Tumpukan menyimpan buku masak di setiap instance, dan menjalankan resep dari cache, bukan repositori. Saat Anda memulai instance baru, OpsWorks Stacks mengunduh buku masak Anda dari repositori ke cache instance. Namun, jika Anda kemudian memodifikasi buku masak khusus Anda, OpsWorks Stacks tidak secara otomatis memperbarui cache instans online.
**Solusi:** Jalankan [perintah tumpukan Update Cookbooks](workingstacks-commands.md) untuk secara eksplisit mengarahkan OpsWorks Stacks untuk memperbarui cache buku masak instans online Anda.
## Instance Terjebak di Status Booting
**Masalah:** Ketika Anda me-restart sebuah instance, atau auto healing restart secara otomatis, operasi startup berhenti pada `booting` status.
**Penyebab:** Salah satu kemungkinan penyebab masalah ini adalah konfigurasi VPC, termasuk VPC default. Instans harus selalu dapat berkomunikasi dengan layanan OpsWorks Stacks, Amazon S3, dan paket, buku masak, dan repositori aplikasi. Jika, misalnya, Anda menghapus gateway default dari VPC default, instance kehilangan koneksinya ke layanan Stacks. OpsWorks Karena OpsWorks Stacks tidak dapat lagi berkomunikasi dengan [agen](troubleshoot-debug-cli.md) instance, ia memperlakukan instance sebagai gagal dan [menyembuhkannya secara otomatis.](workinginstances-autohealing.md) Namun, tanpa koneksi, OpsWorks Stacks tidak dapat menginstal agen instance pada instance yang disembuhkan. Tanpa agen, OpsWorks Stacks tidak dapat menjalankan resep Pengaturan pada instance, sehingga operasi startup tidak dapat berkembang melampaui status “booting”.
**Solusi:** Ubah konfigurasi VPC Anda sehingga instance memiliki konektivitas yang diperlukan.
## Instans Secara Tak Terduga Mulai Ulang
**Masalah:** Instance yang berhenti tiba-tiba dimulai ulang.
**Penyebab 1:** Jika Anda telah mengaktifkan [penyembuhan otomatis](workinginstances-autohealing.md) untuk instans Anda, OpsWorks Stacks secara berkala melakukan pemeriksaan kesehatan pada EC2 instans Amazon terkait, dan memulai ulang yang tidak sehat. Jika Anda menghentikan atau menghentikan instance yang OpsWorks dikelola Stacks menggunakan EC2 konsol Amazon, API, atau CLI, Stacks tidak akan diberi tahu. OpsWorks Sebaliknya, ia akan menganggap instance yang dihentikan sebagai tidak sehat dan secara otomatis memulai ulang.
**Solusi:** Kelola instans Anda hanya dengan menggunakan konsol OpsWorks Stacks, API, atau CLI. Jika Anda menggunakan OpsWorks Stacks untuk menghentikan atau menghapus instance, itu tidak akan dimulai ulang. Untuk informasi selengkapnya, lihat [Memulai, Menghentikan, dan Memulai Ulang Instans 24/7 Secara Manual](workinginstances-starting.md) dan [Menghapus Instans OpsWorks Stacks](workinginstances-delete.md).
**Penyebab 2:** Contoh dapat gagal karena berbagai alasan. Jika Anda mengaktifkan penyembuhan otomatis, OpsWorks Stacks secara otomatis memulai ulang instance yang gagal.
**Solusi:** Ini adalah operasi normal; tidak perlu melakukan apa pun kecuali Anda tidak ingin OpsWorks Stacks memulai ulang instance yang gagal. Dalam hal ini, Anda harus menonaktifkan penyembuhan otomatis.
## `opsworks-agent`Proses Berjalan pada Instance
**Masalah:** Beberapa `opsworks-agent` proses berjalan pada instance Anda. Contoh:
```
aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24
```
**Penyebab:** Ini adalah proses sah yang diperlukan untuk operasi normal agen. Mereka melakukan tugas-tugas seperti menangani penerapan dan mengirim pesan keep-alive kembali ke layanan.
**Solusi:** Ini adalah perilaku normal. Jangan hentikan proses ini; melakukannya akan membahayakan operasi agen.
## Perintah execute\$1recipes yang tidak terduga
**Masalah:** Bagian **Log** pada halaman detail instance menyertakan `execute_recipes` perintah yang tidak terduga. `execute_recipes`Perintah tak terduga juga dapat muncul di halaman **Stack** dan **Deployments.**
**Penyebab:** Masalah ini sering disebabkan oleh perubahan izin. Saat Anda mengubah izin SSH atau sudo pengguna atau grup, OpsWorks Stacks berjalan `execute_recipes` untuk memperbarui instance tumpukan dan juga memicu peristiwa Konfigurasi. Sumber `execute_recipes` perintah lainnya adalah OpsWorks Stacks memperbarui agen instance.
**Solusi:** Ini adalah operasi normal; tidak perlu melakukan apa pun.
Untuk melihat tindakan apa yang dilakukan `execute_recipes` perintah, buka halaman **Deployments** dan klik stempel waktu perintah. Ini membuka halaman detail perintah, yang mencantumkan resep utama yang dijalankan. Misalnya, halaman detail berikut adalah untuk `execute_recipes` perintah yang dijalankan `ssh_users` untuk memperbarui izin SSH.
![\[Command details page showing successful execution of Recipes and ssh_users on php-app1.\]](http://docs.aws.amazon.com/id_id/opsworks/latest/userguide/images/command_details.png)
Untuk melihat semua detail, klik **tampilkan** di kolom **Log** perintah untuk menampilkan log Chef terkait. Cari log untuk**Run List**. OpsWorks Resep pemeliharaan tumpukan akan berada di bawah`OpsWorks Custom Run List`. Misalnya, berikut ini adalah daftar run untuk `execute_recipes` perintah yang ditunjukkan pada tangkapan layar sebelumnya, dan menunjukkan setiap resep yang terkait dengan perintah.
```
[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
"ssh_users", "test_suite", "opsworks_cleanup"]
```