Cette architecture illustre une implémentation d’un environnement Sterling Order Management Software (OMS) dans Azure. Cet article n’aborde pas en détail l’installation de Sterling OMS. Pour en savoir plus sur le processus d’installation, consultez Installing Sterling Order Management Software.
Les logos Red Hat sont des marques de commerce de Red Hat, Inc. L’utilisation de ces marques n’implique aucune approbation. Apache® et Apache ActiveMQ sont soit des marques déposées, soit des marques commerciales d’Apache Software Foundation aux États-Unis et/ou dans d’autres pays. L’utilisation de ces marques n’implique aucune approbation de l’Apache Software Foundation.
Architecture
Téléchargez un fichier Visio de cette architecture.
Vous pouvez déployer une charge de travail afin qu’elle soit accessible en interne ou en externe. Utilisez la configuration la mieux adaptée à vos besoins.
Workflow
L’architecture répond aux exigences de l’infrastructure des manières suivantes :
- Une plateforme d’hébergement de conteneurs pour est utilisée pour déployer des charges de travail hautement disponibles dans des zones de disponibilité Nous recommandons Azure Red Hat OpenShift.
- Un service de base de données complètement managé fonctionne comme base de données back-end pour le système OMS. Sterling OMS prend actuellement en charge IBM Db2, Oracle Database et PostgreSQL. Nous recommandons Azure Database pour PostgreSQL avec l’option de serveur flexible.
- Une configuration scalable et hautement disponible fournit un environnement permettant d’exécuter un répartiteur de messages comme IBM MQ qui est conforme à l’API Java Message Service (JMS). Le diagramme n’inclut pas cette configuration. En fonction de vos besoins, elle peut être interne à votre cluster, ou externe à votre cluster.
- Les points de terminaison privés isolent et contribuent à sécuriser le trafic réseau vers tous les services connectés.
- Des machines virtuelles Azure supplémentaires facultatives sont utilisées à des fins de gestion et de développement.
- Les partages Azure Files Premium et Standard fournissent un stockage pour les fichiers journaux et d’autres données de configuration d’application.
Composants
Azure Red Hat OpenShift fournit des clusters OpenShift hautement disponibles et complètement managés à la demande. Ces clusters sont supervisés et exploités conjointement par Microsoft et Red Hat.
Le réseau virtuel Azure est le composant fondamental pour vos réseaux privés dans Azure. Des réseaux virtuels sont utilisés pour la communication entre les nœuds, les services Azure et les besoins de connectivité hybride.
Azure Files offre des partages de fichiers complètement managés dans le cloud, accessibles via les protocoles SMB et NFS. Dans cette solution, Azure Files héberge les données avec état pour les bases de données et les systèmes qui se trouvent à l’intérieur du cluster.
Azure Bastion est un service entièrement géré qui fournit un accès RDP et SSH sécurisé et transparent aux machines virtuelles sans aucune exposition via des adresses IP publiques. Dans cette solution, Azure Bastion est facultatif. Vous pouvez utiliser Azure Bastion et un sous-réseau pour fournir un accès sécurisé étendu à l’un des nœuds Worker ou aux machines JumpBox facultatives.
Azure Database pour PostgreSQL est un service de base de données relationnelle complètement managé basé sur le moteur de base de données PostgreSQL. Azure Database pour PostgreSQL offre des performances prévisibles et une scalabilité dynamique, et convient aux charges de travail critiques pour l’entreprise. Son modèle de déploiement de serveur flexible offre une flexibilité et un contrôle précis des fonctions de gestion de base de données et des paramètres de configuration.
Machines virtuelles Azure est une offre IaaS (infrastructure as a service). Vous pouvez utiliser des machines virtuelles pour déployer des ressources de calcul à la demande et évolutives. Cette solution utilise des machines virtuelles Linux dans Azure afin de fournir une JumpBox pour la gestion de vos ressources et services basés sur Azure OMS.
Autres solutions
Si vous disposez d’une connectivité réseau dans votre environnement Azure, vous pouvez effectuer l’installation à partir d’une machine existante au lieu d’utiliser une machine virtuelle Linux Azure.
Les services suivants ne sont généralement pas nécessaires, mais ils sont des alternatives efficaces :
- IBM Db2 sur Azure est une alternative facultative au modèle de serveur flexible d’Azure Database pour PostgreSQL. Si vous exécutez IBM Db2 sur des machines virtuelles, familiarisez-vous avec l’utilisation d’Azure Load Balancer et du logiciel de clustering Pacemaker afin d’obtenir une haute disponibilité pour vos serveurs de base de données.
- Azure NetApp Files prend en charge n’importe quel type de charge de travail en fournissant une haute disponibilité et des performances élevées. Azure NetApp Files est idéal pour les charges de travail sensibles aux E/S, telles que les charges de travail IBM Db2 qui s’exécutent sur des machines virtuelles Azure.
- Oracle Database sur Azure est une alternative facultative au modèle de serveur flexible d’Azure Database pour PostgreSQL.
Détails du scénario
IBM Sterling OMS est un système de gestion des commandes qui fournit une plateforme de traitement des commandes omnicanale complète. Ce système comprend des fonctionnalités telles que :
- Visibilité et demande d’inventaire en temps réel
- Orchestration des commandes et workflows entièrement configurables
- Logistique inversée pour les retours multicanaux et l’état des ordres de retour
Un partenariat entre Microsoft et l’équipe IBM Sterling OMS garantit que cette solution est configurée pour s’exécuter de manière optimale sur Azure. Cet article fournit une conception pour l’exécution de Sterling OMS 10.0 et versions ultérieures sur Azure pour les clients qui prennent en charge IBM et un partenaire pour l’installation. Pour obtenir des réponses à des questions propres au produit, contactez votre équipe IBM.
Cas d’usage potentiels
De nombreux secteurs et industries utilisent des solutions OMS, notamment :
- Retail
- Ecommerce
- Industrie
Pour plus d’informations sur les cas d’usage d’OMS, consultez IBM Sterling Order Management.
Recommandations
Ces conseils prennent en charge Sterling OMS 10.0 Q3 2022 et versions ultérieures. Ces versions offrent les meilleures options d’intégration à Azure, car elles prennent en charge PostgreSQL et la plateforme de conteneurs Azure Red Hat OpenShift. Avant de créer votre propre déploiement, utilisez QuickStart Guide: Sterling Order Management on Azure pour déployer Sterling OMS. Une fois que vous comprenez le fonctionnement du déploiement et de la configuration, vous pouvez déterminer plus rapidement les exigences de conception de votre implémentation.
Microsoft travaille en étroite collaboration avec IBM et d’autres partenaires pour s’assurer que les conseils, l’architecture et le guide de démarrage rapide vous offrent la meilleure expérience sur Azure. Ces ressources suivent les bonnes pratiques décrites dans le Microsoft Azure Well-Architected Framework. Pour obtenir du support au-delà de cette documentation, contactez votre équipe de compte IBM.
Avant de poursuivre votre déploiement, répondez aux questions suivantes sur votre conception :
- Votre déploiement de Sterling OMS est-il nouveau, ou migrez-vous un déploiement existant vers Azure ?
- Quelle plateforme de base de données back-end prévoyez-vous d’utiliser ? De quelle taille de base de données avez-vous besoin pour vos données ?
- Quel type de répartiteur de messages basé sur JMS envisagez-vous d’utiliser ?
- Où envisagez-vous de déployer le système de messagerie :
- Dans le même cluster OpenShift ?
- Externe au cluster sur une autre plateforme ou sur des machines virtuelles ?
- Disposez-vous d’un registre de conteneurs existant, et prévoyez-vous de continuer à l’utiliser ?
- De quels quantité et tailles de machines virtuelles avez-vous besoin pour vos nœuds Worker ?
- Quelles sont vos exigences de sécurité liées au chiffrement ?
- Quelles sont vos exigences d’accès, et quelles considérations relatives à l’intégration du fournisseur d’identité (IdP) devez-vous prendre en compte ?
- Quels sont vos besoins en matière de connectivité ? De quelles règles de pare-feu avez-vous besoin pour vous connecter aux services internes et externes (sortants) ?
- Quelle est votre stratégie en matière de haute disponibilité et reprise d’activité ?
Sterling OMS
Sterling OMS version 10.0.2209.0 a été testé sur Azure. Nous vous recommandons d’utiliser la dernière version de Sterling OMS.
Avant de déployer vos ressources Azure pour prendre en charge votre environnement Sterling OMS, familiarisez-vous avec les exigences suivantes :
- Pour connaître la configuration système requise par OMS, consultez System Requirements.
- Sterling OMS dépend d’un système de base de données relationnelle pour la gestion de l’état et des données. Un système de répartiteur de messages compatible JMS est également requis pour les workflows de commande et la communication de service à service. Sterling OMS prend en charge plusieurs options de répartiteur de messages et de bases de données que vous pouvez déployer dans votre environnement. Pour plus d’informations, consultez les ressources suivantes :
- Niveau base de données : Installing and configuring database tier software on UNIX or Linux
- Répartiteur de messages JMS : Integrating with JMS Systems
Azure Red Hat OpenShift
Sterling OMS a été testé avec Azure Red Hat OpenShift version 4.10.15. Avant de déployer Azure Red Hat OpenShift :
- Choisissez un domaine. Lorsque vous déployez Azure Red Hat OpenShift, spécifiez un nom de domaine, qui sera ajouté à tous les services déployés dans votre cluster.
- Déterminez la visibilité de votre API et de l’entrée. Déterminez comment vous souhaitez que votre API de cluster OpenShift (pour la gestion) et l’entrée (pour les applications et services déployés) soient accessibles sur Internet. Si vous utilisez la connectivité privée pour masquer votre API ou votre entrée, vous pouvez uniquement atteindre ces points de terminaison à partir d’une machine capable d’atteindre le réseau sur lequel vous déployez votre service.
- Calculez les tailles et les quantités de machines virtuelles de contrôle et de travail. Dans Azure Red Hat OpenShift, la quantité de contrôles est un nombre fixe, avec une taille minimale recommandée. Vos nœuds Worker, qui exécutent vos charges de travail d’application telles que Sterling OMS, sont dimensionnés séparément. Lorsque vous déployez votre instance, tenez compte du nombre requis de nœuds Worker dans votre cluster, ainsi que de la taille appropriée de chacun d’eux. Vous devrez peut-être effectuer des tests et une validation pour déterminer les quantités et tailles correctes. Ces valeurs dépendent du nombre d’agents dans votre déploiement et du nombre de pods pour chaque type d’agent que vous exécutez. Après le déploiement, vous pouvez ajuster ces valeurs lorsque vous devez effectuer une mise à l’échelle.
Pour plus d’informations, consultez Avant de commencer pour Azure Red Hat OpenShift.
Dimensionner votre environnement
Nous vous recommandons d’utiliser les dernières machines virtuelles de la série Ds comme nœuds Worker, par exemple les séries Dsv3, Dasv4, Dsv4, Dasv5 et Dsv5. Les dernières versions de ces machines virtuelles offrent les meilleures performances. Lorsque vous déployez d’autres nœuds, utilisez uniquement des machines virtuelles qui disposent d’un stockage Premium.
Spécificités de la base de données
Sterling OMS proposant différentes options de base de données back-end, il est important de décider d’abord de la plateforme sur laquelle héberger votre base de données. Vous pouvez ensuite prendre des décisions concernant la taille de cette plateforme. Gardez à l’esprit les instructions générales suivantes pendant cette procédure :
-
Azure Database pour PostgreSQL, modèle de déploiement de serveur flexible : en raison de la nature de ses options de mise à l’échelle et de redondance, le modèle de serveur flexible d’Azure Database pour PostgreSQL est la méthode de prédilection pour héberger les charges de travail Sterling OMS dans Azure. Lorsque vous déployez votre instance :
- Sélectionnez le niveau de calcul qui correspond à vos modèles d’utilisation. Nous vous recommandons de commencer par un niveau à usage général, et de sélectionner un nombre approprié de cœurs. Notez également que votre processeur, votre mémoire et vos IOPS sont liés à votre sélection de taille de calcul.
- Ajoutez le stockage approprié. Rappelez-vous également que l’augmentation du stockage augmente les coûts, et que vous ne pouvez pas réduire votre stockage provisionné. Par conséquent, il est important de connaître la taille de vos données initiales et la croissance prédite.
- Ajustez les paramètres du serveur, tels que
max_connections
, qui affectent la capacité de vos agents à maintenir la connectivité à votre base de données.
- Db2 sur des machines virtuelles : lorsque vous exécutez Db2 sur des machines virtuelles Azure, plusieurs facteurs complexes doivent être pris en compte, tels que les performances et la disponibilité. Pour obtenir un article détaillé sur un déploiement Db2 hautes performances sur Azure, consultez Haute disponibilité d’IBM Db2 LUW sur les machines virtuelles Azure sur Red Hat Enterprise Linux Server. Cet article décrit les considérations relatives au dimensionnement et aux performances. Il illustre également comment déployer un cluster Db2 à haute disponibilité qui utilise Pacemaker.
- Oracle : si vous utilisez actuellement Oracle Database, ou si vous envisagez de migrer vers Oracle, familiarisez-vous avec les ressources suivantes pour exécuter des charges de travail Oracle sur Azure :
Spécificités de la file d’attente de messages
Sterling OMS nécessite un répartiteur de messages basé sur JMS. Le plus souvent, IBM MQ est utilisé. La meilleure façon d’exécuter une instance IBM MQ hautement disponible dans Azure consiste à utiliser les graphiques Helm IBM MQ pour les déploiements Kubernetes. Vous pouvez déployer ces graphiques dans votre cluster Azure Red Hat OpenShift existant sur des Workers distincts afin d’isoler vos charges de travail. Vous pouvez également déployer et installer manuellement IBM MQ sur des machines virtuelles si vous préférez.
Dans le cadre du déploiement standard, vous pouvez définir vos files d’attente au moment du déploiement, ce qui réduit le temps de configuration nécessaire pour faire tourner vos instances. Le déploiement standard crée une instance active et deux instances passives de votre gestionnaire de files d’attente. Une fois votre déploiement terminé, vous pouvez utiliser SSH pour vous connecter au pod leader actuel et définir votre fichier de liaisons JMS. Vous pouvez ensuite utiliser ce fichier pour créer votre carte de configuration pour votre déploiement Sterling OMS.
IBM prend également en charge d’autres systèmes de mise en file d’attente de messages basés sur JMS, tels qu’Apache ActiveMQ. Pour plus d’informations, consultez Message queues in Sterling Order Management Software. Vos options de déploiement varient en fonction de la solution.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
Le maintien de l’accès et de la visibilité dans le cycle de vie de maintenance de vos ressources peut être l’une des plus grandes opportunités de votre organisation de fonctionner efficacement et de maintenir le temps de fonctionnement. Pour aider à améliorer la posture de sécurité de votre environnement, il est important d’utiliser l’authentification sécurisée et de maintenir vos solutions à jour. Utilisez le chiffrement pour protéger toutes les données qui se déplacent tant à l’intérieur qu’à l’extérieur de votre architecture.
Azure fournit Sterling OMS à l’aide des modèles IaaS et PaaS (platform as a service). Microsoft crée des protections de sécurité dans le service aux niveaux suivants :
- Centre de données physique
- Réseau physique
- Hôte physique
- Hyperviseur
Évaluez soigneusement les services et technologies que vous sélectionnez pour les zones situées au-dessus de l’hyperviseur, telles que la dernière version corrigée d’Azure Red Hat OpenShift pour une version majeure. Veillez à fournir les contrôles de sécurité appropriés pour votre architecture. Vous êtes responsable de la mise à jour corrective et de la maintenance de la sécurité des systèmes IaaS. Microsoft assume ce rôle pour les services PaaS comme Azure Red Hat OpenShift. Même si vous pouvez lancer une mise à niveau pour Azure Red Hat OpenShift, elle est complètement managée par Microsoft et Red Hat. Pour plus d’informations sur la mise à jour corrective et la mise à niveau d’Azure Red Hat OpenShift, consultez Mettre à niveau un cluster Azure Red Hat OpenShift.
Utilisez des groupes de sécurité réseau (NSG) pour filtrer le trafic réseau échangé avec des ressources au sein de votre réseau virtuel. Avec ces groupes, vous pouvez définir des règles qui accordent ou refusent l’accès à vos services Sterling OMS. Voici quelques exemples :
- Blocage de l’accès à toutes les autres parties de votre infrastructure déployée, telles que les ports et services spécifiques utilisés par votre répartiteur de messages ou votre base de données back-end
- Contrôle des emplacements qui ont accès à Sterling OMS et au cluster OpenShift
Les numéros et plages de ports que vous devez ouvrir dépendent de nombreux facteurs. En voici quelques-uns à prendre en compte :
- Port 443, pour la communication de service à service
- Ports propres à la base de données, tels que le port 5432 pour l’option de serveur flexible d’Azure Database pour PostgreSQL.
- Ports de file d’attente de messages tels que le port 1414 pour IBM MQ
Tenez également compte des points suivants :
- Les nœuds de cluster Azure Red Hat OpenShift doivent disposer d’un accès Internet sortant. Si vous ne pouvez pas fournir cet accès, ces nœuds ont besoin, au minimum, d’un accès aux points de terminaison Azure Resource Manager et de journalisation des services.
- IBM fournit des conseils pour l’implémentation de plusieurs applications OMS Sterling qui partagent des services communs, comme une base de données back-end. Ces déploiements ont également des considérations en ce qui concerne le pare-feu intra-application. Pour plus d’informations, consultez Opening firewall ports for intra-app communication.
Si vous avez besoin d’accéder à vos autres nœuds non-Azure Red Hat OpenShift, vous pouvez éventuellement utiliser Azure Bastion pour accéder à vos machines virtuelles. Pour des raisons de sécurité, n’exposez pas de machines virtuelles à un réseau ou à Internet sans configurer des groupes de sécurité réseau pour contrôler l’accès à ces machines.
Le chiffrement côté serveur de stockage sur disque Azure contribue à protéger vos données. Il vous aide également à respecter les engagements de votre organisation en matière de sécurité et de conformité. Avec des disques managés Azure, SSE chiffre les données au repos conservées dans le cloud. Ce comportement s’applique par défaut tant au système d’exploitation qu’aux disques de données. OpenShift utilise SSE par défaut. Azure Red Hat OpenShift prend également en charge les clés de chiffrement gérées par le client (CMEK) pour les disques de système d’exploitation de votre cluster.
Authentification
Vous devez configurer OAuth pour Azure Red Hat OpenShift. Pour plus d’informations, consultez Vue d’ensemble de l’authentification et de l’autorisation dans la documentation Azure Red Hat OpenShift.
Protéger votre infrastructure
Contrôlez l’accès aux ressources Azure que vous déployez. Chaque abonnement Azure entretient une relation d’approbation avec un locataire Microsoft Entra. Utilisez le contrôle d’accès en fonction du rôle Azure pour accorder aux utilisateurs de votre organisation des autorisations d’accès appropriées sur les ressources Azure. Accordez l’accès en assignant des rôles Azure à des utilisateurs ou à des groupes jusqu’à une certaine étendue. L’étendue peut être appliquée à un abonnement, à un groupe de ressources ou à une ressource unique. Veillez à auditer tous les changements apportés à l’infrastructure. Pour plus d’informations sur l’audit, consultez le journal d’activité Azure Monitor.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Un déploiement standard de Sterling OMS nécessite les composants suivants : Vous pouvez ajuster la plupart de ces ressources basées sur le calcul pour répondre à vos besoins. Par exemple, vous pouvez effectuer un scale-up de vos nœuds d’agent IBM MQ pour bénéficier d’un débit plus élevé.
Azure Red Hat OpenShift (pour OMS)
- Trois machines virtuelles de contrôle (Standard_D8s_v5)
- Trois machines virtuelles Worker (Standard_D8s_v5)
Ressources supplémentaires
- Un réseau virtuel (/16), avec les sous-réseaux suivants pris en compte :
- Sous-réseau de nœud de contrôle Azure Red Hat OpenShift (/24)
- Sous-réseau de nœud Worker Azure Red Hat OpenShift (/24)
- Sous-réseau de données, si nécessaire (/27)
- Sous-réseau de machines virtuelles supplémentaire, si nécessaire (/27)
- Sous-réseau de gestion, si nécessaire (/30)
- Une instance d’Azure Database pour PostgreSQL avec l’option de serveur flexible
- Une instance d’Azure Container Registry
- Deux comptes Stockage Azure
- Trois zones DNS
- Deux équilibreurs de charge
- Une machine virtuelle JumpBox
- Azure Bastion
Les déploiements individuels peuvent différer, par exemple si vous exécutez Db2 sur des machines virtuelles Azure ou si vous déployez IBM MQ dans votre environnement Azure Red Hat OpenShift. Pour passer en revue un exemple d’estimation, utilisez la calculatrice de coûts. Les configurations varient ; vérifiez donc votre configuration avec votre équipe de dimensionnement IBM avant de finaliser votre déploiement.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
Azure Red Hat OpenShift dispose de fonctionnalités intégrées pour le self-healing, la mise à l’échelle et la résilience, afin de garantir le bon fonctionnement d’Azure Red Hat OpenShift et de Sterling OMS. Azure Red Hat OpenShift et Sterling OMS ont été conçus pour des composants qui échouent et qui récupèrent. Une condition essentielle pour que le self-healing fonctionne est qu’il y ait suffisamment de nœuds Worker. Pour effectuer une récupération à partir d’une défaillance de zone au sein d’une région Azure, vos nœuds de contrôle et de travail doivent être équilibrés entre les zones de disponibilité.
Sterling OMS et Azure Red Hat OpenShift utilisent le stockage de base de données pour rendre l’état persistant en dehors du cluster Kubernetes. Les journaux et autres ressources d’application sont persistés dans un compte de stockage. Pour vous assurer que les dépendances de stockage continuent de fonctionner pendant une défaillance, utilisez dans la mesure du possible le stockage redondant interzone. Ce type de stockage reste disponible lorsqu’une zone échoue. Votre déploiement de base de données doit également prendre en compte les configurations multizones.
L’erreur humaine étant courante, veillez à déployer Sterling OMS en utilisant autant d’automatisation que possible. Pour obtenir des exemples de scripts permettant de configurer l’automatisation complète de bout en bout, consultez QuickStart Guide: Sterling Order Management on Azure sur GitHub.
Déployer ce scénario
Avant de commencer, passez en revue les conditions requises pour Sterling OMS dans System Requirements. Vérifiez également que vous disposez des ressources suivantes :
- Accès à un abonnement Azure avec autorisation Lecteur
- Inscription d’application ou nom de principal de service disposant des autorisations Contributeur et Administrateur d’accès utilisateur sur l’abonnement
- Domaine ou sous-domaine délégué à une zone Azure DNS
- Clé de droit IBM Sterling OMS
- Dimensionnement de cluster recommandé par IBM
- Réseau virtuel existant ou nouveau, en fonction de vos besoins. Pour obtenir un exemple de création d’un réseau virtuel avec deux sous-réseaux vides, consultez Tutoriel : Créer un cluster Azure Red Hat OpenShift 4
- Exigences de haute disponibilité et de reprise d’activité pour votre déploiement spécifique
- Un fichier de configuration OMEnviroment, omenvironment.yaml, à utiliser lorsque vous déployez Sterling OMS via le catalogue d’opérateurs OpenShift
Pour obtenir un guide pas à pas sur l’installation d’Azure Red Hat OpenShift et Sterling OMS sur Azure, notamment sur la façon de satisfaire aux prérequis, consultez QuickStart Guide: Sterling Order Management on Azure.
Points à prendre en considération pour le déploiement
La bonne pratique actuelle consiste à déployer des charges de travail à l’aide de l’infrastructure en tant que code (IaC) plutôt que de déployer manuellement des charges de travail, car le déploiement manuel peut entraîner une mauvaise configuration. Les charges de travail basées sur des conteneurs peuvent être sensibles à la configuration incorrecte, ce qui peut réduire la productivité.
Avant de créer votre environnement, consultez QuickStart Guide: Sterling Order Management on Azure afin de bien comprendre les paramètres de conception. Le guide de démarrage rapide n’est pas destiné à un déploiement prêt pour la production, mais vous pouvez utiliser les ressources du guide pour accéder à un mécanisme de niveau production pour le déploiement.
IBM offre des services spécialisés pour vous aider lors de l’installation. Contactez votre équipe IBM pour obtenir du support.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Principaux auteurs :
- David Baumgarten | Architecte principal
- Drew Furgiuele | Architecte senior
- Roeland Nieuwenhuis | Architecte en chef
Autres contributeurs :
- Aneesh AR | Ceinture noire Services cloud senior
- Vijaya Bashyam | Membre senior du personnel technique
- James Read | Architecte de solution principal EMEA
- Andy Repton | Ceinture noire OpenShift managé
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Prerequisites to deploying certified containers using Sterling Order Management Software Operator
- Sterling Order Management - Best Practices Guide
- IBM Passport Advantage
- Démarrage rapide : Déployer un cluster Azure Red Hat OpenShift
- Démarrage rapide : Créer une instance Azure Database pour PostgreSQL - Serveur flexible
- Sécuriser l’accès à Azure Red Hat OpenShift avec Azure Front Door
- Utiliser le fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets sur Azure Red Hat OpenShift
- IBM MQ in Containers
- Azure Red Hat OpenShift
- Qu’est-ce qu’Azure Database pour PostgreSQL ?
- Présentation de Red Hat sur Azure
- Travailler avec Azure Database pour PostgreSQL