Anda sedang melihat dokumentasi Apigee Edge.
Buka
dokumentasi Apigee X. info
Apigee Edge menyediakan berbagai jenis resource, dan masing-masing memiliki tujuan yang berbeda. Ada beberapa resource tertentu yang dapat dikonfigurasi (yaitu dibuat, diperbarui, dan/atau dihapus) hanya melalui UI Edge, API pengelolaan, atau alat yang menggunakan API pengelolaan, dan oleh pengguna dengan peran dan izin prasyarat. Misalnya, hanya admin org yang termasuk dalam organisasi tertentu yang dapat mengonfigurasi resource ini. Artinya, resource ini tidak dapat dikonfigurasi oleh pengguna akhir melalui portal developer, atau dengan cara lain. Referensi ini mencakup:
- Proxy API
- Alur bersama
- Produk API
- Cache
- KVM
- Keystore dan truststore
- Host virtual
- Server target
- File sumber daya
Meskipun resource ini memiliki akses terbatas, jika ada modifikasi yang dilakukan bahkan oleh pengguna yang diotorisasi, data historis akan ditimpa dengan data baru. Hal ini disebabkan karena resource ini hanya disimpan di Apigee Edge sesuai dengan statusnya saat ini. Pengecualian utama untuk aturan ini adalah proxy API dan alur bersama.
Proxy API dan Alur Bersama di bagian Kontrol Revisi
Proxy API dan alur bersama dikelola -- dengan kata lain, dibuat, diperbarui, dan di-deploy -- melalui revisi. Revisi diberi nomor secara berurutan, sehingga Anda dapat menambahkan perubahan baru dan menyimpannya sebagai revisi baru atau mengembalikan perubahan dengan men-deploy revisi sebelumnya dari alur bersama/proxy API. Kapan saja, hanya boleh ada satu revisi proxy/alur bersama API yang di-deploy di lingkungan, kecuali jika revisi memiliki jalur dasar yang berbeda.
Meskipun proxy API dan alur bersama dikelola melalui revisi, jika modifikasi dilakukan pada revisi yang ada, tidak ada cara untuk melakukan roll back karena perubahan lama hanya ditimpa.
Audit dan Histori
Apigee Edge menyediakan fitur Audits dan API, Produk, serta histori organisasi yang dapat berguna dalam skenario pemecahan masalah. Fitur ini memungkinkan Anda melihat informasi seperti siapa yang melakukan operasi tertentu (membuat, membaca, mengupdate, menghapus, men-deploy, dan membatalkan deployment) serta kapan operasi dilakukan di resource Edge. Namun, jika operasi pembaruan atau penghapusan dilakukan pada resource Edge mana pun, audit tidak dapat memberikan data lama kepada Anda.
Antipola
Mengelola resource Edge (tercantum di atas) langsung melalui UI Edge atau API pengelolaan tanpa menggunakan sistem kontrol sumber
Terdapat kesalahpahaman bahwa Apigee Edge akan dapat memulihkan resource ke status sebelumnya setelah modifikasi atau penghapusan. Namun, Edge Cloud tidak menyediakan pemulihan resource ke status sebelumnya. Oleh karena itu, pengguna bertanggung jawab untuk memastikan bahwa semua data yang terkait dengan resource Edge dikelola melalui pengelolaan kontrol sumber, sehingga data lama dapat dipulihkan kembali dengan cepat jika terjadi penghapusan yang tidak disengaja atau situasi ketika setiap perubahan perlu di-roll back. Hal ini khususnya penting untuk lingkungan produksi yang memerlukan data untuk traffic runtime.
Mari kita jelaskan hal ini dengan bantuan beberapa contoh dan dampak yang dapat ditimbulkan jika data tidak dikelola melalui sistem kontrol sumber dan dimodifikasi/dihapus secara sadar atau tidak disadari:
Contoh 1: Penghapusan atau modifikasi proxy API
Saat proxy API dihapus, atau perubahan di-deploy pada revisi yang sudah ada, kode sebelumnya tidak dapat dipulihkan. Jika proxy API berisi kode Java, JavaScript, Node.js, atau Python yang tidak dikelola dalam sistem pengelolaan kontrol sumber (SCM) di luar Apigee, banyak pekerjaan dan upaya pengembangan yang bisa hilang.
Contoh 2: Penentuan proxy API menggunakan host virtual tertentu
Masa berlaku sertifikat host virtual akan berakhir dan host virtual tersebut perlu diupdate. Mengidentifikasi proxy API mana yang menggunakan host virtual tersebut untuk tujuan pengujian mungkin sulit jika ada banyak proxy API. Jika proxy API dikelola dalam sistem SCM di luar Apigee, akan mudah untuk menelusuri repositori.
Contoh 3: Penghapusan keystore/truststore
Jika keystore/truststore yang digunakan oleh host virtual atau konfigurasi server target dihapus, keystore/truststore tidak akan dapat dipulihkan kembali kecuali jika detail konfigurasi keystore/truststore, termasuk sertifikat dan/atau kunci pribadi, disimpan dalam kontrol sumber.
Dampak
- Jika salah satu resource Edge dihapus, resource dan isinya tidak akan dapat dipulihkan dari Apigee Edge.
- Permintaan API mungkin gagal dengan error tidak terduga yang menyebabkan pemadaman layanan hingga resource dipulihkan kembali ke status sebelumnya.
- Sulit untuk mencari interdependensi antara proxy API dan resource lainnya di Apigee Edge.
Praktik Terbaik
- Gunakan SCM standar apa pun yang digabungkan dengan pipeline continuous integration dan continuous deployment (CICD) untuk mengelola proxy API dan alur bersama.
- Gunakan SCM standar apa pun untuk mengelola resource Edge lainnya, termasuk produk API,
cache, KVM, server target, host virtual, dan keystore.
- Jika sudah ada resource Edge, gunakan API pengelolaan untuk mendapatkan detail konfigurasi bagi resource tersebut sebagai payload JSON/XML dan simpan dalam pengelolaan kontrol sumber.
- Kelola update baru apa pun pada resource ini di pengelolaan kontrol sumber.
- Jika perlu membuat resource Edge baru atau memperbarui resource Edge yang ada, gunakan payload JSON/XML yang sesuai dan disimpan di pengelolaan kontrol sumber, dan perbarui konfigurasi di Edge menggunakan API pengelolaan.
* KVM terenkripsi tidak dapat diekspor dalam teks biasa dari API. Pengguna bertanggung jawab untuk mencatat nilai apa yang dimasukkan ke dalam KVM terenkripsi.