Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
Apigee Edge fornisce molti tipi diversi di risorse, ognuna delle quali ha uno scopo diverso. Esistono alcune risorse che possono essere configurate (ovvero create, aggiornate e/o eliminate) solo tramite la UI perimetrale, 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 gli sviluppatori né con altri mezzi. Queste risorse includono:
- Proxy API
- Flussi condivisi
- Prodotti basati su API
- Cache
- KVM
- Archivi chiavi e truststore
- Host virtuali
- Server di destinazione
- File di risorse
Sebbene queste risorse abbiano accesso limitato, se vengono apportate modifiche anche dagli utenti autorizzati, i dati storici vengono semplicemente sovrascritti con i nuovi dati. Ciò è dovuto al fatto che 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 durante il controllo delle revisioni
I proxy API e i flussi condivisi vengono gestiti, ovvero creati, aggiornati e sottoposti a deployment, tramite revisioni. Le revisioni sono numerate in sequenza, il che ti consente di aggiungere nuove modifiche e salvarle come nuova revisione o annullare una modifica eseguendo il deployment di una revisione precedente del proxy API o del flusso condiviso. In qualsiasi momento, può essere eseguito il deployment di una sola revisione di un proxy API o di un 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 siano gestiti tramite revisioni, se vengono apportate modifiche a una revisione esistente, non è possibile eseguire il rollback poiché le vecchie modifiche vengono semplicemente sovrascritte.
Controlli e cronologia
Apigee Edge fornisce le funzionalità di audit e di cronologia di API, prodotti e organizzazione che possono essere utili negli scenari di risoluzione dei problemi. Queste funzionalità 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 di eliminazione su una delle risorse Edge, i controlli non possono fornire i dati precedenti.
Antipattern
Gestione delle risorse perimetrali (elencate sopra) direttamente tramite UI o API di gestione Edge senza utilizzare il sistema di controllo del codice sorgente
Si ritiene che Apigee Edge sarà in grado di ripristinare le risorse allo stato precedente dopo le modifiche o le eliminazioni. Tuttavia, Edge Cloud non consente di ripristinare le risorse al loro stato precedente. Pertanto, è responsabilità dell'utente garantire 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 di situazioni in cui è necessario eseguire il rollback di qualsiasi modifica. Ciò è particolarmente importante per gli ambienti di produzione in cui questi dati sono richiesti per il traffico di runtime.
Spieghiamo questo 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 non gestito in un sistema di gestione del controllo del codice sorgente (SCM) al di fuori di Apigee, molto lavoro e impegno di sviluppo potrebbero andare persi.
Esempio 2: determinazione dei proxy API utilizzando host virtuali specifici
Un certificato su un host virtuale sta per scadere e questo host virtuale deve essere aggiornato. Identificare quali proxy API utilizzano quell'host virtuale a scopo di test può essere difficile se ci sono molti proxy API. Se i proxy API sono gestiti in un sistema SCM esterno ad Apigee, sarebbe facile eseguire ricerche nel repository.
Esempio 3: eliminazione dell'archivio chiavi o dell'archivio attendibilità
Se un archivio chiavi/archivio attendibilità utilizzato da un host virtuale o dalla configurazione di un server di destinazione viene eliminato, non sarà possibile ripristinarlo a meno che i dettagli di configurazione dell'archivio chiavi o dell'archivio attendibilità, inclusi i certificati e/o le chiavi private, non vengano 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 comportano un'interruzione fino a quando la risorsa non viene ripristinata allo stato precedente.
- È difficile cercare interdipendenze tra proxy API e altre risorse in Apigee Edge.
Best practice
- Utilizza qualsiasi SCM standard abbinata a una pipeline di integrazione continua e deployment continuo (CICD) per gestire proxy API e flussi condivisi.
- Utilizza qualsiasi SCM standard per la gestione delle altre risorse Edge, tra cui prodotti API, cache, KVM, server di destinazione, host virtuali e archivi chiavi.
- Se sono già presenti risorse Edge, utilizza le API di gestione per ottenere i dettagli di configurazione come payload JSON/XML e archiviarle nella gestione del controllo del codice sorgente.
- Gestisci eventuali nuovi aggiornamenti a 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 come testo normale dall'API. È responsabilità dell'utente tenere un record dei valori inseriti nelle KVM criptate.