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, ognuna con un 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 da utenti con i ruoli e le autorizzazioni di prerequisito. 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 sviluppatori né in altro modo. tra cui:

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

Sebbene queste risorse abbiano un accesso limitato, se vengono apportate modifiche anche dagli utenti autorizzati, i dati storici vengono semplicemente sovrascritti con i nuovi dati. Questo accade perché 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 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 un determinato momento, in un ambiente può essere dispiegato un solo flusso di proxy API/condiviso, 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 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 l'interfaccia utente o le API Apigee senza utilizzare il sistema di controllo del codice 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 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 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. Identificare i proxy API che 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, 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 recuperarla e i relativi 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 le interdipendenze tra i 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 gestire le altre risorse Apigee, tra cui prodotti API, cache, KVM, server di destinazione, host virtuali e keystore.
    • Se esistono risorse Apigee, 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