使用管理代理配置 Git

您可以通过使用来管理代理 Git 配置。

基于 Git 的配置管理功能是可选的。 如果已具有为主机代理程序提供基于文件的配置的其他方法,例如 AnsibleTerraformChefPuppet,那么可能不需要基于 Git 的配置管理。

注:

  • 主机代理程序引导程序版本 1.2.11 中提供了基于 Git 的配置管理功能。
  • 主机代理程序引导程序版本 1.2.12 添加了对 HTTP/HTTPS 基本认证的支持。

主机代理程序可以从远程 Git 存储库检索其配置。 主机代理程序配置 文档中讨论的所有配置都可通过 Git 进行管理。 某些主机代理程序配置要求主机代理程序在生效之前重新启动(本文档在相关部分中阐明了此需求)。

何时使用 Git 基于配置的管理

Instana主机代理程序随附默认配置,在多数生产场景中无需修改这些配置。

然而,诸如动态版本固定、主机代理后端配置 (尤其在使用多个后端时)、 密钥管理和主机标签等功能,若能借助集中式版本控制机制,便能实现一次配置即可自动推送至整个环境或场景中部署的主机代理,从而显著提升效率。

Instana 主机代理程序具有内置 Git 客户机,可从您操作的远程存储库访存配置。 当主机代理程序发现其 *instanaAgentDir*/etc/ 目录中的本地 Git 存储库时,它会自动激活其基于 Git 的配置管理功能,并在名为 configuration 的本地存储库中远程查找 Git。 在启动时,主机代理程序将根据远程存储库中提供的内容来更新其本地存储库。 有关配置更新过程的更多信息,请参阅配置更新部分。

您的 Git 存储库设置要求已在 "先决条件 "部分中概述。

先决条件

注: 主机代理程序配置可能包含敏感信息(例如凭证),并且应该防止未经授权的访问。

基于 Git 的配置管理不采用任何本地 Git 客户机或其他工具。 主机代理需要访问已配置的远程 Git 存储库。 此访问权限包括网络连接和 Git 身份验证:

  • 托管远程 Git 存储库的系统必须能够通过主机代理的网络连接访问。 系统需要根据传输 Git 协议提供访问权限。 当前,主机代理支持 HTTP 和 HTTPS 传输协议。 此外,还必须打开相应的端口。

  • 从代理引导程序的上述版本开始,支持基本 HTTP/HTTPS1.2.12 身份验证。 可以使用环境变量 INSTANA_GIT_REMOTE_USERNAMEINSTANA_GIT_REMOTE_PASSWORD 来设置访问凭证。

设置

自签名证书

如果你自己托管仓库 Git ,可以使用自签名证书。 要使代理安全地连接到存储 Git 库,必须将自签名证书导入Java信任存储库。 有关更多信息,请参阅自签名证书

使用.netrc文件进行身份验证

访问存储 Git 库的权限可通过使用文件 .netrc 提供密码或访问令牌来授权。 .netrc 已被广泛使用,有关它的详细信息,可以访问 .netrc 联机帮助页

您可以在用户主目录(例如)中 root配置文件 .netrc ,该目录是Instana主机代理的运行位置。 请参阅以下 .netrc 示例文件以了解 github.com 该存储库:

machine github.com
login oauth2
password <access_token>
注意: 请将 <access_token> 替换为实际的访问令牌。

Git 仓库结构

在存储 Git 库中,您需要保持与 *instanaAgentDir*/etc.目录相同的目录结构。 例如,若要获取名为 configuration-mysql.yaml的 Git 文件中的数据,该文件需放置在名为 的 Git 目录 instana 中(即文件 instana/configuration-mysql.yaml)。 否则,当文件从存储 Git 库获取时,该文件会被放置在服务器上的错误位置,导致 Instana 主机代理无法使用该文件。

下图展示了一个 Git 存储库的示例结构:

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

使用 systemd

使用 systemd 时,指定附加参数最简单的方法是使用替换文件。 要查看替换目录的路径,请运行以下命令:

systemctl status instana-agent

此目录中的文件必须具有文件 .conf扩展名,否则将被忽略。

  1. 在 目录 /etc/systemd/system/instana-agent.service.d/ 中创建一个新文件,文件扩展名为 .conf,例如 git-configuration-environments.conf
  2. 将以下内容添加到该文件:
    [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>`.
    
    

添加或更改替换文件后,请完成以下步骤:

  1. 通过运行 systemctl daemon-reload 命令重新加载 drop-in 文件。
  2. 通过运行命令 systemctl restart instana-agent 重启 Instana 主机代理。

使用环境变量

若已设置以下环境变量,则当主机代理启动时,它会检查本地 Git 存储库是否存在于指定 *instanaAgentDir*/etc/ 文件夹中。 如果本地 Git 存储库不存在,主机代理将创建一个与远程存储库相连的本地存储库。

如果 Instana 代理直接在主机上运行,则需要在主机上设置以下环境变量。 如果主机代理在容器化环境中运行,请在容器级别设置这些变量。

环境变量 描述
INSTANA_GIT_REMOTE_REPOSITORY 远程 Git 存储库 URL 的;例如, https://github.com/<your_account>/<your_repo>.git
INSTANA_GIT_REMOTE_BRANCH Instana 主机代理将跟踪的远程分支名称;例如: main
INSTANA_GIT_REMOTE_USERNAME 可选:用于基本身份验证的用户名或访问令牌(参见本表后的注释。)
INSTANA_GIT_REMOTE_PASSWORD 可选:基本身份验证中使用的密码(参见本表后的注释。)
注意: 若需使用访问令牌替代用户名和密码进行基本身份验证,请在参数中设置访问 INSTANA_GIT_REMOTE_USERNAME令牌。 这确保了基本身份验证在不使用用户名的情况下配置正确。

通过一行命令

请参阅文档 OneLiner 中的-u-b-g-p 选项 ,它们分别映射到环境方法的、 INSTANA_GIT_REMOTE_USERNAMEINSTANA_GIT_REMOTE_BRANCHINSTANA_GIT_REMOTE_REPOSITORYINSTANA_GIT_REMOTE_PASSWORD 环境变量。

下表展示了环境变量与单行命令参数之间的映射关系:

环境变量 单行命令的参数
INSTANA_GIT_REMOTE_REPOSITORY -g =(可选,如果设置了 -b,那么需要)
INSTANA_GIT_REMOTE_BRANCH -b =(可选,如果设置了 -g,那么需要)
INSTANA_GIT_REMOTE_USERNAME -u =(可选,如果设置了 -p,那么需要)
INSTANA_GIT_REMOTE_PASSWORD -p =(可选)

带 Docker 图片

通过将 INSTANA_GIT_REMOTE_REPOSITORYINSTANA_GIT_REMOTE_BRANCHINSTANA_GIT_REMOTE_USERNAMEINSTANA_GIT_REMOTE_PASSWORD 环境变量添加到 Docker 容器中,这些步骤与环境方法基本相同。

例如,以下代码示例提供了在容器中启动主机代理所需的参数,以及启用 Git 基于配置管理的必要 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

通过代理管理仪表板

基于 Git 的配置管理可在代理管理仪表板的配置管理部分进行设置。

重要提示: 您必须在 INSTANA_GIT_REMOTE_REPOSITORY 地址末尾添加 后缀 .git ,例如 https://github.com/<your_account>/<your_repo>.git。 此外,要为访问存储 Git 库配置基本身份验证,您可以使用一个 .netrc 文件。 有关更多信息,请参阅使用.netrc文件进行身份验证

手动设置

手动设置包括初始化 *instanaAgentDir*/etc/ 文件夹中的 Git 存储库,以及添加名为 configurationremote

主机代理程序通过使用 configuration 远程配置的跟踪分支来拉取本地 main 分支。 可以通过多种方式来设置 Git 存储库,并且您可以自由选择最适合设置的存储库。

例如,通过以下设置,可以从 configuration 远程的 main 分支获取主机代理程序拉取配置:

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

以下示例允许从 configuration 远程中的 my-configurations 分支中拉取配置:

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

Git URL 上的官方文档中描述了可能的 <git-repository-url> 格式。

配置更新

主机代理程序从远程存储库访存配置更新:

  1. 启动或重新启动时。
  2. 通过代理管理仪表板启动 reboot 的。
  3. 通过在代理管理仪表板上执行配置更改。
  4. 通过本节 Host Agent 所述的 Web API 以及依赖它的集成(如更新 GitHub 代理操作 )。

基于 Git 的配置管理在本地 main 分支上运行,并使用已配置的远程跟踪分支的版本对其进行更新。 如果未配置跟踪分支,那么会向主机代理程序日志文件添加错误消息。 在未运行进一步配置更新的情况下,代理程序将使用当前配置来恢复其监视。

本地更改不是预期的,并且会在更新时丢弃。 基于 Git 的配置管理会影响未跟踪的文件,因此最初不需要将所有文件添加到存储库。

通过 Git 钩子触发更新

Git Hook 是可以放置在存储库的 .git/hooks 目录中的程序,它们在 Git 存储库的生命周期中的不同时间触发。 Git 提供许多不同的挂钩,并且 post-update 挂钩是最适合与基于 Git的主机代理程序配置管理集成的。

GitOps-Demo 存储库提供了一个示例 Gitpost-update 钩子 ,当存储库中的分支被更新时,该钩子会触发主机代理的更新。

您将会看到在触发推送之后,脚本的预期输出已发送回 Git 客户机:

$ 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

通过 GitHub 更新操作触发更新

Instana GitHub 的此操作 GitOps 允许您通过 Instana 的 Web API 直接触发主机代理的远程操作。

GitOps - 演示存储库显示了如何在 GitHub 上设置存储库以管理主机代理程序配置,以及如何使用针对 GitOps 的 Instana GitHub 操作来自动触发更新。

示例

私有 GitHub 仓库

GitHub 通过使用令牌来支持 HTTPS 认证,这可以由主机代理程序使用,如本部分中所述。

要使用 GitHub 存储库,必须先创建个人访问令牌。 具体操作方法详见 《创建个人访问令牌 》文档 GitHub 页面。 该令牌仅需要读许可权即可访问存储库。

GitHub 期望令牌以 HTTPS 基本认证用户名形式提供,密码为空。 因此,通过设置以下环境变量集,可以将主机代理程序配置为对 GitHub 存储库使用 HTTPS 基本认证:

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=''

请注意,与用户名相同的空密码和个人令牌原则也适用于配置主机代理程序,以进行基于 Git 的配置管理的其他方法。 有关可能采用的配置方法的概述,请参阅设置部分。

通过以下方式控制代理更新: Git

您可以使用多种方法来控制部署在生产环境中的主机代理的版本更新。 若使用静态代理,则需根据需要手动更新主机代理。 若使用动态代理,可配置更新设置以设定更新间隔、固定版本等参数。 有关更多信息,请参阅 《动态主机代理的更新配置》。 如果未指定任何配置,系统将每天自动对动态代理进行更新。 此外,若需对主机代理的版本更新实施更严格的管控,可结合动态代理版本固定与 Git 基于配置的管理方案。 若您拥有测试环境,可在将更新部署至生产环境前,针对类似生产环境的场景对代理部署进行测试。

控制 Kubernetes 代理更新

您可以使用Argo CD来控制和管理动态 Kubernetes 代理的更新。 通过这种方法,您可以通过设置环境变量来指定代理的版本。

对于操作员安装,可通过自定义资源设置环境变量;对于 Helm 图表安装,则需 values.yaml 通过配置文件进行设置。

Argo CD 监控存储库的指定分支,并将任何新变更自动应用到集群中。 通过这种方式配置更新,您可以精确控制更新的实施时机。 您可以安排在非高峰时段安装更新,而不是自动运行它们。 此外,此配置还为您提供指定确切使用的代理版本的灵活性。

有关如何实现将代理版本固定与Argo CD集成相结合的工作流的示例和说明,请参阅instana/argocd-demo 存储库。

在此示例中,仓库包含用于生产集群版本固定的分支以及用于测试环境 main 版本固定的分支 test 。 因此, test 该分支固定了更新的代理版本。 此配置旨在测试新版本在测试集群中的运行情况,然后再将代理版本推广到生产集群。 有关如何使用 Mend Renovate 在新版本可用时自动创建针对 testmain 分支的新拉取请求的信息,请参阅下一节。

控制主机代理更新

有关如何实现将代理版本固定与 Git 基于配置管理的流程的示例,请参阅 instana/gitops-demo 存储库。

此示例存储库使用 GitHub 作为存储库托管服务,采用 Mend Renovate 实现依赖项更新自动化,并通过 GitHub Actions 向 Instana 后端发送请求。 您可以将所有这些服务替换为您选择的服务。 请确保满足以下要求才能实施基于 Git 的更新流程:

  • Git 作为源代码仓库格式

  • 在配置变更时,通过自动化向Instana后端发送 HTTP 请求

    您可在此使用任意自动化方案。 然而,请确保中的版本 instana/com.instana.agent.bootstrap.AgentBootstrap.cfg 已更新,并且为不同环境使用不同的分支。

该仓库包含 分支 main ,用于追踪代理生产部署的当前状态,以及 test 分支,代表代理测试环境。

Mend Renovate 配置为监视 instana/agent-updates 仓库中的新标签,并将这些标签与配置文件 instana/com.instana.agent.bootstrap.AgentBootstrap.cfg 中的版本进行比较。 当在仓库 instana/agent-updates 中检测到新标签时,Mend Renovate会基于分支 test 创建一个分支,并发起拉取请求 GitHub ,将更改添加到分支 test 上的配置文件中。 您可以使用Renovate提供的多种选项,例如将更新计划设置为每周仅执行一次 ,或为拉取请求分配特定 GitHub 处理者以进行手动审批。 当拉取请求合并到分支 test 时, GitHub Actions会运行一个工作流来通知已配置的Instana后端。 随后,Instana后端向所有符合测试环境特定区域和标签约束条件的代理发送重启命令。

此外,第二个工作流会将当前 instana/com.instana.agent.bootstrap.AgentBootstrap.cfg 文件从分支 test 复制到新功能分支,并针对该 main 分支发起拉取请求,从而确保代理版本从测试环境顺利迁移至生产环境。

在生产环境中验证更改后,您可以将更改合并到 main 主分支。 合并时, GitHub Actions会运行一个工作流,向Instana后端发送更新请求,该请求涉及所有连接到生产环境的代理。

请参阅以下样本配置:

# This field specifies which version set of components should be used by the agent;
# its value must be a valid tag from https://github.com/instana/agent-updates/tags
# version = <tag>
# renovate: datasource=github-tags depName=instana/agent-updates versioning=loose
version = 2024.09.02.0634

# This field controls which set of components is used by the agent at runtime.
productName = ${env:INSTANA_PRODUCT_NAME}

origin = package dynamic
注意: 每当 Instana 后端收到代理配置更新时,它都会重启所有匹配的代理。 根据代理数量及其在硬件上的分布情况,此次重启可能会导致资源消耗出现短暂激增。 如果负载必须延迟处理,您可以扩展示例,添加额外的分支来表示待更新的代理批次。 您还可以调整仓库自动化设置,使其仅等待一次手动审批,并在预设延迟后自动将更新推送到其他分支,从而避免增加手动管理的工作量。