Antipola: Mengelola resource tanpa menggunakan pengelolaan kontrol sumber

Anda sedang melihat dokumentasi Apigee dan Apigee Hybrid.
Lihat dokumentasi Apigee Edge.

Apigee menyediakan berbagai jenis resource dan masing-masing memiliki fungsi yang berbeda. Ada resource tertentu yang dapat dikonfigurasi (yaitu, dibuat, diupdate, dan/atau dihapus) hanya melalui UI Apigee, Apigee API, atau alat yang menggunakan API, dan oleh pengguna yang memiliki 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 pada resource tersebut bahkan oleh pengguna yang diberi otorisasi, data historis akan ditimpa dengan data baru. Hal ini disebabkan karena resource ini disimpan di Apigee hanya sesuai dengan statusnya saat ini. Pengecualian utama untuk aturan ini adalah proxy API dan alur bersama.

Proxy API dan Alur Bersama dalam Kontrol Revisi

Proxy API dan alur bersama dikelola -- dengan kata lain, dibuat, diperbarui, dan di-deploy -- melalui revisi. Revisi diberi nomor urut, yang memungkinkan Anda menambahkan perubahan baru dan menyimpannya sebagai revisi baru atau mengembalikan perubahan dengan men-deploy revisi alur bersama/proxy API sebelumnya. Kapan saja, hanya boleh ada satu revisi dari proxy API/alur bersama yang di-deploy di lingkungan, kecuali jika revisi tersebut 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 akan ditimpa.

Audit dan Histori

Apigee menyediakan fitur Audit yang dapat berguna dalam skenario pemecahan masalah. Fitur ini memungkinkan Anda melihat informasi seperti siapa yang menjalankan operasi tertentu (membuat, membaca, memperbarui, menghapus, men-deploy, dan membatalkan deployment) serta kapan operasi tersebut dilakukan di resource Apigee. Namun, jika operasi pembaruan atau penghapusan dilakukan pada resource Apigee mana pun, audit tidak dapat memberikan data lama kepada Anda.

Antipola

Mengelola resource Apigee (tercantum di atas) secara langsung melalui UI atau API Apigee tanpa menggunakan sistem kontrol sumber

Ada kesalahpahaman bahwa Apigee akan dapat memulihkan resource ke status sebelumnya setelah perubahan atau penghapusan. Namun, Apigee tidak menyediakan pemulihan resource ke status sebelumnya. Oleh karena itu, pengguna bertanggung jawab untuk memastikan bahwa semua data yang terkait dengan resource Apigee dikelola melalui pengelolaan kontrol sumber, sehingga data lama dapat dipulihkan kembali dengan cepat jika terjadi penghapusan yang tidak disengaja atau situasi ketika perubahan perlu di-roll back. Hal ini sangat penting untuk lingkungan produksi tempat data ini diperlukan untuk traffic runtime.

Mari kita jelaskan hal ini dengan bantuan beberapa contoh dan jenis dampak yang dapat terjadi jika data tidak dikelola melalui sistem kontrol sumber dan diubah/dihapus secara sengaja atau tidak disadari:

Contoh 1: Penghapusan atau perubahan proxy API

Saat proxy API dihapus, atau perubahan di-deploy pada revisi yang sudah ada, kode sebelumnya tidak akan dapat dipulihkan. Jika proxy API berisi kode Java, JavaScript, atau Python yang tidak dikelola dalam sistem pengelolaan kontrol sumber (SCM) di luar Apigee, banyak pekerjaan pengembangan dan upaya yang bisa hilang.

Contoh 2: Penentuan proxy API menggunakan host virtual tertentu

Masa berlaku sertifikat host virtual akan berakhir dan host virtual tersebut perlu diperbarui. 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, Anda tidak akan dapat memulihkannya kembali kecuali detail konfigurasi keystore/truststore, termasuk sertifikat dan/atau kunci pribadi, disimpan dalam kontrol sumber.

Dampak

  • Jika salah satu resource Apigee dihapus, resource dan isinya tidak dapat dipulihkan dari Apigee.
  • Permintaan API mungkin gagal dengan error tidak terduga yang menyebabkan pemadaman layanan hingga resource dipulihkan kembali ke keadaan sebelumnya.
  • Sulit untuk mencari inter-dependensi antara proxy API dan resource lain di Apigee.

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 Apigee lainnya, termasuk produk API, cache, KVM, server target, host virtual, dan keystore.
    • Jika sudah ada resource Apigee, gunakan Apigee API untuk mendapatkan detail konfigurasinya sebagai payload JSON/XML dan simpan di pengelolaan kontrol sumber.
    • Kelola update baru apa pun atas resource ini di pengelolaan kontrol sumber.
    • Jika perlu membuat resource Apigee baru atau mengupdate resource yang ada, gunakan payload JSON/XML yang sesuai dan tersimpan di pengelolaan kontrol sumber, lalu perbarui konfigurasi di Apigee menggunakan API.

* KVM terenkripsi tidak dapat diekspor dalam teks biasa dari API. Pengguna bertanggung jawab untuk mencatat nilai-nilai yang dimasukkan ke dalam KVM terenkripsi.

Bacaan lebih lanjut