マルチスレッドが実験的実装
これまでPythonはグローバルインタプリタロックを採用してきましたが、今回のPython 3.13.0では新たな方針に沿って、初めて実験的にグローバルインタプリタロックをなくしてマルチスレッド処理を可能にしたフリースレッドモード（free-threaded mode）を実現したビルドが登場しました。
PythonでJITコンパイラとマルチスレッド処理が実験的に実装された「Python 3.13.0」正式公開 － Publickey
ただしこのフリースレッドモードは、標準的なPythonの実装として公開されるビルドとは別の、「python3.13t」（あるいはpython3.13t.exe）としてビルドされた実行ファイルを用いて、環境変数「PYTHON_GIL」を設定するか、引数「-X gil=1」を設定して起動したときに有効になります。
PythonでJITコンパイラとマルチスレッド処理が実験的に実装された「Python 3.13.0」正式公開 － Publickey
Python 3.13.0ではJIT（Just-in-Time）コンパイラの実験的実装も始まりました。C言語によるPythonの標準的な実装であるCPythonに対して「--enable-experimental-jit」オプションを付けてビルドした場合にJITコンパイラが有効になります。
PythonでJITコンパイラとマルチスレッド処理が実験的に実装された「Python 3.13.0」正式公開 － Publickey
JITコンパイラとは、スクリプト実行時にインタプリタによる実行と並行してバックグラウンド処理でネイティブバイナリを生成し、再び同じ処理が実行される際にはネイティブバイナリを実行することでより高速な処理を実現する手法です。
PythonでJITコンパイラとマルチスレッド処理が実験的に実装された「Python 3.13.0」正式公開 － Publickey
JavaScriptやRubyなど人気の高いプログラミング言語の多くは処理速度を高速化するためにすでにJITコンパイラを搭載しており、それがようやくPythonにも採用されることとなりました。
PythonでJITコンパイラとマルチスレッド処理が実験的に実装された「Python 3.13.0」正式公開 － Publickey
⇧ う～む、「GIL（Global Interpreter Lock）」の影響範囲が大き過ぎる気はしますが、将来的には「GIL（Global Interpreter Lock）」は廃止の方向で進むんですかね？
ネットワーク機器の設定情報をバックアップするツール「Oxidized」とは
GitHubに公開されている公式のREADEMEの説明によると、
Oxidized is a network device configuration backup tool. It's a RANCID replacement!
It is light and extensible and supports over 130 operating system types.
⇧ ネットワーク機器の設定情報のバックアップを目的としているツールであり、130を超える「OS（Operation System）」に対応していますと。
というか、「OS（Operation System）」の種類の多さに絶句するしかないんだが...
で、各々の「OS（Operation System）」で、設定情報を取得する際に利用できるコマンドが異なるからして、個別対応する形にならざるを得ないということらしい。
ちなみに、「Oxidized」以外にもいろいろあり、「Repositories」で絞り込みをかけると、
⇧ とあるのだけど、いずれもドキュメントが整備されていないので、何か上手くいかない時はソースコードを確認せざるを得ないという感じで、なかなかに辛い状況...
2024年10月15日（火）追記：↓ ここから
何と言っても、
⇧「Oxidized」のリポジトリなのに、「oxidized」をインストールせずに「oxidized-web」をインストールしている「Dockerfile」というのが、よく分からんのよね...
どうやら、
⇧ Gitリポジトリの「Dockerfile」はガン無視で、「Docker Hub」から直にDockerイメージをプルしてきて生成する感じらしい...
Gitリポジトリの「Dockerfile」の存在が謎過ぎるんだが...
2024年10月15日（火）追記：↑ ここまで
ネットワーク機器の設定情報をバックアップするツール「Oxidized」の動作環境を構築してみる
業務で「Oxidized」を利用する機会があったので、環境構築を備忘録として残しておく。
基本的には、
⇧ 上記の記事の時に説明したように、最低限、仮想マシン2台があれば「Oxidized」の機能を試すことはできますと。
手順の流れとしては、
- 仮想マシン（対象機器）にSSHログインし、接続情報を確認する
- 仮想マシン（Oxidized）にSSHログインし、ユーザーを作成する ※1
- ユーザーのホームディレクトリ（/home/[user]）で、「Oxidized」の関連ファイル群を git cloneしてくる ※2
- 「Oxidized」の設定ファイルを作成する
- /home/[user]/.config/oxidized/config ※3
- /home/[user]/.config/oxidized/router.db
- VS Code（Visual Studio Code ）の拡張機能をインストールする
- 動作確認を行う
※1 Dockerを使うのであれば、Dockerfileで行う。
※2 Dockerを使うのであれば、git cloneするものは、Dockerfile、乃至は、docker-compose.ymlとかだけあれば良い。
※3「Oxidized」側で、configファイルの配置場所は決められている。
⇧ とあるように、
| No | 環境変数 | 内容 |
|---|---|---|
| 1 | OXIDIZED_HOME | /etc/oxidized/config |
| 2 | HOME | ~/.config/oxidized/config |
の順番で参照するらしいのだけど、「Oxidized」を実行する際は、rootユーザー以外のユーザーで行うのを推奨してるらしい。
何と言うか、「oxidized」というユーザーを前提にしてるっぽいのだが、ユーザーを変えても良いのかも分からないんだが、
⇧ 上記サイト様によりますと、「環境変数」の「OXIDIZED_HOME」が意味を為していない模様。
「Oxidized」の公式のドキュメントによると、
『You can set the env variable OXIDIZED_HOME to change its home directory.』
とあるので、「環境変数」の「OXIDIZED_HOME」を設定すれば、「HOME」を変えられるとあるのだが、「Oxidized」が参照するconfigファイルのパスを変えられるのかと思いきや、変えられないと。
混乱させてくれますな...
では、動作環境を構築していきますか。
ちなみに、公式のドキュメントによると、
⇧「Oxidized」のインストール方法としては、
- Debian and Ubuntu
- CentOS, Oracle Linux, Red Hat Linux
- FreeBSD
- Build from Git
- Docker
- Podman-Compose
- Installing Ruby 2.3 using RVM
⇧ 7パターンありますと。
■1. 仮想マシン（対象機器）にSSHログインし、接続情報を確認する
「Oxidized」で必要となる「router.db」ファイルの設定に必要な情報を確認します。
必要な情報は、
| No | 項目 | 内容 |
|---|---|---|
| 1 | ホスト名 | 対象機器のホスト名 |
| 2 | IPアドレス | 対象機器のIPアドレス |
| 3 | Oxidizedのmodelクラスの識別子 | Oxidizedのconfigのmodel_mapのキー |
| 4 | SSHログインユーザー | 対象機器のSSHユーザー |
| 5 | SSHログインユーザーのパスワード | 対象機器のSSHユーザーのパスワード |
になるので、これらの情報の内、以下についてを確認します。
「SSHログインユーザー」「SSHログインユーザーのパスワード」については、対象機器の管理者に確認するしか無いのだが...
自分の環境では、VirtualBoxで仮想マシン（対象機器）※を構築しているので、SSHログインして「ホスト名」「IPアドレス」を確認。
※ VirtualBox以外の仮想ソフトウェアで作成でも全く問題ない。可能であれば、実機が望ましいが、ネットワーク機器の「OS（Operation System）」は有償になってくると思われるので、我々のように「金の弾丸」に頼れない経済弱者は「OSS（Open Source Software）」に縋ることにしよう。勿論、「OS（Operation System）」固有のコマンドについて動作確認はできないわけだが...
とりあえず、
⇧ 上記サイト様を参考に、確認します。
IPアドレスの確認
ip a
ホスト名の確認
getent hosts [ip aで確認したIPアドレス]
適当なテキストエディタにコピペしておきます。
■2. 仮想マシン（Oxidized）にSSHログインし、ユーザーを作成する
以下、「Oxidized」をどちらで動かすかによって、手順が変わる。
- ホストで動かす場合
- Dockerコンテナのようなもので動かす場合
■■ホストでOxidizeを動かす場合
もう一台の仮想マシン（「Oxidized」を稼働させる用）にSSHログインし、「Oxidized」を動作する「ユーザー」を作成します。（「Oxidized」の実行はrootユーザー以外が推奨のため）。
自分の環境では、「WSL 2（Windows Subsystem for Linux 2）」で仮想マシン※を構築しているので、SSHログインします。
※ WSL 2（Windows Subsystem for Linux 2）以外の仮想ソフトウェアで作成でも全く問題はない。
ユーザー「oxidized」を追加します。
useradd oxidized
ユーザー「oxidized」のパスワードを設定します。
passwd oxidized
ユーザー「oxidized」のホームディレクトリが作成されているか確認。
ls -la /home
を実行しておく。
■■DockerコンテナでOxidizeを動かす場合
「Dockerfile」で、ユーザーを追加するが、
⇧「Oxidized」で用意されている「Dockerfile」で追加しているユーザーを利用するのであれば、作業不要。
■3. ユーザーのホームディレクトリ（/home/[user]）で、「Oxidized」の関連ファイル群を git cloneしてくる
以下、「Oxidized」をどちらで動かすかによって、手順が変わる。
- ホストで動かす場合
- Dockerコンテナのようなもので動かす場合
■■ホストでOxidizeを動かす場合
GitHubで公開されているREADMEにある、
⇧「Installation」の手順を実施していく。
手順としては、
⇧ 4つほど用意されている模様。
ただ、「Build from Git」については、事前に「Git」と「Ruby」のインストールは最低限、必要な気がするんだが、手順には記載が無いんよね...
■■DockerコンテナでOxidizeを動かす場合
「Git」がインストールされていない場合は、事前に「Git」をインストールしておきましょう。
仮想マシン（「Oxidized」を稼働させる用）にSSHログインしている状態で、ディレクトリの移動。
cd [適当なディレクトリ]
git cloneを実行する。
git clone https://github.com/ytti/oxidized.git
認証情報の入力を求められたら、以下で認証。
| No | 項目 | 内容 |
|---|---|---|
| 1 | ユーザー | 個人用GitHubアカウント |
| 2 | パスワード※1 | PAT（Personal Access Token） |
※1 公開鍵認証を利用している場合は、認証情報の入力は求められないと思われる。「PAT（Personal Access Token）」は事前に、「GitHub」の「Settings」で作成しておく。
git cloneされているか確認。
ls -laR
■4. 「Oxidized」の設定ファイルを作成する
以下、「Oxidized」をどちらで動かすかによって、手順が変わる。
- ホストで動かす場合
- Dockerコンテナのようなもので動かす場合
設定ファイルは、以下の2つ。
| No | 設定ファイル | 内容 |
|---|---|---|
| 1 | configファイル | Oxidizedの諸々の設定 |
| 2 | router.dbファイル ※ | 対象機器に接続するための情報。Oxidizedのmodelクラスも指定。 |
※ 対象機器が複数になる場合は、対象機器の数だけ行数が増える。設定内容のフォーマットは後述。
◇configファイル
■■ホストでOxidizeを動かす場合
以下のファイルを作成する。
- /home/[user※]/.config/oxidized/config
- /home/[user※]/.config/oxidized/router.db
※ userは「oxidized」にしておくのが無難な気がする。
■■DockerコンテナでOxidizeを動かす場合
Dockerコンテナのディレクトリとマウントするホストのディレクトリに作成しておく。
⇧ 上記を参考に、Dockerコンテナ内の「/home/oxidized/.config/oxidized」ディレクトリにマウントする形になっていればOK。
※ Dockerコンテナの生成・起動の際に、Dockerコンテナ内の「/home/oxidized/.config/oxidized」ディレクトリにマウントするのを忘れなければOK。
作成したら、各々のファイルを編集。
■■ホストでOxidizeを動かす場合
●/home/[user]/.config/oxidized/config
vi /home/[user]/.config/oxidized/config
■■DockerコンテナでOxidizeを動かす場合
●[適当なディレクトリ]/config
vi [適当なディレクトリ]/config
ファイルの内容は同じで。
■■共通
以下のように設定。
---
#username: oxidized
#password: S3cr3tx
#model: junos
interval: 60 #interval in seconds
log: ~/.config/oxidized/log
debug: false
threads: 30 # maximum number of threads
# use_max_threads:
# false - the number of threads is selected automatically based on the interval option, but not more than the maximum
# true - always use the maximum number of threads
use_max_threads: false
timeout: 20
retries: 3
prompt: !ruby/regexp /^([\w.@-]+[#>]\s?)$/
crash:
directory: ~/.config/oxidized/crashes
hostnames: false
#vars:
# enable: S3cr3tx
groups: {}
rest: 127.0.0.1:8888
pid: ~/.config/oxidized/oxidized.pid
input:
default: ssh, telnet
debug: false
ssh:
secure: false
output:
file:
directory: ~/.config/oxidized/configs
# default: git
# git:
# user: Oxidized
# email: oxidized@example.com
# repo: "~/.config/oxidized/oxidized.git"
source:
default: csv
csv:
file: ~/.config/oxidized/router.db
delimiter: !ruby/regexp /:/
map:
name: 0
ip: 1
model: 2
username: 3
password: 4
vars_map:
enable: 5
model_map:
local_test: linuxgeneric
# cisco: ios
# juniper: junos
⇧ といった感じにしてますが、誠に遺憾なことに設定項目の意味について公式のドキュメントの情報が足りな過ぎるので、雰囲気で設定せざるを得ない...
ちなみに、modelクラスについては、
⇧ 追加することができるのだが、暗黙的なファイルの命名規則があるらしく、「アンダースコア」を含むとエラーになったので要注意。
つまり、
- エラー出ない
customios.rb - エラー出る
custom_ios.rb
⇧ のような感じで、modelクラスのファイルの命名は、アルファベットだけにしておいた方が良さそう。
まぁ、無茶苦茶に泥沼にハマったんだが（涙）
◇router.dbファイル
■■ホストでOxidizeを動かす場合
●/home/[user]/.config/oxidized/router.db
vi /home/[user]/.config/oxidized/router.db
■■DockerコンテナでOxidizedを動かす場合
●[適当なディレクトリ]/router.db
vi [適当なディレクトリ]/router.db
■■共通
続いて、仮想マシン（対象機器）に対するSSH接続情報などを設定する。
以下のように設定
[対象機器のホスト名]:[IPアドレス]:[モデル ※1]:[対象機器へのSSHログインユーザー]:[対象機器へのSSHログインユーザーのパスワード]
※1 configの設定項目「model_map」のkey
⇧ 対象機器の数の分だけ行数がある感じになるかと。
■5. 「Oxidized」をデバッグするのに必要な依存ライブラリをインストールする
「Oxidized」を動作させるのに必要な依存ライブラリをインストールしていく。
ちなみに、Dockerで動作させる場合は、依存ライブラリのインストールは不要だが、デバッグ実行とかする場合は、Dockerで動作させた状態だと無理そうな気がしている。
と言うのも、
⇧ 上記の記事の時に出てきた「runit」というライブラリで、Dockerコンテナが起動する際に、「Oxidized」が実行されてしまい常駐プロセスのように稼働してしまうので、デバッグ実行ができそうにない。
■■ホストでOxidizeを動かす場合
共通を参照。
■■DockerコンテナでOxidizedを動かす場合
Dockerfileで自動起動させないようにしておく。
■■共通
環境にも依りけりとは思うが、
debug.gem は Ruby3.1 からデフォルトでRubyに同梱されている gem です。ソースコードは以下リポジトリにあります。
【RubyKaigi2023】debug.gem 1.8.0 で Ruby のデバッグをしてみる【VSCode】 #Ruby_記事投稿キャンペーン - Qiita
⇧ 上記サイト様を参考に、
※1 Ruby 3.1以上を利用しているなら、同梱されているのでインストール不要。
※2 テストしないなら不要。
※3 Oxidizedのプロセス確認用。必須というわけではない。
あたりがあると良さそう。
■6. VS Code（Visual Studio Code ）の拡張機能をインストールする
「VS Code（Visual Studio Code ）」を利用して開発していくことを想定しているが、最低限、
- リモート接続元のVS Code（Visual Studio Code）のワークスペース
- Remote Development
- リモート接続先のVS Code（Visual Studio Code）のワークスペース
⇧ 上記はインストールしておいた方が良いかと。
■7. 動作確認
では、「VS Code（Visual Studio Code ）」の「拡張機能」である「Remote Development」を利用して、「WSL 2（Windows Subsystem for Linux 2）」にSSHログイン。
■■ホストでOxidizeを動かす場合
ディレクトリを選択。
「TERMINAL」で、ユーザーを切り替えて、「[git cloneしたディレクトリ]/bin」に移動。
su oxidized
cd [git cloneしたディレクトリ]/bin
「Oxidized」を実行する。
ruby oxidized
⇧ で実行できる。
■■DockerコンテナでOxidizedを動かす場合
■■■Oxidizedが自動起動するようになっている場合
Dockerfileのある場所に移動。
cd [Dockerfileの配置されているディレクトリ]
Dockerイメージ作成。
docker build . -t [NAME※1]:[TAG]※1
※1 Docker Composeなどを利用する場合は、docker-compose.ymlの設定に合わせる。
その後、
- docker run
- docker-compose up
- docker compose up
いずれかで、Dockerコンテナの生成・起動。
■■■Oxidizedが自動起動するようになっていない場合
TODO：未検証
公式のドキュメントの情報が少な過ぎて、
⇧ 海外でも、動作しないっていう話が出てるんよね...
控えめに言っても、地獄でしかないんだが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
