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 Support Tim di AWS re:Post atau melalui AWS Dukungan Premium.

AWS 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.

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, AWS 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 Buku Masak Kustom (untuk buku masak).

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, AWS 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, yang menyediakan jejak audit dan cara mudah untuk kembali ke versi sebelumnya.

Misalnya, Anda dapat membuat pipeline penerapan menggunakan alat seperti Jenkins. 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 atau buku masak.

Menerapkan Kode ke Instans Online

AWS 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 Cookbooks Kustom (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.

Topik

• Menggunakan Rolling Deployment
• Menggunakan Tumpukan Terpisah
• Mengelola Database Backend

Menggunakan Rolling Deployment

Penerapan bergulir memperbarui aplikasi pada instance server aplikasi online stack dalam beberapa fase. Dengan setiap fase, Anda memperbarui subset instans 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, 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 dari load balancer dengan menggunakan konsol Elastic Load Balancing, CLI, atau SDK.

2. 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.

3. Terapkan pembaruan ke sisa instance di Availability Zone dan verifikasi bahwa mereka berfungsi dengan benar dan memiliki metrik yang dapat diterima.

4. 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 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.

Topik

• Menggunakan Tumpukan Pengembangan, Pementasan, dan Produksi
• Menggunakan Strategi Penerapan Biru-Hijau

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 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 AWS OpsWorks Stacks dengan menggunakan halaman Izin 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. 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 AWS 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.

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.

catatan

Alih-alih menggunakan konsol AWS 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, AWS 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 AWS OpsWorks tumpukan Stacks, bersama dengan Route 53 dan kumpulan penyeimbang beban Elastic Load Balancing. 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 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 untuk menangani volume lalu lintas yang diharapkan.

• Anda telah menggunakan fitur routing tertimbang 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 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 penyeimbang beban untuk menangani lalu lintas yang diharapkan.

2. 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.

3. Pantau metrik kinerja tumpukan hijau. Jika mereka dapat diterima, tingkatkan bobot tumpukan hijau sehingga menangani mungkin 10% dari lalu lintas yang masuk.

4. 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.

5. Lepaskan penyeimbang beban dari layer server aplikasi tumpukan biru tua dan kembalikan ke kolam.

6. 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.

Mengelola Database Backend

Jika aplikasi Anda bergantung pada basis data backend, Anda harus beralih dari aplikasi lama ke yang baru. AWS OpsWorks Stacks mendukung opsi database berikut.

Lapisan Amazon RDS

Dengan lapisan Amazon Relational Database Service (Amazon RDS), 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.

AWS OpsWorks Stacks menginstal file dengan data koneksi pada server aplikasi Anda dalam format yang mudah dapat digunakan oleh aplikasi Anda. AWS 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.

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.

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.