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

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
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
  • 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. 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 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 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, una revisione esistente, non c'è modo di eseguirne il rollback poiché le modifiche precedenti sono sovrascritto.

Controlli e cronologia

Apigee fornisce la funzionalità di controllo che può essere utile 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 Apigee. Tuttavia, se vengono eseguite operazioni di aggiornamento o eliminazione su una delle risorse Apigee, i controlli non possono fornirti i dati precedenti.

Antipattern

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

È errato ritenere che Apigee possa ripristinare le risorse allo stato precedente dopo le modifiche o le eliminazioni. Tuttavia, Apigee non fornisce il ripristino delle risorse allo stato precedente. Pertanto, è responsabilità dell'utente assicurarsi che tutti i dati relativi alle risorse Apigee 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 sono 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 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 dell'impegno potrebbe andare perso.

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. 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, 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 Apigee viene eliminata, non è possibile recuperare la risorsa, i suoi contenuti da Apigee.
  • 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 proxy API e altre risorse in Apigee.

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 la gestione delle altre risorse Apigee, inclusi i prodotti API, cache, KVM, server di destinazione, host virtuali e archivi chiavi.
    • Se esistono risorse Apigee esistenti, utilizza le API Apigee 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 Apigee o aggiornare quelle esistenti, 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 non criptato dall'API. È responsabilità dell'utente mantenere un record dei valori inseriti nelle KVM criptate.

Per approfondire