Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Questa pagina documenta le note di rilascio di tutto il software Apigee Adapter for Envoy per il 2021 e gli anni precedenti.
Consulta Adapter for Envoy per le note di rilascio correnti (2022 e versioni successive).
v2.0.4
Il 3 dicembre 2021 abbiamo rilasciato la versione 2.0.4 di Apigee Adapter for Envoy.
Funzionalità e miglioramenti
- L'elenco delle versioni di Envoy e Istio supportate per il comando
samples
della CLI è stato aggiornato. Ora queste versioni sono supportate per i campioni:- Versioni di Envoy da 1.18 a 1.20
- Versioni di Istio da 1.10 a 1.12
Problemi risolti
- È stato aggiunto un controllo di nullità per il caricamento della chiave privata del blocco PEM per evitare errori irreversibili. (Problema n. 360)
- Gli errori di autorizzazione del servizio remoto vengono ora registrati a livello di debug. Un'eccezione a questa classificazione
riguarda gli errori di recupero dei token per le chiavi API. In questo caso, gli errori vengono registrati a livello di errore
in modo che siano visibili anche se il livello di log di debug per
apigee-remote-service-envoy
è disattivato. Vedi anche Impostare i livelli di log del servizio remoto. (Problema n. 104)
v2.0.3
Il 21 settembre 2021 abbiamo rilasciato la versione 2.0.3 di Apigee Adapter for Envoy.
Problemi risolti
- È stato risolto un problema di logging di Analytics relativo alle risposte dirette. Il problema si è verificato solo in determinate
circostanze. Ad esempio:
- Per le richieste che non richiedono il controllo di autenticazione/autorizzazione, non è stato generato alcun
authContext
e i metadati dinamici erano nulli, pertanto la voce di log di accesso è stata ignorata. - La risposta negata utilizzava il codice RPC anziché il codice HTTP, pertanto i record venivano visualizzati nell'interfaccia utente Apigee come riusciti.
- Per le richieste che non richiedono il controllo di autenticazione/autorizzazione, non è stato generato alcun
v2.0.2
Il 7 giugno 2021 abbiamo rilasciato la versione 2.0.2 di Apigee Adapter for Envoy.
Problemi risolti
- È stata corretta una race condition che poteva causare errori 403 e panico quando gli ambiti delle rivendicazioni JWT erano nulli.
v2.0.1
Martedì 29 aprile 2021 abbiamo rilasciato la versione 2.0.1 di Apigee Adapter for Envoy.
Problemi risolti
Funzionalità | Descrizione |
---|---|
Bug |
È stato risolto un problema che causava il malfunzionamento della versione 2.0.0 se utilizzata con Apigee hybrid versione 1.5.0 o Apigee. Se esegui l'upgrade dell'installazione di Apigee hybrid alla versione 1.5.x, il percorso di upgrade consigliato per l'adattatore è:
Se utilizzi Apigee, esegui l'upgrade dell'adattatore alla versione 2.0.1. |
v2.0.0
Martedì 6 aprile 2021 abbiamo rilasciato la versione 2.0.0 di Apigee Adapter for Envoy.
Funzionalità e miglioramenti
Funzionalità | Descrizione |
---|---|
Supporto dell'ambiente multi-tenant |
Ora puoi abilitare l'adattatore per gestire più ambienti in un'organizzazione Apigee. Questa funzionalità ti consente di utilizzare un adattatore Apigee per Envoy associato a un'organizzazione Apigee per gestire più ambienti. Prima di questa modifica, un adattatore era sempre collegato a un ambiente Apigee. Per saperne di più su questa funzionalità, consulta Supporto dell'ambiente multi-tenant. |
Supporto dell'API Envoy v3 | |
Supporto dei metadati di Envoy |
Envoy 1.16+ consente
l'invio di metadati Questa funzionalità è supportata solo per Envoy 1.16+ e Istio 1.9+.
Con questa modifica, la seguente configurazione non viene più aggiunta al file di configurazione Envoy ( additional_request_headers_to_log: - x-apigee-accesstoken - x-apigee-api - x-apigee-apiproducts - x-apigee-application - x-apigee-clientid - x-apigee-developeremail - x-apigee-environment Se vuoi aggiungere intestazioni alle richieste per un caso speciale, imposta la proprietà
|
Dividere il proxy remote-token dal proxy remote-service |
Il proxy remote-service è stato refactorizzato in due proxy separati. Il provisioning della versione 2.0.x
installerà due proxy API: remote-service e remote-token. Gli endpoint
Questa modifica crea una separazione utile delle funzioni. Ora, il proxy remote-service
viene utilizzato solo per le comunicazioni interne dell'adattatore, mentre il proxy remote-token
fornisce un flusso di lavoro OAuth di esempio che puoi personalizzare. Non sovrascriveremo mai
il proxy remote-token personalizzato, anche se viene utilizzato il comando |
Supporto per l'acquisizione dei dati | L'adattatore ora supporta il trasferimento dei metadati Envoy alla funzionalità di acquisizione dei dati di Apigee, che invia i dati acquisiti nelle variabili specificate ad Apigee Analytics per l'utilizzo nei report personalizzati. Questa funzionalità offre una funzionalità simile al criterio di acquisizione dati di Apigee. Per ulteriori informazioni su questa funzionalità, vedi Acquisizione dei dati per i report personalizzati. |
RBAC non richiesto | Come indicato in precedenza in Supporto dei metadati di Envoy, ora rifiutiamo immediatamente le richieste non autorizzate senza richiedere un filtro RBAC separato. Poiché il controllo dell'accesso basato sui ruoli non viene utilizzato, i client ora riceveranno questi codici di stato HTTP in modo appropriato dall'adattatore:
Se vuoi consentire la continuazione delle richieste non autorizzate, puoi farlo impostando
|
Le intestazioni x-apigee-* non vengono più aggiunte per impostazione predefinita |
Come indicato in precedenza nella sezione Supporto dei metadati Envoy,
le intestazioni |
Corrispondenza personalizzata di una richiesta con un'operazione del prodotto API Apigee |
La semantica della proprietà di configurazione
Per sostituire questo valore dell'intestazione utilizzando i metadati di Envoy, puoi passare l'elemento di metadati typed_per_filter_config: envoy.filters.http.ext_authz: "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute check_settings: context_extensions: apigee_api: httpbin.org |
I dati di Analytics per le richieste rifiutate vengono registrati immediatamente | L'adattatore Envoy ora registra immediatamente le richieste rifiutate in Analytics come richiesto, anziché attendere che la richiesta venga restituita nel log degli accessi. Questo metodo è più efficiente e non richiede l'allegato di metadati alla richiesta. |
Il supporto UDCA è stato rimosso | Lo streaming all'agente di raccolta dati universale (UDCA) di Apigee in Apigee hybrid e Apigee non è più necessario per l'analisi, in quanto è stato sostituito dal caricamento diretto. Questa modifica rimuove semplicemente il supporto legacy per questa opzione. |
Aggiunto il supporto mTLS per Edge for Private Cloud nei comandi CLI provision/bindings |
Gli utenti di Apigee Edge for Private Cloud possono fornire certificati TLS lato client e certificati root tramite |
Supporto di mTLS tra l'adattatore e il runtime Apigee |
Puoi fornire i certificati TLS lato client nella sezione |
Altri problemi e correzioni
- È stato risolto un problema per cui più configurazioni di operazioni con la stessa origine API condividevano gli stessi identificatori dei bucket di quota e causavano conflitti nel calcolo della quota. (Problema n. 34)
- È stato risolto un problema per cui le operazioni senza verbi specificati causavano il rifiuto della richiesta (il comportamento previsto è quello di consentire tutti i verbi se non ne viene specificato nessuno). (Problema n. 39)
v1.4.0
Mercoledì 16 dicembre 2020 abbiamo rilasciato la versione 1.4.0 di Apigee Adapter for Envoy.
Piattaforme supportate
Pubblichiamo i file binari per macOS, Linux e Windows.
Pubblichiamo immagini Docker da distroless, Ubuntu e Ubuntu con Boring Crypto di Google.
In questa versione supportiamo le seguenti piattaforme:
- Apigee hybrid versione 1.3.x, 1.4.x (data di rilascio in attesa), Apigee per il cloud pubblico, Apigee per il cloud privato e Apigee su Google Cloud
- Versioni di Istio 1.5, 1.6, 1.7, 1.8
- Versioni di Envoy 1.14, 1.15, 1.16
Funzionalità e miglioramenti
Funzionalità | Descrizione |
---|---|
Il proxy remote-service non richiede più l'associazione a
un prodotto API che utilizza target di servizio remoti. |
Poiché questa associazione non è più necessaria, tieni presente le seguenti modifiche:
|
Il ruolo Amministratore dell'organizzazione Apigee non è più necessario per il provisioning. |
Anziché richiedere l'autorizzazione di amministratore dell'organizzazione per il provisioning, ora puoi utilizzare
i ruoli IAM Creator e Deployer. Per eseguire il provisioning correttamente, devi concedere entrambi questi ruoli.
|
Altri problemi e correzioni
- È stato risolto un problema per cui il riprovisioning di Apigee senza l'opzione
--rotate
terminava con un errore. - La CLI di provisioning ora legge e riutilizza le credenziali del account di servizio di Analytics
da un determinato file
config.yaml
(problema n. 133).
v1.3.0
Lunedì 23 novembre 2020 abbiamo rilasciato la versione 1.3.0 di Apigee Adapter for Envoy.
Piattaforme supportate
Pubblichiamo i file binari per macOS, Linux e Windows.
Pubblichiamo immagini Docker da distroless, Ubuntu e Ubuntu con Boring Crypto di Google.
In questa versione supportiamo le seguenti piattaforme:
- Apigee hybrid versione 1.3.x, 1.4.x (data di rilascio in attesa), Apigee per il cloud pubblico, Apigee per il cloud privato e Apigee su Google Cloud
- Versioni di Istio 1.5, 1.6, 1.7, 1.8
- Versioni di Envoy 1.14, 1.15, 1.16
Funzionalità e miglioramenti
Funzionalità | Descrizione |
---|---|
Supporto per OperationGroups dei prodotti API. | OperationGroups associa le risorse e l'applicazione della quota associata in un proxy o
servizio remoto con metodi HTTP. Per maggiori dettagli, vedi
OperationGroup.
(Valido solo per Apigee su Google Cloud e Apigee hybrid) |
Rimuovi il supporto del proxy di inoltro dinamico dalla generazione di campioni. | A causa di questa modifica, i client devono includere l'intestazione HOST se il nome host è diverso dall'host di destinazione del servizio remoto impostato nel prodotto API. Ad esempio:
curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org" Consulta Crea un prodotto API. |
Supporta i service account e Workload Identity. | Per consentire il caricamento dei dati di analisi su Apigee quando
esegui l'adattatore al di fuori di un cluster ibrido Apigee, devi utilizzare il
parametro analytics-sa con il comando apigee-remote-service-cli provision . Inoltre, l'adattatore ora supporta Workload Identity su Google Kubernetes
Engine (GKE). Vedi comando Provision.
(Valido solo per Apigee su Google Cloud e Apigee hybrid) |
Nuovo attributo di configurazione jwt_provider_key . |
Questa chiave viene aggiunta al file di configurazione.
Rappresenta la chiave payload_in_metadata del provider JWT nella
configurazione di Envoy
o l'emittente JWT RequestAuthentication nella configurazione di Istio. |
L'attributo di configurazione KeepAliveMaxConnectionAge ora
è impostato su 1 minuto per impostazione predefinita. |
Il valore predefinito precedente era 10 minuti. Questa modifica consente una scalabilità più fluida. Questo valore viene utilizzato anche per la durata dello stream dei log di accesso. Consulta il file di configurazione. |
Comandi CLI rimossi. | I seguenti comandi dell'interfaccia a riga di comando sono stati ritirati. Ti consigliamo di utilizzare le
API Apigee
per aggiornare i target dei servizi remoti per i prodotti API:
|
È stato aggiunto un nuovo comando CLI. | Il comando:
apigee-remote-service-cli samples templates elenca le opzioni disponibili
che puoi utilizzare con il flag |
Modificato il comando CLI esistente. | È stata apportata una modifica al comando apigee-remote-service-cli samples create . I flag specifici dei modelli Envoy o Istio vengono controllati rigorosamente e
vengono restituiti errori per i flag utilizzati in modo errato. L'opzione del modello native è
deprecata. Per ottenere un elenco dei modelli disponibili, utilizza il comando apigee-remote-service-cli samples templates .
Vedi anche Riferimento per l'interfaccia a riga di comando.
|
La risposta dell'endpoint /token ora segue la
specifica OAuth2. |
Il parametro access_token è stato aggiunto alla risposta e il parametro token
è ritirato. |
v1.2.0
Mercoledì 30 settembre 2020 abbiamo rilasciato la versione 1.2.0 di Apigee Adapter for Envoy.
Piattaforme supportate
Pubblichiamo i file binari per macOS, Linux e Windows.
Pubblichiamo immagini Docker da distroless, Ubuntu e Ubuntu con Boring Crypto di Google.
In questa versione supportiamo le seguenti piattaforme:
- Apigee hybrid versione 1.3.x
- Versioni di Istio 1.5, 1.6, 1.7
- Versioni di Envoy 1.14, 1.15
Funzionalità e miglioramenti
Funzionalità | Descrizione |
---|---|
Assistenza per Apigee su Google Cloud | Ora puoi utilizzare Apigee Adapter for Envoy con Apigee su Google Cloud. Puoi eseguire l'adattatore nel proprio cluster o eseguendo il servizio remoto per Envoy come binario nativo o in un container. Esegui il provisioning dell'adattatore su Apigee utilizzando il comando provision. |
Caricamento diretto dei dati di analisi | Ora puoi configurare l'adattatore Apigee per caricare direttamente i dati di analisi su Apigee. Se utilizzi
Apigee hybrid, questa
nuova funzionalità consente di eseguire il deployment dell'adattatore nel proprio cluster Kubernetes, al di fuori
del cluster in cui è installato Apigee hybrid. Per attivare il caricamento diretto, utilizza il nuovo
flag --analytics-sa con il comando provision .
Vedi il comando di provisioning.
|
Il controllo dello stato restituisce "Pronto" dopo che i dati del prodotto API sono stati caricati da Apigee | Il controllo di integrità di Kubernetes non restituirà "Pronto" finché i dati del prodotto API non saranno caricati da Apigee. Questa modifica semplifica lo scaling e l'upgrade, perché nessun traffico verrà inviato all'adattatore appena istanziato finché non sarà pronto. |
Altri problemi e correzioni
- È stato risolto un problema per risolvere un potenziale deadlock di sincronizzazione della quota (problema n. 17).
- Le annotazioni di Prometheus sono state spostate nella specifica del pod (Issue #69).
- È stato risolto un problema relativo agli errori di verifica emessi in modo errato (problema n. 62).
v1.1.0
Mercoledì 26 agosto 2020 abbiamo rilasciato la versione 1.1.0 di Apigee Adapter for Envoy.
Piattaforme supportate
Pubblichiamo i file binari per macOS, Linux e Windows.
Pubblichiamo immagini Docker da distroless, Ubuntu e Ubuntu con Boring Crypto di Google.
Nella versione 1.1.0 supportiamo le seguenti piattaforme:
- Apigee hybrid versione 1.3
- Versioni di Istio 1.5, 1.6, 1.7
- Versioni di Envoy 1.14, 1.15
Funzionalità e miglioramenti
Funzionalità | Descrizione |
---|---|
Verifica le associazioni | È stato aggiunto un nuovo comando apigee-remote-service-cli bindings verify
alla CLI. Questo comando verifica che il prodotto API vincolato specificato e le relative
app per sviluppatori associate abbiano anche un prodotto di servizio remoto associato. Consulta
Verificare un collegamento. |
Genera campioni | È stato aggiunto un nuovo comando apigee-remote-service-cli samples create
alla CLI. Questo comando crea
file di configurazione di esempio per i deployment nativi di Envoy o Istio. I file di configurazione
che generi con questo comando sostituiscono i file di esempio installati
con l'adattatore per Envoy nelle versioni precedenti. Vedi
Comando Samples. |
Autenticazione OAuth2 | L'adattatore ora utilizza l'autenticazione OAuth2 quando l'autenticazione a più fattori (MFA) è
abilitata per Apigee. Utilizza il flag --mfa ogni volta che utilizzi il flag --legacy . |
Container Distroless | L'adattatore ora utilizza l'immagine distroless (gcr.io/distroless/base ) di Google anziché scratch per la base dell'immagine Docker predefinita. |
Altri problemi e correzioni
- È stato risolto un problema della CLI per i comandi di binding in OPDK. (#29)
- La quota potrebbe bloccarsi in caso di perdita della connessione (apigee/apigee-remote-service-envoy. (#31)
- Le immagini Docker ora vengono create con l'utente non root (999).
- Gli esempi di Kubernetes impongono che l'utente non sia root.
--http1.1
non è più necessario per i comandi curl sugli endpoint proxy. Il flag è stato rimosso dagli esempi.
v1.0.0
Venerdì 31 luglio 2020 abbiamo rilasciato la versione GA di Apigee Adapter for Envoy.
Piattaforme supportate
Pubblichiamo i file binari per macOS, Linux e Windows.
Pubblichiamo immagini Docker da zero, Ubuntu e Ubuntu con Boring Crypto.
Nella versione 1.0.0 supportiamo le seguenti piattaforme:
- Apigee hybrid versione 1.3
- Versioni 1.5 e 1.6 di Istio
- Versioni di Envoy 1.14, 1.15
Aggiunte e modifiche
Tra la release v1.0-beta4 e la disponibilità generale, sono state apportate le seguenti modifiche all'adattatore:
Vai a Boring Builds
È ora disponibile una nuova build che utilizza librerie Go BoringSSL conformi a FIPS.
- Modifiche ai flag del livello di log
I flag del livello di logging per il servizio apigee-remote-service-envoy sono stati modificati per coerenza:
Vecchia bandiera Nuovo flag log_level
log-level
json_log
json-log
- Nuovi flag della CLI
Sono stati aggiunti nuovi flag ai comandi CLI
token
:Flag Descrizione --legacy
Imposta questo flag se utilizzi Apigee Cloud. --opdk
Imposta questo flag se utilizzi Apigee for Private Cloud.