Panoramica di Managed Runtime

Managed Runtime fornisce l'infrastruttura per distribuire, ospitare e monitorare lo storefront PWA Kit.

Questa guida illustra gli elementi principali di Managed Runtime e come accedervi.

Per ambiente si intende l'intera infrastruttura cloud e i valori di configurazione di uno storefront ospitato da Managed Runtime. Gli ambienti vengono utilizzati per distinguere lo storefront Production da altri storefront distribuiti per altre finalità, ad esempio di sviluppo o di test.

Poiché gli ambienti sono basati su microservizi molto efficienti caratterizzati da scalabilità verticale e orizzontale automatica, è possibile creare il numero desiderato di ambienti senza alcun costo aggiuntivo. Ad esempio, è possibile creare un ambiente di breve durata dedicato a un singolo sprint di sviluppo Agile o per una singola storia utente all'interno di tale sprint. Se un ambiente non è più necessario, si consiglia di eliminarlo.

Gli ambienti contrassegnati come Production hanno la priorità per il monitoraggio da parte del team Salesforce Support. Per contrassegnare un ambiente come Production è possibile procedere in due modi:

1. Utilizzando lo strumento Runtime Admin. Per istruzioni passo passo per la creazione di un ambiente o la modifica di un ambiente esistente, consultare la sezione Ambienti della guida Amministrazione.
2. Utilizzando Managed Runtime API. Gli endpoint projects_target_create e projects_target_partial_update presentano entrambi il parametro is_production. Per contrassegnare un ambiente come Production con questi endpoint, impostare is_production su true.

Il codice storefront che viene eseguito in un ambiente è denominato bundle. Utilizzare gli strumenti per sviluppatori inclusi in PWA Kit per generare un bundle e sottoporlo a push in Managed Runtime.

Dopo essere stato sottoposto a push, il bundle può essere designato come "distribuito" utilizzando Runtime Admin o Managed Runtime API. Ogni progetto può essere associato a più bundle, ma per ogni ambiente può essere designato come distribuito un solo bundle. È possibile cambiare il bundle designato come distribuito in qualsiasi momento. Per ulteriori informazioni, vedere Push e distribuzione dei bundle.

Per consentire la gestione di più ambienti, ogni ambiente appartiene anche a un progetto e ogni progetto appartiene a un'organizzazione. Un'organizzazione può contenere più progetti per più storefront e ogni progetto può contenere più ambienti. Un utente Managed Runtime può appartenere a più organizzazioni per separare i diversi flussi di lavoro.

Ogni organizzazione può avere al massimo 100 ambienti totali e 10 ambienti Production. Se si desidera aumentare questi limiti, contattare il rappresentate Salesforce Support.

Le organizzazioni e l'appartenenza di un utente a un'organizzazione sono determinate dalle impostazioni in Account Manager. Un utente può appartenere a un'organizzazione in qualità di membro o di amministratore. In Managed Runtime i membri possono interagire solo con i progetti per i quali è stato loro assegnato un ruolo. Gli amministratori possono interagire con tutti i progetti di un'organizzazione.

Un utente può disporre delle seguenti funzionalità per un progetto Managed Runtime:

• Browse (Sfoglia): per visualizzare il progetto in Runtime Admin.
• Manage Redirects (Gestisci reindirizzamenti): per gestire i reindirizzamenti del progetto. Per ulteriori informazioni, consultare la documentazione sui reindirizzamenti.
• Deploy (Distribuisci): per distribuire i nuovi bundle o ripristinare la distribuzione di un bundle precedente.
• Manage Team (Gestisci team): per visualizzare, aggiungere, invitare, rimuovere e modificare i ruoli dei membri dei team per il progetto.
• Access Logs (Accedi ai registri): per applicare il comando tail ai registri in tutti gli ambienti.

A ogni utente è assegnato un ruolo di progetto che determina le funzionalità di cui dispone. (Un utente può avere un solo ruolo.) I ruoli di progetto possono essere assegnati a qualsiasi utente in un'organizzazione.

La tabella seguente mostra le funzionalità associate a ogni ruolo:

In ogni ambiente Managed Runtime, l'app React nel bundle pubblicato viene eseguita all'interno di un ambiente Node.js. Per rispondere alle richieste di pagina e renderizzare i risultati, viene utilizzato il framework web Express con l'aiuto dei sistemi di rendering e routing di PWA Kit. Questa combinazione di React, Node ed Express viene definita App Server (sebbene da un punto di vista tecnico l'App Server venga eseguito con tecnologia "serverless"). L'App Server è ottimizzato per funzionare su un'infrastruttura cloud che offre costi di elaborazione contenuti, elevata disponibilità, rendering rapido e massima scalabilità.

Poiché il sistema di rendering e routing di PWA Kit gestisce le differenze tra gli ambienti di sviluppo locali e gli ambienti Managed Runtime, il codice viene eseguito in modo prevedibile al momento della distribuzione. Questa prevedibilità permette di sfruttare la produttività del team di sviluppo incoraggiandolo a distribuire bundle con maggiore frequenza.

Attualmente l'App Server supporta le versioni 1.2 e successive di Transport Layer Security (TLS).

Il codice in esecuzione sull'App Server ha accesso alle seguenti variabili di ambiente:

• DEPLOY_TARGET: ID dell'ambiente.
• EXTERNAL_DOMAIN_NAME: nome di dominio impostato nell'ambiente.
• MOBIFY_PROPERTY_ID: ID del progetto a cui appartiene l'ambiente.

L'app server è supportato da diversi servizi edge, tra cui:

• Un WAF (Web Application Firewall) per proteggere gli ambenti dagli attacchi informatici
• Un server proxy per accelerare le richieste API
• Una rete CDN (Content Delivery Network) per il caching delle richieste e per accelerare il caricamento delle pagine
• Funzioni edge che elaborano le richieste e gestiscono i reindirizzamenti

Il server proxy e la rete CDN sono illustrati dettagliatamente nella guida Invio delle richieste a un proxy. La funzione edge denominata elaboratore di richieste è illustrata nella guida Massimizzazione dell'indice di riscontri cache.

I servizi edge di Managed Runtime sono distribuiti strategicamente nell'intera infrastruttura cloud pubblica. Per garantire prestazioni più veloci, ogni servizio è ubicato il più vicino possibile all'utente.

Per gestire le impostazioni di organizzazioni, progetti, ambienti e bundle sono disponibili due strumenti:

1. Managed Runtime Admin, un'interfaccia utente basata sul Web.
2. Managed Runtime API, una REST API che offre le stesse funzionalità dello strumento basato sul Web, oltre ad alcune altre.

Utilizzare lo strumento Runtime Admin per le attività di routine, come la distribuzione di un nuovo bundle di codice in un ambiente. Utilizzare l'API se si desidera un controllo programmatico, ad esempio per la creazione automatica di un ambiente come parte di uno script di integrazione continuo.

Gli strumenti di amministrazione consentono di configurare autonomamente numerose impostazioni, tra cui:

• Indirizzi IP ammessi
• Bundle attualmente distribuito
• Area di distribuzione
• Proxy
• Reindirizzamenti
• Autorizzazioni utente
• Flag di ambiente Production

L'accesso agli strumenti di amministrazione è controllato mediante i ruoli di Account Manager e una chiave API. Per i processi di integrazione continua e recapito continuo, l'organizzazione fornisce in genere utenti bot dedicati con chiavi API proprie.

Curiosità: Come lo storefront, lo strumento Runtime Admin è un'app React headless distribuita in Managed Runtime.

Durante la creazione dello storefront, tenere presente i seguenti vincoli degli ambienti Managed Runtime:

• Gli ambienti rispondono solo alle richieste la cui intestazione Host HTTP corrisponde al nome host esterno impostato in Runtime Admin.
• Le dimensioni massime di un bundle sono di 400 MB, mentre quelle di tutti i file ssr_only e ssr_shared in esso contenuti sono di 249 MB.
• Gli asset statici che possono essere caricati e distribuiti sono limitati ai seguenti tipi di contenuto: application/javascript, application/json, image/png ,image/gif, image/jpeg, image/svg+xml, image/webp, text/css, text/plain e font (ttf, woff, woff2, otf ecc.). Tutti gli altri tipi di contenuto devono essere forniti da un sistema esterno.
• Il percorso / accetta solo le richieste HTTP GET.
• Le dimensioni delle richieste e delle risposte non possono superare i 6 MB.
• I cookie, inclusa l'intestazione Cookie della richiesta HTTP e Set-Cookie della risposta HTTP, non sono supportati per impostazione predefinita. Possono essere abilitati impostando l'attributo allow_cookies in un ambiente con l'endpoint projects_target_partial_update e utilizzando PWA Kit in versione 3.1.0 o superiore.
• Le dimensioni massime della riga e delle intestazioni delle richieste HTTP sono di 10.240 byte. Le richieste che superano queste dimensioni restituiscono una risposta HTTP 413 Content Too Large (HTTP 413 Contenuto troppo grande).
• Il tempo di esecuzione per le richieste del server applicazioni è limitato a 20 secondi.
• I rifiuti di promesse non gestiti interrompono il rendering dell'app.
• Non è possibile escludere la cache CDN utilizzando l'intestazione della richiesta HTTP x-mobify-cachebreaker: 1
• Il prefisso di percorso /mobify è riservato agli endpoint gestiti. Gli endpoint includono:
  • /mobify/ping: restituisce un codice di risposta HTTP 200 quando l'ambiente è funziona correttamente.
  • /mobify/redirect/$path: restituisce una risposta simile a projects_target_redirect_retrieve.
  • /mobify/proxy/$name: restituisce una risposta da un proxy.
• Le richieste HTTP provenienti da ambienti Managed Runtime non utilizzano indirizzi IP fissi. Per consentire le richieste elenco (LIST) dall'App Server, utilizzare l'intervallo di indirizzi IP AWS per EC2. Per consentire le richieste elenco (LIST) dai proxy, utilizzare CLOUDFRONT_ORIGIN_FACING.

I proxy Managed Runtime hanno vincoli diversi.

È possibile iscriversi agli aggiornamenti relativi alla disponibilità dei servizi Managed Runtime su Salesforce Status.

Dopo la panoramica degli elementi principali di Managed Runtime, è il momento di passare agli aspetti pratici. Per iniziare, consultare la guida Push e distribuzione dei bundle.