Git を使用したエージェント設定の管理
Git を使用して、エージェントの設定を管理できます。
Gitベースの構成管理機能はオプションです。 ホスト・エージェントのファイル・ベース構成を配信する他の手段 ( Ansible、Terraform、 Chef、または Puppet)の場合は、 Gitベースの構成管理は必要ありません。
注:
- Gitベースの構成管理機能は、ホスト・エージェントのブートストラップ・バージョン
1.2.11から使用できます。 - ホスト・エージェント・ブートストラップ・バージョン
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 のトランスポートプロトコルをサポートしています。 さらに、適切なポートが開いている必要があります。
バージョン
1.2.12より上のエージェント・ブートストラップからは、基本HTTP/HTTPS認証がサポートされます。 環境変数のINSTANA_GIT_REMOTE_USERNAMEとINSTANA_GIT_REMOTE_PASSWORDを使用して、アクセス資格情報を設定できます。
セットアップ
自己署名証明書
Git リポジトリーを自分でホストする場合は、自己署名証明書を使用できます。 エージェントが Git リポジトリに安全に接続するには、自己署名証明書を Java のトラストストアにインポートする必要があります。 詳細については、 「自己署名証明書」 を参照してください。
.netrc ファイルを使用した認証
Git リポジトリーへのアクセスは、 .netrc ファイルを使用してパスワードまたはアクセス・トークンを指定することで許可できます。 .netrc は広く使用されており、その詳細については、 .netrc マニュアル・ページを参照してください。
Instana ホストエージェントが実行されているユーザーのホームディレクトリ(例: root)にあるファイル .netrc を設定できます。 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/ を再起動して変更を反映させることもできます。環境変数を使用して
以下の環境変数を設定した場合、ホスト・エージェントの開始時に、 *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 フォルダを削除し、エージェント *instanaAgentDir*/etc/ を再起動して変更を反映させることもできます。ワンライナーコマンドで
ドキュメント OneLiner 内の -g、 -b、 -u および -p オプション を参照してください。これらは、 環境変数 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 フォルダを削除し、エージェント *instanaAgentDir*/etc/ を再起動して変更を反映させることもできます。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 ベースの構成管理は、エージェント管理ダッシュボードの 「構成管理 」セクションで設定できます。
https://github.com/<your_account>/<your_repo>.gitのような .git サフィックスを追加する必要があります。 さらに、 Git リポジトリへのアクセス用に基本認証を設定するには、ファイル .netrc を使用できます。 詳細については、 「.netrc ファイルを使用した認証」 を参照してください。API を使用する場合
Gitベースの構成管理は、 Web REST API 資料の Host Agent セクションで説明されているように、API を使用して初期化および構成できます。
手動セットアップ
手動セットアップでは、 *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-repository-url> 形式については、 Git の URLの公式資料で説明されています。
構成の更新
ホスト・エージェントは、リモート・リポジトリーから構成の更新を取り出します。
- 始動時または再始動時。
- エージェント管理ダッシュボードから
reboot開始された - エージェント管理ダッシュボードでの設定変更を通じて。
- 前述
Host Agentのセクションで説明した Web サイト API および、それに依存する「 GitHub Update Agent 」アクションなどの連携機能を通じて。
Gitベースの構成管理は、ローカル main ブランチ上で動作し、構成済みのリモート・トラッキング・ブランチのバージョンで更新します。 トラッキング・ブランチが構成されていない場合は、エラー・メッセージがホスト・エージェント・ログ・ファイルに追加されます。 これ以上の構成更新は実行されませんが、エージェントは現在の構成を使用してモニターを再開します。
ローカル変更は予期されていないため、更新時に破棄されます。 トラッキング解除されたファイルは Gitベースの構成管理によって影響を受けるため、最初はすべてのファイルをリポジトリーに追加する必要はありません。
Git のフックを使用して更新をトリガーする
Git フックは、リポジトリーの .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 」の更新アクションを使用して更新を実行する
GitOps 用の Instana GitHub アクションを使用すると、 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 [file]`ファイルを使用して、環境変数を設定できます。
Argo CDはリポジトリの指定されたブランチを監視し、新しい変更があれば自動的にクラスターに適用します。 この方法で更新を設定することで、更新が適用されるタイミングを細かく制御できるようになります。 更新プログラムを自動的に実行するのではなく、利用が集中しない時間帯にインストールするようにスケジュールを設定できます。 さらに、この設定により、使用しているエージェントのバージョンを正確に指定する柔軟性が得られます。
エージェントのバージョン固定とArgo CDの統合を組み合わせたワークフローの実装例と手順については、 instana/argocd-demo リポジトリを参照してください。
この例では、リポジトリには本番クラスタでのバージョン固定用の ブランチ main と、テスト環境でのバージョン固定用の ブランチ test が含まれています。 したがって、 test このブランチには新しいエージェントのバージョンが固定されています。 この構成の目的は、エージェントのバージョンを本番クラスタに展開する前に、テストクラスタで新しいバージョンをテストすることです。 新バージョンが利用可能になった際に、Mend Renovate を使用して および main ブランチ test に対して新しいプルリクエストを自動的に作成する方法については、次のセクションを参照してください。
ホストエージェントの更新を制御する
エージェントのバージョン固定と Git ベースの設定管理を組み合わせたワークフローの実装例については、instana/gitops-demo リポジトリを参照してください。
このサンプルリポジトリでは、リポジトリホスティングサービスとして GitHub、依存関係の更新自動化にはMend Renovate、そして Instana バックエンドへのリクエスト送信には GitHub Actionsを使用しています。 これらのサービスはすべて、お好みのサービスに置き換えることができます。 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 ブランチの設定ファイルに変更を追加します。 例えば、更新を週に一度だけスケジュールするとか、プルリクエストに特定のGitHubハンドルを割り当てて手動で承認するとか、Renovateが提供する様々なオプションを使うことができます。 プルリクエストが GitHub ブランチ test にマージされると、 Actionsはワークフローを実行し、設定された Instana バックエンドに通知を送ります。 その後、 Instana のバックエンドは、テスト環境の特定のゾーンおよびタグの条件に一致するすべてのエージェントに対して、エージェントの再起動コマンドを送信します。
さらに、2番目のワークフローは、現在のinstana/com.instana.agent.bootstrap.AgentBootstrap.cfgファイルをtestブランチから新しいfeatureブランチにコピーし、mainブランチに対してプルリクエストをオープンします。
本番環境のような環境で変更が検証されたら、main ブランチに変更をマージします。 マージを行うと、 GitHub Actions はワークフローを実行し、本番環境に接続されているすべてのエージェントに対して、 Instana Backend へ更新リクエストを送信します。
以下のサンプル構成を参照してください。
# 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