演習 - Azure 仮想マシンに Elastic をデプロイする

90 分

この演習では、3 つのAzure VM に自己管理 Elasticsearch クラスターを準備し、Kibana を別の VM にインストールします。認証された HTTPS 要求と合成ドキュメントを使用して、ノードが 1 つのクラスターを形成していることを確認します。本番環境への移行ではなく、使い捨て可能な学習環境です。この演習で参照されているガイダンスへのリンクは、概要の 詳細情報 セクションにあります。

手順で管理者ワークステーションが明示的に示されていない限り、ローカル Windows PowerShell ではなく、指定された Ubuntu VM 上の SSH セッションで Bash のコマンド例を実行してください。各ブロックを順番に実行し、コマンドが失敗した場合は停止します。すべての山かっこプレースホルダーをご自身の値で置き換えます。他のベンダーチュートリアルの RPM コマンドは使用しないでください。

1. ラボの準備をする

Elastic 9.5.5 は、このリビジョンに対して選択された公開リリースです。開始する前に、Elastic Support Matrix とバージョンポリシーを確認してください。このリリースが保守対象外になった場合は、承認された保守対象リリースをスタック全体で一貫して使用し、そのインストール手順を再確認してください。

合成データでのみ、次の参照構成を使用します。

Setting	検査値
リソースグループ	新しい `elastic-on-azure-vm-rg`
Region	米国東部 2、または必要なクォータとサイズを持つ別の承認済みリージョン
OS イメージ	Ubuntu Server 24.04 LTS、x64、第 2 世代
Elastic パッケージ	Elasticsearch と Kibana 9.5.5
VM	`es-node1`、`es-node2`、`es-node3`、および `kibana-node`
各 VM のサイズ	`Standard_D2s_v5`: 2 vCPU と 8 GiB RAM
VM あたりのストレージ	64 GiB 永続マネージド OS ディスク、Standard SSD LRS。エフェメラル OS ディスクなし
Network	`elastic-lab-vnet`、アドレス空間 `10.42.0.0/16`;サブネット `elastic-lab-subnet`、 `10.42.0.0/24`
プライベートアドレス	`es-node1`: `10.42.0.10`; `es-node2`: `10.42.0.11`; `es-node3`: `10.42.0.12`; `kibana-node`: `10.42.0.20`
管理者	`azureuser` SSH 公開キーで認証済み
外向き接続	Standard NAT ゲートウェイとその Standard パブリック IP、または承認済みの既存のエグレスパス

リソース作成のアクセス許可、少なくとも 8 つの利用可能なリージョン vCPU、および十分な Dsv5 ファミリクォータを確認してください。これらの VM サイズは、パフォーマンスの保証ではなく、この小規模なラボの初期構成です。 Azure料金計算ツールで、4 つの VM、4 つのマネージドディスク、NAT ゲートウェイ、そのパブリック IP、データ処理/転送、および必要な管理者接続リソースを見積もります。リージョン、通貨、予想されるランタイム、および置き換えたサイズを記録します。

SSH/SCP を使用し、承認された既存の VPN を介してこのサブネットへの ルーティングされたプライベート接続 を備えた管理者ワークステーションが必要です。ワークステーションのブラウザーは、プライベート Kibana アドレスにも到達する必要があります。サブネットが実際に認識する管理者のソース IP 範囲を取得し、提案された VNet 範囲が接続されたネットワークと重複していないことを確認します。範囲が重なる場合は、別の範囲を選択し、この演習全体を通してアドレスの例を置き換えてください。

Important

ラボをプロビジョニングする前に、承認された管理者ネットワークパスを確立してください。 NAT Gatewayは、管理者のイングレスではなく、アウトバウンドのインターネット接続を提供します。 Azure ポータルログイン、通常のCloud Shell セッション、または Bastion SSH セッションだけでは、ローカルブラウザーにプライベート Kibana へのルートは提供されません。アプリケーション VM をパブリックに公開することで、接続できない状態を回避しないでください。

ブラウザー HTTPS の場合は、サブジェクト代替名（SAN）が Kibana プライベート IP をカバーする承認済みの認定資格証/秘密キーを取得するか、手順 8 のラボ専用認定資格証生成手順に従います。ブラウザーはその発行元を信頼している必要があります。組織のポリシーで一時的なラボ CA が許可されていない場合は、続行する前に承認された証明書を手配してください。

Important

このラボは、ライブ売上データの移行ターゲットではありません。運用設計にはさらに、容量計画、障害ドメイン計画、復元テスト済みスナップショット、監視、アップグレード/復旧計画が必要です。

2. Azure リソースをプロビジョニングする

演習専用のリソースグループを作成します。名前が既に存在する場合は、そのグループを再利用するのではなく、別の名前を選択します。手順 1 から VNet とサブネットを作成し、承認済みのルーティングされた管理者アクセスパスを確立します。この破棄可能なリソースグループには、共有 VPN やその他の共有インフラストラクチャを配置しないでください。

作成フローについては、Azure portal の『Create a Linux VM』ガイドを使用しますが、そのガイドの例の設定は変更して使用します。

手順 1 で指定したイメージ、サイズ、管理者で、4 つの VM をそれぞれ作成します。承認された SSH 公開キーを使用し、対応する秘密キーを VM ではなくワークステーションに保持します。
ディスク で、Standard SSD ストレージを備えた 64 GiB マネージド OS ディスクを選択します。このラボでは、その永続 OS ディスク上のパッケージの既定の /var/lib/elasticsearch データディレクトリを使用します。運用ワークロードのサイズは、通常は専用のマネージドデータディスクを使用して個別にサイズ設定する必要があります。
［Networking］ で、elastic-lab-vnet と elastic-lab-subnet を選択します。 [パブリック IP] を [なし] に、パブリック受信ポートを [なし] に設定します。これらの設定を Kibana とすべての Elasticsearch ノードに適用します。ロードバランサーを作成したり、NGINX をインストールしたり、ポート 80 を開いたりしないでください。
[ 確認と作成] を選択し、検証と価格設定を確認してから、[ 作成 ] を選択して SSH キーの確認を完了します。デプロイの完了を待ちます。
Elastic をインストールする前に、各 VM の ネットワーク>ネットワーク設定を開き、そのネットワークインターフェイスを選択し、次に IP 構成> でプライマリ IP 構成を選択します。プライベート IP の割り当てを静的に設定し、手順 1 のアドレスを設定してから保存します。アドレスの変更により、VM が再起動されることがあります。接続する前に完了を待ちます。ゲスト IP を手動で変更するのではなく、DHCP によって Ubuntu のネットワークインターフェイスを構成したままにします。

静的プライベート IP 構成、マネージドディスク、Elasticsearch データパスに関するガイダンスを参照してください。クラスターデータを一時ストレージに配置しないでください。 Azureデプロイが成功しても、Elasticsearch がインストールされているわけではありません。

3. パッケージをダウンロードする前に接続を構成する

新しい NAT ベースのラボの場合は、「標準 NAT ゲートウェイの作成」の 「NAT ゲートウェイの作成」 セクションに従います。ラボリソースグループとリージョンに elastic-lab-nat を作成し、その Standard パブリック IP elastic-lab-egress-ipを作成し、ゲートウェイを elastic-lab-subnetに関連付けます。そのクイックスタートの VM または Bastion のデプロイを繰り返さないでください。パブリック IP はゲートウェイに属し、どの VM にも属していません。承認されたファイアウォール/エグレスパスが既に存在する場合は、代わりにそれを使用します。共有ルーティングを変更したり、NAT を無差別に追加したりしないでください。

そのエグレスパスを介して、DNS 解決、時刻同期、および Ubuntu および Elastic のパッケージエンドポイントへのアクセスを許可します。 NAT だけでは送信コンテンツのフィルターにはなりません。

Note

新しいプライベートサブネットがインターネット接続を提供するとは想定しないでください。現在の Azure portalの既定値と、該当する新しいネットワーク API の動作には、明示的な送信接続性が必要です。既存の仮想ネットワークがすべて自動的に変更されるわけではありません。 Azure のアウトバウンド接続に関するガイダンスを参照してください。

ラボリソースグループに elastic-lab-nsg を作成し、 elastic-lab-subnetに関連付けます。接続する前に、次の受信規則を追加してください。明示的な送信元/宛先アドレスには IPアドレス を使用し、送信元ポートには任意を使用し、<administrator-source-CIDR> を承認済みのルーティングソース範囲に置き換えます。コンマ区切りの各リストは、1 つの拡張ルール内の複数の IP アドレスを表します。

Priority	Name	プロトコル/宛先ポート	Sources	Destinations	アクション
100	AllowAdminSSH	TCP / 22	`<administrator-source-CIDR>`	`10.42.0.10,10.42.0.11,10.42.0.12,10.42.0.20`	許可する
110	AllowElasticsearchTransport	TCP / 9300	`10.42.0.10,10.42.0.11,10.42.0.12`	`10.42.0.10,10.42.0.11,10.42.0.12`	許可する
120	AllowElasticsearchHTTPS	TCP / 9200	`10.42.0.10,10.42.0.11,10.42.0.12,10.42.0.20`	`10.42.0.10,10.42.0.11,10.42.0.12`	許可する
130	AllowAdminKibana	TCP / 5601	`<administrator-source-CIDR>`	`10.42.0.20`	許可する
200	DenyOtherLabIngress	任意 / 任意	Any	`10.42.0.0/24`	Deny

拒否ルールは必須です。そうしないと、AzureのデフォルトのAllowVNetInBoundルールにより、他のVNetトラフィックが許可されてしまいます。数値の優先順位が低い方が最初に評価されます。この破棄可能な NAT ベースのラボの既定の送信規則を保持します。組織のエグレスフィルタリングは別です。これらのフローに対応するゲストファイアウォール規則を照合し、サブネットと NIC の有効な規則の両方を調べます。 NSG はステートフルであるため、許可された送信接続の応答トラフィックには追加の受信許可は必要ありません。これらの規則は、ルーティングされたワークステーションを前提としており、異なる管理設計には対応するルールが必要です。 NSG ルールの評価に関するガイダンスを参照してください。

管理者ワークステーションから、プライベートアドレスを使用して各 VM に接続します。例:

ssh -i "<ssh-private-key-path>" azureuser@10.42.0.10

承認されたプロセスを通じて SSH ホストの識別情報を確認します。各 VM で、sudo apt-get update を実行し、DNS、ルーティング、またはリポジトリのエラーを解決してから続行します。

4. 最初の Elasticsearch ノードをインストールして起動する

es-node1で、公式の APT リポジトリを設定します。パッケージをインストールする前に、各 VM でも後ほどこのリポジトリブロックを繰り返します。これらのコマンドは、新しい Ubuntu ホスト用です。既存のインストールに重複する Elastic リポジトリを追加しないでください。

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg unzip
curl --fail --silent --show-error https://artifacts.elastic.co/GPG-KEY-elasticsearch \
  -o /tmp/elastic-signing-key.asc
gpg --show-keys --with-fingerprint /tmp/elastic-signing-key.asc

プライマリキーフィンガープリントを Debian インストールガイドの 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 と比較します。異なる場合は、確認されていないキーをインポートするのではなく、停止して、公式のガイダンスを確認してください。

sudo gpg --dearmor --output /usr/share/keyrings/elasticsearch-keyring.gpg \
  /tmp/elastic-signing-key.asc
sudo chmod 644 /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/9.x/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/elastic-9.x.list
sudo apt-get update

正確なリリースをインストールし、インストールされているバージョンを記録します。

sudo apt-get install -y elasticsearch=9.5.5
dpkg-query -W -f='${Package} ${Version}\n' elasticsearch

バンドルされている JDK を使用します。要求されたバージョンをインストールできない場合は、停止して、パッケージの可用性とメンテナンスポリシーを確認します。1 つのノードに別のバージョンをサイレントインストールしないでください。

各 Elasticsearch ノードを開始する前に、システム構成のガイダンスを確認してください。 sudo swapoff -aを使用してこれらの専用ラボホストのスワップを無効にし、/etc/fstabのスワップエントリをコメントアウトします。また、スワップを再作成するイメージ固有のメカニズムも無効にします。 OS の再起動後に swapon --show をもう一度確認してください。 sysctl vm.max_map_count確認します。1048576未満の場合は、vm.max_map_count=1048576で/etc/sysctl.confを設定し、sudo sysctl --systemを実行して、もう一度確認します。パッケージはこれを自動的に構成する可能性があるため、競合する定義を追加するのではなく、実際に適用される値を確認してください。

パッケージはサービスの制限を設定します。 systemctl show elasticsearch -p LimitNOFILE -p LimitNPROCを使用して検査します。ブートストラップチェックが失敗した場合は、システム構成ガイダンスを使用します。ヒープの自動サイズ設定と既定のノードロールを保持します。

/etc/elasticsearch/elasticsearch.yml で sudoedit を開きます。パッケージガイドの「クラスターの最初のノードとしてノードを設定」セクションに従って、重複するキーを追加するのではなく、既存の設定を編集します。

cluster.name: es-on-azure
transport.host: 10.42.0.10
transport.port: 9300
http.host: 0.0.0.0
http.port: 9200

既定のノード名、パッケージで生成された TLS/キーストア設定、およびこの最初のノードの初期ブートストラップエントリを保持します。この初期ブートストラップの前に、ファイル全体を置き換えたり、 discovery.seed_hosts を設定したりしないでください。 HTTP バインディングには、ローカルチェックのループバックと、登録と Kibana 用のプライベートインターフェイスが含まれます。これは、パブリック IP を持つ VM がなく、ネットワークアクセスが制限されているためにのみ適しています。

パッケージサービスを有効化して開始する:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service
sudo systemctl status elasticsearch.service --no-pager

Debian/systemd インストールの場合は、文書化されたツールを使用して、組み込みの管理者パスワードを設定またはリセットします。対話的な起動時のパスワードメッセージを待機しないでください。

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic

生成された資格情報を安全に格納します。それをモジュール、コマンド、スクリーンショット、または共有ドキュメントに貼り付けないでください。ローカル HTTPS エンドポイントを確認します。curl がパスワードの入力を求めます。

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/"

予想されるクラスター名とインストールされているバージョンを確認します。生成された構成とログを調べて、セキュリティ、HTTP TLS、およびトランスポート TLS が有効になっており、必要な証明書/キーストアエントリが存在することを確認します。動作する HTTP エンドポイントだけでは、トランスポート TLS は証明されません。起動、TLS セットアップ、または HTTPS が失敗した場合は、続行する前に Elasticsearch ログと自動構成時の例外を調べます。セキュリティを無効にしたり、不完全な手動 TLS 構成を追加したり、既存のデータディレクトリを破棄して障害を乗り越えたりしないでください。

5. その他の Elasticsearch ノードを登録する

es-node2、手順 4 のリポジトリのセットアップ、正確なバージョンのパッケージのインストール、OS の前提条件チェックを繰り返しますが、サービスを開始したり、最初のノードのブートストラップ構成をコピーしたりしないでください。稼働中の最初のノードで、ノード登録トークンを作成します。

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s node

es-node2で、最初のサービスが開始される前に、Debian/RPM 再構成ツールでトークンを使用してください。

sudo /usr/share/elasticsearch/bin/elasticsearch-reconfigure-node \
  --enrollment-token "<node-enrollment-token>"

再構成プロンプトを確認して確定します。 elasticsearch.ymlで、cluster.name: es-on-azure、transport.host: 10.42.0.11、transport.port: 9300、http.host: 0.0.0.0、およびhttp.port: 9200を設定します。生成された証明書、トラスト、および検出の構成を保持します。手順 4 のサービスコマンドを使用してサービスを有効にして開始し、元のクラスターに参加していることを確認します。

2 番目のノードが参加したらすぐに、再起動する前に最初の 2 つのノードで手順 6 を実行してください。次に、es-node3と新しく生成されたトークンを使用して、transport.host: 10.42.0.12の登録シーケンスを繰り返し、3 つのノードすべてに手順 6 を適用します。トークンは 30 分後に期限切れになります。一時的な資格情報として扱います。 -s kibanaで作成されたトークンでは、Elasticsearch ノードを登録することはできません。 3 つの独立したクラスターをブートストラップしたり、データディレクトリをマージしようとしたりしないでください。

Debian ガイドの「ノードを再構成して既存のクラスターに参加させる」セクションを参照してください。

6. 検出構成を統合する

2 番目のノードが参加したらすぐに、再起動する前に最初のノードの検出構成を更新してください。 3 つのノードすべてが参加したら、 すべての ノードで構成を確認します。

確立されたクラスターの構成から cluster.initial_master_nodes を削除し、discovery.seed_hosts を 3 つのマスター適格ノードの安定したプライベートアドレスに設定します。

discovery.seed_hosts:
  - "10.42.0.10:9300"
  - "10.42.0.11:9300"
  - "10.42.0.12:9300"

ノードを再起動または追加するときに cluster.initial_master_nodes を再導入しないでください。 Debian ガイドの「構成ファイルの更新」セクションを参照してください。これは、最初の登録が成功したと思われる場合でも重要です。

7.クラスターのメンバーシップと正常性を確認する

es-node1で、認証付きHTTPSリクエストを実行します。

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/_cat/nodes?v"

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/_cluster/health?pretty"

目的のクラスターには 3 つのノードがある想定です。ロール、選出されたマスター、およびヘルス状態が隠されていないことを確認します。割り当て可能なレプリカを持つこの 3 ノードラボでは、成功と判断する前にヘルスが green であることを必須とします。HTTP 200 応答を成功として扱うのではなく、割り当てられていないシャードを調査します。

他のノードから、手順 4 のローカル HTTPS ルート要求を使用し、同じクラスター管理者パスワードを使用して、同じ cluster_uuid を確認します。ディスカバリの統合後、sudo systemctl restart elasticsearch.serviceを1ノードずつ実行し、各ノードが再参加し、クラスタが復旧してから、次のノードを再起動します。これはラボチェックであり、運用環境のローリング再起動手順に代わるものではありません。

8. Kibana をインストールして HTTPS を構成する

kibana-nodeで、手順 4 のリポジトリのセットアップを繰り返し、Elasticsearch ではなく Kibana をインストールします。

sudo apt-get install -y kibana=9.5.5
dpkg-query -W -f='${Package} ${Version}\n' kibana

ブラウザー証明書を準備する

既に承認されたサーバー証明書と対応する秘密キーがある場合は、それらを安全に kibana-node に転送し、認定資格証のインストールと Kibana の登録を続行します。サーバー証明書ファイルに必要な中間証明書を含めます。そのサブジェクト代替名は、10.42.0.20 を対象に含めるか、承認された DNS 名を認定資格証とブラウザーの URL で一貫して使用する必要があります。

それ以外の場合は、一時的なラボ CA を信頼するための承認を得て、es-node1 で次を実行してください。ブラウザーから Kibana HTTPS に対して、有効期間が短い別の CA が作成されます。Elasticsearch で自動的に構成された CA またはトランスポート認定資格証は置き換えません。

sudo install -d -m 700 /root/elastic-lab-pki
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil ca --pem \
  --days 30 --out /root/elastic-lab-pki/kibana-ca.zip
sudo unzip /root/elastic-lab-pki/kibana-ca.zip -d /root/elastic-lab-pki
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil cert --pem \
  --name kibana-server --ip 10.42.0.20 --days 30 \
  --ca-cert /root/elastic-lab-pki/ca/ca.crt \
  --ca-key /root/elastic-lab-pki/ca/ca.key \
  --out /root/elastic-lab-pki/kibana-server.zip
sudo unzip /root/elastic-lab-pki/kibana-server.zip -d /root/elastic-lab-pki
install -d -m 700 "$HOME/kibana-tls"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/kibana-server/kibana-server.crt "$HOME/kibana-tls/"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/kibana-server/kibana-server.key "$HOME/kibana-tls/"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/ca/ca.crt "$HOME/kibana-tls/kibana-lab-ca.crt"
sudo openssl x509 -in /root/elastic-lab-pki/ca/ca.crt -noout -fingerprint -sha256

CA 秘密キーは es-node1に保持します。ワークステーションまたは Kibana VM にコピーしないでください。このラボでは、ファイルシステムで保護された暗号化されていない PEM サーバーキーを使用します。運用環境では、組織の PKI とキー保護プロセスを使用します。証明書ユーティリティリファレンスでは、オプションについて説明します。

管理者ワークステーションで、自分のアカウントのみがアクセスできる、同期されていないプライベートディレクトリに移動します。 SSH 経由でステージ済みの3つのファイルをダウンロードし、サーバー証明書とサーバー秘密キーのみを Kibana にアップロードします。各 VM に適切な SSH キーを使用します。

scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-server.crt .
scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-server.key .
scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-lab-ca.crt .
scp -i "<kibana-ssh-private-key-path>" kibana-server.crt kibana-server.key azureuser@10.42.0.20:

ダウンロードした CA の SHA-256 証明書フィンガープリントが、 es-node1に表示されたものと一致するかどうかを確認します。プラットフォームおよび組織のポリシーに従い、のみをkibana-lab-ca.crtとして、ラボのブラウザで使用されている信頼ストアにインポートします。クリーンアップのために信頼の変更を記録します。秘密キーを信頼されたルートとしてインポートしたり、証明書の警告をバイパスしたり、一般的に使用するためにこのラボ CA を配布したりしないでください。

認定資格証をインストールして Kibana を登録する

kibana-node で、PEM ファイルをインストールします。

sudo install -o root -g kibana -m 640 "$HOME/kibana-server.crt" /etc/kibana/kibana-server.crt
sudo install -o root -g kibana -m 640 "$HOME/kibana-server.key" /etc/kibana/kibana-server.key
rm -- "$HOME/kibana-server.crt" "$HOME/kibana-server.key"

組織の証明書を使用する場合は、ソースファイル名を調整します。秘密キーが暗号化されている場合は、例で公開するのではなく、Kibana キーストアを使用して server.ssl.keyPassphrase を指定します。 Kibana 秘密キーパスフレーズ設定リファレンスでは、その設定の目的について説明します。

/etc/kibana/kibana.ymlでsudoeditを開き、プライベートリスナーとブラウザーの TLS を構成し、重複を作成するのではなく、既存のキーを編集します。

server.host: "10.42.0.20"
server.port: 5601
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/kibana-server.crt
server.ssl.key: /etc/kibana/kibana-server.key

Elasticsearch 接続設定は、登録するまで未設定のままにします。証明書のアクセス許可とブラウザーの信頼については、Kibana HTTPS ガイダンスを参照してください。

Elasticsearch ノードで新しい Kibana 登録トークンを生成します。

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

kibana-node で、サービスを開始します:

sudo systemctl daemon-reload
sudo systemctl enable kibana.service
sudo systemctl start kibana.service
sudo systemctl status kibana.service --no-pager

サービスの状態に6桁の確認コードを記録するか、必要に応じてsudo journalctl -u kibana.service --no-pagerを確認します。ワークステーションブラウザーで、 https://10.42.0.20:5601 (または承認済みの DNS 名) を開きます。 Kibana 登録トークンを指定し、Elastic を設定 を選択し、メッセージが表示されたら確認コードを指定します。トークンの有効期限が切れている場合は、別のトークンを生成してください。 Debian の登録フローに従ってください。初期管理のために elastic を使用してログインし、ルーチン作業用に適切な権限範囲のユーザーを作成します。

Kibana が HTTPS を使用して目的のクラスターに接続し、その Elasticsearch HTTP CA を信頼していることを確認します。ブラウザーから Kibana への信頼と Kibana から Elasticsearch への信頼は別です。登録時の Elasticsearch CA をブラウザーのラボ CA に置き換えないでください。

登録後、既存の elasticsearch.hosts 設定を更新して、次の 3 つのノードをすべて含めてください。

elasticsearch.hosts:
  - "https://10.42.0.10:9200"
  - "https://10.42.0.11:9200"
  - "https://10.42.0.12:9200"

登録処理で生成されたサービスアカウント認証と elasticsearch.ssl.certificateAuthorities 設定を保持します。 sudo systemctl restart kibana.serviceで Kibana を再起動し、もう一度アクセスを確認します。複数ノード接続のガイダンスを参照してください。

Note

この演習では、1 つの Kibana VM をプロビジョニングします。 Kibana の高可用性ではなく、インストールを示します。実稼働マルチインスタンスデプロイでは、前のユニットで説明した共有設定が必要です。

9. 合成ドキュメントを確認する

初期管理時に Kibana の Dev Tools コンソールを使用します。明示的なレプリカを持つ専用ラボインデックスを作成します。

PUT module-lab-check
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  }
}

PUT module-lab-check/_doc/1?refresh=wait_for
{
  "message": "Azure VM lab connectivity check"
}

GET module-lab-check/_doc/1

GET _cluster/health/module-lab-check?wait_for_status=green&timeout=60s

GET _cat/shards/module-lab-check?v

ドキュメントの応答に "found": true と予期されるメッセージが含まれていることを確認します。ヘルス応答には、"status": "green" と "timed_out": falseが必要です。シャード応答には、1 つのプライマリ (p) と 1 つのレプリカ (r) が表示され、両方が STARTED で、異なるノード上にある必要があります。 HTTP 200 だけのレスポンスでは不十分です。

Kibana で、グローバル検索を使用して データビュー を検索し、インデックスパターン module-lab-check でデータビューを作成し、ドキュメントにタイムスタンプフィールドがないため 時間フィルターを使用したくない を選択します。 Discover を開き、このデータビューを選択して、メッセージを見つけます。データビューの作成ガイドを参照してください。

実際のトランザクション、資格情報、または顧客データをペイロードとして使用しないでください。 Logstash を使用するオプションのインジェストプロジェクトは、この演習とは別です。概要の次の手順を参照してください。

10. 構成を弱めずにトラブルシューティングを行う

セキュリティ制御を無効にせずに一般的な問題のトラブルシューティングを行うには、次のチェックを使用します。

症状:	チェック
SSH またはブラウザーの接続がタイムアウトする	ワークステーションルート、実際のソース IP 範囲、サブネット/NIC の有効な NSG 規則、ゲストファイアウォール、リスナーアドレス、サービスの状態
パッケージのダウンロードに失敗する	DNS と明示的なアウトバウンド接続性、正しいリポジトリ、署名キー、および正確なパッケージバージョンの可用性
ノードが起動に失敗する	`/var/log/elasticsearch/es-on-azure.log`、システム設定、メモリ/ディスク容量、重複する YAML キー、ブートストラップ構成
ノード登録失敗	新しい `node` スコープのトークン、最初のノードの HTTPS 到達可能性、プライベートトランスポート接続、一致するバージョンとクラスター名
証明書のエラー	適切な発行元 CA、認定資格証の有効期限とサブジェクト代替名、一致するサーバーキー、およびサービスの読み取りアクセス許可を確認します。`curl -k` は決して使用しないでください。
Kibana が起動しない	`sudo journalctl -u kibana.service --no-pager`、証明書/キーの形式とアクセス許可、Elasticsearch ホスト、および登録設定
黄/赤の状態	Dev Tools でのシャードの状態と `GET _cluster/allocation/explain`。レプリカをゼロに設定するのではなく、割り当ての原因を修正する

11. クリーンアップ

Warning

リソースグループの削除により、リソースとそのデータが完全に削除されます。最初にグループを検査し、破棄可能な演習リソースのみが含まれている場合にのみ続行します。共有ネットワーク、運用デプロイ、または保持する必要があるデータは削除しないでください。

Azure ポータルで、演習リソースグループを開き、その内容を確認し、[リソースグループの削除] を選択して、名前を入力して確認を完了します。削除が完了するまで待ちます。ディスク、スナップショット、パブリック IP、エグレスリソースなど、そのグループの外部で作成されたラボリソースを確認します。この演習に属するリソースのみを削除します。ネットワーク管理者に、共有接続サービスを削除せずに、必要に応じてラボ固有の接続構成を削除してもらいます。

ダウンロードしたサーバー秘密キーとその他の一時証明書のコピーをワークステーションから削除します。記録された指紋を使用して、追加した一時的なラボ CA 信頼エントリのみを削除します。組織のトラストアンカーを削除しないでください。ラボ固有の SSH 秘密キーは、他の場所で使用されていない場合にのみ削除します。 VM リソースグループを削除しても、ワークステーションファイルやトラストストアエントリは削除されません。

サービスの停止またはゲスト OS のシャットダウンは、Azure の完全なクリーンアップではありません。割り当て解除によって VM コンピューティング料金は停止されますが、保持されているストレージまたはネットワークの料金が必ずしも停止されるとは限りません。 VM の課金状態に関するガイダンスを参照してください。

フィードバック

このページはお役に立ちましたか?