Anti-pattern: gestisci 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 offre 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 l'interfaccia utente di Apigee, le API Apigee o gli strumenti che utilizzano le API, e dagli 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 portali per gli sviluppatori, né tramite 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 semplicemente vengono 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 controllo delle revisioni

I proxy API e i flussi condivisi vengono gestiti, ovvero creati, aggiornati e sottoposti a deployment, mediante revisioni. Le revisioni sono numerate in sequenza, il che 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 è possibile eseguire 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 modifiche precedenti vengono semplicemente sovrascritte.

Controlli e cronologia

Apigee offre la funzionalità di audit che può essere utile nella 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 le operazioni sono state eseguite sulle risorse Apigee. Tuttavia, se vengono eseguite operazioni di aggiornamento o eliminazione su una qualsiasi delle risorse Apigee, i controlli non possono fornire i dati meno recenti.

Antipattern

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

Si pensa erroneamente che Apigee sarà in grado di ripristinare le risorse allo stato precedente dopo 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 vengano 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 o Python non gestito in un sistema di gestione del controllo del codice sorgente (SCM) al di fuori di Apigee, molto lavoro e sforzi 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 l'host virtuale deve essere aggiornato. Identificare quali proxy API 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, sarebbe facile eseguire ricerche nel repository.

Esempio 3: eliminazione dell'archivio chiavi o dell'archivio attendibile

Se viene eliminato un archivio chiavi/un archivio di attendibilità utilizzato da un host virtuale o da un server di destinazione, non sarà possibile ripristinarlo a meno che i dettagli di configurazione dell'archivio chiavi/dell'archivio di attendibilità, inclusi certificati e/o chiavi private, non vengano 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 con errori imprevisti, determinando un'interruzione fino al ripristino dello stato precedente della risorsa.
  • È difficile cercare interdipendenze tra i proxy API e altre risorse in Apigee.

Best practice

  • Utilizza qualsiasi SCM standard abbinato a una pipeline di integrazione continua e deployment continuo (CICD) per gestire i proxy API e i flussi condivisi.
  • Utilizza qualsiasi SCM standard per gestire le altre risorse Apigee, tra cui prodotti API, cache, KVM, server di destinazione, host virtuali e archivi chiavi.
    • Se esistono risorse Apigee esistenti, utilizza le API Apigee per ottenere i dettagli di configurazione come payload JSON/XML e archiviarli 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 le risorse 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 un record dei valori inseriti nelle KVM criptate.

Per approfondire