1 : Déploiement d'IHM de flotte sur des machines similaires
Scénario : Vous avez plusieurs actifs similaires, tels que des lignes, des skids, des cellules ou des sites, et vous souhaitez une expérience opérateur cohérente avec une interface homme-machine (IHM) et un modèle de mise à jour prévisible.
Une approche basée sur les conteneurs offre une cohérence en lançant l'application d'exécution dans un contexte de conteneur standardisé, et une répétabilité en utilisant des paramètres de lancement de conteneur documentés tels que la publication de port, la dénomination de conteneur et le comportement de redémarrage facultatif. Si vous avez besoin que l'application d'exécution conserve les fichiers ou les paramètres qu'elle crée, connectez le conteneur à un dossier réel sur l'ordinateur. Ainsi, les données restent même si le conteneur est redémarré ou remplacé.
2 : Services de périphérie modulaires côte à côte
Scénario : Vous souhaitez une visualisation en périphérie et vous pouvez également vouloir des capacités adjacentes déployées à ses côtés (par exemple, FactoryTalk® Remote Access™ Runtime).
Les conteneurs permettent de déployer plusieurs composants côte à côte sur un hôte tout en les conservant emballés indépendamment. Et les recommandations d'exécution des conteneurs FactoryTalk Optix fournissent le mécanisme concret pour exécuter l'application d'exécution Optix dans Docker en tant que composant de visualisation dans les déploiements.
Dans une architecture de périphérie composable, il est également avantageux d'exécuter des services de connectivité à distance parallèlement au runtime de visualisation. Par exemple, FactoryTalk® Remote Access™ Runtime est disponible sous forme d'image Docker, ce qui permet de le déployer en tant que conteneur distinct à côté d'un conteneur runtime FactoryTalk Optix (ou à côté d'un autre service conteneurisé complémentaire sur le même hôte). Cela convient naturellement aux hôtes de conteneurs, car les conteneurs sont conçus pour fonctionner côte à côte sur la même machine tout en maintenant l'isolation des processus.
3 : Déploiements dans le cloud
Scénario : Certaines entreprises étendent également cette approche des conteneurs aux environnements hébergés dans le cloud lorsqu'elles souhaitent disposer d'une empreinte d'exécution gérée de manière centralisée, de mécanismes de déploiement standardisés ou d'un alignement plus facile avec les opérations essentielles du cloud.
Dans ces scénarios, le même principe de logiciel conteneurisé de base s'applique. Un runtime Optix peut être conditionné et exploité comme une charge de travail conteneurisée, tandis que le calcul sous-jacent est fourni par l'infrastructure cloud du client et régi par ses politiques informatiques et sa posture de sécurité.
Cela s'intègre naturellement aux flux de travail compatibles avec le cloud Optix : FactoryTalk® Optix Studio™ Pro prend en charge la collaboration hébergée dans le cloud et le développement basé sur un référentiel. Et Rockwell Automation décrit des modèles de déploiement à distance qui exploitent FactoryTalk Remote Access, réduisant ainsi la nécessité d'être physiquement sur site pour fournir des mises à jour.
Considérations relatives au déploiement conteneurisé de FactoryTalk Optix
Limite de tierce partie
Pour ceux qui débutent avec les logiciels conteneurisés, veuillez vous référer au fournisseur de tierce partie, tel que Docker ou Portainer, pour obtenir de l'aide et connaître les conditions de licence.
Comportement de licence
Si vous ne fournissez pas de clé de licence d'habilitation, l'application FactoryTalk Optix cesse de fonctionner après 120 minutes. Vous trouverez plus d'informations dans l'aide FactoryTalk Optix.
La publication de port est liée à la configuration de l'application
Lorsque Optix s'exécute dans un conteneur, choisissez un port sur le PC hôte et « transmettez-le » au port qu'Optix utilise pour son client web. Ce port interne est le port Web Presentation Engine que vous avez défini dans FactoryTalk® Optix Studio™.
La persistance doit être intentionnelle
Décidez à l'avance ce qui doit être sauvegardé et ce qui peut être temporaire. L'option de liaison de volume existe pour conserver les modifications apportées à l'exécution en écrivant les modifications d'exécution dans un dossier local sur la machine hôte, afin que les modifications ne soient pas perdues lorsque le conteneur redémarre ou est remplacé.
La répétabilité est la priorité, tout le reste vient ensuite
La valeur pratique du déploiement de FactoryTalk Optix avec un logiciel conteneurisé réside dans la répétabilité.
Les conteneurs logiciels offrent un moyen cohérent et documenté d'exécuter la même application d'exécution dans différents environnements, en utilisant des concepts standard de lancement de conteneur tels que la publication de port, le comportement de redémarrage et (si nécessaire) le mappage de volume pour la persistance. Cela soutient l'objectif plus large de la conteneurisation qui est de réduire la dérive des environnements et d'améliorer la cohérence du développement à la production dans les technologies de l'information et les technologies opérationnelles.
Vous souhaitez passer à l'étape suivante ? Découvrez comment ThinManager® logiciel et FactoryTalk Optix s'inscrivent dans la discussion plus large sur la conteneurisation, sans changer les fondamentaux décrits. Et vous pouvez approfondir l'ensemble du portefeuille de logiciels et de dispositifs matériels FactoryTalk Optix basés sur le cloud ici.
