使用 Git 管理代理配置
您可以使用 Git 来管理代理配置。
基于 Git 的配置管理功能是可选的。 如果已具有为主机代理程序提供基于文件的配置的其他方法,例如 Ansible、Terraform、Chef 或 Puppet,那么可能不需要基于 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 传输协议。 此外,还必须打开相应的端口。
从高于 V
1.2.12的代理程序引导程序开始,支持基本HTTP/HTTPS认证。 可以使用环境变量INSTANA_GIT_REMOTE_USERNAME和INSTANA_GIT_REMOTE_PASSWORD来设置访问凭证。
设置
自签名证书
如果您自己托管 Git 存储库,那么可以使用自签名证书。 为了让代理能够安全地连接到 Git 存储库,您必须将自签名证书导入 Java 的信任库中。 如需更多信息,请参阅 “自签名证书 ”。
使用.netrc 文件进行身份验证
可以通过使用 .netrc 文件提供密码或访问令牌来授权访问 Git 存储库。 .netrc 已被广泛使用,有关它的详细信息,可以访问 .netrc 联机帮助页。
您可以在运行 Instana 主机代理的用户主目录(例如)中配置该 .netrcroot 文件。 请参阅 github.com 存储库的以下样本 .netrc 文件:
machine github.com
login oauth2
password <access_token>
Git 仓库结构
在 Git 存储库中,您需要具有与 *instanaAgentDir*/etc中相同的目录结构。 例如,如果要从名为 configuration-mysql.yaml的 Git 文件获取数据,那么需要将此文件放在名为 instana 的 Git 目录 (即,文件 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,否则将忽略这些文件。
- 在
/etc/systemd/system/instana-agent.service.d/目录中创建扩展名为.conf的新文件,例如git-configuration-environments.conf。 - 将以下内容添加到该文件:
[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>`.
添加或更改混入文件后,请完成以下步骤:
- 通过运行 systemctl daemon-reload 命令来重新装入混入文件。
- 运行命令 systemctl restart instana-agent ,重启 Instana 主机代理。
.git ,并重启代理程序以使更改生效。使用环境变量
如果已设置以下环境变量,那么在启动主机代理程序时,它会检查 *instanaAgentDir*/etc/ 文件夹中是否存在本地 Git 存储库。 如果本地 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令牌。 这将确保在没有用户名的情况下正确配置基本认证。.git ,并重启代理程序以使更改生效。使用单行命令
请参阅 OneLiner 文档中的 , -b, -u 和 -p 选项 -g,这些选项分别对应于环境方法 INSTANA_GIT_REMOTE_REPOSITORY中的, INSTANA_GIT_REMOTE_BRANCH, INSTANA_GIT_REMOTE_USERNAME 和 INSTANA_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 =(可选) |
.git ,并重启代理程序以使更改生效。配有 Docker 图片
通过将 INSTANA_GIT_REMOTE_REPOSITORY、INSTANA_GIT_REMOTE_BRANCH、INSTANA_GIT_REMOTE_USERNAME 和 INSTANA_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 的配置管理可在 “代理管理”仪表板中的 “配置管理 ”部分进行设置。
.git ,例如 https://github.com/<your_account>/<your_repo>.git. 此外,要为访问 Git 仓库配置基本身份验证,您可以使用一个 .netrc 文件。 如需更多信息,请参阅 “使用.netrc 文件进行身份验证 ”。使用 API
可以使用 API 来初始化和配置基于 Git 的配置管理,如 Web REST API 文档的 Host Agent 部分中所述。
手动设置
手动设置包括初始化 *instanaAgentDir*/etc/ 文件夹中的 Git 存储库,以及添加名为 configuration 的 remote。
主机代理程序通过使用 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> 格式。
配置更新
主机代理程序从远程存储库访存配置更新:
- 启动或重新启动时。
- 通过在 上启动
reboot的 ,在代理管理仪表盘中进行操作。 - 通过在代理管理仪表盘上进行配置更改。
- 通过第
Host Agent节中所述的 Web API ,以及依赖于它的集成,例如 GitHub 更新代理操作。
基于 Git 的配置管理在本地 main 分支上运行,并使用已配置的远程跟踪分支的版本对其进行更新。 如果未配置跟踪分支,那么会向主机代理程序日志文件添加错误消息。 在未运行进一步配置更新的情况下,代理程序将使用当前配置来恢复其监视。
本地更改不是预期的,并且会在更新时丢弃。 基于 Git 的配置管理会影响未跟踪的文件,因此最初不需要将所有文件添加到存储库。
使用 Git 钩子触发更新
Git Hook 是可以放置在存储库的 .git/hooks 目录中的程序,它们在 Git 存储库的生命周期中的不同时间触发。 Git 提供许多不同的挂钩,并且 post-update 挂钩是最适合与基于 Git的主机代理程序配置管理集成的。
GitOps-Demo 仓库提供了一个示例性的 post-updateGit 钩子 ,该钩子会在仓库中的分支发生更新时触发主机代理的更新。
您将会看到在触发推送之后,脚本的预期输出已发送回 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 动态代理的更新。 通过这种方法,您可以通过设置环境变量来指定代理的版本。
对于 Operator 安装,您可以通过自定义资源设置环境变量;对于 Helm 图表安装,则可通过 values.yaml 文件进行设置。
Argo CD 会监控仓库中的指定分支,并将任何新变更自动应用到集群中。 通过这种方式配置更新,您可以精确控制更新的应用时机。 您可以将更新设置为在非高峰时段安装,而不是自动运行。 此外,此配置还允许您灵活指定所使用的代理程序的具体版本。
有关将代理版本锁定与 Argo CD 集成相结合的工作流的示例及实现指南,请参阅 instana/argocd-demo 仓库。
在此示例中,该仓库包含用于在生产集群中锁定版本的 分支 main ,以及用于在测试环境中锁定版本的 分支 test 。 因此, test 该分支已固定了一个较新的代理版本。 此配置的目的是在将代理版本部署到生产集群之前,先在测试集群中测试任何新版本。 有关如何使用 Mend Renovate 在新版本发布时自动针对 test 和 main 分支创建新拉取请求的信息,请参阅下一节。
控制主机代理的更新
有关如何实施将代理版本固定与基于 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