Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info
Apigee Edge fornisce molti tipi diversi di risorse, ognuna con un scopo diverso. 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 di prerequisito. 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 né in altro modo. tra cui:
- 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 dagli utenti autorizzati, i dati storici vengono semplicemente sovrascritti con i nuovi dati. Questo accade perché queste risorse vengono archiviate in Apigee Edge solo in base al loro stato corrente. Le principali eccezioni a questa regola sono i proxy API e i flussi condivisi.
Proxy API e flussi condivisi sotto il 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 nuova revisione o ripristinare una modifica implementando una revisione precedente del flusso condiviso/proxy API. In un determinato momento, in un ambiente può essere dispiegato un solo flusso di proxy API/condiviso, a meno che le revisioni non abbiano un percorso di base diverso.
Sebbene i proxy API e i flussi condivisi siano gestiti tramite revisioni, se vengono apportate modifiche a una revisione esistente, non è possibile eseguire il rollback poiché le modifiche precedenti vengono semplicemente sovrascritte.
Controlli e cronologia
Apigee Edge fornisce le funzionalità di audit e cronologia di API, prodotti e organizzazioni che possono essere utili per la 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 sulle risorse Edge. Tuttavia, se vengono eseguite operazioni di aggiornamento o eliminazione su una delle risorse Edge, i controlli non possono fornirti i dati meno recenti.
Antipattern
Gestire le risorse Edge (elencate sopra) direttamente tramite l'interfaccia utente di Edge o le API di gestione senza utilizzare il sistema di controllo del codice sorgente
È errato ritenere che Apigee Edge possa ripristinare le risorse allo stato precedente dopo le modifiche o le eliminazioni. Tuttavia, Edge Cloud non fornisce il ripristino delle risorse allo stato precedente. Pertanto, è responsabilità dell'utente assicurarsi che tutti i dati relativi alle risorse Edge siano gestiti tramite la gestione del controllo del codice sorgente, in modo che i vecchi dati possano essere ripristinati rapidamente in caso di eliminazione accidentale o situazioni in cui è necessario eseguire il rollback di eventuali modifiche. Questo è particolarmente importante per gli ambienti di produzione in cui questi dati sono richiesti per il traffico di runtime.
Spieghiamolo con l'aiuto di alcuni esempi e del 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 implementata una modifica in 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 (SCM) esterno ad Apigee, gran parte del lavoro di sviluppo e degli sforzi potrebbe andare perduto.
Esempio 2: determinazione dei proxy API utilizzando host virtuali specifici
Un certificato su un host virtuale sta per scadere e l'host virtuale deve essere aggiornato. Identificare i proxy API che utilizzano l'host virtuale a scopo di test può essere difficile se sono presenti molti proxy API. Se i proxy API sono gestiti in un sistema SCM esterno ad Apigee, sarà facile eseguire ricerche nel repository.
Esempio 3: eliminazione del keystore/truststore
Se un keystore/truststore utilizzato da un host virtuale o da una configurazione del server di destinazione viene eliminato, non sarà possibile ripristinarlo a meno che i dettagli di configurazione del keystore/truststore, inclusi i certificati e/o le 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 del servizio finché la risorsa non viene ripristinata allo stato precedente.
- È difficile cercare interdipendenze tra i proxy API e altre risorse in Apigee Edge.
Best practice
- Utilizza qualsiasi SCM standard abbinato a una pipeline di integrazione e deployment continui (CICD) per gestire i proxy API e i flussi condivisi.
- Utilizza qualsiasi SCM standard per gestire le altre risorse Edge, tra cui prodotti API, cache, KVM, server di destinazione, host virtuali e keystore.
- Se esistono risorse Edge esistenti, utilizza le API di gestione per recuperare i dettagli di configurazione come payload JSON/XML e memorizzarli nella gestione del controllo del codice sorgente.
- Gestisci eventuali 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 memorizzato nella gestione del controllo del codice sorgente e aggiorna la configurazione in Edge utilizzando le API di gestione.
* Le KVM criptate non possono essere esportate in testo non criptato dall'API. È responsabilità dell'utente mantenere un record dei valori inseriti nelle KVM criptate.