Préparation du déploiement de l'agent

L'agent Schematics étend la possibilité de travailler directement sur votre réseau privé ou sur des zones de réseau isolées. Les agents permettent aux utilisateurs de contrôler la configuration réseau et l'accès qu'ils donnent à un agent pour exécuter des travaux d'espace de travail et d'action. Les agents sont conçus sans accès entrant depuis Schematics et sans ouverture de pare-feu entrant ou de ports d'accès réseau. Toutes les communications entre l'agent et Schematics sont sortantes de l'agent et sous contrôle utilisateur.

Schematics L'agent est un ensemble de microservices qui s'exécutent sur les clusters Kubernetes de votre compte. Ils utilisent également un seau Object Storage comme magasin de données intermédiaire ou temporaire pour les fichiers journaux et les fichiers d'état générés par les tâches de l'espace de travail ou de l'action.

Passez en revue et exécutez les tâches répertoriées pour préparer votre environnement IBM Cloud® afin de déployer un nouvel agent.

Compte et réseaux

Un agent fournit Schematics la possibilité d'exécuter des travaux d'espace de travail et d'action au sein d'un compte cible et du réseau privé des comptes. Les politiques de réseau doivent être configurées pour permettre au cluster sur lequel l'agent est déployé de communiquer avec Schematics, ainsi qu'avec les IBM Cloud API, les services et, par exemple, les Git privées d'un utilisateur ou les instances Vault. Pour plus d'informations, voir la section Planification de l'accès au réseau de l'agent et de sa configuration.

• Enregistrez les informations relatives aux zones réseau autorisées et à l'infrastructure accessible à l'agent.

Cluster

Un Schematics Agent peut être déployé sur des IBM Cloud Kubernetes Service et Red Hat OpenShift Kubernetes Service clusters. Vous pouvez utiliser un cluster existant ou mettre à disposition un nouveau cluster avec la configuration minimale suivante.

• Pour le IBM Cloud Kubernetes Service v1.28 et les versions ultérieures du cluster. Vous devez mettre à jour le chemin réseau afin que les images soient tirées via une passerelle VPE au lieu d'un point d'extrémité de service privé ou améliorer le modèle d'agent Schematics.
• Configuration minimale: trois noeuds worker avec la version b4x16. Cette configuration peut être utilisée pour exécuter quatre travaux d'espace de travail ou d'action en parallèle.
• Enregistrez des informations sur le cluster, telles que cluster ID, cluster resource group et region, pour une utilisation ultérieure.

Lors de la mise à niveau d'un agent dans le cluster ca-mon, assurez-vous que les points d'extrémité de service private et public sont activés. Ces points finaux ne sont nécessaires que lors de l'installation ou de la mise à jour. Après une installation ou une mise à jour réussie, vous pouvez désactiver le point de terminaison du service public. Cependant, vous devez réactiver le point d'extrémité du service public pour les futures mises à niveau de l'agent.

Pour prendre en charge les agents sur le site Red Hat OpenShift Kubernetes Service en fonction des besoins, vous pouvez contrôler le trafic de sortie par le biais de groupes de sécurité et de listes de contrôle d'accès au réseau (ACL).

Vous devez définir les règles des groupes de sécurité et les ACL au niveau du VPC avant de déployer un agent sur le cluster. Pour plus d'informations, voir le Script de Terraform pour définir les groupes de sécurité et les ACL sur un VPC.

Si vous installez un agent sur un cluster où le point de terminaison public est désactivé et le type d'accès OAuth pour le cluster est vpegw, vous devez créer une politique d'autorisation de service à service ( S2S ) entre Schematics et Kubernetes avec le rôle Viewer. La version de l'agent doit être 1.7.0 ou une version ultérieure. Pour plus d'informations sur la création de politiques S2S, voir Utilisation des autorisations pour accorder l'accès entre les services.

IBM Cloud Object Storage

L'agent Schematics utilise un seau Object Storage pour stocker des données temporaires. L'instance IBM Cloud Object Storage doit se trouver dans le même groupe de ressources que le cluster. De plus, le nouveau compartiment doit se trouver dans la même région que le cluster.

• Pour déployer un agent, vous devez disposer des privilèges nécessaires pour créer le HMAC credentials pour le compartiment Object Storage et stocker les données d'identification en tant que secret Kubernetes.
• L'instance IBM Cloud Object Storage et le seau doivent être créés pour que le déploiement soit réussi.
• Enregistrez des informations sur les ressources IBM Cloud Object Storage telles que COS instance name, COS bucket name et bucket region pour une utilisation ultérieure.

Autorisation d'accès IAM

Vous devez au minimum disposer d'autorisations d'accès pour le service Kubernetes, le groupe de ressources, Object Storage, et le service Schematics pour déployer un agent.

• Pour déployer un agent dans un autre compte en utilisant un ServiceID ou APIKey, vous devez vous assurer que l'administrateur du compte donne la permission pour tous les services énumérés dans permission de déployer un agent.

CLI IBM Cloud

Utilisez la version récente de IBM Cloud CLI et le Schematics CLI v1.12.12 ou un plug-in plus récent pour installer un agent. Pour plus d'informations sur l'installation du plug-in, voir installation du Schematics CLI plug-in.

Prise en charge de la version de Terraform

L'agent prend en charge l'espace de travail à l'aide de Terraform et v1.13 v1.14. Les espaces de travail avec des versions plus anciennes de Terraform doivent être mis à jour vers l'une des versions prises en charge par un agent. Pour plus d'informations, consultez le calendrier de dépréciation et les actions à effectuer par les utilisateurs pour procéder à la mise à niveau.

Vous ne pouvez déployer qu'une seule instance d'agent sur un cluster Kubernetes. Pour déployer plusieurs agents dans un seul compte IBM Cloud, ils doivent être déployés dans différents clusters Kubernetes. Chaque agent et cluster peut prendre en charge différentes zones d'isolement du réseau dans votre environnement de cloud.

Un agent peut être associé à et exécuter des travaux pour un compte IBM Cloud et une région géographique. Les agents ne peuvent pas être partagés avec d'autres comptes ou exécuter des travaux pour plusieurs comptes. Le diagramme représente l'association des agents à une région géographique Schematics. Ici, plusieurs agents ayant accès à des ressources privées locales dans des emplacements distants sont associés à différentes instances géographiques Schematics.

Cette image est une représentation artistique et ne reflète pas les frontières politiques ou géographiques réelles.

Planification de la configuration et de l'accès au réseau de l'agent

Schematics L'agent permet d'exécuter des tâches d'espace de travail et d'action sur votre réseau privé avec un accès direct aux ressources de votre réseau privé et de vos centres de données. Le diagramme suivant illustre un modèle de déploiement d'agent possible dans un environnement de cluster avec plusieurs VPC connectés via une passerelle Transit Gateway.

Pour utiliser des ressources privées, votre environnement de cloud privé doit être configuré pour permettre au cluster de s'exécuter sur votre agent. Il a également accès aux API, aux services et aux ressources pour permettre l'exécution des travaux d'espace de travail et d'actions. En général, Terraform utilise HTTPS pour configurer le service sur le port 443. Alors qu' Ansible utilise SSH via le port 22 pour effectuer la configuration du VSI en post-provisionnement. Ces chemins de réseau HTTPS et SSH sont illustrés dans le diagramme.

Les stratégies de groupe de sécurité VPC ou de liste de contrôle d'accès doivent être configurées pour permettre au cluster d'agents d'accéder aux API IBM Cloud À l'aide de HTTPS et à tout VSI cible à l'aide de SSH.

L'accès aux ressources du centre de données peut être configuré à l'aide de Direct Link ou d'une connexion VPN.

Avec les agents, vous devez effectuer les règles de sécurité réseau pour le cluster Kubernetes et les règles de groupe de sécurité VPC ou de liste de contrôle d'accès pour l'agent en cours d'exécution. Par conséquent, déterminer la capacité des travaux d'espace de travail et d'action à accéder aux ressources de cloud privé et aux API IBM Cloud pour la mise à disposition et la configuration des services.

- The number of concurrent Terraform, and Ansible jobs.
- The number of Terraform and Ansible pods.
- The resource limits for the agent deployment.