2024年10月5日土曜日

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

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

コンテナレジストリの「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のマニュアルを確認する。

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のマニュアルを確認する。

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からダウンロードすることができる。

今回の場合は、以下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のインストール手順は以下に記載している。

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

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

本記事では、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 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番号デバイス名
1ens34
2ens37
3ens38
4ens39
5ens40
6ens41
7ens42
8ens43
9ens44
10ens45
こちらはESXi 7と異なり、1つ目のNICのデバイス名はens34となり、2つ目以降は37番から1ずつ増加して名称が割り当てられることが確認できた。

参考

更新履歴

  • 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インストール後、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を導入する。マニフェストファイルは以下からダウンロードできる。

今回は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で送信する手順は完了となる。

人気の投稿