技術メモメモ: 2024

2024年11月7日木曜日

DELL周辺機器レビュー③ (Dell Bluetooth®トラベルマウス – MS700)

Dell Technologies Japan様(@DellTechJapan)の「【A】テレワークを快適にする周辺機器セット」のモニタープレゼントに当選し、以下3つの製品を提供いただいた。

それぞれの使用感をレビューしたいと思う。本記事ではDell Bluetooth®トラベルマウス – MS700 のレビューを記載する。

「Dell Bluetooth®トラベルマウス – MS700」レビュー

大きさなど

本マウスは単4電池 x 2本必要となる。動作確認用として電池付きなのがありがたい。

電池の蓋はマグネット式になっており、電池が落下しないようストッパーが付いている。

大きさは通常のマウスと同じくらいの大きさとなる。手元のマウスと比べてみると、若干薄い程度でほぼ同じ大きさとなっていた。

本体を捻ることで電源ON/OFFができる

このマウスの特徴として、本体を捻ることで電源ON/OFFができる。

通常の使用時は普通のマウスと同じ程度の厚みがある。

本体を捻り電源をOFFにすると、薄くコンパクトになる。そのため、持ち運び時にかさばることがない。

また、電源OFFの状態からONの状態に戻すと、すぐにPCでマウスが認識されるため、認識待ちなどでストレスを感じることはなく使用することができた。

マウスホイール

マウスホイールはホイール式ではなく、タッチセンサー式となっている。スクロール時の動かし方はホイールとは同じではあるが、物理的なホイールがないことで最初は違和感を感じる可能性がある。ただ、慣れればホイールと遜色なく操作はできそうだ。

総評

Dell EcoLoop Pro バックパック 15 の総評として、メリット・デメリットを以下にまとめる。

メリット

電源ON時は、通常のマウスと同じ程度の厚みがあり、マウス操作時に違和感を感じにくい。
電源OFF時は、本体が薄くなりコンパクトになる。

デメリット

マウスホイールがタッチセンサー式となるため、慣れるまではスクロール操作に違和感を感じる可能性がある。

2024年11月5日火曜日

DELL周辺機器レビュー② (Dell EcoLoop Pro バックパック 15)

それぞれの使用感をレビューしたいと思う。本記事ではDell EcoLoop Pro バックパック 15 のレビューを記載する。

「Dell EcoLoop Pro バックパック 15」レビュー

大きさと容量

大きさとしては幅31cm x 高さ44cm x 奥行17cmとなっており、重量は660gとなる。第一印象としては奥行きがスリムで非常に軽く、ノートPCや周辺機器などを十分に入れるだけの容量があるか心配になるほどだった。

実際は、十分な容量があり、ノートPC、マウス、ヘッドセットに加え、モバイルバッテリーやケーブル類など、通勤や客先移動時に必要な仕事道具を問題なく収納して持ち運ぶことができる(さらに、季節的に薄手の上着ぐらいなら問題なく収納できた)。

また、ペットボトル用のメッシュ状の収納ポケットが左右にあり、折りたたみ傘、ペットボトルの飲み物なども、バックパックの中に入れることなく持ち運ぶことができる。

収納スペース

背中側からPC収納スペース、周辺機器収納スペース、小物類収納スペースの大きく3つの区画に分かれている。

面白い点として、キーボードやヘッドセットといったマークが収納スペースに貼り付けてあった。マークに従い、周辺機器収納スペースには、ヘッドセットなどを入れ、小物類収納スペースにはマウスやその他財布などを収納すると、仕事道具を整理して収納することができる(当然自分好みで収納場所は変えてもよい)。

PC収納スペース

一番背中側のPC用スペースは、15.6インチまでのPCに対応しており非常に広いスペースが確保されている。写真は13インチのノートPCを入れた状態となるが、見ての通りスペースには余裕があり、追加でモバイルモニターなども収納できそうだ。

背中側

背中側はメッシュ状のクッション素材となっており、夏場などで背中が熱くなる際も、蒸れにくくなりそうだ。また、スーツケース用のストラップも付いている。

総評

Dell EcoLoop Pro バックパック 15 の総評として、メリット・デメリットを以下にまとめる。

メリット

一見コンパクトながら、十分な容量を備える。満員電車などでも邪魔になりにくい。
PCを常に持ち運ぶような働き方を想定した収納スペースを備えており、周辺機器を整理した状態で持ち運ぶことができる。
金額もリーズナブル(6,780円)。

デメリット

特に大きなデメリットはないが、強いて言えば、技術書などで分厚い本などを入れようとした場合、収納場所を工夫する必要があるかもしれない。

2024年11月4日月曜日

DELL周辺機器レビュー① (Dell Pro 有線 ANC ヘッドセット – WH5024)

それぞれの使用感をレビューしたいと思う。本記事ではDell Pro 有線 ANC ヘッドセット – WH5024のレビューを記載する。

「Dell Pro 有線 ANC ヘッドセット – WH5024」レビュー

音声とマイクについて

本ヘッドセットは、無線ではなく有線接続専用のヘッドセットとなる。無線でないためヘッドセットを付けながら動き回るといったことはできないが、ヘッドセット自体はバッテリーなどが搭載不要であることから、軽量になっている印象となる(その代わり、ケーブル分の重量は増えてしまうが)。

数日使ってみたが、音声やマイクの性能は十分で、Web会議で相手の音や自分の音が聞こえにくいということはなかった。また、ANC(アクティブノイズキャンセリング)がよい感じに周りの音を減少してくれるので、オフィスなどで多少周りが騒がしい環境であっても、問題なくWeb会議ができそうだ。

収納ケース

収納ケースが付いており持ち運び時に有線ケーブルが散らからず、便利になっている。

イヤーパッド

イヤーパッドはクッション性が十分にあり、長時間使用しても耳が痛くなりにくくなっている。また、アーム部分が耳の角度に応じて回転するため、きちっと耳にフィットする。

有線ケーブルとコントローラー

無線ではなく有線となり、いわゆるイヤホンプラグではなくUSBケーブルによる接続となる。USBはType-CだけでなくType-Aへの変換コネクターが付属している。

コントローラーが付いており、手元でマイクミュートのON/OFFや音量調整ができる。Web会議などで相手の環境の音が小さく、音量を上げたい場合などにおいて手元ですぐに音量調整できるのはありがたい。

「Dell Peripheral Manager」による細かな管理

USB接続をすると、Windows 11においては自動的に「Dell Peripheral Manager」のインストールが求められる。本ソフトウェアを用いることで、ヘッドセットの細かな設定ができるようになるため、特に問題がなければインストールした方が便利だろう。

なお、本ヘッドセットはマイクON/OFF時に音声ガイダンスで案内がされるのだが、ガイダンスがWeb会議中の会話と干渉するため、人によっては音声ガイダンスをOFFにしたい場合もあると思われる(私がそうだった)。本ソフトウェアを用いることで、音声ガイダンスのON/OFFが設定可能となる。

総評

Dell Pro 有線 ANC ヘッドセット – WH5024の総評として、メリット・デメリットを以下にまとめる。

メリット

イヤーパッドのクッション性が高く、アーム部分も稼働することで長時間のWeb会議でも痛くなりにくい。
手元にコントローラーがあり、簡単にマイクON/OFFや音量調整ができる。
ANCが優秀で多少騒がしい環境でもWeb会議ができる。
「Dell Peripheral Manager」で音声ガイダンスを無効化などの細かな設定ができる。

デメリット

有線接続なので使用中に席を離れることができない。
音声ガイダンスを無効に知るとANCのON/OFFの状態が判断しづらい。

2024年10月19日土曜日

Ansible core 2.17にしたらRHEL 8系でdnfモジュール実行できなくなった話

先日、Ansibleコントロールノードを10.4.0 (Ansible core 2.17)にバージョンアップした。

RHEL系のOSに導入したAnsibleをバージョンアップする手順

RHEL 8系のOSに対してdnfモジュールを用いて操作をしようとしたところ、以下のようなエラーが発生し実行に失敗してしまった。

TASK [Update gitlab packages] *******************************************************************************************************************************************************************
{
  "changed": false,
  "module_stderr": "Shared connection to 192.168.11.26 closed.\r\n",
  "module_stdout": "Traceback (most recent call last):\r\n  File \"<stdin>\", 
  line 12, in <module>\r\n  File \"<frozen importlib._bootstrap>\", 
  line 971, in _find_and_load\r\n  File \"<frozen importlib._bootstrap>\", 
  line 951, in _find_and_load_unlocked\r\n  File \"<frozen importlib._bootstrap>\", 
  line 894, in _find_spec\r\n  File \"<frozen importlib._bootstrap_external>\", 
  line 1157, in find_spec\r\n  File \"<frozen importlib._bootstrap_external>\", 
  line 1131, in _get_spec\r\n  File \"<frozen importlib._bootstrap_external>\", 
  line 1112, in _legacy_get_spec\r\n  File \"<frozen importlib._bootstrap>\", 
  line 441, in spec_from_loader\r\n  File \"<frozen importlib._bootstrap_external>\", 
  line 544, in spec_from_file_location\r\n  File \"/tmp/ansible_ansible.legacy.dnf_payload_25y3u3vr/ansible_ansible.legacy.dnf_payload.zip/ansible/module_utils/basic.py\", line 5\r\nSyntaxError: future feature annotations is not defined\r\n",
  "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error",
  "rc": 1
}

RHEL 8のOSにPython 3.12を個別にdnfでインストールして、ansible_python_interpreterでPythonのパスを指定しても、dnfモジュールはうまく動作してくれないので、いろいろ調べたところ、どうやらこれは、管理ノード側のPythonが古い(Python 3.7未満)ことによる「仕様」であり解決できないようだ。

以下に本情報が記載されている、GitHubのIssueを日本語訳したものを引用する。

ansible-core 2.17 は、ターゲット実行に Python 3.7 以降のみをサポートしています。それより低いバージョンの Python を使用しているシステムはサポートされていません。これらのシステムでは、より新しいバージョンの Python をインストールできる可能性がありますが、パッケージマネージャーなどのシステムタスク用のパッケージが不足しているため、すべてのモジュールが機能しない可能性があります。
そのコメントに従って、よりフレンドリーなエラーのために機能を人為的に制限することは、長期的には価値がないと判断しました。
SyntaxError: future feature annotations is not defined #82068

残念ながら、自宅はまだまだRHEL 8系OSが現役なので、この仕様は非常に困る。本事象の回避のため、AnsibleコントロールノードをAnsible 10.x (Ansible core 2.17) → Ansible 9.x (Ansible core 2.16) にダウングレードすることにした。

Ansibleダウングレード手順

1. インストール可能なAnsibleのバージョン確認

まずは、インストール可能なAnsibleのバージョンを確認する。存在しないバージョンとして0を指定することで、エラー表示にてインストール可能なバージョンが表示される。

# python3 -m pip install --upgrade ansible=='0'
ERROR: Ignored the following yanked versions: 9.0.0, 9.5.0, 9.6.0, 10.0.0
ERROR: Could not find a version that satisfies the requirement ansible==0 (from versions: 1.0, 1.1, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.6, 1.6.1, 1.6.2, 1.6.3, 1.6.4, 1.6.5, 1.6.6, 1.6.7, 1.6.8, 1.6.9, 1.6.10, 1.7, 1.7.1, 1.7.2, 1.8, 1.8.1, 1.8.2, 1.8.3, 1.8.4, 1.9.0.1, 1.9.1, 1.9.2, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 2.0.0.0, 2.0.0.1, 2.0.0.2, 2.0.1.0, 2.0.2.0, 2.1.0.0, 2.1.1.0, 2.1.2.0, 2.1.3.0, 2.1.4.0, 2.1.5.0, 2.1.6.0, 2.2.0.0, 2.2.1.0, 2.2.2.0, 2.2.3.0, 2.3.0.0, 2.3.1.0, 2.3.2.0, 2.3.3.0, 2.4.0.0, 2.4.1.0, 2.4.2.0, 2.4.3.0, 2.4.4.0, 2.4.5.0, 2.4.6.0, 2.5.0a1, 2.5.0b1, 2.5.0b2, 2.5.0rc1, 2.5.0rc2, 2.5.0rc3, 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7, 2.5.8, 2.5.9, 2.5.10, 2.5.11, 2.5.12, 2.5.13, 2.5.14, 2.5.15, 2.6.0a1, 2.6.0a2, 2.6.0rc1, 2.6.0rc2, 2.6.0rc3, 2.6.0rc4, 2.6.0rc5, 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.6.5, 2.6.6, 2.6.7, 2.6.8, 2.6.9, 2.6.10, 2.6.11, 2.6.12, 2.6.13, 2.6.14, 2.6.15, 2.6.16, 2.6.17, 2.6.18, 2.6.19, 2.6.20, 2.7.0.dev0, 2.7.0a1, 2.7.0b1, 2.7.0rc1, 2.7.0rc2, 2.7.0rc3, 2.7.0rc4, 2.7.0, 2.7.1, 2.7.2, 2.7.3, 2.7.4, 2.7.5, 2.7.6, 2.7.7, 2.7.8, 2.7.9, 2.7.10, 2.7.11, 2.7.12, 2.7.13, 2.7.14, 2.7.15, 2.7.16, 2.7.17, 2.7.18, 2.8.0a1, 2.8.0b1, 2.8.0rc1, 2.8.0rc2, 2.8.0rc3, 2.8.0, 2.8.1, 2.8.2, 2.8.3, 2.8.4, 2.8.5, 2.8.6, 2.8.7, 2.8.8, 2.8.9, 2.8.10, 2.8.11, 2.8.12, 2.8.13, 2.8.14, 2.8.15, 2.8.16rc1, 2.8.16, 2.8.17rc1, 2.8.17, 2.8.18rc1, 2.8.18, 2.8.19rc1, 2.8.19, 2.8.20rc1, 2.8.20, 2.9.0b1, 2.9.0rc1, 2.9.0rc2, 2.9.0rc3, 2.9.0rc4, 2.9.0rc5, 2.9.0, 2.9.1, 2.9.2, 2.9.3, 2.9.4, 2.9.5, 2.9.6, 2.9.7, 2.9.8, 2.9.9, 2.9.10, 2.9.11, 2.9.12, 2.9.13, 2.9.14rc1, 2.9.14, 2.9.15rc1, 2.9.15, 2.9.16rc1, 2.9.16, 2.9.17rc1, 2.9.17, 2.9.18rc1, 2.9.18, 2.9.19rc1, 2.9.19, 2.9.20rc1, 2.9.20, 2.9.21rc1, 2.9.21, 2.9.22rc1, 2.9.22, 2.9.23rc1, 2.9.23, 2.9.24rc1, 2.9.24, 2.9.25rc1, 2.9.25, 2.9.26rc1, 2.9.26, 2.9.27rc1, 2.9.27, 2.10.0a1, 2.10.0a2, 2.10.0a3, 2.10.0a4, 2.10.0a5, 2.10.0a6, 2.10.0a7, 2.10.0a8, 2.10.0a9, 2.10.0b1, 2.10.0b2, 2.10.0rc1, 2.10.0, 2.10.1, 2.10.2, 2.10.3, 2.10.4, 2.10.5, 2.10.6, 2.10.7, 3.0.0b1, 3.0.0rc1, 3.0.0, 3.1.0, 3.2.0, 3.3.0, 3.4.0, 4.0.0a1, 4.0.0a2, 4.0.0a3, 4.0.0a4, 4.0.0b1, 4.0.0b2, 4.0.0rc1, 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.7.0, 4.8.0, 4.9.0, 4.10.0, 5.0.0a1, 5.0.0a2, 5.0.0a3, 5.0.0b1, 5.0.0b2, 5.0.0rc1, 5.0.1, 5.1.0, 5.2.0, 5.3.0, 5.4.0, 5.5.0, 5.6.0, 5.7.0, 5.7.1, 5.8.0, 5.9.0, 5.10.0, 6.0.0a1, 6.0.0a2, 6.0.0a3, 6.0.0b1, 6.0.0b2, 6.0.0rc1, 6.0.0, 6.1.0, 6.2.0, 6.3.0, 6.4.0, 6.5.0, 6.6.0, 6.7.0, 7.0.0a1, 7.0.0a2, 7.0.0b1, 7.0.0rc1, 7.0.0, 7.1.0, 7.2.0, 7.3.0, 7.4.0, 7.5.0, 7.6.0, 7.7.0, 8.0.0a1, 8.0.0a2, 8.0.0a3, 8.0.0b1, 8.0.0rc1, 8.0.0, 8.1.0, 8.2.0, 8.3.0, 8.4.0, 8.5.0, 8.6.0, 8.6.1, 8.7.0, 9.0.0a1, 9.0.0a2, 9.0.0a3, 9.0.0b1, 9.0.0rc1, 9.0.1, 9.1.0, 9.2.0, 9.3.0, 9.4.0, 9.5.1, 9.6.1, 9.7.0, 9.8.0, 9.9.0, 9.10.0, 9.11.0, 10.0.0a1, 10.0.0a2, 10.0.0a3, 10.0.0b1, 10.0.0rc1, 10.0.1, 10.1.0, 10.2.0, 10.3.0, 10.4.0, 10.5.0, 11.0.0a1)
ERROR: No matching distribution found for ansible==0

2. Ansible 9.11.0をインストール

Ansible 9.xの最新バージョンとなるAnsible 9.11.0をインストールする。

# python3 -m pip install ansible=='9.11.0'

Ansibleのバージョンを確認するとAnsible core 2.16.12になっていることがわかる。

# ansible --version
ansible [core 2.16.12]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.12/site-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.12.3 (main, Jul  2 2024, 16:34:01) [GCC 8.5.0 20210514 (Red Hat 8.5.0-22)] (/usr/bin/python3)
  jinja version = 3.1.4
  libyaml = True

3. 動作確認

あらためて、dnfモジュールを含めたPlaybookを実行すると、以下の通り成功した。

TASK [Update gitlab packages] **************************************************************************************************************************************************************************************
changed: [t1026gitl]

以上で、Ansibleのダウングレード手順は完了となる。今後は、RHEL 8系のサーバーを徐々にRHEL 9系に移行し、Ansibleの最新バージョンが利用できるよう環境を整えていきたい。

2024年10月5日土曜日

コンテナレジストリ「Harbor」バージョンアップ手順

Docker Hubのようにコンテナイメージを格納し、Dockerにてイメージをダウンロード(Pull)して利用できるようにするサービスをコンテナリポジトリと呼ぶ。

コンテナレジストリの「Harbor」は、OSSのコンテナレジストリであり、自宅検証環境にプライベートのコンテナレジストリを構築することができる。

↓コンテナレジストリ「Harbor」のインストール手順はこちら。

OSSのコンテナレジストリ「Harbor」インストール手順

本記事では、コンテナレジストリ「Harbor」バージョンアップ手順を記載する。

環境

Harbor自体はDockerコンテナとして動作する。Harbor及びDockerが動作するOSとしてはAlmaLinuxを使用した。

OS : AlmaLinux release 8.10
Docker : 20.10.21
Docker Compose : v2.12.2
Harbor : v2.8.0→v2.11.1

今回の作業の簡単な概要図を以下に記載する。

バージョンアップ手順

1. アップグレードパスを確認

Harborはアップグレードパスが存在し、場合によっては段階的にバージョンアップ作業を行う必要がある。

アップグレードパスは残念ながらマニュアル等でまとまったページはないため、各バージョンアップ手順の記述を見て判断する必要がある。

今回の場合は、v2.8→v2.11のバージョンアップとなるので、まずはv2.11のマニュアルを確認する。

Upgrade Harbor and Migrate Data (v2.11)

This guide covers upgrade and migration to v2.11.0. This guide only covers migration from v2.9.0 and later to the current version. If you are upgrading from an earlier version, refer to the migration guide for an earlier Harbor version.

上記の記載にあるように、v2.9.0以降であれば直接バージョンアップができるが、そうでない場合は、古いバージョンのマニュアルを見ること、と記載されている。

次にv2.9のマニュアルを確認する。

Upgrade Harbor and Migrate Data (v2.9)

This guide covers upgrade and migration to v2.9.0. This guide only covers migration from v2.7.0 and later to the current version. If you are upgrading from an earlier version, refer to the migration guide for an earlier Harbor version.

こちらはv2.7.0以降であれば直接バージョンアップできる。今回はv2.8からのバージョンアップとなるので、アップグレードパスは「v2.8→v2.9→v.211」となることが確認できた。

2. インストーラの入手

Harborのインストーラは、オンラインインストーラとオフラインインストーラの2種類が用意されている。今回はオフラインインストーラを用いる。ダウンロードは以下URLからダウンロードすることができる。

Releases - goharbor/harbor

今回の場合は、以下2つのファイルをダウンロードした。

harbor-offline-installer-v2.9.5.tgz
harbor-offline-installer-v2.11.1.tgz

3. Harbor停止

まず、起動中のHarborを停止する。

cd ~/harbor/
docker compose down

4. バックアップ

現在のバージョンのHarborの設定ファイルとデータベースのバックアップを行う。

cd ~
mkdir backup_2.8
mv harbor backup_2.8/harbor_2.8
cp -r /data/database ~/backup_2.8/

5. 新バージョンのファイルを展開

ダウンロードしたインストーラを展開し、インストーラに含まれるDockerイメージをロードする。

tar zxf harbor-offline-installer-v2.9.5.tgz
docker image load -i harbor/harbor.v2.9.5.tar.gz

6. 設定ファイルをマイグレーション

設定ファイル(harbor.yml)をマイグレーションする。

ls -l ~/backup_2.8/harbor_2.8/harbor.yml
cp ~/backup_2.8/harbor_2.8/harbor.yml ~/harbor
docker run -it --rm -v /:/hostfs goharbor/prepare:v2.9.5 migrate -i ~/harbor/harbor.yml

実際の実行結果は以下となる。

# docker run -it --rm -v /:/hostfs goharbor/prepare:v2.9.5 migrate -i ~/backup_2.8/harbor_2.8/harbor.yml
migrating to version 2.9.0
Written new values to /root/harbor/harbor.yml

7. 新バージョンインストール

以上で準備が整ったので、新バージョンのHarborをインストールおよび起動する。インストールはinstall.shを実行して実施する。

cd ~/harbor
./install.sh

8. ターゲットバージョンとなるまで、手順3～7を繰り返す

ターゲットバージョンとなるまで、手順3～7を繰り返す。バージョンが変わるため、フォルダパスやインストーラのファイル名の読み替えは必要となるが、手順に変更はない。

以下、参考情報として、v2.9→v2.11へのバージョンアップ手順を記載する。

cd ~/harbor/
docker compose down

cd ~
mkdir backup_2.9
mv harbor backup_2.9/harbor_2.9
cp -r /data/database ~/backup_2.9/

tar zxf harbor-offline-installer-v2.11.1.tgz
docker image load -i harbor/harbor.v2.11.1.tar.gz

ls -l ~/backup_2.9/harbor_2.9/harbor.yml
cp ~/backup_2.9/harbor_2.9/harbor.yml ~/harbor
docker run -it --rm -v /:/hostfs goharbor/prepare:v2.11.1 migrate -i ~/harbor/harbor.yml

cd ~/harbor
./install.sh

以上で、コンテナレジストリ「Harbor」バージョンアップ手順は完了となる。

2024年9月22日日曜日

RHEL系のOSに導入したAnsibleをバージョンアップする手順

自宅ではAnsibleを用いて各種作業の自動化を進めている。Ansibleのインストール手順は以下に記載している。

AnsibleコントロールノードをAlmaLinux上に構築する

上記は、2022年7月にインストールした記事であり、Ansibleのバージョンが6.0.0とかなり古くなっていた。

Ansibleのバージョン情報は、以下URLから確認することができ、Ansible core 2.13に該当するAnsible 6.xはすでにUnmaintained (end of life)となっている。

Releases and maintenance - Ansible Documentation

本記事では、RHEL系のOSに導入したAnsibleをバージョンアップする手順を記載する。

環境

コントロールノードとなるOSは、AlmaLinuxを用いる。Red Hat系のディストリビューションであるRHELやRocky Linuxなどでも同様の手順で作業ができるだろう。

OS : AlmaLinux 8.5
Python : 3.8 → 3.9
Ansible : 6.0.0 → 8.1.0

また、以下バージョンにおいても同様の手順で実施できることを確認している。

OS : AlmaLinux 8.10
Python : 3.9 → 3.12
Ansible : 8.3.0 → 10.4.0

Ansibleバージョンアップ手順

1. pipを最新バージョンに更新

Ansibleインストール前に、pip自体を最新化する。

# python3 -m pip install --upgrade pip

2. インストール可能なAnsibleのバージョンを確認

pipを使ってインストール可能なバージョンを確認してみる。pip install [インストールモジュール名]=='0'のように存在しないバージョンを記載すると、インストール可能なバージョンの一覧が表示される。

以下の通り、Python 3.8の場合は、Ansible 6.xまでしか表示されない。そのため、以降の手順でPython 3.9のインストールを行うことにする。

# python3 -m pip install --upgrade ansible=='0'
～(中略)～
ansible== (from versions: (中略) 6.0.0, 6.1.0, 6.2.0,
6.3.0, 6.4.0, 6.5.0, 6.6.0, 6.7.0)
ERROR: No matching distribution found for ansible==0

3. Pythonをインストール

Ansibleを利用する場合、Pythonも対応するバージョンを使用する必要がある。例えば、最近のバージョンでは以下のバージョン制約がある。

Ansible	Python
10.x	3.10-3.12
9.x	3.10-3.12
8.x	3.9-3.11
7.x	3.9-3.11
6.x	3.8-3.10

Ansibleのバージョン8.1.0の場合は、Python 3.9及びpipをインストールする。

# dnf install python39-pip -y

4. 通常使用するPythonの入れ替え

通常利用するPythonをPython変更するため、alternativesを使って、以下の通り設定する。以下はPython 3.6をPython 3.9に変更する手順となる。

# ls -l /usr/bin/python3*
lrwxrwxrwx 1 root root   25  7月  1  2022 /usr/bin/python3 -> /etc/alternatives/python3
lrwxrwxrwx 1 root root   31 10月 10  2021 /usr/bin/python3.6 -> /usr/libexec/platform-python3.6
lrwxrwxrwx 1 root root   32 10月 10  2021 /usr/bin/python3.6m -> /usr/libexec/platform-python3.6m
-rwxr-xr-x 1 root root 7760  4月 21  2022 /usr/bin/python3.8
-rwxr-xr-x 1 root root 7768  4月  4 01:41 /usr/bin/python3.9

# alternatives --list
libnssckbi.so.x86_64    auto    /usr/lib64/pkcs11/p11-kit-trust.so
python                  auto    /usr/libexec/no-python
ifup                    auto    /usr/libexec/nm-ifup
cifs-idmap-plugin       auto    /usr/lib64/cifs-utils/cifs_idmap_sss.so
python3                 manual  /usr/bin/python3.8
libwbclient.so.0.15-64  auto    /usr/lib64/samba/wbclient/libwbclient.so.0.15

# alternatives --set python3 /usr/bin/python3.9

# alternatives --list
libnssckbi.so.x86_64    auto    /usr/lib64/pkcs11/p11-kit-trust.so
python                  auto    /usr/libexec/no-python
ifup                    auto    /usr/libexec/nm-ifup
cifs-idmap-plugin       auto    /usr/lib64/cifs-utils/cifs_idmap_sss.so
python3                 manual  /usr/bin/python3.9
libwbclient.so.0.15-64  auto    /usr/lib64/samba/wbclient/libwbclient.so.0.15

5. 再度、インストール可能なAnsibleのバージョンを確認

再度、pipを最新化したのち、インストール可能なAnsibleのバージョンを確認する。今度は、8.xのバージョンがインストール可能となっていることがわかる。

# python3 -m pip install --upgrade pip

# python3 -m pip install --upgrade ansible=='0'
～(中略)～
ansible== (from versions: (中略) 6.0.0, 6.1.0, 6.2.0,
6.3.0, 6.4.0, 6.5.0, 6.6.0, 6.7.0, 7.0.0a1, 7.0.0a2,
7.0.0b1, 7.0.0rc1, 7.0.0, 7.1.0, 7.2.0, 7.3.0, 7.4.0,
7.5.0, 7.6.0, 7.7.0, 8.0.0a1, 8.0.0a2, 8.0.0a3,
8.0.0b1, 8.0.0rc1, 8.0.0, 8.1.0)
ERROR: No matching distribution found for ansible==0

6. Ansibleバージョンアップ

Pythonをインストールしたら、インストール対象のAnsibleのバージョン(今回は8.1.0)を指定して、以下の通りAnsibleをインストールする。

# python3 -m pip install ansible=='8.1.0'

問題なくインストールされたことを以下コマンドで確認する。Ansible 8.1.0がインストールされ、ansibleコマンドの表示バージョンがansible core 2.15となっていることがわかる。

# pip3 list
Package             Version
------------------- -------
ansible             8.1.0
ansible-core        2.15.1
cffi                1.15.1
cryptography        41.0.1
importlib-resources 5.0.7
Jinja2              3.1.2
MarkupSafe          2.1.3
packaging           23.1
pip                 20.2.4
pycparser           2.21
PyYAML              6.0
resolvelib          1.0.1
setuptools          50.3.2

# ansible --version
ansible [core 2.15.1]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.9/site-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.9.16 (main, Apr  3 2023, 12:39:37) [GCC 8.5.0 20210514 (Red Hat 8.5.0-18)] (/usr/bin/python3)
  jinja version = 3.1.2
  libyaml = True

7. Ansible関連のPythonモジュールを追加

最後に、Ansibleを実行する際に必要となるPythonモジュールをインストールする。

私の環境の場合は以下をインストールした。

モジュール	用途
ansible-lint	Ansible Lint(構文チェックツール)本体。
jmespath	Ansible Lintの構文チェックで利用されるモジュール。
pywinrm	Windows操作用モジュール。
pyvmomi	vSphere操作用モジュール。
zabbix-api	Zabbix操作用モジュール。
passlib	パスワードハッシュ用モジュール。

# python3 -m pip install ansible-lint jmespath
# python3 -m pip install pywinrm pyvmomi zabbix-api passlib

以上で、RHEL系のOSに導入したAnsibleのバージョンアップ手順は完了となる。

Ansible 8.1.0へバージョンアップ後も、ほとんどのPlaybookはそのまま実行させることができたが、Zabbix操作のPlaybookは接続時の指定方法が変更となっており、そのままでは実行できなかった。Ansibleを用いたZabbixの操作方法の最新手順は、以下別記事に記載する。

AnsibleでZabbixを操作する (Ansible 8.1 [core 2.15]対応)

また、Ansible core 2.17以降は、ターゲット側にPython 3.7以降のインストールが必須となっているため注意すること(それ以前はPython 2.7の実行が可能だった)。

更新履歴

2023/7/1 新規作成
2024/9/22 汎用的に使用できるよう、記載を修正

2024年9月15日日曜日

vSphere環境のRHELのネットワークデバイスの名称ルール (ens192、224…) を確認してみた

RHEL 7以降より、ネットワークデバイスが従来のeth0、eth1といったものからens192、ens224といった名称に変更になっている。これは、「biosdevname」と呼ばれる仕組みで名称が決定されるようになった。

この名称ルールによって、vSphereの仮想環境に構築したRHELのネットワークデバイスは、必ず「ensNNN (NNNは数字3桁)」となる。「en」はEthernetを示し「s」はホットプラグの意味となり、末尾3桁の数字は、PCIスロットの「Physical Slot」の値で決定するようだ。

上記法則は調べてわかったのだが、実際は末尾3桁の付与される法則は連番で付与されるものではなく、毎回NICを追加してからネットワークデバイス名称を確認する作業が必要となってしまう。そこで、実際にvSphereの仮想環境で、RHEL 8及びRHEL 9の仮想マシンに仮想NICを10本を付けた際のネットワークデバイス名の命名ルールを確認することにした。

なお、ESXi 7とESXi 8ではPhysical Slotの番号が変わったことにより、ネットワークデバイス名も変更となっている。

ネットワークデバイス名 (ESXi 7)

ESXi 7にRHELをインストールし、OSを起動した状態で、1個ずつ仮想NIC追加し確認を行った。付与されるネットワークデバイス名称は以下のようになった。

NIC番号	デバイス名
1	ens192
2	ens224
3	ens256
4	ens161
5	ens193
6	ens225
7	ens257
8	ens162
9	ens194
10	ens226

どうやらネットワークデバイス名称の数字は以下のように32ずつ増加して推移するようだ。なお、ens160が存在しない理由は、Physical Slotの160を「VMware PVSCSI SCSI Controller」が利用しているためとなる。

なお、「Physical Slot」はlspciコマンドで確認ができる。確かに、「Physical Slot」の値と名称は一致しているようだ。

# lspci -v
～(中略)～

03:00.0 Serial Attached SCSI controller: VMware PVSCSI SCSI Controller (rev 02)
        Subsystem: VMware PVSCSI SCSI Controller
        Physical Slot: 160
        Flags: bus master, fast devsel, latency 0, IRQ 18
        I/O ports at e000 [size=8]
        Memory at fe900000 (64-bit, non-prefetchable) [size=32K]
        Expansion ROM at fe910000 [disabled] [size=64K]
        Capabilities: [40] Express Endpoint, MSI 00
        Capabilities: [7c] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [94] Power Management version 3
        Capabilities: [9c] MSI-X: Enable+ Count=24 Masked-
        Capabilities: [100] Device Serial Number 57-0d-a1-90-50-05-05-68
        Kernel driver in use: vmw_pvscsi
        Kernel modules: vmw_pvscsi

～(中略)～

1b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
        Subsystem: VMware VMXNET3 Ethernet Controller
        Physical Slot: 256
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at fd103000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd102000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd100000 (32-bit, non-prefetchable) [size=8K]
        I/O ports at 4000 [size=16]
        Expansion ROM at fd110000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [48] Express Endpoint, MSI 00
        Capabilities: [84] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [9c] MSI-X: Enable+ Count=25 Masked-
        Capabilities: [100] Device Serial Number 00-0c-29-ff-ff-5a-a4-cb
        Kernel driver in use: vmxnet3
        Kernel modules: vmxnet3

1c:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
        Subsystem: VMware VMXNET3 Ethernet Controller
        Physical Slot: 257
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at fd003000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd002000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd000000 (32-bit, non-prefetchable) [size=8K]
        I/O ports at 3000 [size=16]
        Expansion ROM at fd010000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [48] Express Endpoint, MSI 00
        Capabilities: [84] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [9c] MSI-X: Enable+ Count=25 Masked-
        Capabilities: [100] Device Serial Number 00-0c-29-ff-ff-5a-a4-f3
        Kernel driver in use: vmxnet3
        Kernel modules: vmxnet3

ネットワークデバイス名 (ESXi 8)

ESXi 8にRHELをインストールし、OSを起動した状態で、1個ずつ仮想NIC追加し確認を行った。付与されるネットワークデバイス名称は以下のようになった。

NIC番号	デバイス名
1	ens34
2	ens37
3	ens38
4	ens39
5	ens40
6	ens41
7	ens42
8	ens43
9	ens44
10	ens45

こちらはESXi 7と異なり、1つ目のNICのデバイス名はens34となり、2つ目以降は37番から1ずつ増加して名称が割り当てられることが確認できた。

参考

11.6. BIOSDEVNAME を使用した一貫性のあるネットワークデバイスの命名

更新履歴

2020/8/29 新規作成
2024/9/15 ESXi 8の場合のデバイス名の記載を追加

2024年9月14日土曜日

Oracle VM VirtualBox (Windows版)＆Guest Additionsインストール手順 (6.1、7.1対応)

WindowsやMACのPCにて手軽にLinuxなどの検証を行いたい場合がある。そのような場合には、PCにインストール可能なホスト側仮想化ソフトウェアを利用し、Linuxの仮想マシンを構築することができる。

ホスト型仮想化ソフトウェアとして利用可能なものは、以下のようなものがある。

製品名	プラットフォーム	説明
Oracle VM VirtualBox	Windows, macOS, Linuxなど	様々なプラットフォームで動作し、無償であるにも関わらずかなり柔軟に仮想マシンの設定が可能。また、Vagrantを使えば構築の自動化も可能。
VMware Workstation Player	Windows	vSphereでおなじみのVMwareのホスト型仮想化ソフトウェア。
VMware Fusion Player	macOS	macOSを所有していないため評価不可。

今回は、「Oracle VM VirtualBox」をWindows環境にインストールし、VirtualBox上にWindows Server 2019とRHEL 8.4をインストールする手順を記載する。

環境

VirtualBoxをインストールする手ごろなWindowsクライアントがすぐに用意できなかったため、たまたまインストールしていたWindows Server 2022 PreviewにVirtualBoxをインストールしたが、他Windows環境でも手順に差異はないだろう。

また、VirtualBoxは6.1.24と7.1.0の二種類でインストールを確認しているが、本記事の画面は6.1.24のものを記載する。

Windows Server 2022 Preview
Oracle VM VirtualBox 6.1.24 / 7.1.0

なお、私の環境はESXi上のOSにVirtualBoxをインストールする構成となる。このような構成の場合は、ESXiのCPUの設定にて「ハードウェアアシストによる仮想化をゲスト OS に公開」を有効にすること。

Oracle VM VirtualBoxインストール手順

1. Oracle VM VirtualBoxのダウンロード

VirtualBox本家とOracle 日本のいずれかからVirtualBoxのダウンロードができる。Oracle 日本でダウンロードできるバージョンは少し古くなってしまうことから、特に理由がなければ本家からダウンロードすれば問題ない。

また、同じサイトでダウンロードできるOracle VM VirtualBox Extension Packもダウンロードしておく。Extension Packをインストールすることで、USBコントローラやディスク暗号化などの拡張機能を利用することができる。

2. (VirtualBox 7以降)Pythonのインストール

VirtualBoxの前提として、Pythonとpywin32のインストールが必要となる。Pythonは以下からダウンロードしてインストールする。Pythonは管理者として実行してインストールすること。

Python Releases for Windows | Python.org

Pythonインストール後、PowerShellを開き、pywin32をインストールする。

pip install pywin32 --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --trusted-host pypi.org

3. VirtualBox本体のインストール

ダウンロードしたexeファイルをダブルクリックすれば、インストールウィザードを起動する。基本的には、すべてを「次へ」を押して進めばよい。

インストールが開始されると、「このデバイスをインストールしますか?」と表示されるので、「インストール」を選んでおく。

4. Extension Packのインストール

VitualBoxをインストールしたのち、Extension Packのファイル (vbox-extpack) をダブルクリックすることでインストールを開始することができる。

ライセンス規約が表示されるので、一番下までスクロールしたのち、「同意します」を選択する。

インストールが成功すると、以下のような「拡張機能パッケージ Oracle VM Virtual Box Extension Pack のインストールに成功しました。」のメッセージが表示される。
※完了メッセージが表示されない場合もある模様。

VirtualBox上にWindows Server 2019をインストール

1. 仮想マシンを作成

「新規」ボタンをクリックすることで、仮想マシンの作成ウィザードが表示される。以下のように設定を行い仮想マシンを作成する。

設定値	説明
名前	任意で指定。今回はwin2019とする。
タイプ	Microsoft Windows
バージョン	Windows 2019 (64-bit)
メモリーサイズ	任意で指定。デフォルトは2048MB
ハードディスク	「仮想ハードディスクを作成する」を選択
ハードディスクのファイルタイプ	デフォルトの「VDI (VirtualBox Disk Image)」を選択する。なお、「VHD」 (Hyper-Vで使用) や「VMDK」 (ESXiで使用) も選択可能。
物理ハードディスクにあるストレージ	可変サイズと固定サイズが選択できる。いわゆるシックプロビジョニングとシンプロビジョニングに対応する。「固定」の場合はディスク作成時にすべての容量が割り当てられてしまい効率が悪いので、使用した分だけディスクサイズを割り当てていく「可変」を選択する。
ファイルの場所とサイズ	任意で指定。デフォルトは50GB

2. OSをインストールメディアから起動

作成した仮想マシンの「設定」を開き、「ストレージ」→「光学ドライブ」を選択する。CDマークを選択し、「ディスクファイルを選択」を選択し、Windows Server 2019のISOイメージを選択する。

仮想マシンの起動モードは以下3種類ある。VirtualBox用語となっており、初見では動作の違いが判らないため、それぞれの違いを以下に記載する。

起動モード	説明
通常起動	起動時に仮想マシンのコンソールが開く。コンソールを閉じる際は、「状態保存 (いわゆるサスペンド)」または「仮想マシンの停止」のみ選択が可能。
ヘッドレス起動	起動時に仮想マシンのコンソールが開かない。起動後に「表示」を選択することで仮想マシンのコンソールを開くことができる。コンソールを閉じる際に「バックグラウンドで動作を継続」を選択することで、仮想マシンのコンソールを閉じても起動状態を継続させることが可能。
デタッチモード起動	起動時に仮想マシンのコンソールが開く。それ以外は「ヘッドレス起動」と同様となり、「バックグラウンドで動作を継続」を選択可能。

通常は、仮想マシンのバックグラウンドでの起動が選択可能な、「デタッチモード起動」を選択しておけば問題ないだろう。

3. OSインストール

Windows Serverのインストールメディアを読み込むので、Enterを押しインストールを開始させる。インストール手順自体は特に通常と変更は不要であるため割愛する。

インストール完了後はインストールメディアは不要となることから、「デバイス」→「光学ドライブ」→「仮想ドライブからディスクを除去」を選択しインストールメディアを取り出しておこう。

4. Guest Additionsをインストール

VirtualBoxでは「Guest Additions」と呼ばれる、ESXiでいうところのVMware Toolsと同様の機能を待つエージェントのインストールが推奨される。

「デバイス」→「Guest Additions CDイメージの挿入…」を選択する。

すると、仮想CDドライブに「VirtualBox Guest Additions」というメディアがマウントされるので、これをダブルクリックすることでインストールウィザードが開始される。インストールウィザードでは、基本的には、すべてを「次へ」を押して進めばよい。

インストールが開始されると、「このデバイスをインストールしますか?」と表示されるので、「インストール」を選んでおく。

最後に再起動を求められるため、再起動して完了となる。

Guest Additionsが正常にインストールされていることの確認は、「仮想マシン」→「セッション情報」→「ランタイム情報」から確認することができる。

VirtualBox上にRHEL 8.4をインストール

1. 仮想マシンを作成～OSインストール

Windows Serverと同様の手順となるため割愛する。

2. Guest Additionsをインストール

RHELに対してGuest Additionsをインストールする場合は、GUIではなくCLIによるインストールを行う。

まず、前提パッケージとして以下が必要となる。

kernel-headers
kernel-devel
tar
bzip2
gcc
make
perl
elfutils-libelf-devel

上記パッケージをdnfまたはyumを使ってインストールを行うのだが、インターネット経由でインストールする場合、ネットワーク設定やサブスクリプション登録など手順が多くなる。そこで、今回はRHELのOSインストールメディアに含まれるパッケージを用いてインストールを行う。

まず、OSインストールメディアのパッケージが含まれるディレクトリをリポジトリとして登録する。

# cat << EOF > /etc/yum.repos.d/dvd-base.repo
[dvd-base]
baseurl=file:///media/BaseOS/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
EOF

# cat << EOF > /etc/yum.repos.d/dvd-appstream.repo
[dvd-appstream]
baseurl=file:///media/AppStream/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
EOF

次にOSインストールメディアをマウントし、dnfにてパッケージのインストールを行う。

# mount /dev/cdrom /media/
mount: /media: 警告: デバイスは書き込み禁止です、読み込み専用でマウントします.
# dnf install kernel-headers kernel-devel -y
# dnf install tar bzip2 gcc make perl elfutils-libelf-devel -y
# eject /dev/sr0

次に、OSインストールメディアを「Guest Additions」のメディアに変更する。Windows Serverの手順と同様、「デバイス」→「Guest Additions CDイメージの挿入…」を選択したのち、VBoxLinuxAdditions.runを実行すると、自動的にGuest Additionsがインストールされる。

# mount /dev/cdrom /media/
mount: /media: 警告: デバイスは書き込み禁止です、読み込み専用でマウントします.

# /media/VBoxLinuxAdditions.run
Verifying archive integrity... All good.
Uncompressing VirtualBox 6.1.24 Guest Additions for Linux........
VirtualBox Guest Additions installer
Removing installed version 6.1.24 of VirtualBox Guest Additions...
Copying additional installer modules ...
Installing additional modules ...
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel
modules.  This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel
4.18.0-305.el8.x86_64.
ValueError: File context for /opt/VBoxGuestAdditions-6.1.24/other/mount.vboxsf already defined

最後に再起動をしておく。

# reboot

再起動後、Guest Additionsのサービスvboxaddの正常起動を確認できれば完了となる。

# systemctl status vboxadd
● vboxadd.service
     Loaded: loaded (/opt/VBoxGuestAdditions-7.1.0/init/vboxadd; enabled; preset: disabled)
     Active: active (exited) since Fri 2024-09-13 22:13:12 JST; 56s ago
    Process: 43447 ExecStart=/opt/VBoxGuestAdditions-7.1.0/init/vboxadd start (code=exited, status=0/SUCCESS)
   Main PID: 43447 (code=exited, status=0/SUCCESS)
        CPU: 483ms

 9月 13 22:13:12 localhost.localdomain systemd[1]: Starting vboxadd.service...
 9月 13 22:13:12 localhost.localdomain vboxadd[43447]: VirtualBox Guest Additions: Starting.
 9月 13 22:13:12 localhost.localdomain systemd[1]: Finished vboxadd.service.

更新履歴

2021/8/14 新規作成
2024/9/14 VirtualBox 7.1.0のインストール結果を反映

2024年9月4日水曜日

Fluentdを使ってKubernetesのログをsyslogで送信する

KubernetesのPodのログはファイルに出力はされているが、1台のサーバーにログ集約を行い一元管理をしたい場合がある。そのような用途で利用されるソフトウェアとしてFluentdがある。

本記事では、Fluentdを使ってKubernetesのログをsyslogで送信する手順を記載する。

環境

今回の環境の構成概要図を以下に記載する。赤枠個所が本記事の設定個所となる。

以下に今回構築する各種ソフトウェアのバージョンを記載する。

ホストOS : AlmaLinux 8.6
Docker : 24.0.6
cri-dockerd: 0.3.4
Kubernetes: v1.29.4

Fluentd導入

1. `fluentd-kubernetes-daemonset`のマニフェストファイルをダウンロード

FluentdをKubernetesで動作させるため、fluentd-kubernetes-daemonsetを導入する。マニフェストファイルは以下からダウンロードできる。

https://github.com/fluent/fluentd-kubernetes-daemonset/tree/master

今回はsyslogによるログ送信をしたいことから、fluentd-daemonset-syslog.yamlをダウンロードする。ダウンロード方法は任意となるが、curlを使う場合は以下の通り行う。

# curl -LO https://raw.githubusercontent.com/fluent/fluentd-kubernetes-daemonset/master/fluentd-daemonset-syslog.yaml

2. マニフェストファイルを修正

マニフェストファイルそのままではsyslogファイルを正常に送ることができないため、以下の★箇所の修正を行う。

`fluentd-daemonset-syslog.yaml`

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
    version: v1

～(中略)～

---
apiVersion: apps/v1
kind: DaemonSet

～(中略)～

      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-syslog
        env:
          - name: K8S_NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name:  SYSLOG_HOST
            value: "192.168.1.1" # ★ログ送信先のsyslogサーバーを指定
          - name:  SYSLOG_PORT
            value: "514" # ★ポート番号を変更する場合は修正
          - name:  SYSLOG_PROTOCOL
            value: "tcp" # ★udpまたはtcpを指定
          - name:  FLUENTD_SYSTEMD_CONF
            value: "disable" # ★"No such file or directory retrying in 1s"のエラーログ抑止のため指定
          - name:  TZ
            value: "Asia/Tokyo" # ★Fluentdのログのタイムゾーンを指定(デフォルトはUTC)
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        # When actual pod logs in /var/lib/docker/containers, the following lines should be used.
        - name: dockercontainerlogdirectory     # ★アンコメント
          mountPath: /var/lib/docker/containers # ★アンコメント
          readOnly: true                        # ★アンコメント
        # When actual pod logs in /var/log/pods, the following lines should be used.
        #- name: dockercontainerlogdirectory    # ★コメントアウト
        #  mountPath: /var/log/pods             # ★コメントアウト
        #  readOnly: true                       # ★コメントアウト
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      # When actual pod logs in /var/lib/docker/containers, the following lines should be used.
      - name: dockercontainerlogdirectory  # ★アンコメント
        hostPath:                          # ★アンコメント
          path: /var/lib/docker/containers # ★アンコメント
      # When actual pod logs in /var/log/pods, the following lines should be used.
      #- name: dockercontainerlogdirectory # ★コメントアウト
      #  hostPath:                         # ★コメントアウト
      #    path: /var/log/pods             # ★コメントアウト

3. マニフェストファイルをapply

修正したマニフェストファイルapplyする。

# kubectl apply -f fluentd-daemonset-syslog.yaml
serviceaccount/fluentd created
clusterrole.rbac.authorization.k8s.io/fluentd created
clusterrolebinding.rbac.authorization.k8s.io/fluentd created
daemonset.apps/fluentd created

成功すると、fluentdのPodが各KubernetesノードでRunningとなるはずだ。

# kubectl get pod -n=kube-system
NAME                                READY   STATUS    RESTARTS      AGE
coredns-76f75df574-dntsp            1/1     Running   1 (51d ago)   105d
coredns-76f75df574-lswd4            1/1     Running   1 (51d ago)   105d
etcd-t1051kube                      1/1     Running   1 (51d ago)   105d
etcd-t1052kube                      1/1     Running   1 (51d ago)   105d
etcd-t1053kube                      1/1     Running   1 (51d ago)   105d
fluentd-k98t7                       1/1     Running   0             18s
fluentd-pn55s                       1/1     Running   0             18s
fluentd-xq6rb                       1/1     Running   0             18s
kube-apiserver-t1051kube            1/1     Running   1 (51d ago)   105d
kube-apiserver-t1052kube            1/1     Running   1 (51d ago)   105d
kube-apiserver-t1053kube            1/1     Running   1 (51d ago)   105d
kube-controller-manager-t1051kube   1/1     Running   3 (20d ago)   105d
kube-controller-manager-t1052kube   1/1     Running   2 (51d ago)   105d
kube-controller-manager-t1053kube   1/1     Running   2 (19d ago)   105d
kube-proxy-7lhj5                    1/1     Running   1 (51d ago)   105d
kube-proxy-gx8rj                    1/1     Running   1 (51d ago)   105d
kube-proxy-krjfz                    1/1     Running   1 (51d ago)   105d
kube-scheduler-t1051kube            1/1     Running   3 (51d ago)   105d
kube-scheduler-t1052kube            1/1     Running   1 (51d ago)   105d
kube-scheduler-t1053kube            1/1     Running   3 (19d ago)   105d

4. 動作確認

ログ送信先となるsyslogサーバーにてログの受信状況を確認する。以下は私の環境の例となる。Fluentd経由でSquidのPodの標準出力に対して出力された接続ログが出力されている。
※Podのログを収集する場合、標準出力に対して出力させるようコンテナを構成する必要があるため注意する。

Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.225  83353 10.244.1.0 TCP_TUNNEL/200 6767 CONNECT www.googleapis.com:443 - HIER_DIRECT/172.217.175.234 -
Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.225  63309 10.244.3.0 TCP_TUNNEL/200 2408 CONNECT play.google.com:443 - HIER_DIRECT/142.251.222.14 -
Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.225 138131 10.244.0.1 TCP_TUNNEL/200 28279 CONNECT apis.google.com:443 - HIER_DIRECT/172.217.175.238 -
Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.226  63194 10.244.0.1 TCP_TUNNEL/200 4006 CONNECT play.google.com:443 - HIER_DIRECT/142.251.222.14 -
Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.224  56514 10.244.1.0 TCP_TUNNEL/200 2491 CONNECT ogs.google.com:443 - HIER_DIRECT/142.250.196.110 -

以上で、Fluentdを使ってKubernetesのログをsyslogで送信する手順は完了となる。

2024年8月31日土曜日

rsyslogでリモートサーバーのログを集約管理する

大半のLinuxディストリビューションに導入されているrsyslogはリモートサーバーへログを送信したり、受信したりする機能がある。この機能を活用すると、1台のサーバーにてログの集約管理が実現できる。

本記事では、rsyslogでリモートサーバーのログを集約管理する手順を記載する。

環境

今回の環境の構成概要図を以下に記載する。赤枠個所が本記事の設定個所となる。

設定手順はAlmaLinux 9にて確認しているが、他のディストリビューションのrsyslogでも、同じ設定で対応が可能と思われる。

受信側設定

1. ログ保管用ディレクトリの作成

リモートサーバーのログを保管するディレクトリとして、/remotelogを作成する。また、ローテーションしたファイルを保管するディレクトリとして、配下に_oldディレクトリを作成する。

# mkdir /remotelog
# mkdir /remotelog/_old

2. rsyslogの設定

/etc/rsyslog.confの以下個所をアンコメントし、TCP及びUDPにてsyslog受信をできるよう設定する。

`/etc/rsyslog.conf`

module(load="imudp") # needs to be done just once
input(type="imudp" port="514")

module(load="imtcp") # needs to be done just once
input(type="imtcp" port="514")

次に、受信したsyslogに記載されているホスト名の情報をもとに、個別のファイルを作成する設定をrsyslogに対して行う。

templateにて動的にファイル名を設定するルールを作成し、それをactionのDynaFile(動的ファイル名)にて指定することで、リモートサーバーからsyslogを受信すると、自動的に/remotelog/[ホスト名].logというファイルを作成しログが保存される。

なお、ログ集約サーバー自身のログは、通常通り/var/log配下に出力させるため、if文で127.0.0.1のIPアドレスを除外するように設定した。

`/etc/rsyslog.d/41-recieve-log.conf`

# Template
template(name="TmplRemoteLogFile" type="string"
  string="/remotelog/%HOSTNAME%.log"
)

# Other remote servers
if $fromhost-ip != '127.0.0.1' then {
  action(type="omfile" DynaFile="TmplRemoteLogFile")
  stop
}

3. 設定反映

rsyslogの設定内容に問題がないことを以下コマンドで確認する。-Nオプションはコンフィグチェックのオプションとなる。

# rsyslogd -N 1
rsyslogd: version 8.2310.0-4.el9, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

問題なければrsyslogのサービス再起動を行い、設定を反映させる。

# systemctl restart rsyslog

設定反映後、TCP/514、UDP/514のポートでLISTENされていることを確認しておこう。

# ss -nl | grep 514
udp   UNCONN 0      0            0.0.0.0:514            0.0.0.0:*
udp   UNCONN 0      0            [::]:514               [::]:*
tcp   LISTEN 0      25           0.0.0.0:514            0.0.0.0:*
tcp   LISTEN 0      25           [::]:514               [::]:*

4. logrotateの設定

ファイルを日次でログローテートするよう、以下の通りlogrotateの設定を行う。olddirにてローテーション先のディレクトリを同一ディレクトリから変更している。

`/etc/logrotate.d/remotelog`

/remotelog/*.log
{
    daily
    rotate 7
    dateext
    compress
    delaycompress
    create 644 root root
    missingok
    olddir=/remotelog/_old
    sharedscripts
    postrotate
        /usr/bin/systemctl -s HUP kill rsyslog.service >/dev/null 2>&1 || true
    endscript
}

送信側設定

1. rsyslogの設定

先ほど設定したrsyslogサーバーにログを送信するため、以下ファイルを作成する。TCP送信とUDP送信で、微妙に記載方法が異なる。syslogというとUDPによる送信というイメージが強いが、ログの欠落が発生しづらい点からTCPによる送信が個人的にはお勧めの設定となる。

`/etc/rsyslog.d/40-send-log.conf`

TCPで送信する場合

*.* @@[rsyslogサーバーのIPアドレス]:514

UDPで送信する場合。

*.* @[rsyslogサーバーのIPアドレス]:514

2. 設定反映

rsyslogの設定内容に問題がないことを以下コマンドで確認する。-Nオプションはコンフィグチェックのオプションとなる。

# rsyslogd -N 1
rsyslogd: version 8.2310.0-4.el9, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

問題なければrsyslogのサービス再起動を行い、設定を反映させる。

# systemctl restart rsyslog

動作確認

送信元サーバーにてloggerコマンドを実行し、想定通りログが送信させることを確認する。

# logger "test syslog message"

rsyslogサーバーにてログが表示されれば成功となる。

# tail /remotelog/test-server.log
Aug 31 07:29:06 test-server root[605149]: test syslog message

以上で、rsyslogでリモートサーバーのログを集約管理する手順は完了となる。

2024年8月25日日曜日

Splunk本体とUniversal ForwarderをAlmaLinux 9にインストールする手順

自宅環境にてログ集約と解析ができるようにログ管理基盤を作ることにした。ログ解析にはSplunk を利用する方針とした。本記事では、Splunk本体とUniversal ForwarderをAlmaLinux 9にインストールする手順を記載する。

以下は自宅のログ管理基盤の構成概要図となる。赤枠個所が本記事の範囲となる。

環境

環境は以下の通りとなる。Splunk本体とUniversal Forwarderを導入するサーバーは別サーバーとしている。

OS : AlmaLinux 9.4
Splunk : 9.0.3
Splunk Universal Forwarder : 9.0.3

Splunkのインストール

1. Splunkインストーラのダウンロード

Splunkは以下URLからダウンロードできる。ダウンロードするためにはアカウント作成が必要となる。

https://www.splunk.com/ja_jp/download/splunk-enterprise.html

Linux版は、.deb、.rpm、.tgzの3点が選べるが、個人的お勧めは.tgzとなる。本手順も.tgzによるインストールを記載する。

2. インストール

ダウンロードしたファイル(本手順ではsplunk-9.3.0-51ccf43db5bd-Linux-x86_64.tgzというファイル名となる)をサーバーに配置し、以下コマンドで展開するのみでインストールは完了する。

tar xvzf splunk-9.3.0-51ccf43db5bd-Linux-x86_64.tgz -C /opt

3. Splunkの初回起動と初期設定

/opt/splunk/binディレクトリにSplunk本体の実行ファイルがあるので、以下の通り実行することで、初回起動時の以下処理が実行される。

ライセンス条項に同意
管理ユーザ名の設定 (デフォルトはadmin)
管理ユーザのパスワードの設定

# cd /opt/splunk/bin/
# ./splunk start
SPLUNK GENERAL TERMS

Last Updated: August 12, 2021

These Splunk General Terms ("General Terms") between Splunk Inc., a Delaware
corporation, with its principal place of business at 270 Brannan Street, San
Francisco, California 94107, U.S.A ("Splunk" or "we" or "us" or "our") and you
("Customer" or "you" or "your") apply to the purchase of licenses and
subscriptions for Splunk's Offerings. By clicking on the appropriate button,
or by downloading, installing, accessing or using the Offerings, you agree to
these General Terms. If you are entering into these General Terms on behalf of
Customer, you represent that you have the authority to bind Customer. If you
do not agree to these General Terms, or if you are not authorized to accept
the General Terms on behalf of the Customer, do not download, install, access,
or use any of the Offerings.

～(中略)～

Do you agree with this license? [y/n]: y　←★"y"を入力

This appears to be your first time running this version of Splunk.

Splunk software must create an administrator account during startup. Otherwise, you cannot log in.
Create credentials for the administrator account.
Characters do not appear on the screen when you type in credentials.

Please enter an administrator username: admin　←★管理者ユーザ名を入力
Password must contain at least:
   * 8 total printable ASCII character(s).
Please enter a new password:　 　　　←★パスワードを入力
Please confirm new password: 　　　　←★パスワードを再入力
Copying '/opt/splunk/etc/openldap/ldap.conf.default' to '/opt/splunk/etc/openldap/ldap.conf'.

～(中略)～

The Splunk web interface is at http://example:8000

5. 自動起動設定

.tgzファイルを解凍しただけなので、これだけではサーバ再起動時に自動起動してくれないため、コマンドで自動起動するよう設定する。ただし、AlmaLinux 9などのRHEL 9系においてchkconfigパッケージがインストールされていない場合、以下の通りエラーが発生する。

# /opt/splunk/bin/splunk enable boot-start
Can't create RC file "/etc/init.d/splunk": No such file or directory

そのため、chkconfigパッケージがインストールされていない場合はインストールを事前に行っておく。

# dnf install chkconfig -y

chkconfigインストール後、以下の通り実行し、自動起動設定を行う。

# /opt/splunk/bin/splunk enable boot-start
Init script installed at /etc/init.d/splunk.
Init script is configured to run at boot.

試しに再起動を行ったのちステータスを確認したところ、問題なくSplunkが「running」ステータスとなっていた。

# reboot

# uptime
 10:26:23 up 0 min,  1 user,  load average: 0.14, 0.03, 0.01
# /opt/splunk/bin/splunk status
splunkd is running (PID: 1411).
splunk helpers are running (PIDs: 1412 1565 1570 1799 1864).

6. 管理Web画面にアクセス

以上を実施したのち「http://<インストールしたホスト名 or IPアドレス>:8000」にアクセスすると、管理画面が表示されるはずなので、初回起動時に設定した管理者ユーザとパスワードでログインしてみよう。

ログインに成功すると、以下のようなSplunk の管理画面が表示される。

7. Splunk Universal Forwarderからの受信許可設定

管理画面の右上の「設定」＞「転送と受信」を選択し、「受信の設定」の「+新規追加」ボタンを押しておく。

受信ポートは9997を設定し、「保存」を選択する。

Splunk Universal Forwarderのインストール

1. Splunk Universal Forwarderインストーラのダウンロード

Splunk Universal Forwarderは以下URLからダウンロードできる。ダウンロードするためにはアカウント作成が必要となる。

https://www.splunk.com/ja_jp/download/universal-forwarder.html

Linux版は、.deb、.rpm、.tgzの3点が選べるが、個人的お勧めは.tgzとなる。本手順も.tgzによるインストールを記載する。

2. インストール

ダウンロードしたファイル(本手順ではsplunkforwarder-9.3.0-51ccf43db5bd-Linux-x86_64.tgzというファイル名となる)をサーバーに配置し、以下コマンドで展開するのみでインストールは完了する。

# tar xvzf splunkforwarder-9.3.0-51ccf43db5bd-Linux-x86_64.tgz -C /opt/

3. Splunkの初回起動と初期設定

/opt/splunk/binディレクトリにSplunk本体の実行ファイルがあるので、以下の通り実行することで、初回起動時の以下処理が実行される。

ライセンス条項に同意
管理ユーザ名の設定 (デフォルトはadmin)
管理ユーザのパスワードの設定

# cd /opt/splunkforwarder/bin/
# ./splunk start
SPLUNK GENERAL TERMS

Last Updated: August 12, 2021

These Splunk General Terms ("General Terms") between Splunk Inc., a Delaware
corporation, with its principal place of business at 270 Brannan Street, San
Francisco, California 94107, U.S.A ("Splunk" or "we" or "us" or "our") and you
("Customer" or "you" or "your") apply to the purchase of licenses and
subscriptions for Splunk's Offerings. By clicking on the appropriate button,
or by downloading, installing, accessing or using the Offerings, you agree to
these General Terms. If you are entering into these General Terms on behalf of
Customer, you represent that you have the authority to bind Customer. If you
do not agree to these General Terms, or if you are not authorized to accept
the General Terms on behalf of the Customer, do not download, install, access,
or use any of the Offerings.

～(中略)～

Do you agree with this license? [y/n]: y　←★"y"を入力

This appears to be your first time running this version of Splunk.

Splunk software must create an administrator account during startup. Otherwise, you cannot log in.
Create credentials for the administrator account.
Characters do not appear on the screen when you type in credentials.

Please enter an administrator username: admin　←★管理者ユーザ名を入力
Password must contain at least:
   * 8 total printable ASCII character(s).
Please enter a new password: 　 　　　←★パスワードを入力
Please confirm new password:  　　　　←★パスワードを再入力
Creating unit file...
Initd script /etc/init.d/splunk exists. splunk is currently enabled as init.d bootstart service.
Please run "splunk disable boot-start" first to disable it as init.d boot-start service
Failed to create the unit file. Please do it manually later.

～(中略)～

All preliminary checks passed.

Starting splunk server daemon (splunkd)...  
PYTHONHTTPSVERIFY is set to 0 in splunk-launch.conf disabling certificate validation for the httplib and urllib libraries shipped with the embedded Python interpreter; must be set to "1" for increased security
Done

5. 自動起動設定

.tgzファイルを解凍しただけなので、これだけではサーバ再起動時に自動起動してくれないため、コマンドで自動起動するよう設定する。Splunk本体と異なり、-user rootによる起動時の実行ユーザー指定が必要であり、かつsystemdによる登録となっており、chkconfigパッケージの導入は不要となる。

# /opt/splunkforwarder/bin/splunk stop
# /opt/splunkforwarder/bin/splunk enable boot-start -user root
Systemd unit file installed by user at /etc/systemd/system/SplunkForwarder.service.
Configured as systemd managed service.
# systemctl status SplunkForwarder
○ SplunkForwarder.service - Systemd service file for Splunk, generated by 'splunk enable boot-start'
     Loaded: loaded (/etc/systemd/system/SplunkForwarder.service; enabled; preset: disabled)
     Active: inactive (dead)
# systemctl start SplunkForwarder

6. 送信先のサーバ (インデクサー) を設定

Splunkのログ受信および解析を行う機能を「インデクサー」と呼ぶ。Universal Forwarderのログ送信先としてインデクサーを指定する必要があるため、splunk add forward-server <インデクサーのIPアドレス or ホスト名>:<ポート番号>コマンドにて行う。

# cd /opt/splunkforwarder/bin/
# ./splunk add forward-server 192.168.1.1:9997
Splunk username: admin
Password:
Added forwarding to: 192.168.1.1:9997.
# ./splunk list forward-server
Active forwards:
        None
Configured but inactive forwards:
        192.168.1.1:9997

本設定は、/opt/splunkforwarder/etc/system/local/outputs.confに記述される。

# cat /opt/splunkforwarder/etc/system/local/outputs.conf
[tcpout]
defaultGroup = default-autolb-group

[tcpout:default-autolb-group]
server = 192.168.1.1:9997

[tcpout-server://192.168.1.1:9997]

7. モニター対象のログを追加

今回は例として/var/log配下のログをすべて監視対象として、Splunk本体のインデクサーに送信する。splunk add monitor <モニター対象のファイル or ディレクトリ>コマンドで設定する。なお、本設定は再起動は不要で反映される。

# cd /opt/splunkforwarder/bin/
# ./splunk add monitor /var/log
Added monitor of '/var/log'.

splunk list monitorで設定確認を行う。ディレクトリが登録され、ディレクトリ内の各ファイルが表示されていれば問題ない。

# ./splunk list monitor
Monitored Directories:
	$SPLUNK_HOME/var/log/splunk
		/opt/splunkforwarder/var/log/splunk/audit.log
		/opt/splunkforwarder/var/log/splunk/btool.log
		/opt/splunkforwarder/var/log/splunk/conf.log

～(中略)～
	$SPLUNK_HOME/var/run/splunk/search_telemetry/*search_telemetry.json
	$SPLUNK_HOME/var/spool/splunk/tracker.log*
		/opt/splunkforwarder/var/spool/splunk/tracker.log
	/var/log　←★/var/log配下のログが追加されている。
		/var/log/anaconda
		/var/log/anaconda/anaconda.log
		/var/log/anaconda/dbus.log

～(以下略)～

8. 受信確認

Splunkにログインし「Search & Reporting」にて、index=*にてサーチを行い、ログが表示されることを確認しよう。

以上で、Splunk本体とUniversal ForwarderをAlmaLinux 9にインストールする手順は完了となる。

2024年8月11日日曜日

OpenAI APIを使ってZabbixの障害イベントを生成AIに連携する

ChatGPTでおなじみのOpenAIは、OpenAI APIと呼ばれるAPIによる利用が可能となっている。APIを利用することで、curlコマンドなどを用いて手軽に生成AIの機能をシステムに組み込んで利用することができる。

本記事では、OpenAI APIを使ってZabbixの障害アラートを生成AIに連携する手順を記載する。

具体的には、OpenAI APIを用いて以下のプロンプトを連携し、Zabbixの障害アラートの原因の問い合わせを行う。問い合わせで得られた生成AIの応答をZabbixのメッセージとして表示できるようにする。

Please tell me the cause of the error message below.
[障害アラートの内容]

なお、本記事の作成にあたり、以下の記事も参考にさせていただいた。

ZabbixとChatGPTを連携してみた（メディアタイプ編） – TechHarmony

環境

今回の環境は以下の通り。

Zabbix 7.0

OpenAIのアカウントを作成していない場合は、事前に作成をしておこう。ChatGPTを利用している場合は、すでにアカウント作成済みとなるため、新たにアカウント作成は不要となる。

OpenAI APIのAPI keyを取得

1. OpenAI API keyの作成画面にログイン

以下URLにアクセスすると、OpenAI API keyの作成画面が表示される。

https://platform.openai.com/account/api-keys

2. API keyを作成

「Create new secret key」ボタンを押し、API keyを作成する。

作成時にkeyの名前の入力を求められるが、未入力でも問題ない。

作成完了後、API keyが表示されるので、必ずコピーして控えること。ここでコピーしておかないと、以降確認することができないため、API keyを再作成する必要がある。

3. OpenAI APIの利用状況を確認

OpenAI APIはリクエストや応答に含まれるトークンの数によって課金される。トークンは英語の場合は1単語がおおよそ1トークンとなるようだが、日本語の場合は1文字が1トークン以上の場合があるとの情報があるので注意する。

トークンの使用状況は以下URLから確認することができる。

https://platform.openai.com/account/usage

なお、アカウントを新規作成した際は、5.00 USD分の無料利用枠がある(3か月の期限付き)。テストする際にかなりAPIを使用してみたが、それでも0.03 USDしか消費しなかったので、5.00 USDあれば検証用途としては十分だろう。

OpenAI API連携用スクリプトの作成

1. `curl`によるOpenAI API実行方法

curlを使う場合は以下の通り実行すればOpenAI APIによる問い合わせができる。

# API keyを設定
export OPENAI_API_KEY='sk-********'

header='Content-Type: application/json'
apiurl='https://api.openai.com/v1/chat/completions'
prompt="ここに問い合わせしたい内容を記載。"
json='{"model": "gpt-4o-mini", "messages": [{"role": "user", "content": "'${prompt}'"}]}'

# API実行
curl ${apiurl} -sS -H "Authorization: Bearer ${OPENAI_API_KEY}" -H "${header}" -d "${json}"

実行結果は以下の通り。.choices[0].message.contentがAIの回答となる。

# curl ${apiurl} -sS -H "Authorization: Bearer ${OPENAI_API_KEY}" -H "${header}" -d "${json}"
{
  "id": "chatcmpl-xxxxxxxx",
  "object": "chat.completion",
  "created": 1723324974,
  "model": "gpt-4o-mini-2024-07-18",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "もちろんです！問い合わせ内容をお知らせいただければ、適切な回答やアドバイスをお伝えいたします。どのようなことについてお尋ねですか？",
        "refusal": null
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 17,
    "completion_tokens": 40,
    "total_tokens": 57
  },
  "system_fingerprint": "fp_48196bc67a"
}

2. スクリプト作成

curlによるOpenAI APIの実行方法を用いて、Zabbixの障害アラートを連携するスクリプトを以下の通り作成した。各環境に合わせて、OpenAIのAPI keyやZabbix API実行用のユーザとパスワードを設定すること。

障害アラートへのメッセージ追加はZabbix APIを使用する。Zabbix APIの使い方は、以下別記事を参考にしていただきたい。

Zabbix API入門

また、OpenAI APIで同時に多数のリクエストを実行すると、応答がうまく得られずnullが返ってくる場合があったため、負荷分散を目的として、実行間隔制御の待機時間(最小10秒～最大120秒)を設定した。

`send_chatgpt_api.sh`

#!/bin/bash

# アラート内容を引数に代入
eventid=$1
alert=$(echo $2 | sed -e 's/"/\\"/g')

# 実行間隔制御 (10秒+ランダム時間)
sleep $(( 10 + ($RANDOM % 110) ))

# API keyを設定
export OPENAI_API_KEY='sk-********'

# モデルを選択
#model="gpt-3.5-turbo"
model="gpt-4o-mini"

header='Content-Type: application/json'
apiurl='https://api.openai.com/v1/chat/completions'
prompt="Zabbixで検知した以下イベントメッセージの原因及び解消方法を簡潔に教えてください。\n\n${alert}"
json='{"model": "'${model}'", "messages": [{"role": "user", "content": "'${prompt}'"}]}'

# API実行
result=$(curl ${apiurl} -sS -H "Authorization: Bearer ${OPENAI_API_KEY}" -H "${header}" -d "${json}")

# 出力
result_message=$(echo $result | jq -r '.choices[0].message.content')

# Zabbix APIログイン
header='Content-Type:application/json-rpc'
apiurl='http://[ZabbixサーバのURL]/zabbix/api_jsonrpc.php'
json='{"jsonrpc": "2.0","method": "user.login","params": {"username": "Admin","password": "********"},"id": 1,"auth": null}'
zbxauth=$(curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq -r ".result")

# Zabbix APIでイベントにメッセージ追加
json='{"jsonrpc": "2.0","method": "event.acknowledge","params": {"eventids": "'${eventid}'","action": 4,"message": "'$(echo ${result_message} | sed -e 's/"/\\"/g')'"},"auth": "'${zbxauth}'","id": 1}'
curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq

# Zabbix APIログオフ
json='{"jsonrpc": "2.0","method": "user.logout","params": [],"id": 4,"auth": "'$zbxauth'"}'
curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq

exit 0

3. スクリプトをZabbixサーバに配置

本スクリプトは、Zabbixサーバの/usr/local/binに配置し、実行権限を付与しておく。

# cp send_chatgpt_api.sh /usr/local/bin/
# chmod +x /usr/local/bin/send_chatgpt_api.sh
# ls -l /usr/local/bin/send_chatgpt_api.sh
-rwxr-xr-x 1 root root 1753  9月 23 07:41 /usr/local/bin/send_chatgpt_api.sh

実行方法は以下の通りとなる。

/usr/local/bin/send_chatgpt_api.sh '[イベントID]' '[アラート内容]'

Zabbixのトリガーアクションを設定

1. スクリプト設定

Zabbixのスクリプト設定を以下の通り行う。

設定項目	設定値
名前	Send ChatGPT
タイプ	スクリプト
次で実行	Zabbixサーバー
コマンド	`/usr/local/bin/send_chatgpt_api.sh '{EVENT.ID}' '{ITEM.VALUE}'`

2. トリガーアクション設定

Zabbixのトリガーアクション設定を以下の通り行う。今回は、「軽度の障害」以上の場合にスクリプトを実行するよう設定する。

設定項目	設定値
名前	Send ChatGPT
実行条件	「メンテナンス期間外」 AND 「トリガーの深刻度以上軽度の障害」

アクションの実行内容は以下の通り、先ほど作成したスクリプトを指定する。

設定項目	設定値
処理内容	Send ChatGPT
ターゲットリスト	Zabbix server

動作確認

実際に障害アラートを発生させて、動作を確認してみよう。

例として、以下の障害アラートを発生させてみた。ポートチャネルPo1からgi3が除外されたアラートとなる。

SNMP Trap from t1250c250 : 2024/02/10 15:11:26. .1.3.6.1.4.1.9.6.1.101.0.161 
Normal General event UNKNOWN - %TRUNK-W-PORTREMOVED: Port gi3 removed from Po1 1

しばらくするとスクリプトが実行され、以下の通りOpenAI APIで取得した生成AIの回答がメッセージとして表示された。

このイベントメッセージの原因は、ポートgi3がPo1 1から削除されたことです。 
解決方法は、次のいずれかです。

  1. ネットワーク上でポートを再接続し、Po1 1にgi3を再度追加します。
  2. システムの設定を確認し、ポートが正しく構成されていることを確認します。
  3. 他のネットワークデバイスとの接続に問題がある場合は、接続を確認し、
     必要に応じて修正します。

これらの手順を実行することで、問題が解決する可能性があります。
ただし、具体的な状況に応じて解決方法が異なる場合もあるため、
詳細な情報があれば助かります。

以上で、OpenAI APIを使ってZabbixの障害アラートを生成AIに連携する手順は完了となる。

参考

更新履歴

2023/9/23 新規作成
2024/2/10 OpenAI APIに送るプロンプトを日本語に変更
2024/6/24 send_chatgpt_api.shをZabbix 7.0に対応するように修正
2024/8/11 生成AIモデルをgpt-3.5-turboからgpt-4o-miniに変更

登録: 投稿 (Atom)

「Dell Bluetooth®トラベル マウス – MS700」レビュー

大きさなど

本体を捻ることで電源ON/OFFができる

マウスホイール

総評

メリット

デメリット

「Dell EcoLoop Pro バックパック 15」レビュー

大きさと容量

収納スペース

PC収納スペース

背中側

総評

メリット

デメリット

「Dell Pro 有線 ANC ヘッドセット – WH5024」レビュー

音声とマイクについて

収納ケース

イヤーパッド

有線ケーブルとコントローラー

「Dell Peripheral Manager」による細かな管理

総評

メリット

デメリット

Ansibleダウングレード手順

1. インストール可能なAnsibleのバージョン確認

2. Ansible 9.11.0をインストール

3. 動作確認

環境

バージョンアップ手順

1. アップグレードパスを確認

2. インストーラの入手

3. Harbor停止

4. バックアップ

5. 新バージョンのファイルを展開

6. 設定ファイルをマイグレーション

7. 新バージョンインストール

8. ターゲットバージョンとなるまで、手順3～7を繰り返す

環境

Ansibleバージョンアップ手順

1. pipを最新バージョンに更新

2. インストール可能なAnsibleのバージョンを確認

3. Pythonをインストール

4. 通常使用するPythonの入れ替え

5. 再度、インストール可能なAnsibleのバージョンを確認

6. Ansibleバージョンアップ

7. Ansible関連のPythonモジュールを追加

更新履歴

ネットワークデバイス名 (ESXi 7)

ネットワークデバイス名 (ESXi 8)

参考

更新履歴

環境

Oracle VM VirtualBoxインストール手順

1. Oracle VM VirtualBoxのダウンロード

2. (VirtualBox 7以降)Pythonのインストール

3. VirtualBox本体のインストール

4. Extension Packのインストール

VirtualBox上にWindows Server 2019をインストール

1. 仮想マシンを作成

2. OSをインストールメディアから起動

3. OSインストール

4. Guest Additionsをインストール

VirtualBox上にRHEL 8.4をインストール

1. 仮想マシンを作成～OSインストール

2. Guest Additionsをインストール

更新履歴

環境

Fluentd導入

1. fluentd-kubernetes-daemonsetのマニフェストファイルをダウンロード

2. マニフェストファイルを修正

fluentd-daemonset-syslog.yaml

3. マニフェストファイルをapply

4. 動作確認

環境

受信側設定

1. ログ保管用ディレクトリの作成

2. rsyslogの設定

/etc/rsyslog.conf

/etc/rsyslog.d/41-recieve-log.conf

「Dell Bluetooth®トラベルマウス – MS700」レビュー

1. `fluentd-kubernetes-daemonset`のマニフェストファイルをダウンロード

`fluentd-daemonset-syslog.yaml`

`/etc/rsyslog.conf`

`/etc/rsyslog.d/41-recieve-log.conf`

`/etc/logrotate.d/remotelog`

`/etc/rsyslog.d/40-send-log.conf`

1. `curl`によるOpenAI API実行方法

`send_chatgpt_api.sh`