Présentation de Managed Runtime

Managed Runtime fournit l’infrastructure nécessaire pour déployer, héberger et surveiller votre boutique PWA Kit.

Ce guide couvre les principales parties de Managed Runtime et les moyens d’y accéder.

Un environnement est le terme utilisé pour décrire l’ensemble de l’infrastructure cloud et des valeurs de configuration pour une boutique particulière hébergée par Managed Runtime. Les environnements sont utilisés pour séparer votre boutique de production des autres boutiques déployées à d'autres fins, comme le développement ou les tests.

Comme les environnements fonctionnent sur des microservices très efficaces qui montent et descendent automatiquement en charge, vous pouvez créer autant d'environnements que vous le souhaitez sans frais supplémentaires. Vous pouvez par exemple créer un environnement éphémère dédié à un seul sprint de développement agile ou à un seul récit d'utilisateur dans ce sprint. Si vous n'avez plus besoin d'un environnement, nous vous encourageons à le supprimer.

Les environnements indiqués comme environnements de production sont sur la liste de surveillance prioritaire de l’équipe de Support de Salesforce. Pour les environnements de production, vous pouvez également déboguer à l’aide de Log Center. Pour indiquer un environnement comme un environnement de production, vous avez deux possibilités :

1. Utiliser l’outil Runtime Admin. Les instructions détaillées pour créer un environnement ou modifier un environnement existant se trouvent dans la section Environnements du guide Administration.
2. Utiliser l’API Managed Runtime. Les points de terminaison projects_target_create et projects_target_partial_update comportent tous deux le paramètre is_production. Pour indiquer un environnement comme environnement de production avec ces points de terminaison, configurez le paramètre is_production comme true.

Le code de la boutique qui s'exécute sur un environnement est appelé un paquet. Utilisez les outils de développement inclus dans le PWA Kit pour générer un paquet et l’envoyer à Managed Runtime en mode push.

Après avoir envoyé le paquet en push, vous pouvez utiliser Runtime Admin ou l’API Managed Runtime pour désigner ce paquet comme « déployé ». Chaque projet peut avoir plusieurs paquets, mais chaque environnement ne peut avoir qu'un seul paquet désigné comme déployé. Vous pouvez modifier à tout moment le paquet désigné comme déployé. Pour en savoir plus, reportez-vous à la section Envoyer en Push et déployer des paquets.

Pour vous aider à gérer plusieurs environnements, chaque environnement appartient également à un projet et chaque projet appartient à une organisation. Une organisation peut contenir plusieurs projets pour plusieurs boutiques en ligne et chaque projet peut contenir plusieurs environnements. Un utilisateur de Managed Runtime peut appartenir à plusieurs organisations afin de séparer différents flux de travail.

Chaque organisation peut avoir un maximum de 100 environnements au total et un maximum de 10 environnements de production. Si vous devez augmenter ces limites, contactez votre représentant du support Salesforce.

Les organisations et l’appartenance des utilisateurs aux organisations sont déterminées par les paramètres dans Account Manager. Un utilisateur peut appartenir à une organisation en tant que membre ou en tant qu’administrateur. Les membres ne peuvent interagir qu’avec les projets de Managed Runtime pour lesquels un rôle leur a été attribué. Les administrateurs peuvent interagir avec tous les projets d’une organisation.

Un utilisateur peut disposer des capacités suivantes pour un projet Managed Runtime :

• Browse (Parcourir) : afficher le projet dans Runtime Admin.
• Manage Redirects (Gérer les redirections) : gérer les redirections pour le projet. Veuillez consulter la documentation sur les redirections pour en savoir plus.
• Deploy (Déployer) : déployer de nouveaux paquets ou rétablir le déploiement d'un ancien paquet.
• Manage Team (Gérer l'équipe) : consulter, ajouter, inviter, supprimer et modifier les rôles des membres de l'équipe pour le projet.
• Access Logs (Accéder aux journaux) : suivre les journaux sur l’ensemble des environnements.

Chaque utilisateur se voit attribuer un rôle qui détermine les possibilités dont il dispose. (Un utilisateur ne peut avoir qu'un seul rôle). Les rôles d’un projet peuvent être attribués à n’importe quel utilisateur au sein d’une organisation.

Le tableau suivant montre quelles capacités sont associées à chaque rôle :

Au sein de chaque environnement Managed Runtime, l'application React du paquet publié s'exécute dans un environnement Node.js. Pour répondre aux requests de pages et rendre les résultats, nous utilisons le framework Web Express avec l'aide des systèmes de rendu et de routage de PWA Kit. Nous appelons cette combinaison de React, Node et Express le serveur d’applications. (Bien que, techniquement parlant, le serveur d’applications fonctionne sur une technologie « serverless »). Ce serveur d’applications est optimisé pour fonctionner sur une infrastructure cloud qui offre de faibles coûts de traitement informatique, une haute disponibilité, un rendu rapide et une très grande évolutivité.

Comme le système de rendu et de routage de PWA Kit gère les différences entre les environnements de développement locaux et les environnements Managed Runtime, votre code s'exécute de manière prévisible lorsque vous le déployez. Cette prévisibilité stimule la productivité de votre équipe de développement en l'incitant à déployer des paquets plus fréquemment.

Actuellement, le serveur d’applications prend en charge les versions 1.2 et supérieures du protocole Transport Layer Security (TLS).

Le code qui s’exécute sur le serveur d’applications a accès aux variables d’environnement suivantes :

• DEPLOY_TARGET : l’identifiant de l’environnement.
• EXTERNAL_DOMAIN_NAME : le nom de domaine défini sur l’environnement.
• MOBIFY_PROPERTY_ID : l’identifiant du projet auquel l’environnement appartient.

Le serveur d'applications est supporté par plusieurs services périphériques, notamment :

• Un pare-feu d'application Web (WAF) pour protéger vos environnements des attaques
• Un serveur proxy pour accélérer les requests API
• Un réseau de diffusion de contenu (CDN) pour mettre en cache les requests et accélérer le chargement des pages
• Des fonctions périphériques qui traitent les requests et gèrent les redirections

Le serveur proxy et le CDN sont traités en détail dans notre guide sur Requests via proxy. La fonction périphérique appelée request processor est traitée dans notre guide Maximiser votre taux d'accès au cache.

Les services périphériques de Managed Runtime sont répartis de façon stratégique dans notre infrastructure de cloud public. Chaque service est situé aussi près que possible de l'utilisateur pour en accélérer la performance.

Pour gérer les paramètres de vos organisations, projets, environnements et paquets, nous vous proposons deux outils :

1. Le Managed Runtime Admin, une interface utilisateur Web.
2. L'API Managed Runtime, une API REST qui offre les mêmes fonctionnalités que l'outil Web ainsi que quelques capacités supplémentaires.

Utilisez l’outil Runtime Admin pour les tâches de routine, comme le déploiement d’un nouveau paquet de code dans un environnement. Utilisez l'API si vous avez besoin d'un contrôle programmatique, par exemple pour créer automatiquement un environnement dans le cadre d'un script d'intégration continue.

Les outils d'administration vous permettent de configurer de nombreux paramètres en libre-service, notamment :

• Les adresses IP autorisées
• Les en-têtes de contrôle d’accès autorisés
• Le paquet actuellement déployé
• La région de déploiement
• Les proxys
• Les redirections
• Les autorisations des utilisateurs
• L'indicateur d’environnement de production

L'accès aux outils d'administration est contrôlé par les rôles définis dans Account Manager et une clé API. Pour les processus d'intégration continue (CI) et de livraison continue (CD), des utilisateurs bots dédiés disposant de leurs propres clés API sont généralement fournis par votre organisation.

Anecdote : comme votre boutique en ligne, l’outil Runtime Admin est une application React headless déployée sur Managed Runtime.

Lors de la création de votre boutique en ligne, gardez à l’esprit les contraintes suivantes des environnements Managed Runtime :

• Les environnements ne répondent qu’aux requests dont l’en-tête HTTP Host correspond à leur nom d’hôte externe tel que défini dans Runtime Admin.
• Le chemin / accepte uniquement les requests HTTP GET.
• La taille de la request et de la réponse ne peut pas dépasser 6 Mo.
• La taille de la ligne et des en-têtes de request HTTP ne peut pas dépasser 10 240 octets. Les requests dépassant cette taille renvoient une erreur HTTP 413 Content Too Large.
• Les cookies, y compris la request HTTP Cookie et l’en-tête de réponse HTTP Set-Cookie, ne sont pas pris en charge par défaut. Ils peuvent être activés en définissant l’attribut allow_cookies sur un environnement avec le point de terminaison projects_target_partial_update. Vous pouvez également activer les cookies dans les paramètres d’environnement de Runtime Admin. Les cookies sont pris en charge dans PWA Kit version 3.1.0 ou ultérieure. Voir Personnaliser avec des cookies.
• Les requests dont l’en-tête commence par _ ne sont pas prises en charge. Ces requests seront abandonnées.
• Les requests HTTP provenant d’environnements Managed Runtime n’utilisent pas d’adresses IP fixes. Pour autoriser les requests de liste provenant du serveur d’applications, utilisez la plage d’adresses IP AWS pour EC2. Pour autoriser les requests de liste provenant de proxys, utilisez CLOUDFRONT_ORIGIN_FACING.
• Le préfixe de chemin /mobify est réservé aux points de terminaison gérés. Ces points de terminaison incluent :
  • /mobify/ping : renvoie un code de réponse HTTP 200 lorsque l’environnement fonctionne correctement.
  • /mobify/redirect/$path : renvoie une réponse similaire à projects_target_redirect_retrieve.
  • /mobify/proxy/$name : renvoie une réponse à partir d’un proxy.
• Vous pouvez ignorer le cache CDN à l’aide de l’en-tête de request HTTP : x-mobify-cachebreaker: 1
• Les listes blanches d’adresses IP d’environnement prennent en charge jusqu’à 250 adresses IP. Cette limite ne peut pas être augmentée.
• Les en-têtes de contrôle d’accès à l’environnement prennent en charge jusqu’à 2 en-têtes. Chaque en-tête :
  • Peut contenir jusqu’à 128 caractères.
  • Peut être une combinaison de caractères alphanumériques et de caractères - et _
  • Voir En-têtes de contrôle d’accès.

• Le temps d’exécution des requests du serveur d’applications est limité à 20 secondes.
• Les rejets de « promesse » non gérés interrompent le rendu de l’application.

• La taille des paquets ne peut pas dépasser 400 Mo et la taille de tous les fichiers ssr_only et ssr_shared du paquet ne peut pas dépasser 249 Mo.
• Les ressources statiques pouvant être téléchargées et diffusées sont limitées aux types de contenu suivants : application/javascript, application/json, image/png, image/gif, image/jpeg, image/svg+xml, image/webp, text/css, text/plain et aux polices (ttf, woff, woff2, otf, etc.). Tous les autres types de contenu doivent être servis par un système externe.

Les contraintes des proxys Managed Runtime sont différentes.

Vous pouvez vous abonner aux mises à jour concernant la disponibilité des services Managed Runtime sur Salesforce Status.

Maintenant que vous avez un aperçu des principales parties de Managed Runtime, il est temps de mettre la main à la pâte ! Nous vous recommandons de commencer par le guide Envoyer en Push et déployer des paquets.

• Administration de Managed Runtime
• Guide de l’API Managed Runtime
• Référence de l’API Managed Runtime