Gestion de la configuration des agents à l'aide d' Git

Si vous hébergez le référentiel Git vous-même, vous pouvez utiliser un certificat autosigné. Pour que l'agent puisse se connecter en toute sécurité à un référentiel Git, vous devez importer le certificat auto-signé dans le magasin de certificats Java. Pour plus d'informations, consultez la section « Certificats auto-signés ».

L'accès à un référentiel Git peut être autorisé à l'aide d'un fichier .netrc pour fournir le mot de passe ou le jeton d'accès. .netrc est largement utilisé et des détails le concernant sont disponibles sur la page d'aide de .netrc.

Vous pouvez configurer le .netrc fichier situé dans le répertoire personnel de l'utilisateur (par exemple, root) sur lequel l'agent hôte de Instana est en cours d'exécution. Consultez l'exemple de fichier .netrc suivant pour le référentiel github.com :

machine github.com
login oauth2
password <access_token>
 

Dans le référentiel Git , vous devez disposer de la même structure de répertoires que dans *instanaAgentDir*/etc. Par exemple, si vous souhaitez obtenir des données du fichier Git nommé configuration-mysql.yaml, ce fichier doit être placé dans le répertoire Git nommé instana (c'est-à-dire le fichier instana/configuration-mysql.yaml). Sinon, lorsque le fichier est récupéré depuis le référentiel Git, il est placé au mauvais emplacement sur le serveur et n'est pas utilisé par l'agent hôte Instana.

La figure suivante illustre l'exemple de structure d'un référentiel Git :

repository-root/
├── instana/
│   ├── configuration-mysql.yaml
│   └── com.instana.agent.main.config.UpdateManager.cfg
└── org.ops4j.pax.url.mvn.cfg
 

A l'aide de systemd, la méthode la plus simple pour spécifier les paramètres supplémentaires consiste à utiliser un fichier de dépôt. Pour afficher le chemin d'accès au répertoire de dépôt, exécutez la commande suivante:

systemctl status instana-agent
 

Les fichiers de ce répertoire doivent avoir l'extension de fichier .conf, sinon les fichiers sont ignorés.

1. Créez un nouveau fichier dans le répertoire /etc/systemd/system/instana-agent.service.d/ avec l'extension .conf, par exemple git-configuration-environments.conf.
2. Ajoutez le contenu suivant au fichier :

   [Service]
   Environment=INSTANA_GIT_REMOTE_BRANCH=<branch>
   Environment=INSTANA_GIT_REMOTE_REPOSITORY=<repository_url>
   Environment=INSTANA_GIT_REMOTE_USERNAME=<username>
   Environment=INSTANA_GIT_REMOTE_PASSWORD=<access_token>
   ```   **Notes:**
    - Replace *<branch>* with the name of the remote branch that the Instana host agent connects to.
    - Replace *<repository_url>* with the URL of the remote Git repository; for example, `https://github.com/<your_account>/<your_repo>.git`.
    - Replace *<username>* with a username or access token (for basic authentication). If you are using a `.netrc` file or a public repository, you can remove the whole line `Environment=INSTANA_GIT_REMOTE_USERNAME=<username>`.
    - Replace *<access_token>* with an access token. If you are using an access token as username (basic authentication), a `.netrc` file, or a public repository, you can remove the whole line `Environment=INSTANA_GIT_REMOTE_PASSWORD=<access_token>`.
   
    

Après avoir ajouté ou modifié un fichier de dépôt, procédez comme suit:

1. Rechargez les fichiers de dépôt en exécutant la commande systemctl daemon-reload .
2. Redémarrez l'agent hôte d' Instana, en exécutant la commande systemctl restart instana-agent.

Si vous avez défini les variables d'environnement suivantes, lorsqu'un agent hôte est démarré, il vérifie la présence du référentiel Git local dans le dossier *instanaAgentDir*/etc/ . Si le référentiel Git local n'est pas présent, l'agent hôte crée un référentiel local qui est connecté au référentiel distant.

Si l'agent « Instana » s'exécute directement sur un hôte, les variables d'environnement suivantes doivent être définies sur cet hôte. Si l'agent hôte s'exécute dans un environnement conteneurisé, définissez les variables au niveau du conteneur.

Reportez-vous à la section -g, -b, -u et -p options de la OneLiner documentation, qui correspond aux variables d'environnement INSTANA_GIT_REMOTE_REPOSITORYINSTANA_GIT_REMOTE_PASSWORD , INSTANA_GIT_REMOTE_BRANCH, INSTANA_GIT_REMOTE_USERNAME et pour le méthode environnementale.

Le tableau suivant présente le mappage entre les variables d'environnement et les paramètres de la commande à ligne unique:

Les étapes sont fondamentalement les mêmes que la méthode d'environnement, en ajoutant les variables d'environnement INSTANA_GIT_REMOTE_REPOSITORY, INSTANA_GIT_REMOTE_BRANCH, INSTANA_GIT_REMOTE_USERNAME et INSTANA_GIT_REMOTE_PASSWORD au conteneur Docker .

Par exemple, l'extrait de code suivant indique les paramètres nécessaires au démarrage de l'agent hôte dans un conteneur, ainsi que les paramètres requis pour Git afin d'activer la gestion de la configuration via Git :

# Please enter proper values for all --env arguments.
docker run \
   --detach \
   --name instana-agent \
   --volume /var/run:/var/run \
   --volume /run:/run \
   --volume /dev:/dev:ro \
   --volume /sys:/sys:ro \
   --volume /var/log:/var/log:ro \
   --privileged \
   --net=host \
   --pid=host \
   --env="INSTANA_AGENT_ENDPOINT=" \
   --env="INSTANA_AGENT_ENDPOINT_PORT=" \
   --env="INSTANA_AGENT_KEY=" \
   --env="INSTANA_DOWNLOAD_KEY=" \
   --env="INSTANA_AGENT_ZONE=" \
   --env="INSTANA_GIT_REMOTE_BRANCH=" \
   --env="INSTANA_GIT_REMOTE_PASSWORD=" \
   --env="INSTANA_GIT_REMOTE_REPOSITORY=" \
   --env="INSTANA_GIT_REMOTE_USERNAME=" \
   icr.io/instana/agent
 

La gestion de configuration basée sur l' Git peut être configurée dans la section « Gestion de configuration » du tableau de bord de gestion des agents.

La gestion de la configuration basée sur l' Git peut être initialisée et configurée à l'aide de l' API, comme décrit dans la Host Agent section de la documentation de l' Web REST API.

Une configuration manuelle consiste à initialiser un référentiel Git dans le dossier *instanaAgentDir*/etc/ et à ajouter un remote nommé configuration.

L'agent hôte extrait la branche main locale à l'aide de la branche de suivi configurée à partir de la branche distante configuration . Il existe plusieurs façons de configurer le référentiel Git et vous pouvez choisir librement celle qui correspond le mieux à votre configuration.

Par exemple, la configuration suivante vous permet de disposer des configurations d'extraction d'agent hôte à partir de la branche main de la configuration distante:

etc> git init
etc> git remote add -m main -t main configuration <git-repository-url>
etc> git fetch configuration
etc> git checkout -f -b main --track configuration/main
 

L'exemple suivant vous permet d'extraire les configurations de la branche my-configurations dans le système distant configuration :

etc> git init
etc> git remote add -m main -t my-configurations configuration <git-repository-url>
etc> git fetch configuration
etc> git checkout -f -b main --track configuration/my-configurations
 

Les formats <git-repository-url> possibles sont décrits dans la documentation officielle sur URL Git.

Les points d'ancrage Git sont des programmes que vous pouvez placer dans le répertoire .git/hooks du référentiel et qui se déclenchent à des moments différents du cycle de vie de votre référentiel Git . Git offre de nombreux points d'ancrage différentset le point d'ancrage post-update est le mieux adapté à l'intégration à la gestion de la configuration Gitdes agents hôte.

Le dépôt « GitOps-Demo » fournit un exemple de hook post-update « Git » qui déclenche la mise à jour des agents hôtes chaque fois qu'une branche du dépôt est mise à jour.

Vous voyez que la sortie attendue du script est renvoyée à votre client Git après le déclenchement d'une commande push:

$ gitops-test# git push origin HEAD:main
[detached HEAD 9632c09] origin
 1 file changed, 1 insertion(+), 1 deletion(-)
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 376 bytes | 376.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: GitOps update: Triggering the configuration update of agents matching the following query: 'entity.zone:"test"' ... OK
   699ada9..9632c09  HEAD -> main
 

L 'action « Instana » ( GitHub ) de « GitOps » vous permet de déclencher facilement les agents distants via l'interface Web de « Instana » ( API ).

Le référentiel « GitOps-Demo » explique comment configurer un référentiel sur GitHub pour gérer les configurations de vos agents hôtes, et comment déclencher automatiquement les mises à jour à l'aide de l'action « Instana » de GitHub pour GitOps.

GitHub prend en charge l'authentification par jetons ( HTTPS ), et cette fonctionnalité peut être utilisée par l'agent hôte comme décrit dans cette section.

Pour utiliser un référentiel GitHub , vous devez d'abord créer un jeton d'accès personnel. Vous trouverez des informations détaillées à ce sujet sur la page de documentation « Créer un jeton d'accès personnel » de l' GitHub. Le jeton n'a besoin que de droits d'accès en lecture pour accéder au référentiel.

GitHub attend que le jeton soit fourni sous la forme d 'un nom d'utilisateur d'authentification de base HTTPS avec un mot de passe vide. Par conséquent, l'agent hôte peut être configuré pour utiliser l'authentification de base HTTPS pour les référentiels GitHub en définissant les variables d'environnement suivantes :

INSTANA_GIT_REMOTE_REPOSITORY='https://github.com/<user/organization>/<repository>.git
INSTANA_GIT_REMOTE_BRANCH='<branch>'
INSTANA_GIT_REMOTE_USERNAME='<token>'
INSTANA_GIT_REMOTE_PASSWORD=''
 

Notez que le même principe de mot de passe vide et de jeton personnel que le nom d'utilisateur fonctionne également avec les autres moyens de configuration de l'agent hôte pour la gestion de la configuration basée sur Git. Pour une présentation des approches de configuration possibles, reportez-vous à la section Configuration .

Vous pouvez utiliser plusieurs méthodes pour contrôler les mises à jour de la version de l'agent hôte qui est déployé dans vos environnements de production. Si vous utilisez des agents statiques, vous devez mettre à jour l'agent hôte manuellement selon vos besoins. Si vous utilisez des agents dynamiques, vous pouvez configurer les mises à jour pour définir les intervalles de mise à jour, les versions épinglées, etc. Pour plus d'informations, consultez la section « Configuration des mises à jour des agents hôtes dynamiques ». Si aucune configuration n'est spécifiée, les mises à jour sont automatiquement appliquées à l'agent dynamique tous les jours. En outre, si vous avez besoin d'un contrôle plus strict sur les mises à jour de la version de l'agent hôte, vous pouvez utiliser une combinaison de l'épinglage dynamique de la version de l'agent avec une gestion de la configuration basée sur Git. Si vous disposez d'un environnement de test, vous pouvez tester les déploiements d'agents par rapport à un scénario de type production avant d'appliquer la mise à jour à la production.