🏢

Splunk AppDynamics On-Premises Virtual Applianceをインストールしてみた（前編）

に公開
Splunk
オンプレミス
Observability
APM
appdynamics
tech

はじめに

本記事では、Splunk AppDynamics On-Premises Virtual Appliance（以下AppD VA）を筆者の環境へ実際に新規インストールしてみた際の記録を共有します。インストールに当たっては、その製品マニュアルを参考にしています。

最初に AppD VA とは何かと、前提について説明します。その後、AppD VA のデプロイ、AppDynamics 基本サービスの起動、簡単な動作確認について書きますが、本記事では前編として「AppD VA のデプロイまで」を範囲とします。AppD VA の起動と動作確認は後編とします。

AppD VAとは

AppD VAは、Splunkオブザーバビリティ製品群のうち、Splunk AppDynamicsオンプレミス版オブザーバビリティ・バックエンドの一種です。AppD VAリリース以前からSplunk AppDynamicsにはオンプレミス版がありますが、AppD VAは従来型オンプレミス版の基本機能に加え、次のような機能・特徴を提供します[1][2]。

  1. AIを活用した異常検出、根本原因分析
  2. アプリケーションセキュリティ監視
  3. Splunk Enterpriseとのログ連携
  4. OpenTelemetryトレースの取り込みと表示
  5. 比較的容易なインストールとアップグレード

AppD VAについてのより詳しい説明、含まれるコンポーネント、アーキテクチャ図などについては次のリンク先に記載がありますので、参考にしてください。
https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/about-splunk-appdynamics-on-premises-virtual-appliance

前提

本記事では次のことを前提とします。

  • 本記事の対象読者はSplunk AppDynamicsオンプレミス版の導入を検討しているインフラエンジニア・SRE・アプリケーション開発者
  • AppD VAのバージョンとしては、本執筆時点の最新版である25.7.0を使用
  • このバージョンのインストーラー（正確にはディスクイメージ）と、AppDynamicsオンプレミス版トライアルライセンスを入手できると仮定
    • このトライアルライセンスでは、合計で48 vCPUs以上のサーバー監視ができると仮定
  • AppD VAのプラットフォームとしてサポートされている環境のうち、今回は筆者としてすぐ利用できるAWSをプラットフォームとして使う[3]
    • 対象読者は少なくともAWS Certified Cloud Practitionerレベル以上の知識を持っている
    • AppD VAをデプロイする際にはAWS CLIを使用する
    • AWS CLIを使う環境として、AppD VAインストール先のEC2インスタンスとは別のEC2インスタンス（以下、準備用VM）が用意されていることとする
    • この準備用VMのストレージとしては、AppD VAディスクイメージを一時的に置いておけるほどの空き容量（例: 25 GB 以上）が必要
    • この準備用VMは、AppD VAインストール先のEC2インスタンスとはネットワーク的に近い場所にある（例えば同じリージョンにある）と仮定
  • AppD VAのプロファイル（デプロイメントの規模）としては、サイジング要件に記載のSmallを使う
  • 本記事ではセキュリティあるいは記述量削減のため、設定ファイルやコマンド入出力における一部の情報を「■」あるいは「（中略）」へ置換して記載する

AppD VAのデプロイ

AppD VAをAWS上のEC2インスタンスへデプロイする方法は、次のリンク先に記載があります。
https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/deploy-splunk-appdynamics-on-premises-virtual-appliance/amazon-web-services-aws

端的にはAWS環境を準備し、スクリプトを実行させることによりEC2インスタンスなどのAWSリソースを作成し、構成を確認するという流れになります。筆者の環境では最終的に次のような構成でAppD VA用のEC2インスタンス3個（VM1〜3）がブラウザーからのトラフィックをALB経由で受けられることを目指します。

本章ではこの図のうち、VM1〜3を起動することまでを行います。

デプロイ用スクリプトの用意と設定

まずは準備用VMへログインした後、適当な作業用ディレクトリを作成し、そのディレクトリ以下で作業することにします（以降のシェル操作はすべて準備用 VM 上で実行します）。

[ec2-user@ip-10-0-133-213 ~]$ mkdir work
[ec2-user@ip-10-0-133-213 ~]$ cd !$
cd work

VA AWS デプロイ参照スクリプトの GitHub サイトからスクリプト一式をダウンロードします。

[ec2-user@ip-10-0-133-213 work]$ git clone https://github.com/Appdynamics/appd-virtual-appliance.git
Cloning into 'appd-virtual-appliance'...
（中略）
Resolving deltas: 100% (13/13), done.

AWS 用スクリプト一式のあるディレクトリへ移動し、ファイル一覧を確認します。

[ec2-user@ip-10-0-133-213 work]$ cd appd-virtual-appliance/deploy/aws/
$ ls -l
total 48
-rw-r--r--. 1 ec2-user ec2-user  290 Oct 17 13:36 01-aws-create-profile.sh
-rw-r--r--. 1 ec2-user ec2-user 9413 Oct 17 13:36 02-aws-add-vpc.sh
-rw-r--r--. 1 ec2-user ec2-user  558 Oct 17 13:36 03-aws-create-image-bucket.sh
-rw-r--r--. 1 ec2-user ec2-user  853 Oct 17 13:36 04-aws-import-iam-role.sh
-rw-r--r--. 1 ec2-user ec2-user  251 Oct 17 13:36 05-aws-upload-image.sh
-rwxr-xr-x. 1 ec2-user ec2-user 1309 Oct 17 13:36 06-aws-import-snapshot.sh
-rwxr-xr-x. 1 ec2-user ec2-user  918 Oct 17 13:36 07-aws-register-snapshot.sh
-rwxr-xr-x. 1 ec2-user ec2-user 2519 Oct 17 13:36 08-aws-create-vms.sh
-rw-r--r--. 1 ec2-user ec2-user  550 Oct 17 13:36 aws-delete-vms.sh
-rw-r--r--. 1 ec2-user ec2-user  662 Oct 17 13:36 config.cfg
drwxr-xr-x. 2 ec2-user ec2-user  128 Oct 17 13:36 upgrade

*.shファイルについては実行権限を追加します。

$ chmod a+x *.sh
$ ls -l
total 48
-rwxr-xr-x. 1 ec2-user ec2-user  290 Oct 17 13:36 01-aws-create-profile.sh
-rwxr-xr-x. 1 ec2-user ec2-user 9413 Oct 17 13:36 02-aws-add-vpc.sh
-rwxr-xr-x. 1 ec2-user ec2-user  558 Oct 17 13:36 03-aws-create-image-bucket.sh
-rwxr-xr-x. 1 ec2-user ec2-user  853 Oct 17 13:36 04-aws-import-iam-role.sh
-rwxr-xr-x. 1 ec2-user ec2-user  251 Oct 17 13:36 05-aws-upload-image.sh
-rwxr-xr-x. 1 ec2-user ec2-user 1309 Oct 17 13:36 06-aws-import-snapshot.sh
-rwxr-xr-x. 1 ec2-user ec2-user  918 Oct 17 13:36 07-aws-register-snapshot.sh
-rwxr-xr-x. 1 ec2-user ec2-user 2519 Oct 17 13:36 08-aws-create-vms.sh
-rwxr-xr-x. 1 ec2-user ec2-user  550 Oct 17 13:36 aws-delete-vms.sh
-rw-r--r--. 1 ec2-user ec2-user  662 Oct 17 13:36 config.cfg
drwxr-xr-x. 2 ec2-user ec2-user  128 Oct 17 13:36 upgrade

次に初期設定を確認するため、config.cfgファイルの内容を見てみます。

config.cfg
# Resource Tags
TAGS="{Key=DeploymentEnvironment,Value=Sandbox},{Key=ResourceOwner,Value=tbd@xyz.com}"

# Deployment configs
AWS_PROFILE=va-deployment
AWS_REGION=us-west-2
VPC_NAME=appd-va-vpc-1
SUBNET_NAME=appd-va-subnet-1
IGW_NAME=appd-va-inetgw-1
RT_NAME=appd-va-rt-1
SG_NAME=appd-va-sg-1
VPC_CIDR="10.0.0.0/16"
SUBNET_CIDR="10.0.0.0/24"
IMAGE_IMPORT_BUCKET=appd-va-bucket
APPD_RAW_IMAGE="appd-va-24.7.0-819.ami"
APPD_IMAGE_NAME="appd-va-24.7.0-ec2-disk1"

# VM configurations
VM_TYPE=m5a.4xlarge
VM_NAME_1=appdva-vm-1
VM_NAME_2=appdva-vm-2
VM_NAME_3=appdva-vm-3
VM_OS_DISK=200
VM_DATA_DISK=500

# IPs to permit
VPN_IPS=(
   10.1.11.10/32
   10.1.12.10/32
)

このファイル内の環境変数 1 つ 1 つについて「VA AWS デプロイ参照スクリプトの GitHub サイト」に詳しい説明はありません。しかしながら端的にはこのファイル内で次のことを設定します（不明点は *.sh の参照が早道です）。

  • AWS CLIのため、どのプロファイル使うか
  • どのAWS環境へのデプロイを前提とするか
  • どのリソースを必要に応じて作るか
  • どのディスクイメージ（AMI ファイル）を S3 へアップロードするか

ディスクイメージをS3へアップロードする目的は、S3→EBSスナップショット→AMIという経路でEC2インスタンスのストレージを用意するためです。デプロイの各ステップ詳細については、「VA AWS デプロイ参照スクリプトの GitHub サイト」の説明を見るか、あるいは直接*.shファイルの内容を参照するのが良いです。これらの*.shファイル内でconfig.cfgファイルが最初に読み込まれ、各環境変数が使われます。

config.cfg ファイルでは APPD_RAW_IMAGE 環境変数の値としてディスクイメージファイル名を設定します。そのため、Splunk AppDynamics のダウンロードサイトから AppD VA における AMI タイプのディスクイメージをダウンロードします（約 21 GB）。ダウンロード先は config.cfg と同じディレクトリにします。

$ curl -L -O -H "Authorization: Bearer ■■■（中略）■■■" "https://download.appdynamics.com/download/prox/download-file/appd-va/25.7.0.2255/appd_va_25.7.0.2255.ami"

このcurlコマンドのパラメータには、Splunk AppDynamics のダウンロードサイトの画面内からコピーした値をそのまま使います。

筆者のAWS環境向けにはconfig.cfgファイルを次の内容へ変更しましたが、あなたがAppD VAをデプロイする場合には、あなたの環境や要件に応じて各環境変数の値を書き換えてください。

config.cfg
# Resource Tags
TAGS="{Key=■■■■■■■■_■■■■_■■■■■■■■■■■■■■,Value=private},{Key=■■■■■■■■_■■■■■■■■■■■_■■■■,Value=non-prd}"

# Deployment configs
AWS_PROFILE=default
AWS_REGION=ap-northeast-1
VPC_NAME=akihiko-vpc
SUBNET_NAME=akihiko-subnet-private1-ap-northeast-1a
IGW_NAME=akihiko-igw
RT_NAME=akihiko-rtb-private1-ap-northeast-1a
SG_NAME=akihiko-sg-ec2-all-traffic-from-alb-allowed
VPC_CIDR="10.0.0.0/16"
SUBNET_CIDR="10.0.128.0/20"
IMAGE_IMPORT_BUCKET=akihiko-■■■■■■■■■■■■■■
APPD_RAW_IMAGE="appd_va_25.7.0.2255.ami"
APPD_IMAGE_NAME="akihiko-appd-va-25.7.0-ec2-disk1"

# VM configurations
VM_TYPE=m5a.4xlarge
VM_NAME_1=akihiko-vm31-appdva
VM_NAME_2=akihiko-vm32-appdva
VM_NAME_3=akihiko-vm33-appdva
VM_OS_DISK=200
VM_DATA_DISK=500

# IPs to permit 
VPN_IPS=(
   10.0.0.0/20
   10.0.16.0/24
)

各値についての補足事項は次の通りです。

  • TAGS: VPC、サブネット、インターネットゲートウェイ、ルートテーブル、セキュリティグループ、EC2インスタンスを作成する場合に付与されるタグ。本執筆時点のスクリプトだとS3バケット作成時には使われないため、もし必要な場合は別途付与する
  • SUBNET_NAME: AppD VAをデプロイするEC2インスタンスのサブネット名。筆者環境では後でEC2インスタンスの前段にALBを配置する事を前提するため、プライベートサブネット名を指定している
  • RT_NAME: VPC内で使用するルートテーブル名。SUBNET_NAMEのサブネットに関連付けられる
  • SG_NAME: EC2インスタンスに関連付けたいセキュリティグループにおけるNameタグの値。もしそのセキュリティグループにNameタグが付いていない場合には、事前に付けておくことが必要。筆者用の環境ではALBから転送されるHTTPトラフィックを許可しているセキュリティグループとする
  • APPD_RAW_IMAGE: 事前にcurlにてダウンロードした、AppD VAのAMI用ディスクイメージファイル名
  • VPN_IPS: 02-aws-add-vpc.shを呼び出す場合にはセキュリティグループの設定として使用されるが、筆者用の環境では同スクリプトを呼び出さないため、デフォルトのままとする

デプロイ用スクリプトの実行

config.cfgファイルの内容をあなたの環境に合うように書き換えたら、次はデプロイ用スクリプトの実行をすることにします。デプロイ用スクリプトは、「VA AWS デプロイ参照スクリプトの GitHub サイト」に記載されているよう、ファイル名が0 + 数字で始まる合計8個のシェルスクリプトです。このうち01から03までのスクリプトは、既にリソースがある場合にはスキップして良いと同サイトに記載があります。また筆者用の環境ではAWSプロファイル・VPCは既にあるものを再利用するため、03-aws-create-image-bucket.shから実行するようにします。

$ ./03-aws-create-image-bucket.sh

An error occurred (404) when calling the HeadBucket operation: Not Found
Creating S3 bucket to upload image ...
{
    "Location": "http://akihiko-■■■■■■■■■■■■■■.s3.amazonaws.com/"
}
Created bucket
2025-10-19 17:10:52 akihiko-■■■■■■■■■■■■■■

Created bucket の下に作成対象のバケット名が出力されれば OK です。

続いて04-aws-import-iam-role.shのスクリプトを実行したいところです。しかしながら本執筆時点におけるこのスクリプトの中を見てみると、このスクリプトの事前条件としてvmimportという名前のIAMロールがすでに存在することを前提としています。まだ無い場合には作成しましょう。

$ cat > vmimport-role-trust-policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "vmie.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "vmimport" } }
  }]
}
EOF

$ aws iam create-role \
  --role-name vmimport \
  --assume-role-policy-document file://vmimport-role-trust-policy.json
{
    "Role": {
        （中略）
    }
}

コマンド実行後、作成したロールの内容が JSON 形式で出力されれば OK です。追って04-aws-import-iam-role.shスクリプトを実行しましょう。

$ ./04-aws-import-iam-role.sh

エラーが何も出力されなければ OK です。

続けて05-aws-upload-image.sh、06-aws-import-snapshot.sh、07-aws-register-snapshot.shのスクリプトもそれぞれ実行します。

$ ./05-aws-upload-image.sh
Uploading the image ...
upload: ./appd_va_25.7.0.2255.ami to s3://akihiko-■■■■■■■■■■■■■■/appd_va_25.7.0.2255.ami
2025-10-19 17:52:50 22548578304 appd_va_25.7.0.2255.ami

このスクリプトでは約 21 GB という比較的大きなファイルを S3 バケットへアップロードします。そのため、このスクリプトを実行する準備用 VM が AppD VA インストール先の EC2 インスタンスとはネットワーク的に近い場所にあることが重要です。アップロードした AMI ファイル名が出力されれば OK です。

$ ./06-aws-import-snapshot.sh
Import Task ID: import-snap-ba671e78e2a4f8f5t
Waiting for import task to proceed...
{
    "ImportSnapshotTasks": [
        {
            "ImportTaskId": "import-snap-ba671e78e2a4f8f5t",
            "SnapshotTaskDetail": {
                "DiskImageSize": 22548578304.0,
                "Format": "RAW",
                "Progress": "19",
                "SnapshotId": "",
                "Status": "active",
                "StatusMessage": "downloading/converting",
                "Url": "s3://akihiko-■■■■■■■■■■■■■■/appd_va_25.7.0.2255.ami",
                "UserBucket": {}
            },
            "Tags": []
        }
    ]
}
Current Status: active
（中略）
Current Status: active
Current Status: completed
Snapshot import completed.
Snapshot ID: snap-0807762d937625192

Snapshot import completed. および、その下に Snapshot ID が出力されれば OK です。

$ ./07-aws-register-snapshot.sh
Using snapshot ...
{
    "Snapshots": [
        {
            "StorageTier": "standard",
            "TransferType": "standard",
            "CompletionTime": "2025-10-19T09:20:18.657000+00:00",
            "FullSnapshotSizeInBytes": 22548578304,
            "SnapshotId": "snap-0807762d937625192",
            "VolumeId": "vol-ffffffff",
            "State": "completed",
            "StartTime": "2025-10-19T09:12:05.106000+00:00",
            "Progress": "100%",
            "OwnerId": "■",
            "Description": "Created by AWS-VMImport service for import-snap-ba671e78e2a4f8f5t",
            "VolumeSize": 21,
            "Encrypted": true,
            "KmsKeyId": "arn:aws:kms:ap-northeast-1:■■■■■■■■■■■■:key/■■■■■■■■-■■■■-■■■■-■■■■-■■■■■■■■■■■■"
        }
    ]
}
AMI ID: ami-02a24d6eff05f32c5

エラーが何も出力されず、かつ使用されたスナップショットのメタデータが JSON 形式で出力されれば OK です。

最後のスクリプトである08-aws-create-vms.shファイルの内容に関して、筆者環境向けには次の変更をします。

  • EC2にElastic IPは不要なため、その割り当て処理を削除
  • 07-aws-register-snapshot.sh実行時の出力に"Encrypted": trueおよび"KmsKeyId": "（中略）"の行が含まれていた。そのため、それらのパラメータをaws ec2 run-instancesコマンドの--block-device-mappingsパラメータの値に追加

その変更に関するdiffは次の通りです。

08-aws-create-vms.sh
@@ -26,6 +26,9 @@ if [ -z "$sgID" ]; then
     exit 1
 fi

+# Use the same KMS key as the imported snapshot
+KMS_KEY_ID="arn:aws:kms:ap-northeast-1:■■■■■■■■■■■■:key/■■■■■■■■-■■■■-■■■■-■■■■-■■■■■■■■■■■■"
+
 echo "Creating the VMs ..."
 for VM_ID in 1 2 3; do
     VM_NAME_VAR="VM_NAME_${VM_ID}"
@@ -48,24 +51,14 @@ EOF
                           --groups "$sgID" \
                           --query 'NetworkInterface.NetworkInterfaceId' --output text)

-    # Allocate an Elastic IP
-    allocation_id=$(aws --profile ${AWS_PROFILE} ec2 allocate-address \
-                        --domain vpc \
-                        --query 'AllocationId' --output text)
-
-    # Associate the Elastic IP with the ENI
-    aws ec2 --profile ${AWS_PROFILE} associate-address \
-            --allocation-id ${allocation_id} \
-            --network-interface-id ${network_intf_id}
-
     # requires Nitro instance types
     aws --profile ${AWS_PROFILE} ec2 run-instances \
         --image-id "$AMI_ID" \
        --instance-type "${VM_TYPE}" \
         --network-interfaces "[{\"NetworkInterfaceId\":\"${network_intf_id}\",\"DeviceIndex\":0}]" \
         --block-device-mappings \
-        "DeviceName=/dev/sda1,Ebs={VolumeSize=${VM_OS_DISK},VolumeType=gp3}" \
-        "DeviceName=/dev/sdb,Ebs={VolumeSize=${VM_DATA_DISK},VolumeType=gp3,DeleteOnTermination=false}" \
+        "DeviceName=/dev/sda1,Ebs={VolumeSize=${VM_OS_DISK},VolumeType=gp3,Encrypted=true,KmsKeyId=${KMS_KEY_ID}}" \
+        "DeviceName=/dev/sdb,Ebs={VolumeSize=${VM_DATA_DISK},VolumeType=gp3,DeleteOnTermination=false,Encrypted=true,KmsKeyId=${KMS_KEY_ID}}" \
        --user-data file://user-data.ec2 \
         --no-cli-pager \
         --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=${VM_NAME}},${TAGS}]"

この diff 内容は環境によりますので、必要に応じて調整してください。

筆者環境ではこのdiff内容を08-aws-create-vms.sh.patchというファイルとして保存します。そして次のようにパッチ適用および08-aws-create-vms.shファイルの実行をします。

$ patch 08-aws-create-vms.sh 08-aws-create-vms.sh.patch
patching file 08-aws-create-vms.sh
$ ./08-aws-create-vms.sh
Creating the VMs ...
{
    "ReservationId": "r-0e3c8f62bc3a9926c",
    "OwnerId": "■■■■■■■■■■■■",
    "Groups": [],
    "Instances": [
        {
        （中略）
            "InstanceId": "i-0be03d8706fd0cdfb",
        （中略）
        }
    ]
}
{
    "ReservationId": "r-0b34428ce8b557c17",
    "OwnerId": "■■■■■■■■■■■■",
    "Groups": [],
    "Instances": [
        {
        （中略）
            "InstanceId": "i-08b14f183b3db77ff",
        （中略）
        }
    ]
}
{
    "ReservationId": "r-04b87b1140cd372f8",
    "OwnerId": "■■■■■■■■■■■■",
    "Groups": [],
    "Instances": [
        {
        （中略）
            "InstanceId": "i-0d737e7d1fc6156b1",
        （中略）
        }
    ]
}

しばらく待ち、これら3台の VM（VM_NAME_1からVM_NAME_3のEC2 インスタンス）の起動完了をAWS マネジメントコンソールまたは AWS CLI で確認します。この確認方法について本記事での記載は省略します。

デプロイ後の構成を確認

VM 3台の起動後、Bootstrap the AWS Instanceに記載のユーザー名および初期パスワードを使い、SSH で任意の VM（例: VM1）へログインします。どこから SSH を実行するかは環境依存のためここでの記載は省略しますが、筆者環境では VM1〜3 の前段に NLB を置き、NLB 経由でログインするようにします。

ログイン後、初期パスワードを変更しましょう。

Warning: Permanently added '[■■■■■■■■■.■■■.■■]:20022' (ED25519) to the list of known hosts.
appduser@■■■■■■■■■.■■■.■■'s password:
You are required to change your password immediately (administrator enforced).
You are required to change your password immediately (administrator enforced).
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-1036-aws x86_64)
（中略）

     _                ____   __     ___
    / \   _ __  _ __ |  _ \  \ \   / / \
   / _ \ | '_ \| '_ \| | | |  \ \ / / _ \
  / ___ \| |_) | |_) | |_| |   \ V / ___ \
 /_/   \_\ .__/| .__/|____/     \_/_/   \_\
         |_|   |_|

By accessing the Software herein, you (and the organization you represent)
("You") acknowledge and agree that the use of the Software and open source
software are governed by (1) the Cisco General Terms at
https://www.cisco.com/site/us/en/about/legal/contract-experience/index.html and
the applicable Offer Description(s) at
https://www.cisco.com/c/en/us/about/legal/cloud-and-software/software-terms.html
 or (2) any other superseding agreement between AppDynamics, or its parent
company Cisco Systems, Inc., as applicable, and You.  Capitalized terms not
defined herein shall have the meaning as defined in the Cisco General Terms at
https://www.cisco.com/site/us/en/about/legal/contract-experience/index.html
References to End User in any superseding agreement shall mean You.

AppDynamics Proprietary and Confidential * Revision 2025.7

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

WARNING: Your password has expired.
You must change your password now and login again!
Changing password for appduser.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Connection to ■■■■■■■■■.■■■.■■ closed.

初期パスワード変更後、自動的にログアウトされるため、再度同じVMへログインします。そしてデプロイ後の構成を確認するため、appdctl show bootコマンドを実行します。

$ appdctl show boot
 NAME             | STATUS    | ERROR
------------------+-----------+-------
 storage-setup    | Succeeded | --
 cert-setup       | Succeeded | --
 enable-time-sync | Succeeded | --
 firewall-setup   | Succeeded | --
 hostname         | Succeeded | --
 microk8s-setup   | Succeeded | --
 ssh-setup        | Succeeded | --

STATUS がすべて Succeeded になっていれば OK です。

同様のパスワード変更と、appdctl show bootコマンドの実行は VM1〜3 それぞれで実施します。これにより、AppD VA のデプロイができました。

まとめ

本記事ではAppD VAインストールの前編として、最初にAppD VAとは何かと前提について説明した後、AppD VAのデプロイまでをしてみました。AppD VAはデプロイのプラットフォームとしてAWS以外にも以下をサポートしていますが、今回は筆者都合によりAWSを使いました。

  • VMware vSphere
  • VMware ESXi
  • KVM
  • Microsoft Azure

後編では、今回構築した VM の環境を使い、AppDynamics 基本サービスの起動と、簡単な動作確認をしてみます。

脚注

  1. AppDynamics On-Premises Virtual Appliance (Self-Hosted) ↩︎

  2. Splunk AppDynamics On-Premises Virtual Appliance Enhancements ↩︎

  3. Splunk AppDynamicsオンプレミス版が使われる現場では、プラットフォーム（ハイパーバイザー）としてVMware製品が多く使われるという印象を筆者は持っています。AWS上にセルフホストしている環境は厳密には（つまり狭義では）オンプレミスではないでしょう。しかしながらAppD VAではプラットフォームが何かはあまり重要ではありません。そこで本記事ではAWS上にセルフホストしている環境は広義のオンプレミスであると仮定し、筆者にとって利用しやすいAWSを使います。 ↩︎

Discussion