Impossible d'établir le tunnel-L'agent n'apparaît pas dans la liste des agents actifs

Le tunnel ne s'établit pas et votre agent Satellite Connector n'apparaît pas dans la liste de l'interface utilisateur, sous l'onglet Agents actifs.

Un délai d'environ 2 minutes s'écoule entre le démarrage de l'agent de connecteur et son affichage dans la liste.

Au bout de 2 minutes, si l'agent ne s'affiche toujours pas, procédez comme suit pour le débogage:

1. Vérifiez que l'ID connecteur et la région sont indiqués correctement.

2. Ouvrez le tableau de bord de journalisation et examinez les journaux du connecteur. Souvent, le problème est lié à la clé d'API IAM et vous voyez un message similaire à l'exemple suivant. Pour plus d'informations, voir Pourquoi ma clé d'API ne fonctionne-t-elle pas?.

   Failed to get configuration from API /v1/connectors/U2F0ZWxsaXRlQ29ubmVjdG9yOiJjaTExMGxpdzFwazluMGdybXUyMCI, region us-east, code: 401. IAM Error: "status code: 400. Provided API key could not be found.", API Error: "null", hostname: "482bddf6c60b"
   

3. Vérifiez le journal sur le conteneur de l'agent. Si aucune erreur n'apparaît dans le tableau de bord IBM Cloud Logs, cela signifie qu'un problème survient avant que l'agent ne communique avec les serveurs du tunnel. Vous pouvez obtenir plus d'informations en consultant le fichier journal sur le conteneur de l'agent. La commande varie en fonction de la plateforme de conteneur. Si vous utilisez Docker, vous pouvez utiliser la commande suivante:

   docker logs <container id>
   

4. Vous devez être en mesure de déterminer, à partir des messages de journal, quel est le problème. La raison la plus courante des erreurs est que votre agent ne dispose pas d'un accès sortant public pour communiquer avec les serveurs de tunnel IBM. Voir Pourquoi mon agent de connecteur ne parvient pas à établir le tunnel avec IBM Cloud.

5. Vérifiez que vous utilisez la plateforme matérielle de conteneur appropriée. Par exemple, vous essayez d'exécuter l'image d'agent sur une plateforme arm64. L'agent de connecteur s'exécute uniquement sur les plateformes linux/amd64 ou sur les plateformes qui peuvent émuler amd64. Si tel est le cas, une erreur similaire à la suivante s'affiche:

   {"msg":"exec container process `/usr/local/bin/node`: Exec format error","level":"error","time":"2023-06-16T14:37:54.000567792Z"}
   

   Remarque pour les utilisateurs Apple Mac Silicon: Si vous essayez le connecteur sur un Mac avec Apple silicon qui utilise un processeur ARM64, l'agent de conteneur s'exécutera si Rosetta2 a été installé. Il est normalement installé avec Docker. Lors de l'exécution de l'agent de connecteur, l'avertissement suivant s'affiche:

   icr.io/ibm/satellite-connector/satellite-connector-agent:v1.0.3 WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 43064456c42434f056348a32773a732d02d4a68690fc6b2b36790be8daa49bb2
   

   Dans ce cas, il s'agit simplement d'un avertissement et l'agent de connecteur est en cours d'exécution. Si vous ne souhaitez pas voir l'avertissement, vous pouvez spécifier l'option --platform linux/amd64 dans votre commande docker run.

6. Vérifiez que la plateforme de conteneur peut extraire l'image. L'image se trouve dans IBM Container Registry à l'adresse icr.io/ibm/satellite-connector/satellite-connector-agent:<version>. Vérifiez que vous avez spécifié l'image correctement. La machine exécutant l'agent dispose d'un accès réseau à icr.io et vous êtes connecté à IBM Container Registry. Pour plus d'informations, voir Extraction de l'image de l'agent.

Remarque à l'attention des utilisateurs de l'essaim Docker: si vous voyez l'erreur suivante à propos de " Pas d'image de ce type:

icr.io/ibm/satellite-connector/satellite-connector-agent:v1.0.4   swarm-worker1   Shutdown    Rejected 5 minutes ago   "No such image: icr.io/ibm/sat…"

Cela signifie que Docker Swarm n'a pas pu extraire l'image. Il est probablement dû à des données d'identification IBM Container Registry non valides. Pour résoudre cet incident, procédez comme suit :

1. Supprimez le service.
2. Connectez-vous à l' IBM Container Registry.
3. Redémarrez la pile.

Le tunnel est établi-Le conteneur d'agent est répertorié dans l'onglet Agents actifs de la console

Si votre conteneur d'agent est répertorié dans l'onglet Agents actifs de la console, procédez comme suit pour le débogage:

1. Accédez à votre instance de connecteur et ouvrez le tableau de bord de journalisation. Cette opération filtre automatiquement la sortie de consignation pour votre ID de connecteur.

2. Consultez les messages d'erreur.

   Une fois le tunnel établi, toute erreur sera localisée à la fois dans l'instance IBM Cloud Logs et dans les journaux de la plate-forme de conteneurs de l'agent. La plupart des erreurs sont désormais celles qui tentent d'accéder à un noeud final depuis IBM Cloud vers une application s'exécutant sur site via le tunnel. Lors de l'accès à un noeud final, au début de la connexion, une entrée flowlog est écrite dans l'instance de journalisation. Exemple :

   flowlog: start for client 10.249.96.47:1206 connect to postgres.apps.wdc6.toddjohn.net:5432, conn_type: location
   

   Une fois la connexion fermée, une autre entrée flowlog est écrite avec des détails sur la connexion. Exemple :

   flowlog: end for client 10.249.96.47:1206 connect to postgres.apps.wdc6.toddjohn.net:5432, conn_type: location, duration 387 ms, BytesToCloud 2444, BytesFromCloud 168
   

   La durée correspond à la durée d'ouverture de la connexion et non à la durée de la boucle des demandes.

   Si des erreurs se produisent lors de la tentative de connexion au noeud final, une entrée flowlog contenant les détails de l'erreur est écrite. Exemple :

   flowlog: error when client 10.249.96.47:1209 connecting to postgres.apps.wdc6.toddjohn.net:5433, conn_type: location, detail: connect ECONNREFUSED 192.168.3.84:5433
   

3. Si vous ne voyez aucune entrée flowlog, assurez-vous que votre application IBM Cloud a accès au point de terminaison CSE et qu'elle utilise l'adresse et le port corrects. Par exemple, si vous utilisez une instance VPC ou un cluster d' Kubernetes s VPC, un groupe de sécurité peut bloquer l'accès. Assurez-vous que vos groupes de sécurité autorisent le trafic depuis votre VPC vers l'adresse IP et le port du noeud final CSE.

4. Vérifiez que votre noeud final est configuré correctement et que l'application sur site est en mode écoute sur le nom de domaine complet de destination ou sur l'adresse IP et le port de destination configurés. Si votre application sur site utilise un conteneur, son adresse IP peut changer. Pour plus d'informations, voir Pourquoi ne puis-je pas atteindre mon noeud final depuis IBM Cloud.

5. Si vous exécutez plusieurs agents sur le même connecteur, vérifiez que tous les agents ont un accès réseau au noeud final. Chaque demande de connexion est acheminée vers un agent aléatoire et, par conséquent, tous les agents doivent disposer d'une connectivité réseau avec tous les noeuds finaux sur site. Il n'existe pas de mécanisme permettant de cibler un agent individuel pour un connecteur spécifique.