Antipattern: gestire le risorse senza utilizzare la gestione del controllo del codice sorgente

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Visualizza la documentazione di Apigee Edge.

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

  • Proxy API
  • Flussi condivisi
  • Prodotti basati su API
  • Cache
  • KVM
  • Keystore e truststore
  • Host virtuali
  • Server di destinazione
  • File delle risorse

Sebbene queste risorse abbiano accesso limitato, se vengono apportate modifiche anche da parte degli utenti autorizzati, i dati storici vengono semplicemente sovrascritti con i nuovi dati. Ciò è dovuto al fatto che queste risorse vengono archiviate in Apigee 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 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 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 revisioni, se vengono apportate modifiche a una revisione esistente, non è possibile eseguire il rollback perché le vecchie modifiche vengono semplicemente sovrascritte.

Controlli e cronologia

Apigee fornisce la funzionalità Audit, 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 le operazioni sulle risorse Apigee. Tuttavia, se vengono eseguite operazioni di aggiornamento o eliminazione su una delle risorse Apigee, i controlli non possono fornire i dati precedenti.

Antipattern

Gestione delle risorse Apigee (elencate sopra) direttamente tramite l'interfaccia utente o le API Apigee senza utilizzare il sistema di controllo del codice sorgente

Esiste la convinzione errata che Apigee sia in grado di ripristinare le risorse al loro stato precedente in seguito a modifiche o 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 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 situazioni in cui è necessario annullare qualsiasi 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 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 o Python non gestito in un sistema di gestione del controllo della sorgente (SCM) esterno ad Apigee, si potrebbe perdere molto lavoro di sviluppo.

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 questo host virtuale a scopo di test può essere difficile se sono presenti molti proxy API. Se i proxy API vengono gestiti in un sistema SCM esterno ad Apigee, è facile cercare nel repository.

Esempio 3: eliminazione dell'archivio chiavi/archivio attendibile

Se un keystore/truststore utilizzato da una configurazione di host virtuale o server di destinazione viene eliminato, 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 Apigee viene eliminata, non è possibile recuperare la risorsa e i relativi contenuti da Apigee.
  • Le richieste API potrebbero non riuscire a causa di errori imprevisti che causano interruzioni del servizio fino al ripristino della risorsa allo stato precedente.
  • È difficile cercare le interdipendenze tra i proxy API e altre risorse in Apigee.

Best practice

  • Utilizza qualsiasi SCM standard accoppiato a una pipeline di integrazione continua e deployment continuo (CI/CD) per la gestione dei proxy API e dei flussi condivisi.
  • Utilizza qualsiasi SCM standard per gestire le altre risorse Apigee, inclusi prodotti API, cache, KVM, server di destinazione, host virtuali e keystore.
    • Se esistono risorse Apigee, utilizza le API Apigee per ottenere i dettagli di configurazione come payload JSON/XML e archiviali nel sistema di gestione del controllo della versione.
    • 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.

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

Per approfondire