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 la documentazione di Apigee Edge.

Apigee offre molti tipi diversi di risorse e ognuna di queste 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 API e dagli utenti con ruoli e autorizzazioni dei prerequisiti. Ad esempio, solo gli amministratori dell'organizzazione che appartengono a un'organizzazione specifica possono configurare queste risorse. Ciò significa che queste risorse non possono essere configurate dagli utenti finali tramite portali per gli sviluppatori o con altri mezzi. tra cui:

  • 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. Ciò è dovuto al fatto che queste risorse sono archiviate in Apigee solo nel 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 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 annullare una modifica eseguendo il deployment di una revisione precedente del proxy API/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 mediante 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 controllo, 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 le operazioni 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 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 ritiene erroneamente che Apigee possa ripristinare lo stato precedente delle risorse in seguito a modifiche o eliminazioni. Tuttavia, Apigee non consente di ripristinare lo stato precedente delle risorse. Pertanto, è responsabilità dell'utente assicurarsi che tutti i dati relativi alle risorse Apigee vengano gestiti attraverso la gestione del controllo del codice sorgente, in modo che i vecchi dati possano essere ripristinati rapidamente in caso di eliminazione accidentale o in 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 ciò 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 dei file 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 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 del codice sorgente (SCM) esterno ad Apigee, potresti perdere molto del lavoro e degli sforzi di sviluppo.

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. L'identificazione dei 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, sarebbe facile cercare nel repository.

Esempio 3: eliminazione di archivio chiavi/truststore

Se viene eliminato un archivio chiavi/truststore utilizzato da un host virtuale o da una configurazione del server di destinazione, non sarà possibile ripristinarlo, a meno che i dettagli di configurazione dell'archivio chiavi/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 e i suoi contenuti da Apigee.
  • Le richieste API potrebbero non riuscire con errori imprevisti che causano un'interruzione finché la risorsa non viene ripristinata allo stato precedente.
  • È difficile cercare 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 la gestione delle altre risorse Apigee, tra cui prodotti API, cache, KVM, server di destinazione, host virtuali e archivi chiavi.
    • Se sono presenti risorse Apigee, utilizza le API Apigee per ottenere i relativi dettagli di configurazione come payload JSON/XML e archiviarle nella gestione del controllo del codice sorgente.
    • 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, 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 tenere traccia dei valori inseriti nelle KVM criptate.

Per approfondire