Des agents en conteneur,
à portée de main.

Un agent dans un conteneur est coupé de votre Mac : il ne peut pas dire à Gnista qu’il vous attend. Donnez au conteneur l’utilitaire de Gnista et un chemin de retour, et ses sessions ont leur ligne dans l’encoche comme les autres. Voici comment faire pour un devcontainer sur votre Mac, un conteneur sur un serveur et un pod Kubernetes.

7 jours d’essai gratuitSans compte ni carte · puis 19 € une fois

Mis à jour le

En deux mots

  • Sur votre Mac : activez Réglages ▸ À distance ▸ Agents dans des conteneurs, ajoutez les lignes affichées à votre devcontainer.json, et reconstruisez le conteneur.
  • Sur un serveur que Gnista connecte : montez de la même façon le ~/.gnista du serveur dans le conteneur.
  • Dans Kubernetes : dans Réglages ▸ À distance, choisissez Autre hôte… et saisissez kube:, le contexte, l’espace de noms et le pod.

Les devcontainers sur votre Mac

  1. Dans Réglages ▸ À distance, activez Agents dans des conteneurs. Gnista crée un dossier pour les conteneurs, ~/.gnista/containers, avec son utilitaire pour Linux sur les deux processeurs.
  2. Cliquez sur Copier sous les lignes affichées, et ajoutez-les au devcontainer.json de votre projet.
  3. Reconstruisez le conteneur. À sa création, il connecte les agents qui y sont installés.
  4. Lancez une session dans le conteneur. Sa ligne affiche Docker comme machine.

Les lignes

"mounts": ["source=${localEnv:HOME}/.gnista/containers,target=/opt/gnista,type=bind"],
"containerEnv": { "GNISTA_HOME": "/opt/gnista" },
"postCreateCommand": "/opt/gnista/bin/gnista install all"

Sans devcontainer, montez le même dossier dans n’importe quel conteneur, puis lancez-y une fois /opt/gnista/bin/gnista install all :

docker run -it -v ~/.gnista/containers:/opt/gnista -e GNISTA_HOME=/opt/gnista your-image

Comment ça marche

Docker Desktop ne fait passer aucun socket de votre Mac vers les conteneurs : Gnista écoute donc sur un port de la boucle locale de votre Mac, que les conteneurs joignent sous le nom host.docker.internal. Chaque connexion doit commencer par un mot de passe conservé dans le dossier que vous montez, pour que les autres apps de votre Mac ne puissent rien envoyer. Les images arm64 et x86_64 fonctionnent toutes les deux.

Les conteneurs sur un serveur

Connectez d’abord le serveur : les agents via SSH. Montez ensuite son ~/.gnista dans le conteneur, avec les mêmes lignes que ci-dessus mais ${localEnv:HOME}/.gnista comme source. L’utilisateur du conteneur doit être root, ou avoir votre identifiant d’utilisateur sur le serveur, pour atteindre le socket.

Les pods Kubernetes

  1. Installez kubectl sur votre Mac, avec Homebrew ou Rancher Desktop, et vérifiez que kubectl exec atteint le pod.
  2. Dans Réglages ▸ À distance, cliquez sur Connecter, choisissez Autre hôte… et saisissez kube: suivi du contexte, de l’espace de noms et du pod, par exemple kube:prod/agents/agent-0. Un déploiement fonctionne aussi : kube:prod/agents/deploy/agents.
  3. Gnista configure le pod via kubectl exec, comme il le ferait pour un serveur, et y garde un relais en marche pour les événements des agents. Quand le pod redémarre, Gnista le configure de nouveau.

Limites

  • Toute personne qui peut lancer des commandes dans le conteneur ou le pod peut répondre à vos demandes d’autorisation, comme sur un serveur. Ne connectez que ceux de confiance.
  • Les sessions des conteneurs de votre Mac s’affichent toutes comme Docker, pas conteneur par conteneur. Un clic fait apparaître l’onglet de terminal qui y lance docker exec ou kubectl exec.
  • Conteneurs et pods Linux uniquement, x86_64 ou arm64.
  • Quand votre connexion cloud pour kubectl expire, la ligne du pod indique qu’il vous attend ; reconnectez-vous comme vous le feriez pour kubectl, et Gnista réessaie de lui-même.
  • Les organisations qui désactivent les machines distantes sur leurs Mac désactivent aussi ceci : réglages gérés.

D’autres guides.