Tunnelisation de Sitecore 10.3 à partir d’une machine locale Conteneurs pour un accès global

Je reçois une demande urgente pour préparer une instance Sitecore pour le test de certains outils externes que nos partenaires potentiels font des démonstrations pour nous. Dans les bons moments, je mettrais bien sûr en place un environnement PaaS / Kubernetes approprié ; cependant, pour ma tâche particulière, ce serait une grave exagération ; Parfois, je n’ai accès à aucun abonnement cloud, et ce qui est bien plus important, je manque de temps ! Les échéances pour de telles tâches sont généralement fixées à « hier », alors j’ai commencé à penser au potentiel « déploiement du pauvre » architecture.

Comme beaucoup de développeurs, j’ai aussi un « serveur dans une armoire« ; cependant, ce n’est pas un ordinateur portable à la retraite, mais une véritable machine à haut niveau qui me sert actuellement de serveur hyperviseur branché par une connexion Gigabit Google Fiber. Mon chat adore y passer du temps, et je suis généralement d’accord avec cela étant donné qu’il ne bloque pas la sortie des évents du dissipateur de chaleur :

Mon chat bénéficie d’un équipement d’hyperviseur de haute qualité

Ce serveur tourne sur ltsc2022 noyau, offrant des avantages de performances supplémentaires, comme je l’ai écrit sur l’exécution de 10.3 en mode d’isolation de processus dans un article précédent. Alors pourquoi ne pas réutiliser la base de code de ce même kit de démarrage Next.js conteneurisé pour le plaisir de PoC ?

La question suivante est de savoir comment le rendre accessible à partir de l’Internet mondial extérieur afin que les personnes qui font des démos puissent se connecter d’où elles se trouvent et travailler avec Sitecore comme elles le feraient normalement. En règle générale, pour que cela se produise, je dois entreprendre trois étapes :

1. Définissez un nom d’hôte et configurez Sitecore pour l’installer avec ses sous-domaines.
2. Générez un certificat générique pour un nom de domaine du nom d’hôte ci-dessus.
3. Apportez les modifications DNC requises pour modifier l’enregistrement A et les sous-domaines pour pointer l’adresse IP publique de cette machine.

Mais attendez un peu, ai-je une IP publique ? Malheureusement, je ne commence donc pas à chercher diverses options DynDNS qui nécessitaient encore plus d’efforts que ce que j’allais initialement engager. Mais pire encore – je suis derrière NAT, ce qui signifie que DynDNS n’est pas d’une grande aide ici. Finalement, je me suis souvenu d’une classe spécifique de logiciel de tunnellisation qui sert précisément ce but. D’une large gamme, Tunnel local semblait être la solution gratuite la plus prometteuse que certaines personnes utilisent pour utiliser leurs sites de base pour les démos.

En regardant sa caractéristiques, ça a l’air très attirant :

• c’est totalement gratuit
• ne nécessite aucune inscription/tokens
• installation ultrasimple avec npm
• en raison de ce qui précède, il peut potentiellement tunnel directement dans les conteneurs
• vous donne l’option d’un sous-domaine demandeur temporel, s’il en existe un
• permet de mapper des certificats SSL invalides

L’installation et l’exécution typiques sont ultra-simples :

npm install -g localtunnel
lt --port 8080

Après la seconde commande, LocalTunnel répond par une URL de navigation, qui tunnellisera votre requête vers le port 8080 de la machine hôte sur laquelle il a été exécuté.

Mais comment appliquer ces connaissances à une installation Sitecore compliquée, étant donné que la plupart des services Sitecore dans les conteneurs sont derrière Traefik, qui sert également de point de déchargement SSL ? De plus, le Serveur d’identité nécessite une URL accessible au public pour renvoyer la demande authentifiée avec succès.

La syntaxe d’appel plus avancée ressemble à ci-dessous :

lt --local-host HOST_ON_LOCAL_MACHINE --local-https --allow-invalid-cert --port 443 --subdomain SUBDOMAIN_TO_REQUEST

Pour que Sitecore fonctionne de l’extérieur, je dois le configurer de sorte que les URL externes correspondent aux URL exécutées localement sur l’hôte où Tunnel local court. Avec la commande ci-dessus, si une demande de sous-domaine est satisfaite, elle sera servie par l’URL, ce qui conduit à HOST_ON_LOCAL_MACHINE sur bâbord 443.

Ainsi, dans un Sitecore sans tête, nous avons quatre parties typiques s’exécutant sur des sous-domaines d’un nom d’hôte servi par un certificat générique :

• Gestion de contenu (alias Sitecore lui-même)
• Livraison de contenu
• Serveur d’identité
• Hôte de rendu

OOB ils sont servis par défaut avec quelque chose comme cm.YourProject.localhost, cd.YourProject.localhost, id.YourProject.localhost et www.YourProject.localhost en conséquence. Afin de correspondre HOST_ON_LOCAL_MACHINE pour SUBDOMAIN_TO_REQUEST pour les besoins de cet exercice, j’ai choisi les noms d’hôte suivants pour l’installation :

Les scripts qui créent le modèle Next.js StarterKit et Init.ps1 ne modifiez pas tous les changements de nom d’hôte requis, donc juste au cas où vous le feriez manuellement (recommandé), je vais énumérer certains des emplacements pour les changements :

1. Chaleur.ps1 – un bloc qui fabrique et installe des certificats (recherche par & $mkcert -install)
2. Chaleur.ps1 – un bloc qui ajoute les entrées du fichier hôte (recherche par Add-HostsEntry)
3. Chaleur.ps1 – un bloc qui définit les variables d’environnement (recherche Set-EnvFileVariable "CM_HOST")
4. Up.ps1 – authentification via Sitecore CLI (recherche par dotnet sitecore login)
5. Up.ps1 – exécution finale dans le navigateur (recherche par Start-Process en bas du fichier)
6. .env fichier – remplacer CM_HOST, ID_HOST, RENDERING_HOST et CD_HOST variables
7. S’assurer Circulation configuration (docker\traefik\config\dynamic\certs_config.yaml) fait référence au bon certificat et aux bons fichiers de clé
8. Create-jss-project.ps1 – caractéristiques --layoutServiceHost et --deployUrl paramètres de jss setup command
9. src\rendering\scjssconfig.json
10. src\rendering\src\temp\config.js

Il se peut que vous manquiez certains paramètres et que certains conteneurs le signalent. »unhealthy » statut. Pour un dépannage rapide, je recommanderais temporairement désactivation bilans de santé et retour 0 le code d’état :

test: ["CMD", "powershell", "-command", "exit 0"]

Cette astuce permet docker-compose pour atteindre l’exécution de Traefik afin que vous disposiez d’un routage en action pour naviguer dans les conteneurs défectueux et rechercher la cause réelle d’un problème. N’oubliez pas de renvoyer Heathchecks une fois terminé!

Une fois toutes les étapes d’installation terminées avec succès, vous verrez Sitecore CM et Rendering Host dans le navigateur avec des URL de domaine alternées.

Vous pouvez maintenant démarrer LocalTunnel :

lt --local-host identity.loca.lt --local-https --allow-invalid-cert --port 443 --subdomain identity
lt --local-host sitecore.loca.lt --local-https --allow-invalid-cert --port 443 --subdomain sitecore
lt --local-host rendering.loca.lt --local-https --allow-invalid-cert --port 443 --subdomain rendering
lt --local-host delivery.loca.lt --local-https --allow-invalid-cert --port 443 --subdomain delivery

Lors de la première exécution depuis l’extérieur, il peut vous montrer un écran de notification indiquant que LocalTunnel dessert une URL donnée, et avec une connexion relativement bonne, c’est tout.

Je l’ai brièvement testé, et cela fonctionne bien : aucun problème SSL, Experience Editor s’exécute et permet d’apporter des modifications, puis les publie correctement afin qu’elles soient reflétées lors de la navigation sur Rendering Host. Tout semble bien fonctionner et comme prévu !

J’espère que vous trouverez cela utile et que vous gagnerez peut-être du temps en réalisant vos propres vitrines ou présentations !