Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# OpsWorks Praktik Terbaik Stacks
**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.
Strategi, teknik, dan saran di bagian ini dapat membantu Anda mendapatkan manfaat maksimal dan hasil optimal dari OpsWorks Stacks.
**Topics**
+ [Praktik Terbaik: Penyimpanan Perangkat Root untuk Instans](best-practices-storage.md)
+ [Praktik Terbaik: Mengoptimalkan Jumlah Server Aplikasi](best-practices-autoscale.md)
+ [Praktik Terbaik: Mengelola Izin](best-practices-permissions.md)
+ [Praktik Terbaik: Mengelola dan Menyebarkan Aplikasi dan Buku Masak](best-deploy.md)
+ [Ketergantungan Buku Masak Kemasan Secara Lokal](best-practices-packaging-cookbooks-locally.md)
# Praktik Terbaik: Penyimpanan Perangkat Root untuk Instans
**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.
**catatan**
Topik ini tidak berlaku untuk instance Windows, yang harus didukung Amazon Elastic Block Store.
Instans Amazon Elastic Compute Cloud (Amazon EC2) Linux memiliki opsi penyimpanan perangkat root berikut.
+ **Instans yang didukung toko instans** — Perangkat root bersifat sementara.
Jika Anda menghentikan instance, data pada perangkat root menghilang dan tidak dapat dipulihkan. Untuk informasi selengkapnya, lihat [Amazon EC2 Instance Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html).
+ **Instans yang didukung Amazon EBS** — Perangkat root adalah volume Amazon EBS.
Jika Anda menghentikan instans, volume Amazon EBS tetap ada. Jika Anda me-restart instance, volume secara otomatis di-remount, memulihkan status instance dan data yang disimpan. Anda juga dapat memasang volume pada instance yang berbeda. Untuk informasi selengkapnya, lihat [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html).
Pertimbangkan hal berikut saat memutuskan opsi penyimpanan perangkat root mana yang akan digunakan.
**Waktu Boot**
Setelah start awal, instans Amazon EBS umumnya restart lebih cepat.
Waktu startup awal kira-kira sama untuk kedua jenis penyimpanan. Kedua jenis harus melakukan pengaturan penuh, yang mencakup tugas yang relatif memakan waktu seperti menginstal paket dari repositori jarak jauh. Namun, perhatikan perbedaan ini saat Anda memulai ulang instance:
+ Instance yang didukung toko instans melakukan tugas penyiapan yang sama seperti yang mereka lakukan untuk memulai awal, termasuk penginstalan paket.
Restart membutuhkan waktu yang hampir sama dengan awal awal.
+ Instans Amazon EBS-back mengubah volume root dan menjalankan resep Setup.
Restart biasanya secara signifikan lebih cepat daripada awal awal, karena resep Setup tidak harus melakukan tugas-tugas seperti menginstal ulang paket yang sudah diinstal pada volume root.
**Biaya**
Instans yang didukung Amazon EBS lebih mahal:
+ Dengan instans yang didukung instance-store, Anda hanya membayar saat instance sedang berjalan.
+ Dengan instans yang didukung Amazon EBS, Anda membayar volume Amazon EBS baik instans berjalan atau tidak.
Untuk informasi selengkapnya, lihat [Harga Amazon EBS](https://aws.amazon.com/ebs/pricing/).
**Pencatatan log**
Instans yang didukung Amazon EBS secara otomatis menyimpan log:
+ Dengan instance yang didukung toko instance, log menghilang saat instance berhenti.
Anda harus mengambil log sebelum menghentikan instance atau menggunakan layanan seperti [CloudWatch Log untuk menyimpan log](monitoring-cloudwatch-logs.md) yang dipilih dari jarak jauh.
+ Dengan instans yang didukung Amazon EBS, log disimpan pada volume Amazon EBS.
Anda dapat melihatnya dengan memulai ulang instance, atau dengan memasang volume pada instance lain.
**Dependensi**
Kedua jenis penyimpanan memiliki dependensi yang berbeda:
+ Instans yang didukung instance-store bergantung pada Amazon S3.
Saat Anda memulai instance, itu harus mengunduh AMI dari Amazon S3.
+ Instans yang didukung Amazon EBS bergantung pada Amazon EBS.
Saat Anda memulai instance, instans harus memasang volume root Amazon EBS.
**Rekomendasi:** Jika Anda tidak yakin jenis penyimpanan mana yang paling sesuai dengan kebutuhan Anda, sebaiknya mulai dengan instans Amazon EBS. Meskipun Anda akan dikenakan biaya sederhana untuk volume Amazon EBS, ada sedikit risiko kehilangan data yang tidak diinginkan.
# Praktik Terbaik: Mengoptimalkan Jumlah Server Aplikasi
**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.
Tumpukan produksi biasanya mencakup beberapa server aplikasi yang didistribusikan di beberapa Availability Zone. Namun jumlah permintaan yang masuk dapat sangat bervariasi tergantung pada waktu hari atau hari dalam seminggu. Anda bisa menjalankan server yang cukup untuk menangani beban maksimum yang diantisipasi, tetapi kemudian sebagian besar waktu Anda akhirnya akan membayar lebih banyak kapasitas server daripada yang Anda butuhkan. Untuk menjalankan situs Anda secara efisien, praktik yang disarankan adalah mencocokkan jumlah server dengan volume permintaan saat ini.
OpsWorks Stacks menyediakan tiga cara untuk mengelola jumlah instance server.
+ [Instance 24/7](workinginstances-starting.md) dimulai secara manual dan dijalankan hingga dihentikan secara manual.
+ [Instans berbasis waktu](workinginstances-autoscaling.md) secara otomatis dimulai dan dihentikan oleh OpsWorks Stacks pada jadwal yang ditentukan pengguna.
+ [Instans berbasis beban](workinginstances-autoscaling.md) secara otomatis dimulai dan dihentikan oleh OpsWorks Stacks ketika melewati ambang batas untuk metrik beban yang ditentukan pengguna seperti CPU atau pemanfaatan memori.
**catatan**
Setelah Anda membuat dan mengonfigurasi waktu tumpukan dan instance berbasis beban, OpsWorks Stacks secara otomatis memulai dan menghentikannya berdasarkan konfigurasi yang ditentukan. Anda tidak perlu menyentuhnya lagi kecuali Anda memutuskan untuk mengubah konfigurasi atau jumlah instance.
**Rekomendasi:** Jika Anda mengelola tumpukan dengan lebih dari beberapa instance server aplikasi, sebaiknya gunakan campuran ketiga jenis instans. Berikut ini adalah contoh bagaimana mengelola kapasitas server stack untuk menangani volume permintaan harian variabel dengan karakteristik sebagai berikut.
+ Volume permintaan rata-rata bervariasi secara sinusoidal sepanjang hari.
+ Volume permintaan rata-rata minimum membutuhkan lima instance server aplikasi.
+ Volume permintaan rata-rata maksimum membutuhkan enam belas instance server aplikasi.
+ Lonjakan volume permintaan biasanya dapat ditangani oleh satu atau dua instance server aplikasi.
Ini adalah model yang nyaman untuk tujuan diskusi, tetapi Anda dapat dengan mudah menyesuaikannya dengan variasi volume permintaan dan juga memperluasnya untuk menangani variasi mingguan. Diagram berikut menunjukkan cara menggunakan tiga jenis instance untuk mengelola volume permintaan ini.
![\[Graph showing instance types over 24 hours: time-based, load-based, and 24/7, with average load curve.\]](http://docs.aws.amazon.com/id_id/opsworks/latest/userguide/images/autoscaling.png)
Contoh ini memiliki karakteristik sebagai berikut:
+ Tumpukan memiliki tiga instance 24/7, yang selalu aktif dan menangani beban dasar.
+ Tumpukan memiliki 12 instance berbasis waktu, yang dikonfigurasi untuk menangani variasi harian rata-rata.
Satu berjalan dari jam 10 malam hingga 2 pagi, dua lagi lari dari jam 8 malam hingga 10 malam dan 2 pagi hingga 4 pagi, dan seterusnya. Untuk mempermudah, diagram memodifikasi jumlah instance berbasis waktu setiap dua jam, tetapi Anda dapat memodifikasi angka setiap jam jika Anda menginginkan kontrol yang lebih halus.
+ Tumpukan memiliki instance berbasis beban yang cukup untuk menangani lonjakan lalu lintas yang melebihi apa yang dapat ditangani oleh instance 24/7 dan berbasis waktu.
OpsWorks Tumpukan memulai instance berbasis beban hanya jika beban di semua server yang sedang berjalan melebihi metrik yang ditentukan. Biaya untuk instans yang tidak berjalan minimal (instans yang didukung Amazon EBS) atau tidak sama sekali (instans yang didukung toko instans), jadi praktik yang disarankan adalah membuat cukup banyak instans untuk menangani volume permintaan maksimum yang diantisipasi dengan nyaman. Untuk contoh ini, tumpukan harus memiliki setidaknya tiga instance berbasis beban.
**catatan**
Pastikan Anda memiliki ketiga jenis instans yang didistribusikan di beberapa Availability Zone untuk mengurangi dampak gangguan layanan apa pun.
# Praktik Terbaik: Mengelola Izin
**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.
Anda harus memiliki beberapa bentuk kredensi AWS untuk mengakses sumber daya akun Anda. Berikut ini adalah beberapa pedoman umum untuk menyediakan akses ke karyawan Anda.
+ Pertama dan terpenting, kami menyarankan Anda untuk tidak menggunakan kredensi root akun Anda untuk mengakses sumber daya AWS.
Sebagai gantinya, buat [Identitas IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) untuk karyawan Anda dan tambahkan izin yang menyediakan akses yang sesuai. Setiap karyawan kemudian dapat menggunakan kredensialnya untuk mengakses sumber daya.
+ Karyawan harus memiliki izin untuk mengakses hanya sumber daya yang mereka butuhkan untuk melakukan pekerjaan mereka.
Misalnya, pengembang aplikasi hanya perlu mengakses tumpukan yang menjalankan aplikasi mereka.
+ Karyawan harus memiliki izin untuk hanya menggunakan tindakan yang mereka butuhkan untuk melakukan pekerjaan mereka.
Pengembang aplikasi mungkin memerlukan izin penuh untuk tumpukan pengembangan dan izin untuk menerapkan aplikasi mereka ke tumpukan produksi yang sesuai. Mereka mungkin tidak memerlukan izin untuk memulai atau menghentikan instance pada tumpukan produksi, membuat atau menghapus lapisan, dan sebagainya.
Untuk informasi umum selengkapnya tentang mengelola izin, lihat [AWS Security Credentials](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html).
Anda dapat menggunakan OpsWorks Stacks atau IAM untuk mengelola izin pengguna. Perhatikan bahwa kedua opsi tidak saling eksklusif; kadang-kadang diinginkan untuk menggunakan keduanya.
**OpsWorks Manajemen Izin Tumpukan**
Setiap tumpukan memiliki halaman **Izin** yang dapat Anda gunakan untuk memberikan izin kepada pengguna untuk mengakses tumpukan dan menentukan tindakan apa yang dapat mereka lakukan. Anda menentukan izin pengguna dengan menyetel salah satu tingkat izin berikut. Setiap level mewakili kebijakan IAM yang memberikan izin untuk serangkaian tindakan standar.
+ **Tolak menolak** izin untuk berinteraksi dengan tumpukan dengan cara apa pun.
+ **Tampilkan** izin hibah melihat konfigurasi tumpukan tetapi tidak mengubah status tumpukan dengan cara apa pun.
+ **Deploy** menyertakan izin **Tampilkan** dan juga memberikan izin pengguna untuk menerapkan aplikasi.
+ **Kelola** mencakup izin **Deploy** dan juga memungkinkan pengguna untuk melakukan berbagai tindakan manajemen tumpukan, seperti membuat atau menghapus instance dan lapisan.
Tingkat **Kelola** izin tidak memberikan izin untuk sejumlah kecil tindakan OpsWorks Tumpukan tingkat tinggi, termasuk membuat atau mengkloning tumpukan. Anda harus menggunakan kebijakan IAM untuk memberikan izin tersebut.
Selain menyetel tingkat izin, Anda juga dapat menggunakan halaman **Izin** tumpukan untuk menentukan apakah pengguna memiliki SSH/RDP and sudo/admin hak istimewa pada instance tumpukan. Untuk informasi selengkapnya tentang manajemen izin OpsWorks Stacks, lihat. [Memberikan Izin Per-Stack](opsworks-security-users-console.md) Untuk informasi selengkapnya tentang mengelola akses SSH, lihat[Mengelola Akses SSH](security-ssh-access.md).
**Manajemen Izin IAM**
Dengan manajemen izin IAM, Anda menggunakan konsol IAM, API, atau CLI untuk melampirkan kebijakan berformat JSON ke pengguna yang secara eksplisit menentukan izinnya. Untuk informasi selengkapnya tentang manajemen izin IAM, lihat [Apa itu](https://docs.aws.amazon.com/IAM/latest/UserGuide/Introduction.html) IAM? .
**Rekomendasi:** Mulailah dengan manajemen **Izin OpsWorks ** Tumpukan. Jika Anda perlu menyempurnakan izin pengguna, atau memberikan izin pengguna yang tidak disertakan dalam tingkat **Kelola** izin, Anda dapat menggabungkan kedua pendekatan tersebut. OpsWorks Stacks kemudian mengevaluasi kedua kebijakan untuk menentukan izin pengguna.
**penting**
Jika pengguna memiliki beberapa kebijakan dengan izin yang bertentangan, penolakan selalu menang. Misalnya, Anda melampirkan kebijakan IAM ke pengguna yang mengizinkan akses ke tumpukan tertentu tetapi juga menggunakan halaman Izin tumpukan untuk menetapkan tingkat **izin** **Tolak** kepada pengguna. Tingkat izin **Tolak** diutamakan, dan pengguna tidak akan dapat mengakses tumpukan. Untuk informasi selengkapnya, lihat [logika evaluasi kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html).
Misalnya, Anda ingin pengguna dapat melakukan sebagian besar operasi pada tumpukan, kecuali untuk menambahkan atau menghapus lapisan.
+ Tentukan tingkat izin **Kelola**, yang memungkinkan pengguna melakukan sebagian besar tindakan manajemen tumpukan, termasuk membuat dan menghapus lapisan.
+ Lampirkan [kebijakan yang dikelola pelanggan](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html) berikut ke pengguna, yang menolak izin untuk menggunakan [CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)dan [DeleteLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DeleteLayer.html)tindakan pada tumpukan tersebut. Anda mengidentifikasi tumpukan dengan *[Nama Sumber Daya Amazon (ARN)](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#ARN)*, yang dapat ditemukan di halaman **Pengaturan** tumpukan.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"opsworks:CreateLayer",
"opsworks:DeleteLayer"
],
"Resource": "arn:aws:opsworks:*:*:stack/2f18b4cb-4de5-4429-a149-ff7da9f0d8ee/"
}
]
}
```
------
Untuk informasi selengkapnya, termasuk kebijakan contoh, lihat [Mengelola Izin OpsWorks Tumpukan dengan Melampirkan Kebijakan IAMMelampirkan Kebijakan IAM](opsworks-security-users-policy.md).
**catatan**
Cara lain untuk menggunakan kebijakan IAM adalah dengan menetapkan kondisi yang membatasi akses tumpukan ke karyawan dengan alamat IP atau rentang alamat tertentu. Misalnya, untuk memastikan bahwa karyawan mengakses tumpukan hanya dari dalam firewall perusahaan Anda, tetapkan kondisi yang membatasi akses ke rentang alamat IP perusahaan Anda. Untuk informasi selengkapnya, lihat [Ketentuan](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition).
# Praktik Terbaik: Mengelola dan Menyebarkan Aplikasi dan Buku Masak
**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.
OpsWorks Stacks menyebarkan aplikasi dan buku masak ke setiap instance baru dari repositori jarak jauh. Selama masa hidup instans, Anda sering harus memperbarui aplikasi atau buku masak pada instance online stack untuk menambahkan fitur, memperbaiki bug, dan sebagainya. Ada berbagai cara untuk mengelola aplikasi dan buku masak tumpukan, tetapi pendekatan yang Anda gunakan harus memenuhi persyaratan umum berikut:
+ Semua instance tumpukan produksi harus memiliki aplikasi dan kode buku masak khusus yang sama, dengan pengecualian terbatas untuk tujuan seperti pengujian. A/B
+ Menyebarkan pembaruan seharusnya tidak mengganggu operasi situs, bahkan jika terjadi kesalahan.
Bagian ini menjelaskan praktik yang direkomendasikan untuk mengelola dan menerapkan aplikasi dan buku masak khusus.
**Topics**
+ [Menjaga Konsistensi](#best-deploy-consistency)
+ [Menerapkan Kode ke Instans Online](#best-deploy-deploy)
## Menjaga Konsistensi
Secara umum, Anda perlu mempertahankan kontrol ketat atas aplikasi atau kode buku masak yang berjalan di tumpukan produksi Anda. Biasanya, semua instance harus menjalankan versi kode yang saat ini disetujui. Pengecualian terjadi saat memperbarui aplikasi atau buku masak Anda, seperti yang dijelaskan nanti, dan saat mengakomodasi kasus khusus, seperti melakukan pengujian. A/B
Kode aplikasi dan buku masak disebarkan dari repositori sumber tertentu ke instance tumpukan Anda dengan dua cara:
+ Saat Anda memulai sebuah instance, OpsWorks Stacks secara otomatis menerapkan aplikasi dan kode buku masak saat ini ke instance.
+ Untuk instance online, Anda harus secara manual menerapkan aplikasi atau kode buku masak saat ini dengan menjalankan perintah [Deploy (untuk aplikasi) atau perintah Perbarui](workingapps-deploying.md) [Buku Masak Kustom (untuk buku masak](workingstacks-commands.md)).
Karena ada dua mekanisme penerapan, penting bagi Anda untuk mengelola kode sumber Anda dengan hati-hati untuk menghindari menjalankan kode yang berbeda secara tidak sengaja pada instance yang berbeda. Misalnya, jika Anda menerapkan aplikasi atau buku masak dari cabang master Git, OpsWorks Stacks akan menyebarkan apa yang ada di cabang tersebut pada saat itu. Jika Anda memperbarui kode di cabang master dan kemudian memulai instance baru, instance itu akan memiliki versi kode yang lebih baru daripada instance yang lebih lama. Versi yang lebih baru bahkan mungkin tidak disetujui untuk produksi.
**Rekomendasi: Arsip Amazon S3**
Untuk memastikan bahwa semua instans Anda memiliki versi kode yang disetujui, sebaiknya gunakan aplikasi dan buku masak Anda dari arsip Amazon Simple Storage Service (Amazon S3). Ini menjamin bahwa kode tersebut adalah artefak statis—.zip atau file arsip lainnya—yang harus diperbarui secara eksplisit. Selain itu, Amazon S3 sangat andal, sehingga Anda jarang, jika pernah, tidak dapat mengakses arsip. Untuk memastikan konsistensi lebih lanjut, versi secara eksplisit setiap file arsip dengan menggunakan konvensi penamaan atau dengan menggunakan versi [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html), yang menyediakan jejak audit dan cara mudah untuk kembali ke versi sebelumnya.
Misalnya, Anda dapat membuat pipeline penerapan menggunakan alat seperti [Jenkins](https://jenkins.io/index.html). Setelah kode yang ingin Anda terapkan telah dilakukan dan diuji, buat file arsip dan unggah ke Amazon S3. Semua penerapan aplikasi atau pembaruan buku masak akan menginstal kode dalam file arsip itu dan setiap instance akan memiliki kode yang sama.
**Rekomendasi: Git atau Subversion Repositori**
Jika Anda lebih suka menggunakan repositori Git atau Subversion, jangan gunakan dari cabang master. Sebagai gantinya, beri tag pada versi yang disetujui dan tentukan versi tersebut sebagai sumber [aplikasi](workingapps-creating.md#workingapps-creating-source) atau [buku masak](workingcookbook-installingcustom-enable.md#workingcookbook-installingcustom-enable-repo).
## Menerapkan Kode ke Instans Online
OpsWorks Tumpukan tidak secara otomatis menyebarkan kode yang diperbarui ke instance online. Anda harus melakukan operasi itu secara manual, yang menimbulkan tantangan berikut:
+ Menyebarkan pembaruan secara efisien tanpa mengorbankan kemampuan situs untuk menangani permintaan pelanggan selama proses penyebaran.
+ Menangani penerapan yang gagal, baik karena masalah dengan aplikasi atau buku masak yang diterapkan atau masalah dengan proses penerapan itu sendiri.
Pendekatan paling sederhana adalah menjalankan perintah [Deploy default (untuk aplikasi) atau Perbarui perintah](workingapps-deploying.md) [Cookbooks Kustom](workingstacks-commands.md) (untuk buku masak), yang menyebarkan pembaruan ke setiap instance secara bersamaan. Pendekatan ini sederhana dan cepat, tetapi tidak ada margin untuk kesalahan. Jika penerapan gagal atau kode yang diperbarui memiliki masalah, setiap instance di tumpukan produksi Anda dapat terpengaruh, berpotensi mengganggu atau menonaktifkan situs Anda hingga Anda dapat memperbaiki masalah atau memutar kembali ke versi sebelumnya.
**Rekomendasi:** Gunakan strategi penerapan yang kuat, yang memungkinkan instance yang menjalankan kode versi lama untuk terus menangani permintaan hingga Anda memverifikasi bahwa penerapan berhasil dan dengan percaya diri dapat mentransfer semua lalu lintas masuk ke versi baru.
Bagian berikut memberikan dua contoh strategi penyebaran yang kuat, diikuti dengan diskusi tentang cara mengelola database backend selama penerapan. Untuk singkatnya, mereka menjelaskan pembaruan aplikasi, tetapi Anda dapat menggunakan strategi serupa untuk buku masak.
**Topics**
+ [Menggunakan Rolling Deployment](#best-deploy-rolling)
+ [Menggunakan Tumpukan Terpisah](#best-deploy-environments)
+ [Mengelola Database Backend](#best-deploy-db)
### Menggunakan Rolling Deployment
Penerapan bergulir memperbarui aplikasi pada instance server aplikasi online stack dalam beberapa fase. Dengan setiap fase, Anda memperbarui subset instance online dan memverifikasi bahwa pembaruan berhasil sebelum memulai fase berikutnya. Jika Anda mengalami masalah, instance yang masih menjalankan versi aplikasi lama dapat terus menangani lalu lintas masuk hingga Anda menyelesaikan masalah.
Contoh berikut mengasumsikan bahwa Anda menggunakan praktik yang disarankan untuk mendistribusikan instance server aplikasi stack Anda di beberapa Availability Zone.
**Untuk melakukan penyebaran bergulir**
1. Pada [halaman Deploy App](workingapps-deploying.md), pilih **Advanced**, pilih satu instance server aplikasi, dan deploy aplikasi ke instance tersebut.
Jika ingin berhati-hati, Anda dapat menghapus instance dari penyeimbang beban sebelum menerapkan aplikasi. Ini memastikan bahwa pengguna tidak akan menemukan aplikasi yang diperbarui sampai Anda memverifikasi bahwa itu berfungsi dengan benar. Jika Anda menggunakan Elastic Load Balancing, [hapus instance](https://docs.aws.amazon.com/opsworks/latest/userguide/load-balancer-elb.html) dari load balancer dengan menggunakan konsol Elastic Load Balancing, CLI, atau SDK.
1. Pastikan aplikasi yang diperbarui berfungsi dengan benar dan instans memiliki metrik kinerja yang dapat diterima.
Jika Anda menghapus instance dari penyeimbang beban Elastic Load Balancing, gunakan konsol Elastic Load Balancing, CLI, atau SDK untuk memulihkannya. Versi aplikasi yang diperbarui sekarang menangani permintaan pengguna.
1. Terapkan pembaruan ke sisa instance di Availability Zone dan verifikasi bahwa mereka berfungsi dengan benar dan memiliki metrik yang dapat diterima.
1. Ulangi langkah 3 untuk Availability Zone stack lainnya, satu zona pada satu waktu. Jika Anda ingin sangat berhati-hati, ulangi langkah 1 — 3.
**catatan**
Jika Anda menggunakan penyeimbang beban Elastic Load Balancing, Anda dapat menggunakan pemeriksaan kesehatannya untuk memverifikasi bahwa penerapan berhasil. Namun, atur [jalur ping](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) ke aplikasi yang memeriksa dependensi dan memverifikasi bahwa semuanya berfungsi dengan benar, bukan file statis yang hanya mengonfirmasi bahwa server aplikasi sedang berjalan.
### Menggunakan Tumpukan Terpisah
Pendekatan lain untuk mengelola aplikasi adalah dengan menggunakan tumpukan terpisah untuk setiap fase siklus hidup aplikasi. Tumpukan yang berbeda kadang-kadang disebut sebagai lingkungan. Pengaturan ini memungkinkan Anda untuk melakukan pengembangan dan pengujian pada tumpukan yang tidak dapat diakses publik. Saat Anda siap untuk menerapkan pembaruan, alihkan lalu lintas pengguna dari tumpukan yang menghosting versi aplikasi saat ini ke tumpukan yang menghosting versi yang diperbarui.
**Topics**
+ [Menggunakan Tumpukan Pengembangan, Pementasan, dan Produksi](#best-deploy-environments-stacks)
+ [Menggunakan Strategi Penerapan Biru-Hijau](#best-deploy-environments-blue-green)
#### Menggunakan Tumpukan Pengembangan, Pementasan, dan Produksi
Pendekatan yang paling umum menggunakan tumpukan berikut.
**Tumpukan Pengembangan**
Gunakan tumpukan pengembangan untuk tugas-tugas seperti menerapkan fitur baru atau memperbaiki bug. Tumpukan pengembangan pada dasarnya adalah tumpukan produksi prototipe, dengan lapisan, aplikasi, sumber daya, dan sebagainya yang sama yang disertakan pada tumpukan produksi Anda. Karena tumpukan pengembangan biasanya tidak harus menangani beban yang sama dengan tumpukan produksi, Anda biasanya dapat menggunakan instance yang lebih sedikit atau lebih kecil.
Tumpukan pengembangan tidak dihadapi publik; Anda mengontrol akses sebagai berikut:
+ Batasi akses jaringan dengan mengonfigurasi [aturan masuk grup keamanan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) server aplikasi atau load balancer untuk menerima permintaan masuk hanya dari alamat IP atau rentang alamat tertentu.
Misalnya, batasi akses HTTP, HTTPS, dan SSH ke alamat dalam rentang alamat perusahaan Anda.
+ Kontrol akses ke fungsionalitas manajemen tumpukan OpsWorks Stacks dengan menggunakan halaman [Izin](opsworks-security-users.md) tumpukan.
Misalnya, berikan tingkat izin Kelola ke tim pengembangan, dan Tampilkan izin kepada semua karyawan lainnya.
**Stack Pementasan**
Gunakan staging stack untuk menguji dan menyelesaikan kandidat untuk tumpukan produksi yang diperbarui. Ketika Anda telah menyelesaikan pengembangan, buat staging stack dengan [mengkloning tumpukan pengembangan](workingstacks-cloning.md). Kemudian jalankan rangkaian pengujian Anda di staging stack dan terapkan pembaruan ke tumpukan itu untuk memperbaiki masalah yang muncul.
Stack staging juga tidak menghadap publik; Anda mengontrol tumpukan dan akses jaringan dengan cara yang sama seperti yang Anda lakukan untuk tumpukan pengembangan. Perhatikan bahwa saat Anda mengkloning tumpukan pengembangan untuk membuat staging stack, Anda dapat mengkloning izin yang diberikan oleh OpsWorks manajemen izin Stacks. Namun, kloning tidak memengaruhi izin yang diberikan oleh kebijakan IAM pengguna. Anda harus menggunakan konsol IAM, CLI, atau SDK untuk mengubah izin tersebut. Untuk informasi selengkapnya, lihat [Mengelola izin](opsworks-security-users.md).
**Tumpukan Produksi**
Tumpukan produksi adalah tumpukan yang menghadap publik yang mendukung aplikasi Anda saat ini. Ketika staging stack telah lulus pengujian, Anda mempromosikannya ke produksi dan menghentikan tumpukan produksi lama. Untuk contoh cara melakukannya, lihat [Menggunakan Strategi Penerapan Biru-Hijau](#best-deploy-environments-blue-green).
**catatan**
Alih-alih menggunakan konsol OpsWorks Stacks untuk membuat tumpukan secara manual, buat AWS CloudFormation template untuk setiap tumpukan. Pendekatan ini memiliki keuntungan sebagai berikut:
Kecepatan dan kenyamanan — Saat Anda meluncurkan template, CloudFormation secara otomatis membuat tumpukan, termasuk semua instance yang diperlukan.
Konsistensi — Simpan template untuk setiap tumpukan di repositori sumber Anda untuk memastikan bahwa pengembang menggunakan tumpukan yang sama untuk tujuan yang sama.
#### Menggunakan Strategi Penerapan Biru-Hijau
Strategi penyebaran *biru-hijau* adalah salah satu cara umum untuk menggunakan tumpukan terpisah secara efisien untuk menyebarkan pembaruan aplikasi ke produksi.
+ Lingkungan biru adalah tumpukan produksi, yang menampung aplikasi saat ini.
+ Lingkungan hijau adalah staging stack, yang menampung aplikasi yang diperbarui.
Saat Anda siap untuk menerapkan aplikasi yang diperbarui ke produksi, Anda mengalihkan lalu lintas pengguna dari tumpukan biru ke tumpukan hijau, yang menjadi tumpukan produksi baru. Anda kemudian pensiun dari tumpukan biru tua.
[Contoh berikut menjelaskan cara melakukan penyebaran biru-hijau dengan OpsWorks tumpukan Stacks, bersama dengan [Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) dan kumpulan penyeimbang beban Elastic Load Balancing.](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/SvcIntro.html) Sebelum beralih, Anda harus memastikan hal berikut:
+ Pembaruan aplikasi pada tumpukan hijau telah lulus pengujian dan siap untuk produksi.
+ Tumpukan hijau identik dengan tumpukan biru kecuali bahwa itu termasuk aplikasi yang diperbarui dan tidak menghadap publik.
Kedua tumpukan memiliki izin yang sama, jumlah dan jenis instance yang sama di setiap lapisan, konfigurasi [berbasis waktu dan beban yang sama, dan](workinginstances-autoscaling.md) sebagainya.
+ Semua instance 24/7 tumpukan hijau dan instance berbasis waktu terjadwal sedang online.
+ Anda memiliki kumpulan penyeimbang beban Elastic Load Balancing yang dapat dipasang secara dinamis ke lapisan di kedua tumpukan dan dapat [dipanaskan terlebih dahulu](https://aws.amazon.com/articles/1636185810492479#pre-warming) untuk menangani volume lalu lintas yang diharapkan.
+ Anda telah menggunakan [fitur routing tertimbang](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) Route 53 untuk membuat catatan yang ditetapkan di zona yang dihosting yang menyertakan penyeimbang beban gabungan Anda.
+ Anda telah menetapkan bobot bukan nol ke penyeimbang beban yang dilampirkan ke lapisan server aplikasi tumpukan biru Anda dan bobot nol ke penyeimbang beban yang tidak digunakan. Ini memastikan bahwa penyeimbang beban tumpukan biru menangani semua lalu lintas yang masuk.
**Untuk mengalihkan pengguna ke tumpukan hijau**
1. [Lampirkan salah satu load balancer pool yang tidak digunakan ke layer](layers-elb.md) server aplikasi tumpukan hijau. Dalam beberapa skenario, seperti ketika Anda mengharapkan lalu lintas kilat, atau jika Anda tidak dapat mengonfigurasi uji beban untuk meningkatkan lalu lintas secara bertahap, [pra-hangatkan](https://aws.amazon.com/articles/1636185810492479#pre-warming) penyeimbang beban untuk menangani lalu lintas yang diharapkan.
1. Setelah semua instance tumpukan hijau telah lulus pemeriksaan kesehatan Elastic Load Balancing, ubah bobot dalam set rekor Route 53 sehingga penyeimbang beban tumpukan hijau memiliki bobot bukan nol dan penyeimbang beban tumpukan biru memiliki bobot yang berkurang. Kami menyarankan Anda memulai dengan meminta tumpukan hijau menangani sebagian kecil permintaan, mungkin 5%, dengan tumpukan biru menangani sisanya. Anda sekarang memiliki dua tumpukan produksi, dengan tumpukan hijau menangani beberapa permintaan yang masuk dan tumpukan biru menangani sisanya.
1. Pantau metrik kinerja tumpukan hijau. Jika mereka dapat diterima, tingkatkan bobot tumpukan hijau sehingga menangani mungkin 10% dari lalu lintas yang masuk.
1. Ulangi Langkah 3 sampai tumpukan hijau menangani sekitar setengah dari lalu lintas yang masuk. Masalah apa pun seharusnya muncul pada titik ini, jadi jika tumpukan hijau berkinerja baik, Anda dapat menyelesaikan prosesnya dengan mengurangi bobot tumpukan biru menjadi nol. Tumpukan hijau sekarang menjadi tumpukan biru baru dan menangani semua lalu lintas yang masuk.
1. [Lepaskan penyeimbang beban](layers-elb.md) dari layer server aplikasi tumpukan biru tua dan kembalikan ke kolam.
1. Meskipun tumpukan biru lama tidak lagi menangani permintaan pengguna, kami sarankan untuk menyimpannya untuk sementara waktu jika ada masalah dengan tumpukan biru baru. Dalam hal ini, Anda dapat memutar kembali pembaruan dengan membalikkan prosedur untuk mengarahkan lalu lintas masuk kembali ke tumpukan biru lama. Ketika Anda yakin bahwa tumpukan biru baru beroperasi dengan baik, [matikan tumpukan biru lama](workingstacks-shutting.md).
### Mengelola Database Backend
Jika aplikasi Anda bergantung pada basis data backend, Anda harus beralih dari aplikasi lama ke yang baru. OpsWorks Stacks mendukung opsi database berikut.
**Lapisan Amazon RDS**
Dengan lapisan [Amazon Relational Database Service (Amazon RDS)](workinglayers-db-rds.md), Anda membuat instans RDS DB secara terpisah dan kemudian mendaftarkannya ke tumpukan Anda. Anda dapat mendaftarkan instans RDS DB dengan hanya satu tumpukan pada satu waktu, tetapi Anda dapat mengganti instance RDS DB dari satu tumpukan ke tumpukan lainnya.
OpsWorks Stacks menginstal file dengan data koneksi pada server aplikasi Anda dalam format yang mudah dapat digunakan oleh aplikasi Anda. OpsWorks Stacks juga menambahkan informasi koneksi database ke konfigurasi stack dan atribut deployment, yang dapat diakses oleh resep. Anda juga dapat menggunakan JSON untuk menyediakan data koneksi ke aplikasi. Untuk informasi selengkapnya, lihat [Menghubungkan ke Database](workingapps-connectdb.md).
Memperbarui aplikasi yang bergantung pada database menimbulkan dua tantangan dasar:
+ Memastikan bahwa setiap transaksi dicatat dengan benar selama transisi sambil juga menghindari kondisi balapan antara versi aplikasi baru dan lama.
+ Melakukan transisi dengan cara yang membatasi dampak pada kinerja situs Anda dan meminimalkan atau menghilangkan downtime.
Saat Anda menggunakan strategi penyebaran yang dijelaskan dalam topik ini, Anda tidak bisa begitu saja melepaskan database dari aplikasi lama dan memasangnya kembali ke yang baru. Kedua versi aplikasi berjalan secara paralel selama transisi dan harus memiliki akses ke data yang sama. Berikut ini menjelaskan dua pendekatan untuk mengelola transisi, yang keduanya memiliki kelebihan dan tantangan.
Pendekatan 1: Minta kedua aplikasi terhubung ke database yang sama
**Keuntungan**
+ Tidak ada downtime selama transisi.
Satu aplikasi secara bertahap berhenti mengakses database sementara yang lain secara bertahap mengambil alih.
+ Anda tidak perlu menyinkronkan data antara dua database.
**Tantangan**
+ Kedua aplikasi mengakses database yang sama, jadi Anda harus mengelola akses untuk mencegah kehilangan data atau korupsi.
+ Jika Anda perlu bermigrasi ke skema database baru, versi aplikasi lama harus dapat menggunakan skema baru.
Jika Anda menggunakan tumpukan terpisah, pendekatan ini mungkin paling cocok untuk Amazon RDS karena instance tidak terikat secara permanen ke tumpukan tertentu dan dapat diakses oleh aplikasi yang berjalan pada tumpukan yang berbeda. Namun, Anda tidak dapat mendaftarkan instans RDS DB dengan lebih dari satu tumpukan sekaligus, jadi Anda harus memberikan data koneksi ke kedua aplikasi, misalnya dengan menggunakan JSON. Untuk informasi selengkapnya, lihat [Menggunakan Resep Kustom](workingapps-connectdb.md#workingapps-connectdb-custom).
Jika Anda menggunakan upgrade bergulir, versi aplikasi lama dan baru di-host pada tumpukan yang sama, sehingga Anda dapat menggunakan lapisan Amazon RDS atau MySQL.
Pendekatan 2: Menyediakan setiap versi aplikasi dengan basis datanya sendiri
**Keuntungan**
+ Setiap versi memiliki database sendiri, sehingga skema tidak harus kompatibel.
**Tantangan**
+ Sinkronisasi data antara dua database selama transisi tanpa kehilangan atau merusak data.
+ Memastikan bahwa prosedur sinkronisasi Anda tidak menyebabkan downtime yang signifikan atau secara signifikan menurunkan kinerja situs.
Jika Anda menggunakan tumpukan terpisah, masing-masing memiliki database sendiri. Jika Anda menggunakan penerapan bergulir, Anda dapat melampirkan dua database ke tumpukan, satu untuk setiap aplikasi. Jika aplikasi lama dan yang diperbarui tidak memiliki skema database yang kompatibel, pendekatan ini lebih baik.
**Rekomendasi:** Secara umum, sebaiknya gunakan lapisan Amazon RDS sebagai basis data backend aplikasi karena lebih fleksibel dan dapat digunakan untuk skenario transisi apa pun. Untuk informasi selengkapnya tentang cara menangani transisi, lihat [Panduan Pengguna Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html).
# Ketergantungan Buku Masak Kemasan Secara Lokal
**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.
Anda dapat menggunakan Berkshelf untuk mengemas dependensi buku masak Anda secara lokal, mengunggah paket ke Amazon S3, dan memodifikasi tumpukan Anda untuk menggunakan paket di Amazon S3 sebagai sumber buku masak. Konten yang dikirimkan ke bucket Amazon S3 mungkin berisi konten pelanggan. Untuk informasi selengkapnya tentang menghapus data sensitif, lihat [Bagaimana Cara Mengosongkan Bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) atau [Bagaimana Saya Menghapus Bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) .
Panduan berikut menjelaskan cara mengemas buku masak Anda dan dependensinya ke dalam file.zip, dan kemudian menggunakan file.zip sebagai sumber buku masak Anda untuk instance Linux di Stacks. OpsWorks Panduan pertama menjelaskan cara mengemas satu buku masak. Panduan kedua menjelaskan cara mengemas beberapa buku masak.
Sebelum Anda mulai, instal [Chef Development Kit](https://www.chef.io/downloads) (juga dikenal sebagai Chef DK), yang merupakan bermacam-macam alat yang dibangun oleh komunitas Chef. Anda akan membutuhkan ini untuk menggunakan alat `chef` baris perintah.
## Dependensi Pengemasan Lokal di Chef 12
Di Chef 12 Linux, Berkshelf tidak lagi diinstal secara default pada instance stack. Kami menyarankan Anda menginstal dan menggunakan Berkshelf pada komputer pengembangan lokal untuk mengemas dependensi buku masak Anda secara lokal. Unggah paket Anda, dengan dependensi yang disertakan, ke Amazon S3. Terakhir, ubah tumpukan Chef 12 Linux Anda untuk menggunakan paket yang diunggah sebagai sumber buku masak. Waspadai perbedaan berikut saat Anda mengemas buku masak di Chef 12.
1. Di komputer lokal, buat buku masak dengan menjalankan alat baris `chef` perintah.
```
chef generate cookbook "server-app"
```
Perintah ini membuat buku masak, Berksfile, `metadata.rb` file, dan direktori resep, dan menempatkannya di folder yang memiliki nama yang sama dengan buku masak. Contoh berikut menunjukkan struktur dari apa yang dibuat.
```
server-app <-- the cookbook you've just created
└── Berksfile
├── metadata.rb
└── recipes
```
1. Dalam editor teks, edit Berksfile untuk menunjuk ke buku masak di mana buku masak akan `server-app` bergantung. Dalam contoh kami, kami `server-app` ingin bergantung pada [https://supermarket.chef.io/cookbooks/java](https://supermarket.chef.io/cookbooks/java)buku masak dari Chef Supermarket. Kami menentukan versi 1.50.0 atau versi minor yang lebih baru, tetapi Anda dapat memasukkan versi yang diterbitkan dalam tanda kutip tunggal. Simpan perubahan Anda dan tutup file.
```
source 'https://supermarket.chef.io'
cookbook 'java', '~> 1.50.0'
```
1. Edit `metadata.rb` file untuk menambahkan ketergantungan. Simpan perubahan Anda dan tutup file.
```
depends 'java' , '~> 1.50.0'
```
1. Ubah ke direktori `server-app` buku masak yang dibuat Chef untuk Anda, lalu jalankan `package` perintah untuk membuat `tar` file buku masak. Jika Anda mengemas beberapa buku masak, Anda ingin menjalankan perintah ini di direktori root tempat semua buku masak disimpan. Untuk mengemas satu buku masak, jalankan perintah ini di tingkat direktori buku masak. Dalam contoh ini, kita menjalankan perintah ini di `server-app` direktori.
```
berks package cookbooks.tar.gz
```
Output-nya menyerupai yang berikut. `tar.gz`File dibuat di direktori lokal Anda.
```
Cookbook(s) packaged to /Users/username/tmp/berks/cookbooks.tar.gz
```
1. Di AWS CLI, unggah paket yang baru saja Anda buat ke Amazon S3. Catat URL baru paket buku masak setelah Anda mengunggahnya ke S3; Anda memerlukan URL ini untuk pengaturan tumpukan Anda.
```
aws s3 cp cookbooks.tar.gz s3://bucket-name/
```
Output-nya menyerupai yang berikut.
```
upload: ./cookbooks.tar.gz to s3://bucket-name/cookbooks.tar.gz
```
1. Di OpsWorks Stacks, [ubah tumpukan Anda](https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-installingcustom-enable.html) untuk menggunakan paket yang Anda unggah sebagai sumber buku masak.
1. Setel pengaturan **Gunakan buku masak Chef kustom** ke **Ya**.
1. Setel **jenis Repositori ke Arsip** **S3**.
1. Di **URL Repositori**, tempel URL paket buku masak yang Anda unggah di langkah 5.
Simpan perubahan tumpukan Anda.
## Ketergantungan Kemasan Secara Lokal untuk Satu Buku Masak
****
1. Di komputer lokal, buat buku masak dengan menggunakan alat baris perintah koki:
```
chef generate cookbook "server-app"
```
Perintah ini membuat buku masak dan Berksfile, dan menempatkannya di folder yang memiliki nama yang sama dengan buku masak.
1. Ubah ke direktori buku masak yang dibuat Chef untuk Anda, dan kemudian paket semuanya dengan menjalankan perintah berikut:
```
berks package cookbooks.tar.gz
```
Keluaran terlihat seperti ini:
```
Cookbook(s) packaged to /Users/username/tmp/berks/cookbooks.tar.gz
```
1. Di AWS CLI, unggah paket yang baru saja Anda buat ke Amazon S3:
```
aws s3 cp cookbooks.tar.gz s3://bucket-name/
```
Keluaran terlihat seperti ini:
```
upload: ./cookbooks.tar.gz to s3://bucket-name/cookbooks.tar.gz
```
1. Di OpsWorks Stacks, [ubah tumpukan Anda](https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-installingcustom-enable.html) untuk menggunakan paket yang Anda unggah sebagai sumber buku masak.
## Dependensi Kemasan Secara Lokal untuk Beberapa Buku Masak
Contoh ini membuat dua buku masak dan mengemas dependensi untuk mereka.
1. Di komputer lokal, jalankan `chef` perintah berikut untuk menghasilkan dua buku masak:
```
chef generate cookbook "server-app"
chef generate cookbook "server-utils"
```
Dalam contoh ini, buku masak server-app melakukan konfigurasi Java, jadi kita perlu menambahkan ketergantungan pada Java.
1. Edit `server-app/metadata.rb` untuk menambahkan ketergantungan pada buku masak Java komunitas:
```
maintainer "The Authors"
maintainer_email "you@example.com"
license "all_rights"
description "Installs/Configures server-app"
long_description "Installs/Configures server-app"
version "0.1.0"
depends "java"
```
1. Beri tahu Berkshelf apa yang harus dikemas dengan mengedit file Berksfile di direktori root buku masak sebagai berikut:
```
source "https://supermarket.chef.io"
cookbook "server-app", path: "./server-app"
cookbook "server-utils", path: "./server-utils"
```
Struktur file Anda sekarang terlihat seperti ini:
```
..
└── Berksfile
├── server-app
└── server-utils
```
1. Terakhir, buat paket zip, unggah ke Amazon S3, dan ubah tumpukan OpsWorks Stacks Anda untuk menggunakan sumber buku masak baru. Untuk melakukan ini, ikuti langkah 2 hingga 4 in[Ketergantungan Kemasan Secara Lokal untuk Satu Buku Masak](#best-practices-packaging-cookbooks-locally-one).
## Sumber daya tambahan
Untuk informasi lebih lanjut tentang dependensi buku masak kemasan, lihat berikut ini.
+ [Cara Mengemas Dependensi Cookbook Secara Lokal dengan Berkshelf](https://aws.amazon.com/blogs/devops/how-to-package-cookbook-dependencies-locally-with-berkshelf/) di Blog AWS DevOps
+ [Linux Chef 12 dengan Berkshelf](https://forums.aws.amazon.com/thread.jspa?threadID=221131) di forum OpsWorks
+ [Berkshelf di Chef 12](https://forums.aws.amazon.com/message.jspa?messageID=694464) di forum OpsWorks
+ [Menginstal Buku Masak Kustom](workingcookbook-installingcustom-enable.md) dalam panduan ini
+ [Repositori Buku Masak](workingcookbook-installingcustom-repo.md) dalam panduan ini