Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Apigee Edge fornisce molti tipi diversi di risorse, ognuna con uno scopo diverso scopo. Esistono alcune risorse che possono essere configurate (ovvero create, aggiornate e/o eliminate) solo tramite l'interfaccia utente di Edge, le API di gestione o gli strumenti che utilizzano le API di gestione e dagli utenti con i ruoli e le autorizzazioni prerequisiti. Ad esempio, solo gli amministratori dell'organizzazione appartenenti a un'organizzazione specifica possono configurare queste risorse. Ciò significa che queste risorse non possono essere configurate dagli utenti finali tramite i portali per sviluppatori o in altro modo. Queste risorse includono:
- Proxy API
- Flussi condivisi
- Prodotti basati su API
- Cache
- KVM
- Keystore e truststore
- Host virtuali
- Server di destinazione
- File di risorse
Sebbene queste risorse abbiano un accesso limitato, se vengono apportate modifiche, anche da parte degli utenti autorizzati, i dati storici vengono semplicemente sovrascritti con i nuovi dati. Questo perché queste risorse vengono archiviate in Apigee Edge solo in base al loro stato attuale. Le principali eccezioni a questa regola sono i proxy API e i flussi condivisi.
Proxy API e flussi condivisi sotto controllo delle revisioni
I proxy API e i flussi condivisi vengono gestiti, ovvero creati, aggiornati e di cui viene eseguito il deployment, tramite le revisioni. Le revisioni sono numerate in sequenza, il che ti consente di aggiungere nuove modifiche e salvarle come una nuova revisione o di ripristinare una modifica eseguendo il deployment di una revisione precedente del proxy API/flusso condiviso. In qualsiasi momento, può essere eseguito il deployment di una sola revisione di un proxy API/flusso condiviso in un ambiente, a meno che le revisioni non abbiano un percorso di base diverso.
Sebbene i proxy API e i flussi condivisi vengano gestiti tramite le revisioni, se vengono apportate modifiche a una revisione esistente, non è possibile eseguire il rollback perché le modifiche precedenti vengono semplicemente sovrascritte.
Audit e cronologia
Apigee Edge fornisce le funzionalità di audit e cronologia delle API, dei prodotti e dell'organizzazione che possono essere utili negli scenari di risoluzione dei problemi. Queste funzionalità ti consentono di visualizzare informazioni come chi ha eseguito operazioni specifiche (creazione, lettura, aggiornamento, eliminazione, deployment, e annullamento del deployment) e quando sono state eseguite le operazioni sulle risorse Edge. Tuttavia, se vengono eseguite operazioni di aggiornamento o eliminazione su una delle risorse Edge, gli audit non possono fornire i dati precedenti.
Antipattern
Gestione diretta delle risorse Edge (elencate sopra) tramite l'interfaccia utente di Edge o le API di gestione senza utilizzare il sistema di controllo del codice sorgente
Esiste un'idea sbagliata secondo cui Apigee Edge sarà in grado di ripristinare le risorse al loro stato precedente dopo le modifiche o le eliminazioni. Tuttavia, Edge Cloud non fornisce il ripristino delle risorse al loro stato precedente. Pertanto, è responsabilità dell'utente assicurarsi che tutti i dati relativi alle risorse Edge vengano gestiti tramite la gestione del controllo del codice sorgente, in modo che i dati precedenti possano essere ripristinati rapidamente in caso di eliminazione accidentale o in situazioni in cui è necessario eseguire il rollback di una modifica. Ciò è particolarmente importante per gli ambienti di produzione in cui questi dati sono necessari per il traffico di runtime.
Spieghiamo questo concetto con l'aiuto di alcuni esempi e il tipo di impatto che può essere causato se i dati non vengono gestiti tramite un sistema di controllo del codice sorgente e vengono modificati/eliminati consapevolmente o inconsapevolmente:
Esempio 1: eliminazione o modifica del proxy API
Quando un proxy API viene eliminato o viene eseguito il deployment di una modifica su una revisione esistente, il codice precedente non sarà recuperabile. Se il proxy API contiene codice Java, JavaScript, Node.js o Python che non è gestito in un sistema di gestione del controllo del codice sorgente (SCM) al di fuori di Apigee, si potrebbe perdere molto lavoro e impegno di sviluppo.
Esempio 2: determinazione dei proxy API che utilizzano host virtuali specifici
Un certificato su un host virtuale sta per scadere e l'host virtuale deve essere aggiornato. Se sono presenti molti proxy API, potrebbe essere difficile identificare quali proxy API utilizzano l'host virtuale a scopo di test. Se i proxy API vengono gestiti in un sistema SCM al di fuori di Apigee, sarà facile cercare nel repository.
Esempio 3: eliminazione di keystore/truststore
Se viene eliminato un keystore/truststore utilizzato da una configurazione di host virtuale o server di destinazione, non sarà possibile ripristinarlo a meno che i dettagli di configurazione del keystore/truststore, inclusi certificati e/o chiavi private, non siano archiviati nel controllo del codice sorgente.
Impatto
- Se una delle risorse Edge viene eliminata, non è possibile recuperare la risorsa e i relativi contenuti da Apigee Edge.
- Le richieste API potrebbero non riuscire con errori imprevisti che causano un'interruzione fino a quando la risorsa non viene ripristinata allo stato precedente.
- È difficile cercare le interdipendenze tra i proxy API e altre risorse in Apigee Edge.
Best practice
- Utilizza qualsiasi sistema SCM standard abbinato a una pipeline di integrazione continua e deployment continuo (CICD) per la gestione dei proxy API e dei flussi condivisi.
- Utilizza qualsiasi sistema SCM standard per la gestione delle altre risorse Edge, inclusi prodotti basati su API,
cache, KVM, server di destinazione, host virtuali e keystore.
- Se esistono risorse Edge, utilizza le API di gestione per ottenere i dettagli di configurazione come payload JSON/XML e archiviarli nella gestione del controllo del codice sorgente.
- Gestisci tutti i nuovi aggiornamenti di queste risorse nella gestione del controllo del codice sorgente.
- Se è necessario creare nuove risorse Edge o aggiornare quelle esistenti, utilizza il payload JSON/XML appropriato archiviato nella gestione del controllo del codice sorgente e aggiorna la configurazione in Edge utilizzando le API di gestione.
* I KVM criptati non possono essere esportati in testo non crittografato dall'API. È responsabilità dell'utente tenere traccia dei valori inseriti nei KVM criptati.