Anti-pattern: gestire le risorse senza utilizzare la gestione del controllo del codice sorgente

Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Visualizza Documentazione di Apigee Edge.

Apigee offre molti tipi diversi di risorse e ognuna di queste gestisce che non ha uno scopo specifico. Esistono alcune risorse che possono essere configurate (ovvero create, aggiornate e/o eliminati) solo tramite la UI di Apigee, le API Apigee o gli strumenti che utilizzano le API, e con i ruoli e le autorizzazioni prerequisiti. Ad esempio, solo gli amministratori dell'organizzazione appartenenti a un un'organizzazione specifica può configurare queste risorse. Ciò significa che queste risorse configurate dagli utenti finali tramite portali per sviluppatori o con altri mezzi. Queste risorse include:

  • Proxy API
  • Flussi condivisi
  • Prodotti basati su API
  • Cache
  • KVMs
  • Archivi chiavi e truststore
  • Host virtuali
  • Server di destinazione
  • File di risorse

Anche se queste risorse hanno accesso limitato, nel caso in cui vengano apportate modifiche anche gli utenti autorizzati, i dati storici vengono semplicemente sovrascritti con i nuovi dati. Questo è poiché queste risorse sono archiviate in Apigee solo secondo il loro stato attuale. Le principali eccezioni a questa regola sono i proxy API e i flussi condivisi.

Proxy API e flussi condivisi in controllo di revisione

I proxy API e i flussi condivisi vengono gestiti, ovvero creati, aggiornati e distribuiti, tramite revisioni. Le revisioni sono numerate in sequenza, il che consente di aggiungere nuove modifiche e salvarla come nuova revisione o ripristina una modifica eseguendo il deployment di una revisione precedente dell'API proxy/flusso condiviso. In qualsiasi momento può essere presente una sola revisione di un proxy API/condiviso flusso di cui è stato eseguito il deployment 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, esistenti, non c'è modo di eseguirne il rollback poiché le modifiche precedenti sono sovrascritto.

Controlli e cronologia

Apigee offre la funzionalità di controllo che può essere utile per la risoluzione dei problemi. Queste funzioni ti consentono per visualizzare informazioni come chi ha eseguito operazioni specifiche (creazione, lettura, aggiornamento, eliminazione, e l'annullamento del deployment) e quando sono state eseguite le operazioni sulle risorse Apigee. Tuttavia, gli eventuali aggiornamenti le operazioni di eliminazione o eliminazione vengono eseguite su una qualsiasi delle risorse Apigee, i controlli non possono fornirti i dati più vecchi.

Antipattern

Gestire le risorse Apigee (elencate sopra) direttamente tramite la UI o le API Apigee senza utilizzando il sistema di controllo del codice sorgente

Si ritiene erroneamente che Apigee possa ripristinare le risorse alla versione precedente in seguito a modifiche o eliminazioni. Tuttavia, Apigee non fornisce il ripristino delle risorse allo stato precedente. Pertanto, è responsabilità dell'utente garantire che tutti i dati relativi alle risorse Apigee vengono gestiti tramite la gestione del controllo del codice sorgente, in modo che i dati precedenti possono essere ripristinati rapidamente in caso di eliminazione accidentale o in situazioni in cui è necessario apportare modifiche eseguire il rollback. Ciò è particolarmente importante per gli ambienti di produzione in cui questi dati richiesta 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 sono gestiti tramite un sistema di controllo del codice sorgente e vengono modificati/eliminati consapevolmente o a inconsapevolezza:

Esempio 1: eliminazione o modifica del proxy API

Quando un proxy API viene eliminato o viene eseguito il deployment di una modifica in una revisione esistente, il codice precedente e non saranno recuperabili. Se il proxy API contiene codice Java, JavaScript o Python che non gestiti in un sistema di gestione del controllo del codice sorgente (SCM) esterno ad Apigee, molto lavoro di sviluppo e gli sforzi potrebbero andare persi.

Esempio 2: determinazione dei proxy API utilizzando host virtuali specifici

Un certificato su un host virtuale è in scadenza e l'host virtuale deve essere aggiornato. Identificazione quali proxy API utilizzano l'host virtuale a scopo di test, potrebbero essere difficili Proxy API. Se i proxy API sono gestiti in un sistema SCM esterno ad Apigee, sarebbe facile per eseguire ricerche nel repository.

Esempio 3: eliminazione di archivio chiavi/truststore

Se un archivio chiavi/truststore utilizzato da un host virtuale o dalla configurazione di un server di destinazione eliminato, non sarà possibile ripristinarlo a meno che i dettagli di configurazione un archivio chiavi/truststore, inclusi i certificati e/o le chiavi private, sono archiviati nel controllo del codice sorgente.

Impatto

  • Se una delle risorse Apigee viene eliminata, non è possibile recuperare la risorsa, i suoi contenuti da Apigee.
  • Le richieste API potrebbero non riuscire con errori imprevisti che portano a un'interruzione finché la risorsa non viene ripristinata allo stato precedente.
  • È difficile cercare interdipendenze tra proxy API e altre risorse in Apigee.

Best practice

  • Utilizza qualsiasi SCM standard abbinato a un'integrazione e un deployment continui (CICD) per la gestione dei proxy API e dei flussi condivisi.
  • Utilizza qualsiasi SCM standard per la gestione delle altre risorse Apigee, inclusi i prodotti API, cache, KVM, server di destinazione, host virtuali e archivi chiavi.
    • Se sono già presenti risorse Apigee, utilizza le API Apigee per ottenere di configurazione come payload JSON/XML e di archiviarli nel controllo del codice sorgente gestione dei dispositivi.
    • Gestisci gli eventuali nuovi aggiornamenti a queste risorse nella gestione del controllo del codice sorgente.
    • Se è necessario creare nuove risorse Apigee o aggiornare risorse esistenti, quindi utilizza il payload JSON/XML appropriato, archiviato nella gestione del controllo del codice sorgente e aggiorna la configurazione in Apigee utilizzando le API.

* Le KVM criptate non possono essere esportate in testo normale dall'API. È responsabilità dell'utente. per tenere traccia dei valori inseriti nelle KVM criptate.

Per approfondire