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 melayani tujuan. Ada resource tertentu yang dapat dikonfigurasi (misalnya dibuat, diperbarui, dan/atau dihapus) hanya melalui UI Apigee, API Apigee, atau alat yang menggunakan API, dan dengan pengguna dengan peran dan izin prasyarat. Misalnya, hanya admin org yang tergabung dalam organisasi tertentu dapat mengkonfigurasi sumber daya ini. Artinya, sumber daya ini tidak bisa dikonfigurasi oleh pengguna akhir melalui portal developer, maupun dengan cara lainnya. Referensi ini termasuk:

  • Proxy API
  • Alur bersama
  • Produk API
  • Cache
  • KVM
  • Keystore dan truststore
  • Host virtual
  • Server target
  • File resource

Walaupun sumber daya ini memiliki akses terbatas, jika ada modifikasi yang dibuat pada pengguna yang diotorisasi, maka data historis akan ditimpa dengan data baru. Ini adalah karena resource tersebut hanya disimpan di Apigee 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 simpan sebagai revisi baru atau kembalikan perubahan dengan men-deploy revisi API sebelumnya {i>proxy<i}/alur bersama. Pada waktu tertentu, hanya boleh ada satu revisi proxy API/dibagikan yang di-deploy di suatu lingkungan kecuali jika revisi memiliki jalur dasar yang berbeda.

Meskipun proxy API dan alur bersama dikelola melalui revisi, jika ada modifikasi dibuat ke revisi yang ada, tidak ada cara untuk membatalkan karena perubahan lama hanya akan ditimpa.

Audit dan Histori

Apigee menyediakan fitur Audit yang dapat membantu dalam skenario pemecahan masalah. Fitur-fitur ini memungkinkan Anda untuk melihat informasi seperti siapa yang melakukan operasi tertentu (membuat, membaca, mengupdate, menghapus, men-deploy, dan membatalkan deployment) serta waktu operasi dilakukan di resource Apigee. Namun, jika update apa pun atau penghapusan dilakukan pada salah satu resource Apigee, audit tidak dapat memberi Anda data lama.

Anti-pola

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

Ada kesalahpahaman bahwa Apigee akan dapat memulihkan resource ke versi sebelumnya menyatakan perubahan atau penghapusan berikut. 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 di mana diperlukan perubahan untuk di-roll back. Hal ini sangat penting untuk lingkungan produksi di mana data ini yang diperlukan untuk traffic runtime.

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

Contoh 1: Penghapusan atau modifikasi proxy API

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

Contoh 2: Penentuan proxy API menggunakan host virtual tertentu

Sertifikat pada host virtual akan habis masa berlakunya dan host virtual tersebut perlu diperbarui. Mengidentifikasi proxy API mana yang menggunakan {i> host<i} virtual itu untuk tujuan pengujian mungkin sulit jika ada banyak Proxy API. Jika proxy API dikelola dalam sistem SCM di luar Apigee, akan lebih mudah untuk menelusuri repositori.

Contoh 3: Penghapusan keystore/truststore

Jika keystore/truststore yang digunakan oleh virtual host atau konfigurasi server target dihapus, maka tidak mungkin memulihkannya kembali kecuali detail konfigurasi keystore/truststore, termasuk sertifikat dan/atau kunci pribadi, disimpan di kontrol sumber.

Dampak

  • Jika salah satu resource Apigee dihapus, resource tersebut tidak dapat dipulihkan dan kontennya dari Apigee.
  • Permintaan API mungkin gagal dengan error tak terduga yang menyebabkan pemadaman layanan hingga resource dipulihkan kembali ke status sebelumnya.
  • Sulit untuk mencari interdependensi antara proxy API dan sumber daya lain di Apigee.

Praktik Terbaik

  • Gunakan SCM standar apa pun yang digabungkan dengan continuous integration dan continuous deployment (CICD) pipeline 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 tersedia resource Apigee yang ada, gunakan Apigee API untuk mendapatkan detail konfigurasinya sebagai payload JSON/XML dan menyimpannya di kontrol sumber otomatisasi pengelolaan biaya.
    • Kelola update baru pada resource ini di pengelolaan kontrol sumber.
    • Jika Anda perlu membuat resource Apigee baru atau memperbarui resource yang ada, lalu menggunakan payload JSON/XML yang sesuai yang disimpan dalam manajemen kontrol sumber dan konfigurasi di Apigee menggunakan API.

* KVM terenkripsi tidak dapat diekspor dalam teks biasa dari API. Tanggung jawab pengguna untuk menyimpan catatan tentang nilai apa yang dimasukkan ke dalam KVM terenkripsi.

Bacaan lebih lanjut