MIGRATION ROADMAP — 全17工程
- ① SSH、ユーザー追加
- ② IPv4/IPv6追加、netplan、ufw
- ③ Apache2
- ④ Let's Encrypt
- ⑤ PHP
- ⑥ MariaDB
- ⑦ WordPress
- ⑧ Dovecot、Postfix
- ⑨ Vsftpd
- ⑩ Python
- ⑪ llama.cpp、ChromaDB
- ⑫ Anaconda、Keras、TensorFlow
- ⑬ Node.js
- ⑭ MongoDB
- ⑮ Mosquitto
- ⑯ RabbitMQ
- ⑰ Supervisor
01llama.cppは実質⑩で導入済みだった
RAGシステムのWebSocketサーバーはPython内でllama-cpp-pythonバインディング経由でGGUFモデルを読み込む構成のため、
⑩でenv3.14に入れたllama_cpp_python==0.3.34がそのまま該当し、スタンドアロンバイナリの別途インストールは不要だった。
ただし、そのままのpipインストールはCPUの命令セット（AVX2等）を活かさない汎用ビルドになっていることがあるため、新サーバーのCPU向けに再ビルドした。
$ source /home/login-user/env3.14/bin/activate
$ pip uninstall llama-cpp-python
$ CMAKE_ARGS="-DGGML_NATIVE=ON" pip install llama-cpp-python --no-cache-dir
GGML_NATIVE=ONはビルドを実行しているマシン自身のCPU命令セットを自動検出して最適化する指定。旧サーバーとCPU世代が異なる可能性もあるため、コピーではなく新サーバー上で再ビルドする形にした。
02ChromaDB：バージョンが一致していれば実体コピーのみで足りる
PersistentClient（ローカルディレクトリへの永続化）構成なので、データ移行は基本的にディレクトリのコピーで完結する。 ただしChromaDBは過去に内部の保存形式が非互換な形で変わったことがあるため、旧サーバーと新サーバーのバージョンを確認した。
$ pip show chromadb
Version: 1.5.7
新旧とも1.5.7で一致していたため、スキーマ非互換の懸念なく実体コピーのみで完結。念のため、コレクション名・件数を照合した。
$ python3 -c "import chromadb; client = chromadb.PersistentClient(path='コピー先のパス'); [print(c.name, c.count()) for c in client.list_collections()]"
web_articles 2110
documents 3
確認完了
旧サーバーで把握していたコレクション名・件数と一致。データ移行はこれで完了とみなせる。
03HuggingFaceトークンの移行漏れ
HF_TOKENは環境変数として設定されており、ホームディレクトリのファイルコピーには含まれていなかった（~/.cache/huggingface/tokenのようなファイル形式ではなかった）。新サーバー側で改めて設定が必要だった。
$ echo 'export HF_TOKEN="（トークンの値）"' >> ~/.bashrc
$ source ~/.bashrc
先の話
.bashrcは対話シェル起動時のみ読み込まれるため、⑰でSupervisorによりWebSocketサーバーをデーモン化する際は、systemdのUnit定義にEnvironment=HF_TOKEN=...として移し替える必要がある。今回は動作確認のための暫定対応。
04ここまでの状態
- llama-cpp-pythonを新サーバーのCPU向けに再ビルド（GGML_NATIVE=ON）
- ChromaDBはバージョン一致を確認の上、データ実体コピーのみで移行完了（コレクション名・件数照合済み）
- HF_TOKENを新サーバー側で再設定（.bashrc、⑰で systemd Environment= へ移行予定）
