Extensions

Réponses aux questions courantes concernant l'Agent pour l' IBM Cloud Schematics.

Quelles sont les mises à jour dans l'édition de l'agent GA?

Les fonctions de l'édition de l'agent sont les suivantes.

  • Améliorations apportées à l'expérience de déploiement de l'agent via l'interface de ligne de commande et l'interface utilisateur.
  • Possibilité d'exécuter des playbooks Ansible sur l'agent.
  • Affectation dynamique de travaux d'espace de travail ou d'action à l'agent.

Quels sont les coûts d'installation et d'utilisation des agents?

Voici la répartition des coûts pour le déploiement et l'utilisation d'un agent Schematics.

L'infrastructure prérequise requise pour déployer et exécuter un agent est facturable:

  • Coût des éléments d'infrastructure VPC tels que le sous-réseau et les passerelles publiques.
  • Coût de IBM Cloud Kubernetes Service (cluster) sur VPC, avec un pool de noeuds worker à trois noeuds.
  • Coût de IBM Cloud Object Storage

Exécution du service d'agent:

  • L'exécution de travaux sur des agents n'entraîne aucun coût.
  • La fonction d'agent Schematics version 1 est une fonction non facturable. Les versions futures peuvent être facturables.

Est-il possible d'installer plusieurs agents sur un cluster?

Vous ne pouvez installer qu'un seul agent sur le cluster IBM Cloud Kubernetes Service. Des clusters supplémentaires sont requis pour déployer des agents supplémentaires. Si vous tentez d'installer plusieurs agents sur un cluster, le travail de déploiement échoue avec une erreur de conflit d'espace de nom.

Quelles sont les versions Terraform prises en charge avec les agents?

Seules les deux versions les plus récentes de Terraform prises en charge par Schematics sont prises en charge avec les agents, par exemple, Terraform v1.13 et Terraform v1.14. Les anciennes versions de Terraform ne sont pas prises en charge. Les espaces de travail utilisant des versions plus anciennes de Terraform doivent être mis à jour vers l'une des versions prises en charge avant d'utiliser des agents. Consultez les instructions Mise à niveau vers une nouvelle version de Terraform pour la mise à niveau avant d'utiliser les agents.

Pourquoi l'exécution de l'espace de travail échoue-t-elle avec terraformx.x: executable file not found in $PATH

La version de Terraform utilisée par l'espace de travail n'est pas prise en charge avec les agents. L'agent prend en charge l'espace de travail à l'aide de Terraform v1.13 et v1.14 ou les deux versions les plus récentes de Terraform prises en charge par Schematics. 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, voir la planification d'obsolescence et les actions utilisateur pour la mise à niveau.

Quel type de travaux peut être exécuté dans un agent?

Vous pouvez exécuter les travaux Terraform et Actions de l'espace de travail Schematics sur un agent.

Comment puis-je voir les résultats et les journaux du travail Schematics pour les travaux exécutés sur un agent?

Les journaux des travaux d'espace de travail ou des travaux d'action sont disponibles dans la console de l'interface utilisateur Schematics. Vous pouvez également accéder aux journaux de travail à l'aide de l'API ou de l'interface de ligne de commande de l'espace de travail Schematics.

Quelle est la configuration de cluster minimale requise dans l'édition de l'agent?

L'agent a besoin du service IBM Cloud Kubernetes Service avec un minimum de trois noeuds worker, avec un type b4x16 ou supérieur.

Combien d'espaces de travail peuvent être affectés à un agent?

Actuellement, vous pouvez affecter n'importe quel nombre d'espaces de travail à un agent. Les travaux de l'espace de travail sont mis en file d'attente pour s'exécuter sur l'agent, en fonction de la règle d'affectation de l'agent. L'agent interroge régulièrement Schematics pour l'exécution des travaux, avec un intervalle d'interrogation d'une minute. Par défaut, l'agent exécute uniquement trois travaux en parallèle. Les travaux restants sont mis en file d'attente.

Combien de travaux peuvent être exécutés en parallèle sur un agent?

Schematics L'agent peut effectuer trois Git, des travaux d'espace de travail (commandes Terraform) et des travaux d'action (playbooksAnsible ) en parallèle. Tous les travaux supplémentaires sont mis en file d'attente et s'exécutent à la fin de l'exécution des travaux précédents.

Quel est l'intervalle d'interrogation par défaut pour les agents?

Schematics gère une file d'attente de travaux pour un agent. Par défaut, l'agent interroge les travaux toutes les minutes.

Existe-t-il des limites de délai d'exécution lors de l'utilisation d'agents?

Schematics L'agent assouplie la limitation du délai d'attente pour l'exécution de playbook local-exec, remote-exec et Ansible. Elles sont limitées à 60 minutes dans le service à service partagé afin de garantir une utilisation équitable du service par tous les utilisateurs. Aucune durée n'est appliquée aux travaux exécutés sur les agents. Les longs temps d'exécution des travaux nécessitent davantage de capacité de cluster utilisateur et de noeuds worker pour garantir une exécution rapide de tous les travaux de cluster.

Il est recommandé d'utiliser un service tel que Continuous Delivery pour les travaux à exécution longue exécutant des tâches d'installation de logiciels.

Quelle est la différence entre l'indicateur agent-location et location dans le service d'agent?

Le paramètre --agent-location est une variable qui spécifie la région du cluster dans laquelle un service d'agent est déployé. Par exemple, us-south. Cette valeur doit correspondre à la région de cluster.

Le paramètre --location est une variable qui spécifie la région prise en charge par le service Schematics tel que us-south, us-east, eu-de, eu-gb. L'agent interroge l'instance de service Schematics à partir de cet emplacement, pour rechercher les travaux d'espace de travail ou d'action à traiter.

Un agent peut-il exécuter des travaux d'espace de travail associés à différents groupes de ressources?

Oui, un agent peut exécuter des travaux d'espace de travail ou d'actions associés à n'importe quel groupe de ressources, dans un compte. Les règles d'affectation d'agent sont utilisées pour affecter l'exécution de travaux, en fonction du groupe de ressources, de la région et des balises utilisateur à un agent spécifique.

Un agent peut-il utiliser des espaces de travail et des actions appartenant à différentes régions Schematics ?

Les déploiements d'agents sont associés à une région d'accueil Schematics pour l'exécution des travaux. Ils peuvent uniquement exécuter des travaux d'espace de travail ou d'action définis dans la même région, telle que North America ou Europe.

L'agent interroge régulièrement sa région d'accueil Schematics pour extraire et exécuter des travaux. Il peut uniquement exécuter des travaux d'espace de travail ou d'action définis pour la région contenant sa région d'origine. Par exemple, un agent est déployé sur un cluster d'utilisateurs à Sydney configuré avec eu-de comme emplacement d'origine. L'agent recherche des travaux dans la région Europe, contenant à la fois les régions eu-de et eu-gb. Pour déployer des ressources à l'aide de l'agent Sydney, des espaces de travail ou des actions doivent être créés dans les régions eu-de ou eu-gb.

Est-il possible d'utiliser un agent pour exécuter des travaux pour plusieurs comptes?

Non, les agents sont associés à un compte Schematics parent unique et peuvent uniquement exécuter des travaux pour des espaces de travail ou des actions appartenant à ce compte.

Un espace de travail existant peut-il exécuter des travaux sur un agent?

Oui. Les espaces de travail et les actions sont sélectionnés par règle à exécuter sur les agents. Un Schematics agent-selection-policy affecte des espaces de travail ou des actions existants (ou nouveaux) à exécuter sur un agent cible, s'ils correspondent aux attributs de règle pour les balises, le groupe de ressources, l'emplacement.

Par exemple, si vous disposez d'un espace de travail existant: wks-0120 avec tag=dev et que vous souhaitez que l'espace de travail s'exécute sur Agent-1. Créez un agent-selection-policy avec les règles pour sélectionner Agent-1 lorsque tag == dev. Par la suite, le travail de l'espace de travail, tel que plan, application, mise à jour, est acheminé de manière dynamique pour s'exécuter sur Agent-1.

Quels sont les droits IAM nécessaires pour déployer un agent?

Pour plus d'informations sur les droits d'accès, voir Droits d'accès de l'agent.

Puis-je ajouter des certificats auto-signés ou des certificats TLS au magasin de certificats racine de l'autorité de certification (CA) de confiance d'un pod ou d'un conteneur d' IBM Cloud Kubernetes Service, pendant l'exécution de l'agent?

Oui, procédez comme suit pour injecter les certificats dans un environnement d'exécution d'agent.

Dans les quatre noms de fichier d'extension .cer, veillez à les modifier pour remplacer l'espace par un trait de soulignement.

  1. Créez une mappe de configuration à l'aide du fichier .cer, comme indiqué dans la commande kubectrl.

    kubectl -n schematics-runtime create configmap xyz-root —-from-file 2014-2044_xyz_Root.cer
    
    kubectl -n schematics-runtime create configmap xyz-authentication —-from-file 2014-2029 xyz_Users_Authentication.cer
    
    kubectl -n schematics-runtime create configmap xyz-infrastructure —-from-file 2014-2029 xyz_Infrastructure.cer
    
  2. Montez le fichier de mappe de configuration en tant que volume dans un répertoire /etc/ssl/certs/ en tant que fichier agent-runtime-deployment-certs.yaml dans un répertoire xyz_agent_deployment_files partagé.

Le répertoire partagé xyz_agent_deployment_files comporte deux fichiers yaml nommés - agent-runtime-deployment-certs.yaml et - agent-runtime-deployment.yaml.

Le fichier agent-runtime-deployment-certs.yaml met à jour les certificats et ajoute le fichier agent-runtime-deployment.yaml qui fournit les détails de déploiement souhaités pour injecter les certificats sans modifications supplémentaires.

Quels sont les attributs des espaces de travail ou des actions utilisés pour sélectionner dynamiquement un agent cible pour l'exécution

Les attributs suivants d'un espace de travail ou d'une action d' Schematics s sont utilisés pour sélectionner dynamiquement l'instance d'agent.

  • Groupe de ressources
  • Emplacement (région)
  • Balises

La règle d'affectation d'agent d'une instance d'agent détermine l'agent sélectionné pour exécuter un travail d'espace de travail ou d'action.

Voici un exemple de scénario d'utilisation des balises.

Si votre organisation possède trois zones d'isolement de réseau différentes (telles que Dev, HR-Stage et HR-Prod) et que vous avez installé trois agents (un chacun, pour les trois zones d'isolement de réseau). Vous avez défini un agent-assignment-policy pour l'agent qui s'exécute dans Dev, avec le sélecteur tags=dev. Tous les espaces de travail pour lesquels tags=dev est automatiquement lié à l'agent Dev. En d'autres termes, l'agent Dev est utilisé pour télécharger des modèles Terraform (à partir du référentiel Git ) et exécuter des travaux Terraform. De même, agent-assignment-policy peut inclure d'autres attributs des espaces de travail afin de définir l'agent pour l'exécution des travaux.

Comment activer le mode débogage dans un agent?

Vous pouvez suivre ces étapes pour activer ou désactiver le mode débogage d'un agent.

  1. Connectez-vous à IBM Cloud.
  2. Cliquez sur Kubernetes dans la fenêtre du navigateur, puis sur Clusters.
  3. Dans la page Kubernetes Clusters, cliquez sur votre cluster > tableau de bordKubernetes.
    • Cliquez sur la liste déroulante default pour afficher la liste des espaces de nom:
      • Dans la liste déroulante, entrez les espaces de nom Schematics-job-runtime.
      • Cliquez sur Mappe de configuration dans Configuration et stockage.
      • Dans la page Mappes de configuration. Cliquez sur les trois points de la zone schematics-jobrunner-config.
      • Cliquez sur Editer pour afficher la page Editer une ressource avec les onglets YAML et JSON.
      • Vous pouvez maintenant éditer le paramètre JR_LOGGERLEVEL pour la journalisation des microservices de l'exécuteur de travaux. Par défaut, la valeur est -1, qui indique la désactivation du débogage pour vous permettre d'éditer JR_LOGGERLEVEL en tant que 0.
      • Cliquez sur Mettre à jour pour enregistrer vos modifications.

Puis-je mettre à niveau une version bêta d'agent vers une version GA (General Availability) de l'agent?

Non, vous ne pouvez pas mettre à niveau la configuration bêta de l'agent vers la version GA de l'agent.

L'agent Schematics est-il identique aux agents de cloud Terraform?

Schematics L'agent joue un rôle similaire à celui des agents Terraform Cloud.

Les agents s'exécuteront-ils sur les ressources de cloud IBM Cloud ?

Schematics L'agent ne peut exécuter que des charges de travail d'espace de travail et d'action. Pour la version bêta, les agents sont déployés dans des clusters IBM Cloud IBM Cloud Kubernetes Service dans le compte utilisateur.

Quelles sont les configurations de cluster minimales requises pour prendre en charge 30 travaux sur l'agent Schematics ?

Pour le cluster IBM Cloud® Virtual Servers for Virtual Private Cloud ou IBM Cloud® Kubernetes Service. Vous avez besoin du 9 nombre minimal de noeuds, avec une version bx2.4x16, et éditez les déploiements de microservices d'agent suivants pour avoir le nombre de répliques prescrit.

déploiements de microservice d'agent
Microservice Nombre de répliques
jobrunner 4
bac à sable 8
runtime-ws 16

Comment un utilisateur peut-il identifier le travail créé par un agent?

Vous pouvez identifier que l'espace de travail est créé par un agent via les journaux de travail de l'espace de travail.

Est-il possible qu'un espace de travail soit créé par un agent et qu'il n'y ait toujours pas de référence dans le journal des travaux de l'espace de travail?

Non, si un agent crée un espace de travail, vous devez voir une référence dans le journal de travail de l'espace de travail. Si vous ne voyez pas la référence, vous devez vérifier que la validation de votre règle a échoué.

L'agent Schematics peut-il établir une connexion avec l'instance Git privée?

Oui, l'agent Schematics établit une connexion avec l'instance Git privée. Cependant, vous devez disposer d'un certificat SSL et suivre ces étapes dans les microservices de l'agent.

  1. Établissez une connexion en configurant un certificat d' SSL dans Runtime-ws les microservices Jobrunner, Sandbox, et.
  2. La configuration doit être effectuée à l'aide du montage de la mappe de configuration Kubernetes Service.
    • Créez un ConfigMap avec le certificat requis SSL, par exemple :

      kubectl -n schematics-job-runtime create configmap mytestcert --from-file cert.pem
      
    • Utilisez configmap comme volume et montez comme partagé dans le fichier de déploiement dans les microservices Jobrunner, Sandbox et Runtime-ws.

         apiVersion: apps/v1
         kind: Deployment
         metadata:
         annotations:
         deployment.kubernetes.io/revision: "1"
         kubernetes.io/change-cause: job_runner_1.0
         creationTimestamp: "2023-09-14T12:18:07Z"
         generation: 1
         labels:
         app: jobrunner
         name: jobrunner
         namespace: schematics-job-runtime
         resourceVersion: "23425"
         uid: fa66583a-8bdb-40a1-9b05-df2c2bf56656
         spec:
         progressDeadlineSeconds: 600
         .....
         .....
         volumes:
         - hostPath:
                 path: /var/log/at
                 type: ""
                 name: at-events
         - hostPath:
                 path: /var/log/schematics
                 type: ""
                 name: ext-logs
         - name: mytestcert  #### added as a volume
                 configMap:
                 name: mytestcert
                 status:
                 availableReplicas: 1
                 conditions:
         - lastTransitionTime: "2023-09-14T12:18:42Z"
                 lastUpdateTime: "2023-09-14T12:18:42Z"
                 message: Deployment has minimum availability.
                 reason: MinimumReplicasAvailable
                 status: "True"
                 type: Available
         - lastTransitionTime: "2023-09-14T12:18:07Z"
                 lastUpdateTime: "2023-09-14T12:18:42Z"
                 message: ReplicaSet "jobrunner-7f9ffdf959" has successfully progressed.
                 reason: NewReplicaSetAvailable
                 status: "True"
                 type: Progressing
                 observedGeneration: 1
                 readyReplicas: 1
                 replicas: 1
                 updatedReplicas: 1
      

L'agent Schematics peut-il mettre à jour une connexion avec l'instance Git privée?

Oui, vous pouvez mettre à jour l'agent avec les métadonnées pour effectuer l'intégration du catalogue avec l'instance Git privée. Utilisez l'exemple de demande d'API de mise à jour pour référence.

Effectuez cette étape uniquement si un agent ne possède pas de métadonnées.

curl -X PUT 'https://schematics.cloud.ibm.com/v2/agents/<agent_id>'
    -H 'Authorization: Bearer <token>'
    -H 'X-Feature-Agents: true'
    -H 'refresh_token: <refresh_token>'
    -d '{
"agent_metadata": [
        {
            "name": "purpose",
            "value": ["git"]
        },
        {
            "name": "git_endpoints",
            "value": ["https://myprivate-gitinstance/testrepo"]
        }
      ]
    }'