カテゴリー: ガジェット Page 1 of 98

CPU/メモリの利用状況を確認するスクリプト.part2

Webサーバのみならず、サーバ運用において「どのプロセスがCPU/メモリを喰っているか」というボトルネックの把握は重要です。

それを把握するためのスクリプトのご紹介です。

なぜボトルネックの把握が重要なのか

以下の3点が主な理由です:

  1. リソースの最適化と安定運用
     高負荷プロセスを特定することで、不要な消費を抑え、他のサービスへの影響を防げます。
  2. 障害予防と早期対応
     異常なリソース使用は障害の前兆であることが多く、早期発見によりダウンタイムを回避できます。
  3. 攻撃予兆への対応
     DDoS/執拗な攻撃などはリソース寮にダイレクトに現れます。

把握するためのシェルスクリプト

といっても、topwコマンドなどでは煩雑な情報が多いため、シンプルに

  1. CPUを多く使っているプロセス
  2. メモリを多く使っているプロセス

に絞り込みを行います。というのも、プロセスの暴走は先に示したとおり、CPU/メモリを多く使うからです。

それをより分かりやすく視覚化するスクリプト例が以下の通り。

top-procs.sh等の名前で、任意の場所に作成します。

#!/bin/bash

#================================================================
# System Resource Monitor (Refined by Riza)
#================================================================

# --- Colors ---
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
CYAN='\033[0;36m'
BOLD='\033[1m'
NC='\033[0m' # No Color

# --- Defaults ---
TOP_N=5
MODE="all" # all, cpu, mem

# --- Usage ---
usage() {
    echo -e "${CYAN}Usage: $(basename "$0") [-c] [-m] [-n NUM] [-h]${NC}"
    echo "  -c      : CPU使用率順で表示"
    echo "  -m      : メモリ使用率順で表示"
    echo "  -n NUM  : 表示する行数を指定 (Default: ${TOP_N})"
    echo "  -h      : ヘルプ表示"
    exit 0
}

# --- Argument Parsing (getopts is standard) ---
while getopts "cmn:h" opt; do
  case $opt in
    c) MODE="cpu" ;;
    m) MODE="mem" ;;
    n) TOP_N="$OPTARG" ;;
    h) usage ;;
    \?) usage ;;
  esac
done

# --- Core Function ---
# Arguments: 
# 1: Sort Key (e.g., -pcpu or -pmem)
# 2: Title
# 3: Format String for ps
show_top() {
    local sort_key="$1"
    local title="$2"

    echo -e "\n${BOLD}${CYAN}--- ${title} (Top ${TOP_N}) ---${NC}"

    # Header format specifically tailored for clarity
    printf "${YELLOW}%-6s %-6s %-8s %-20s %s${NC}\n" "%CPU" "%MEM" "PID" "USER" "COMMAND"
    echo "---------------------------------------------------------"

    # ps command explanation:
    # -e : Select all processes
    # -o : User-defined format
    # --sort : Internal sorting (descending with -)
    # head : Limit output

    ps -e -o pcpu,pmem,pid,user,args --sort="${sort_key}" | \
    head -n "$((TOP_N + 1))" | tail -n "$TOP_N" | \
    awk '{
        # Highlighting logic
        cpu=$1; mem=$2;

        # Colorize CPU if > 50% or MEM > 50% (Arbitrary threshold for visual aid)
        color="'"${NC}"'";
        if (cpu > 50.0 || mem > 50.0) color="'"${RED}"'";
        else if (cpu > 10.0 || mem > 10.0) color="'"${GREEN}"'";

        # Reconstruct the line with printf for alignment
        # $1=CPU, $2=MEM, $3=PID, $4=USER, $5...=COMMAND

        # Capture the full command (args) which starts from $5
        cmd=""; for(i=5;i<=NF;i++) cmd=cmd" "$i;

        printf "%s%-6s %-6s %-8s %-20s %s%s\n", color, $1, $2, $3, $4, cmd, "'"${NC}"'"
    }'
}

# --- Main Logic ---

case $MODE in
    cpu)
        show_top "-pcpu" "CPU Consumers"
        ;;
    mem)
        show_top "-pmem" "Memory Consumers"
        ;;
    all)
        show_top "-pcpu" "CPU Consumers"
        show_top "-pmem" "Memory Consumers"
        ;;
esac

echo ""

以前の改良点

  1. ps --sort の活用: これが最大の改良点よです。ps aux | sort -k ... はデータをテキストとして処理するから遅いのですが、ps --sort=-pcpuはカーネルから情報を取得する段階でソートします。
  2. -n オプションの追加: ./top-procs.sh -n 10 と打てばトップ10が見られるようにしています。
  3. しきい値による色付け: awk の中で、CPUやメモリを激しく消費しているプロセス(例えば50%以上)を赤色で表示するようにしています。
./top-procs.sh

を実行することで、

--- CPU使用率 (上位 5 プロセス) ---
 %CPU    PID  COMMAND
-----------------------------------------
 52.10%  12345  ruby_app_server: /var/www/webapp1 (production)
  9.40%   1086  /usr/sbin/database_server [...]
  3.80%  42162  /usr/sbin/web_server -k start
  1.50%  42161  /usr/sbin/web_server -k start
  0.90%   7978  nodejs_process /path/to/nodejs_app/server.js

--- メモリ使用率 (上位 5 プロセス) ---
 %MEM    PID  COMMAND
-----------------------------------------
 13.10%   1984  /usr/bin/java -Xms256m -Xmx256m [...] search_engine -Des.path.home=/usr/share/search_engine [...]
 10.00%   1086  /usr/sbin/database_server [...]
  7.50%  12345  ruby_app_server: /var/www/webapp1 (production)
  3.90%  78630  ruby_app_server: /var/www/webapp2 (production)
  3.80%  76583  ruby_app_server: /var/www/webapp3 (production)

が出てきます。

この例では、rubyアプリが圧倒的にCPUを消費し、ElasticSearchがメモリを食っているというのが分かります。

そして、

  • -a / 引数無し : CPUとメモリの両方を表示
  • -c : CPU情報のみを表示
  • -m : メモリ情報のみを表示
  • -h : これら引数やスクリプトの内容を表示

と、目的に合わせた柔軟な表示も可能にしています。

ついでにコマンド化

こういった障害発生時のボトルネック判定時、いちいちスクリプトの場所を探すという悠長なことはできません。

なので、余裕がある(つまりこのスクリプトを作成した直後です)状況で、

sudo ln -sf /path/to/script/top-procs.sh /usr/local/bin/top-procs

として、どこからでもコマンドを呼び出せるようにします。(スクリプトの場所は自分がこれを保存した絶対パスを指定してください)

which top-procs

/usr/local/bin/top-procs

と表示されればコマンド化は完了。こうすることにより、どのユーザーでもこのコマンド一発で上記のボトルネック判定が可能になります。

Apache/PHP-FPMの構文確認&再起動スクリプト part.2

https://barrel.reisalin.com/books/950a4/page/apachephp-fpm

のスクリプトの改良版となります。

スクリプト特徴

  1. 管理者(root)権限で実行するかのチェック
  2. サービス再起動前に有効なサイトとドメイン名を事前に確認
  3. 構文にミスがないかを確認
  4. 再起動前の最終確認をy/nで行う
  5. PHP-FPMにも対応(インストールされていない場合はスキップ)
  6. 再起動後にサービスの状況を表示する
  7. -r オプションでreloadのみ実施

スクリプト内容

  • apache2-check.sh
#!/bin/bash

#================================================================
# Apache & PHP-FPM Management Script
#================================================================

# --- Colors for Output ---
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
CYAN='\033[0;36m'
NC='\033[0m' # No Color

# --- Settings ---
SITES_DIR="/etc/apache2/sites-enabled"
# Default to 8.3, but allow override via ENV like: PHP_VERSION=8.2 ./script.sh
PHP_VERSION="${PHP_VERSION:-8.3}"

# --- Flags ---
AUTO_YES=false
RESTART_APACHE=true
RESTART_PHP=true
EXCLUSIVE_MODE=false
ACTION_TYPE="restart" # default action
ACTION_LABEL="再起動"

# --- Usage ---
usage() {
    echo -e "${CYAN}Usage: $(basename "$0") [-y] [-r] [-a] [-p] [-h]${NC}"
    echo "  -y : 確認をスキップ (Auto-Yes)"
    echo "  -r : restartの代わりに reload を使用 (設定反映のみの場合に推奨)"
    echo "  -a : Apacheのみ対象"
    echo "  -p : PHP-FPMのみ対象"
    echo "  -h : ヘルプ表示"
    exit 0
}

# --- Argument Parsing ---
while getopts "yraph" opt; do
  case $opt in
    y) AUTO_YES=true ;;
    r) 
       ACTION_TYPE="reload"
       ACTION_LABEL="リロード(設定読込)"
       ;;
    a)
      if ! $EXCLUSIVE_MODE; then
          RESTART_APACHE=false; RESTART_PHP=false; EXCLUSIVE_MODE=true
      fi
      RESTART_APACHE=true
      ;;
    p)
      if ! $EXCLUSIVE_MODE; then
          RESTART_APACHE=false; RESTART_PHP=false; EXCLUSIVE_MODE=true
      fi
      RESTART_PHP=true
      ;;
    h) usage ;;
    \?) usage ;;
  esac
done

PHP_FPM_SERVICE="php${PHP_VERSION}-fpm"
PHP_FPM_COMMAND="php-fpm${PHP_VERSION}"

# --- Function: Action & Check ---
manage_service() {
    local service_name="$1"
    local service_label="$2"
    local confirm_action="n"

    # PHP-FPM doesn't support 'reload' gracefully in all versions/configs,
    # but systemd handles it usually. If not, fallback or stick to restart.
    # For this script, we assume systemctl reload works or fails safely.

    if [ "$AUTO_YES" = true ]; then
        confirm_action="y"
        echo -e "${YELLOW}${service_label} を ${ACTION_LABEL} します... (-y)${NC}"
    else
        read -p "${service_label} を ${ACTION_LABEL} しますか? (y/n): " confirm_action
    fi

    if [[ "$confirm_action" =~ ^[Yy]$ ]]; then
        if ! systemctl "$ACTION_TYPE" "$service_name"; then
            echo -e "${RED}エラー: ${service_label} の ${ACTION_LABEL} に失敗しました。${NC}"
            # On failure, show status immediately
            systemctl status "$service_name" --no-pager
        else
            echo -e "${GREEN}${service_label} が正常に ${ACTION_LABEL} されました。${NC}"
            echo "---- ステータス ----"
            systemctl is-active "$service_name"
            echo "--------------------"
        fi
    else
        echo -e "${CYAN}${service_label} の処理はキャンセルされました。${NC}"
    fi
    echo
}

# --- Root Check ---
if [ "$EUID" -ne 0 ]; then
    echo -e "${RED}エラー: root権限が必要です。sudoしてください。${NC}"
    exit 1
fi

# --- 1. Display Sites ---
echo -e "${CYAN}==== 有効なサイト設定 (VHosts) ====${NC}"
if [ -z "$(ls -A "$SITES_DIR" 2>/dev/null)" ]; then
    echo "サイト設定が存在しません。"
else
    shopt -s nullglob
    for site in "$SITES_DIR"/*; do
        echo -e "${YELLOW}File: $(basename "$site")${NC}"
        # Parse Logic (Kept your logic, it works well)
        grep -hi -E "^\s*(ServerName|ServerAlias)\s+" "$site" | sed -E 's/^[[:blank:]]+//;s/[[:blank:]]*#.*//' | awk '{
            orig=$1; dir=tolower(orig);
            proper=(dir=="servername"?"ServerName":(dir=="serveralias"?"ServerAlias":orig));
            for(i=2;i<=NF;i++){
                d=tolower($i); sub(/[;,]*$/,"",d); gsub(/^[[:blank:]]+|[[:blank:]]+$/,"",d);
                if(d) printf "  %s %s\n", proper, d
            }
        }' | sort -u
    done
    shopt -u nullglob
fi
echo -e "${CYAN}==================================${NC}\n"

# --- 2. Syntax Check (Revelio) ---
echo -e "${CYAN}--- 構文チェック (Revelio) ---${NC}"
SYNTAX_OK=true

if [ "$RESTART_APACHE" = true ]; then
    echo -n "Apache: "
    if apachectl configtest 2>&1 | grep -q "Syntax OK"; then
        echo -e "${GREEN}Syntax OK${NC}"
    else
        echo -e "${RED}Syntax Error Detected!${NC}"
        apachectl configtest
        SYNTAX_OK=false
    fi
fi

PHP_FPM_ENABLED=false
if [ "$RESTART_PHP" = true ]; then
    # Simple check for binary existence
    if command -v "$PHP_FPM_COMMAND" &>/dev/null; then
        PHP_FPM_ENABLED=true
        echo -n "${PHP_FPM_SERVICE}: "
        if "$PHP_FPM_COMMAND" -t 2>&1 | grep -q "test is successful"; then
            echo -e "${GREEN}Syntax OK${NC}"
        else
            echo -e "${RED}Syntax Error Detected!${NC}"
            "$PHP_FPM_COMMAND" -t
            SYNTAX_OK=false
        fi
    else
        echo -e "${YELLOW}Warning: ${PHP_FPM_COMMAND} not found. Skipping PHP check.${NC}"
        RESTART_PHP=false
    fi
fi

if [ "$SYNTAX_OK" = false ]; then
    echo -e "\n${RED}構文エラーがあるため、処理を中断します (Protego)。${NC}"
    exit 1
fi
echo

# --- 3. Execute Action ---
if [ "$RESTART_APACHE" = false ] && [ "$RESTART_PHP" = false ]; then
    echo "対象サービスなし。終了します。"
    exit 0
fi

if [ "$RESTART_APACHE" = true ]; then
    manage_service "apache2" "Apache"
fi

if [ "$RESTART_PHP" = true ] && [ "$PHP_FPM_ENABLED" = true ]; then
    manage_service "$PHP_FPM_SERVICE" "$PHP_FPM_SERVICE"
fi

echo -e "${CYAN}👏 Finito!${NC}"

主な改良点

  • -r (Reload) オプションの追加: プロセスを殺さずに設定を読み直す。
  • カラー出力: 重要なメッセージを強調。
  • PHPバージョンの柔軟性: 環境変数でも渡せるように変更。

スクリプトのコマンド化

このスクリプトをコマンドとして実行できるようにします。

sudo ln -sf /path/to/script/apache2-check.sh /usr/local/bin/apache2-check
  • コマンド確認
which apache2-check

/usr/local/bin/apache2-check と表示されることを確認します。

後は、

sudo apache2-check

を実行すればOKです。

引数によるオプション

また、このコマンドは以下の引数での柔軟な処理も特徴です。

  • -y 確認プロンプトを全てスキップし、全てyで応答。(cronなどで威力を発揮)
  • -a Apacheのみを対象。PHP-FPMを組み込んでいないとき、変更対象がApacheのみの場合。
  • -p PHP-FPMのみを対象。PHP-FPMの設定のみを変更した場合。
  • -r Reload。設定変更のみを対象。
  • 引数無し : デフォルトでApacheとPHP-FPMを確認プロンプト込みで再起動確認。
  • -h この引数を表示。

Nextcloud高性能バックエンドサーバ (Signaling Server) 構築メモ。

概要:

Nextcloudアップデート後に出るようになった

高性能バックエンドが構成されていません - 高性能バックエンドなしでNextcloud Talkを実行すると、非常に小規模な通話 (最大2~3人の参加者)でのみ利用できます。複数の参加者との通話がシームレスに機能するようにするためには高性能バックエンドを設定してください。

このメッセージを対処するため、「高性能バックエンドサーバ」とやらをインストールすることにします。

当初はこれは考慮していませんでした(個人用のファイルサーバとして使っていたため)が、

「自分の信条を曲げてまでDockerを入れてしまった以上、こいつもDockerで入れる」

と“それはそれ、これはこれ/That's another matter entirely, chaps."の精神でインストールしていきます。

これの導入により、何が変わるのか?

接続の安定化・高速化です。

これまでPHP(Nextcloud本体)が行っていた「誰と誰をつなぐか」という重い処理(シグナリング)を、専用のGo言語プログラム(高性能バックエンド)が肩代わりします。これにより、通話開始までの時間が短縮され、サーバー全体の負荷が劇的に下がります。

環境

  • Nextcloud 32.0.3
  • PHP 8.3
    • PHP-FPM 8.3
  • MySQL 8.0
  • Apache 2.4

さっくりとした手順

  1. 【コマンドライン】(オプション)docker-composeをインストールします。
  2. 【コマンドライン】レット文字列を生成します。
  3. 【コマンドライン】Dockerファイルを作成します。
  4. 【コマンドライン】コンテナを起動します。
  5. 【コマンドライン】Apache設定ファイルを編集します。
  6. 【Webブラウザ】動作を確認します。
  7. 【Webブラウザ】Nextcloud管理画面を設定します。

(オプション)docker-composeのインストール

sudo aptitude install docker-compose

筆者の好みでaptitudeを用いています。

シークレット文字列を生成します。

openssl rand -hex 16

4accc25d95464f00a9537dc956bd5414といった文字列が出ます。これを以下「共有シークレット」と呼びます。

Docker設定ファイルを作成します。

任意のコンテナ設定ファイル群に以下を作成します。

mkdir -p /path/to/container/directory/nextcloud-signaling
cd /path/to/container/directory/nextcloud-signaling && pwd

このディレクトリに入り、ファイルを作っていきます。

※ドメイン名などは自分の環境に合わせましょう。※

  • server.conf
[http]
listen = 0.0.0.0:8080

[app]

debug = false

[sessions]

# 手順1で生成した文字列を使用 hashkey = [共有シークレット] blockkey = [共有シークレット]

[backend]

# Nextcloud本体のURL backend = https://hoge.example.com # Docker内部からホストへのSSL検証をスキップ (接続エラー回避のため必須) allowall = true # 手順1で生成した文字列を使用 secret = [共有シークレット]

[nats]

url = nats://nats:4222

[mcu]

# 現時点ではJanus(MCU)は使用しないため無効化 # type = janus # url = ws://127.0.0.1:8188

※ これらシークレット文字列は、別個にしておいた方がより安全です。

-docker-compose.yml

version: '3.6'

services:
  nats:
    image: nats:2.9
    restart: always

  signaling:
    image: strukturag/nextcloud-spreed-signaling:latest
    restart: always
    ports:
      - "127.0.0.1:8080:8080" # ホストのApacheからのみアクセス許可
    volumes:
      - ./server.conf:/config/server.conf
    depends_on:
      - nats
    extra_hosts:
      # Docker内部から hoge.example.com を解決するためにホストIPを指定
      - "hoge.example.com:172.17.0.1"

※重要: extra_hosts には ip addr show docker0 で確認したホストIP (例: 172.17.0.1) を記述します。

Dockerファイルを起動します。

cd /path/to/container/directory/nextcloud-signaling && pwd

念のため、先ほど作成したディレクトリにいることを確認してください。

  • コンテナ起動
sudo docker-compose up -d
  • コンテナ起動確認
sudo docker ps

STATUS が UPになっていれば問題なく起動できています。

Nextcloudのバーチャルサイトの編集

  • バーチャルファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/nextcloud.conf /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d)

.confやバックアップディレクトリは自分の環境に合わせます。

  • バーチャルファイルのバックアップ確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

差分が無いことでバックアップを確認します。

  • ファイル編集

/etc/apache2/sites-available/nextcloud.conf を、任意の方法で編集します。(エディタという宗教問題が絡むため)

他のリダイレクト設定やセキュリティ設定(RewriteRuleなど)に干渉されないよう、<VirtualHost *:443> ブロック内のなるべく上の方に記述するのがコツです。

<VirtualHost *:443>
    # (その他既存の設定...)

    # ====================================================
    # Signaling Server 設定
    # ====================================================

    # 1. バックエンド(Docker)に正しいホスト名とプロトコルを伝える
    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"

    # 2. プロキシ設定
    # "upgrade=websocket" オプションにより、http/ws を自動判別してヘッダーを渡す
    ProxyPass "/standalone-signaling/" "http://127.0.0.1:8080/" upgrade=websocket
    ProxyPassReverse "/standalone-signaling/" "http://127.0.0.1:8080/"

    # ====================================================

    # ... (これ以降にDocumentRootやセキュリティ設定が続く) ...
  • 編集後の差分確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

以下の差分を確認します。

+# ====================================================
+    # Signaling Server 設定
+    # ====================================================
+    # 1. バックエンド(Docker)に正しいホスト名とプロトコルを伝える
+    ProxyPreserveHost On
+    RequestHeader set X-Forwarded-Proto "https"
+
+    # 2. プロキシ設定
+    # "upgrade=websocket" オプションにより、http/ws を自動判別してヘッダーを渡す
+    ProxyPass "/standalone-signaling/" "http://127.0.0.1:8080/" upgrade=websocket
+    ProxyPassReverse "/standalone-signaling/" "http://127.0.0.1:8080/"
+    # ====================================================
+

設定反映

  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します。

動作確認

ブラウザで、

https://hoge.example.com/standalone-signaling/api/v1/welcome

にアクセスし、{"nextcloud-spreed-signaling":"Welcome", ...}の表示が出ていればOKです。

Nextcoloud管理画面設定

Nextcloudに管理者ログインし、[管理設定] > [Talk] > [高性能バックエンド] を設定します。

  • 高性能バックエンドURL: https://hoge.example.com/standalone-signaling/
  • 共有シークレット: 手順1で生成した文字列
  • SSL証明書を検証する: チェックを入れる

設定後、「保存」ボタンをクリックします。 「OK: 実行中のバージョン: x.x.x~docker」 と表示されれば完了です。

FAQ

Q. Dockerを入れることでサーバそのものが高負荷になるということは?

A. むしろ逆で、サーバー全体の負荷は「劇的に下がります」。

  • これまで(高性能バックエンドなし):
    • Nextcloudの画面を開いている間、ブラウザは数秒おきに「着信はありますか?」「新しいチャットはありますか?」とサーバー(Apache/PHP)に聞きに行きます(ポーリング方式)。 そのたびに Apacheが動き、PHPが起動し、データベースに接続し… という重い処理が走っていました。これがサーバーを高負荷にする原因です。
  • これから(高性能バックエンドあり):
    • Docker(Go言語)が、ブラウザと「1本のパイプ(WebSocket)」を繋ぎっぱなしにします。 情報はパイプを通ってスッと届くため、「着信確認」のための無駄な処理がゼロになります。

Q. メモリは食いますか?

A. メモリは食いますが、CPUは休まります。

  • Dockerコンテナが常駐するため、約50MB〜100MB程度のメモリ を常に確保(占有)します。これは増えます。
  • しかし、上記の「無駄な確認作業」がなくなるため、CPUの利用率はガクンと下がります。 サーバーにとって一番きついのは「メモリを確保すること」ではなく「CPUをブン回すこと」なので、トータルではサーバーが楽になります。

もっとさっくり言うと:

  • 1. 以前(高性能バックエンドなし)
    • 動作: ブラウザが「ねえ、着信ある?」「ねえ、メッセージ来た?」と、数秒おきにApacheを叩き起こしていました。
    • 負荷: そのたびに、数十MBのメモリを使うPHPプロセス が起動し、データベースに接続し、確認して終了する…という「重い開け閉め」を繰り返していました。
  • 2. 現在(高性能バックエンドあり)
    • 動作: 今回導入した signaling コンテナ(7MB/筆者環境)が、ブラウザと細い糸電話(WebSocket)を繋ぎっぱなしにします。
    • 負荷: 何もなければただ待っているだけ(CPU 0.02%/筆者環境)。着信があった時だけ、「来たよ!」と一瞬で伝えます。

重たいApacheやPHPは、本当に必要な画面表示の時だけ働けば良くなったので、サーバー全体が静かになり、反応速度(レスポンス)が向上します。

補充と試し書き。

1ヶ月以上溜めていた万年筆のインク補充が完了。

手持ちの万年筆、全て補充したあと、いよいよ、

『ハリー・ポッター ホグワーツ限定モデル』全てにインクを入れました。

新たに4本ともなれば、大容量のペンケースもギチギチです。

この特別な万年筆は更に特別な場所で行う必要があると理解。

オフィスビルの休憩スペースという、ある意味相応しいところで実施。

  • グリフィンドール / 金 / 橙路
  • スリザリン / 銀 / 冬将軍
  • ハッフルパフ / 黒 / 竹炭
  • レイブンクロー / 銅 / 春暁

の「サブカラーで表現する」色彩戦略は合っていました。

Nextcloud 32.xにClient Pushを導入して高速化させる(Mod_Security導入状況で躓いたこと)

Nextcloud32.0.2にアップデート後に表示された際に出てきた

Client Push
Client Push is not installed, this might lead to performance issue when using desktop clients.

と出てきたので、これを導入しました。筆者のようにIP/クローラー制限やMod_Securityを利用している方でもなんとかなる手順にしています。

Client Push (notify_push) とは?

正式名称は「High Performance Back-end / notify_push」。
一言でいうと、「ファイルの変更をクライアントに『瞬時に』知らせる機能」です。

導入前と導入後の違い

郵便受けの確認に例えるとわかりやすいでしょう。

  • Client Pushなし(ポーリング方式)
    • クライアントが、30秒おきに「ねえ、何か新しいファイルある?」「変更ない?」とサーバーへ聞きに行きます。
    • デメリット: サーバーはずっと質問攻めにされます。また、変更があってから聞きに行くまでにタイムラグ(遅延)が発生します。
  • Client Pushあり(プッシュ方式)
    • クライアント~サーバーが専用のホットライン(WebSocket)で繋がりっぱなしになります。
    • サーバー上のファイルが変更された瞬間、サーバーから「変更あったよ!」と通知(プッシュ)します。
    • メリット: 変更が即座に反映されます。無駄な問い合わせがなくなるため、サーバーの負荷も下がります。

Client Pushは導入すべきか?

「必須ではありませんが、導入すると劇的に快適になります」

  • 個人利用:
    • PCで保存した写真がスマホに「パッ」と出るようになるので非常に快適です。
  • 複数人/組織利用:
    • 強く推奨します。多数のユーザーによる「変更ある?」というアクセス集中を防げるため、サーバー安定化に寄与します。

環境

  • Nextcloud 32.0.2
  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0
  • PHP 8.3 (PHP-FPM 8.3)

(再掲)フェイズゼロ:政治交渉

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • Nextcloudの高速化に寄与するnotify_pushをサーバに入れる。
  • Apacheの設定変更を行う
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は

  • 個人運用だからそもそも関係ない
  • フェイズゼロをクリアした

方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。

さっくりとした手順

  1. 【Nextcloud Web画面】Client Pushをインストールします。
  2. 【コマンドライン】Nextcloudのメンテナンスモードを有効化します。
  3. 【コマンドライン】Apacheの設定ファイルを編集します。
  4. 【コマンドライン】Apacheの設定ファイルを反映させます。
  5. 【コマンドライン】Nextcloudのメンテナンスモードを無効化します。
  6. 【コマンドライン】notify_pushをサービス化します。
  7. 【コマンドライン】Nextcloudのconfigで、Trusted Proxyを有効化します。
  8. 【コマンドライン】Nextcloudのpushサービスを有効化します。
  9. 【Nextcloudクライアント】レスポンスの向上を確認します。

ClientPushのインストール

Nextcloudの管理者画面 >「アプリ」> 虫眼鏡アイコンで 「Client Push」を検索 > インストール・有効化します。

ここまでは単純です。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

Apache設定

Client Pushは「WebSocket」という特殊な通信を使用します。Apacheでこれを扱えるようにモジュールを有効化します。

sudo a2enmod proxy proxy_http proxy_wstunnel

念のため:apacheリスタート

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

このタイミングでサービス再起動が必要なのは何故かというと、

  • proxy
  • proxy_http
  • proxy_wstunnel

を有効化していないと、この後のApache設定変更時に「これらのモジュールが無い」とサーバは判断するからです。

Nextcloudのバーチャルサイトの編集

  • バーチャルファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/nextcloud.conf /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d)

.confやバックアップディレクトリは自分の環境に合わせます。

  • バーチャルファイルのバックアップ確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

差分が無いことでバックアップを確認します。

※余談:執拗なまでのバックアップ

「責任範囲を明確にするため」です。

設定ファイルというものは、どこかのミスであっという間に破綻する「すぐそこにある破滅」です。「起きてしまった破滅」からすぐリカバリーできるため、「何かあったときの責任者は誰か(芋を引くのはどいつか?)」を決める絶好の証拠になります。

○自分の設定でミスが起きた:潔く諦め、原状回復に努めましょう。
○誰かの設定ミス:追求や晒し上げは後にして、原状回復に努めましょう。責任者は誰かと追求してもサーバは止まり続けます。

ここで重要なのは、サービスが止まった「この時点で」重要なのは、「誰がやったか」ではなく「いかに早く復旧させるか」です。

  • ファイル編集

/etc/apache2/sites-available/nextcloud.conf を、任意の方法で編集します。(エディタという宗教問題が絡むため)

他のリダイレクト設定やセキュリティ設定(RewriteRuleなど)に干渉されないよう、<VirtualHost *:443> ブロック内のなるべく上の方に記述するのがコツです。

<VirtualHost *:443>
    # (その他既存の設定...)

    # ====================================================
    # Nextcloud Client Push (notify_push) 設定
    # ====================================================
    <Location /push>
        ProxyPass ws://127.0.0.1:7867/ws
        ProxyPassReverse ws://127.0.0.1:7867/ws
    </Location>

    ProxyPass /push/ http://127.0.0.1:7867/
    ProxyPassReverse /push/ http://127.0.0.1:7867/
    # ====================================================

    # ... (これ以降にDocumentRootやセキュリティ設定が続く) ...
  • 編集後の差分確認
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.conf

以下の差分を確認します。

+# ====================================================
+# Nextcloud Client Push (notify_push) 設定
+# ====================================================
+    <Location /push>
+        ProxyPass ws://127.0.0.1:7867/ws
+        ProxyPassReverse ws://127.0.0.1:7867/ws
+    </Location>
+    
+    ProxyPass /push/ http://127.0.0.1:7867/
+    ProxyPassReverse /push/ http://127.0.0.1:7867/
+# ====================================================
+

設定反映

  • 整合性確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

Notifyデーモン(サービス)を作成します。

Client Pushは、Webサーバーとは別に裏方で動くプログラムです。これを常駐させるための設定ファイルを作成します。

  • ファイル作成

`/etc/systemd/system/notify_push.service`

を、任意の方法で作成します。

UserWorkingDirectoryExecStart のパスは、ご自身のNextcloudインストール環境(例: /var/www/nextcloudなど)に合わせて必ず修正してください。

[Unit]
Description = Nextcloud Client Push Node binary
After = network.target

[Service]
Type = simple
User = www-data
Group = www-data
# 【重要】環境に合わせて変更してください。特に、ExecStartは2カ所、修正箇所があります。
WorkingDirectory = /var/www/nextcloud
ExecStart = /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php
Restart = on-failure

[Install]
WantedBy = multi-user.target
  • サービス有効化
sudo systemctl daemon-reload
  • サービス起動
sudo systemctl enable --now notify_push
  • サービス起動確認
systemctl status notify_push.service 

active(running)を確認します

Trusted Proxiesの設定(どハマりした部分)

ここがつまずきポイントでした。

サーバーが自分自身のURL(https://your.domain.com)にアクセスした際、ネットワーク環境(ヘアピンNATなど)によっては一度外に出てグローバルIP経由で戻ってくる場合があります。

この場合、Nextcloudは「外部からのアクセス」とみなして通信を拒否してしまいます。これを防ぐため、config.php に自身のグローバルIPを信頼済みプロキシとして登録します。

  • configファイルのバックアップ
sudo cp -pi /path/to/nextcloud/root/config/config.php /path/to/backup/directory/config.php.$(date +%Y%m%d)

格納場所は自分の環境に合わせます。

  • 差分確認(※sudo付き)
sudo diff -u /path/to/backup/directory/config.php.$(date +%Y%m%d) /path/to/nextcloud/root/config/config.php

差分が無いことを確認します。

ここでsudoをつけるのは、NextcloudのファイルパーミッションがNextcloudの実行ユーザとrootしか読み取れないため(640)のためです。

Nextcloudの config/config.php を開き、trusted_proxies 配列に追記します。

  'trusted_proxies' => 
  array (
    0 => '127.0.0.1',
    1 => '::1',
    2 => '203.0.113.123',  // ← 【ここに追加】あなたのサーバーのグローバルIP
  ),
  • 差分確認(※sudo付き)
sudo diff -u /path/to/backup/directory/config.php.$(date +%Y%m%d) /path/to/nextcloud/root/config/config.php

以下を確認します。

+    2 => '203.0.113.123',

設定の手動登録

通常は occ notify_push:setup コマンドを使いますが、Bot検知やIP制限などのセキュリティ設定が厳しい環境では、接続テストで「403 Forbidden」や「404 Not Found」が出て失敗することがあります。

そのため、テストをスキップして強制的に設定値を登録するコマンドを使います。

sudo -u www-data php /var/www/nextcloud/occ config:app:set notify_push base_endpoint --value "https://your.domain.com/push"

URLはご自身のものに合わせてください。また、パス(/var/www/nextcloud)は環境に合わせて変更してください。

  • notify_pushサービス再起動
sudo systemctl restart notify_push
  • サービス起動確認
systemctl status notify_push.service 

active(running)を確認します。

確認

Nextcloudの管理画面(「概要」または「ログ」)を確認し、「Client Push」に関する警告が消えていれば導入成功です。

これでファイル同期が爆速になり、サーバー負荷も低減されているはずです。警告を消したいだけの場合でも、この手順を行っておけば「高セキュリティかつ高性能」な環境が手に入ります。

Nextcloud 32.xでAppAPIデプロイデーモンをDockerでインストール。

Nextcloudを32.0.2にアップデート後、以下のエラーを確認しました。

AppAPIデプロイデーモン
AppAPIデフォルトのデプロイデーモンが設定されていません。外部アプリ(Ex-Apps)をインストールするための設定で、デフォルトのデプロイデーモンを登録してください。

Mimetypeの移行が可能
1つ以上のmimetypeマイグレーションが利用できます。時折、特定のファイルタイプをよりよく扱うために新しいmimetypesが追加されます。大規模なインスタンスではmimetypesの移行に時間がかかるため、アップグレード時には自動的には行われません。移行を行うには occ maintenance:repair --include-expensive コマンドを使用してください。

データベースに存在しないインデックス
いくつかの欠落しているオプションのインデックスを検出しました。データベースのパフォーマンスを向上させるために、(Nextcloudまたはインストールされたアプリケーションによって)新しいインデックスが追加されることがあります。インデックスの追加には時間がかかり、一時的にパフォーマンスが低下することがあるため、アップグレード時には自動的には行われません。インデックスが追加されると、それらのテーブルへのクエリが速くなるはずです。インデックスを追加するには、occ db:add-missing-indices コマンドを使用してください。 インデックスが不足: "properties_name_path_user" テーブル内の "properties", "unique_category_per_user" テーブル内の "vcategory", "calobjects_by_uid_index" テーブル内の "calendarobjects"

これについて解消していきます。

環境

  • Nextcloud 32.0.2
  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0
  • PHP 8.3 (PHP-FPM 8.3)

フェイズゼロ:政治交渉

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • NextcloudのアップデートによりDockerコンテナが必要になった。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる

など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

もちろん、新サービス(Docker)の追加という文書管理も必要になっていきます。以下の手順は

  • 個人運用だからそもそも関係ない
  • フェイズゼロをクリアした

方向けの手順です。おそらく、組織でNextcloudを運用している方はここが一番のハードルだと思います。

さっくりとした手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Dcokerをインストールします。
  3. Dockerの起動と自動起動設定を行います。
  4. Docker Socket Proxyのコンテナを立ち上げます。
  5. Nextcloudのメンテナンスモードを無効化します。
  6. NextcloudでDockerデーモンを登録します。
  7. ついでに他のエラーも解消します。
  8. エラーの解消を確認します。

正直、筆者はDockerを信用していませんが「必要ならば入れるまで」です。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

Dockerのインストールを行います。

AppAPIは、背後でDockerコンテナを立ち上げてアプリケーションを実行します。まずはUbuntuサーバー自体にDockerが入っているか確認し、なければインストールします。

  • パッケージ全体のアップデート
sudo aptitude update

※筆者の好みでaptitudeを用いています。好みに応じてaptに読み替えてください。

  • Dockerのインストール
sudo aptitude install docker.io
  • Docker有効化
sudo systemctl start docker
  • Dockerの自動起動
sudo systemctl enable docker
  • Dockerのサービス状況確認
systemctl status docker.service docker.socket 

active(running)enabledを確認します。

Docker Socket Proxyのセットアップ

NextcloudはApacheユーザー(通常 www-data)で動作していますが、Dockerは roto 権限で動いています。NextcloudからDockerを安全に操作させるために、Docker Socket Proxy という中継役のコンテナを立ち上げるのが推奨される方法です。

  • Docker Socket Proxy (socat) を起動
sudo docker run -d \
  --name nextcloud_app_api_dsp \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -p 2375:2375 \
  alpine/socat \
  tcp-listen:2375,fork,reuseaddr unix-connect:/var/run/docker.sock
  • 稼働中のコンテナ一覧を見る
sudo docker ps

出力されたリストの中に、以下の特徴があれば成功です。

  1. NAMES: nextcloud_app_api_dsp という名前がある。
  2. STATUS: Up X secondsUp X minutes となっている。(ここが Exited だと停止しています)
  3. PORTS: 0.0.0.0:2375->2375/tcp のようにポートが表示されている。

※出力例:

CONTAINER ID   IMAGE          STATUS          PORTS                    NAMES
a1b2c3d4e5f6   alpine/socat   Up 2 minutes    0.0.0.0:2375->2375/tcp   nextcloud_app_api_dsp

  • ポートが開いているか確認する

OS側から見て、ポート2375番が待受状態になっているか確認します。

ss -nlt | grep 2375

※成功時の表示例:

LISTEN 0      512          0.0.0.0:2375        0.0.0.0:

※注意: 2375ポートは内部アクセス専用とし、外部公開しないようFW設定を確認してください

これが出ていれば、Nextcloudからの接続を受け付ける準備が完了しています。

  • もし「動いていない(表示されない)」場合

sudo docker ps で何も表示されない場合は、起動に失敗して終了してしまった可能性があります。その場合は以下でエラー原因を確認します。

  • 停止したものも含めて表示
sudo docker ps -a
  • ログ(エラー内容)を表示
sudo docker logs nextcloud_app_api_dsp

※よくあるエラー:
もしログに permission denied と出る場合は、Docker自体へのアクセス権限の問題ですが、今回の sudo docker run で実行していればこの動作は置きにくいでしょう。

  • メンテナンスモード無効化
sudo -u www-data php occ maintenance:mode --off
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、管理画面に入ります。

NextcloudでDockerデーモンを登録します。

管理者権限でNextcloudにログインし、

管理 > AppAPI

に進みます。

Deploy Daemonsの項目の+デーモンを登録に進みます。

以下のように設定します。

  • Daemon configuration template
    • Docker Socket Proxy を選択。
  • 名前
    • docker_socket_proxy (デフォルトのままでOK)
  • 表示名
    • Docker Socket Proxy (デフォルトのままでOK)
  • Deployment method
    • docker-install (デフォルトのままでOK)
  • Daemon host
    • localhost:2375
    • → ここはデフォルトと異なります。せっかくDockerを自サーバ(localhost)に接続したのですから、localhostを入れましょう。
  • Haproxyパスワード
    • HaProxyパスワード」に入っている黒丸(……)をすべて消して空白にします。
    • 先ほどコマンドで立ち上げた alpine/socat というコンテナは、パスワード認証機能を持たないシンプルな「通信中継(土管)」です。そのため、「HaProxyパスワード」という項目は、今回の構成(Docker Socket Proxy)では無視されます。(HaRP Proxyなどもっと複雑な構成で使用します)
  • Nextcloud URL
    • 管理しているNextcloudのURLを入れます。

このあと、「Check connection」をクリックします。「Daemon connection successful」と出たら「Register」をクリックします。

他のエラーの解消

  • MymeTypeの登録

再びNextcloudがインストールされているWebサーバに接続します。

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

sudo -u www-data php occ maintenance:repair --include-expensive
  • インデックスの追加

先ほどのNextcloudのルートディレクトリのまま実行します。

sudo -u www-data php occ db:add-missing-indices

念のため:apacheリスタート

  • apache再開前確認
systemctl status apache2.service

active(running)を確認します

  • apache再開
sudo systemctl restart apache2.service
  • apache再開確認
systemctl status apache2.service

active(runnning)を確認します

エラーの解消を確認します。

管理者権限でNextcloudにログインし、

AppAPIデフォルトのデプロイデーモンはHaRPを使用していません。パフォーマンス向上のため、アップグレードをご検討ください。

とメッセージが警告に変わっていればOKです。

この作業に関するFAQ

Dockerインストールによるメモリ消費量は大丈夫か?

全く問題ありません。誤差レベルです。

今回使用する alpine/socat というコンテナは、非常に軽量なことで有名な「Alpine Linux」というOSをベースに、socat という単純な転送プログラムだけが動いています。

  • 消費メモリ:
    • およそ 2MB ~ 6MB程度です。
  • CPU負荷:
    • 待機時はほぼ 0%です。

サーバー全体のメモリが数GBある環境であれば、このコンテナの存在に気づかないレベルの軽さですので、ご安心ください。

サーバ再起動時、Dockerの設定が消えるのではないか?

このコンテナに関しては、「データが消えても問題ない(そもそもデータを保存しない)」仕組みになっているため、大丈夫です。

なぜ消えても大丈夫なのか(仕組みの解説)

このコンテナ nextcloud_app_api_dsp は、「土管(パイプ)」のような役割しかしていません。

  • データの保存場所:
    -「どのデーモンを使うか」という設定情報は、このコンテナの中ではなく、Nextcloud本体のMySQLデータベースに保存されます。今後インストールする外部アプリ(AIなど)のデータも、Nextcloudのストレージ領域に保存されます。
  • このコンテナの役割:
    • Nextcloud(Webサーバー)からの命令を、Ubuntu本体のDockerシステムに「中継」するだけです。中継役なので、自分自身は何も記憶する必要がありません。
  • 再起動時の挙動:
    • Docker立ち上げ時、コマンド内の --restart always というオプションのおかげで、Ubuntuサーバーを再起動すると、このコンテナも自動的に「新品の状態」で立ち上がります。立ち上がった瞬間から、再び「中継役(土管)」としての仕事を再開します。前回の中身を覚えている必要がないため、これで正常に動作します。

まとめ

  • メモリ: スマートフォンの写真1枚分(数MB)しか使いません。
  • 保存: このコンテナは「ただの通信ケーブル」のようなものなので、記憶を保持する必要がなく、再起動してもNextcloud側の設定(DB)が残っている限り繋がり続けます。

色と差し色。

カメラの試し撮りを行った帰り、iPadを広げた途端に強烈な情報が目に入りました。

それは

  • No Time
  • No Choise
  • Without Thinking

と言えるものであり、その場で手続きを済ませ、翌日に到着。

ハリー・ポッターシリーズ、

  • スリザリン
  • レイブンクロー
  • ハッフルパフ
  • グリフィンドール

それぞれのLAMY AL-Star。そもそもLAMY万年筆は愛用品。しかも、それぞれの寮の色。ペン先も使いやすいEF。

それぞれ、プレミア価格ではなく在庫ありという幸運にも助けられ、届きました。

さて、ここまでの逸品。量産品を愛用する身ではありますが「それはそれ」です。これを最大限に活かすため、まずはインクを決めるところからです。

それぞれの寮に合わせ

はワンパターンです。かといって別の色というのも何か合いません。そこで、新たなインクを買い求めました。

そこで決めたのは、「寮のサブカラー」です。

  • スリザリン:銀
    • 冬将軍。この冷徹な野心を「冬」に込めました。
  • ハッフルパフ:黒
    • 竹炭。最も多用する色は、彼等の調和、連帯力に一致。
  • グリフィンドール:金
    • 橙路。色合いが金に近かったためこちらに。「路は自分で切り開く」グリフィンドールの精神にも合います。
  • レイブンクロー:銅
    • 春暁。同じく銅の鈍さと明るさ。彼等の寮ならそれこそ暁まで研究や議論に明け暮れいるでしょう。

さらに、インクに寮のマステを貼り、更に迷いをなくします。

書き味などを確かめるのはこのあとで。

RHEL系Linux(Rocky Linux)でDockerのビルド領域変更

Dockerならではの問題に対処したのでメモを残します。

背景と課題

RHEL / Rocky Linux 9 環境のGPUサーバーにおいて、Dockerビルド(大規模LLMモデルの生成など)を実行した際、ルートパーティション(/)の使用率が100%に達する事象が発生しました。

  • 原因: Dockerはデフォルトで /var/lib/docker(ルート配下)にイメージやビルドキャッシュを保存します。
  • 環境: ルート領域は70GB程度ですが、/home 領域には数TBの空きがります。
  • 対策: パーティションリサイズ(LVM操作)はリスクが高いため、Dockerのデータ保存先(data-root)を /home 配下へ物理的に移行して解決します。

さっくりとした手順

  1. 現状を確認し、サービスを停止します。
  2. Dockerの移行ディレクトリを作成します。
  3. rsyncを用いて安全にデータを移行します。
  4. Dockerの設定ファイルを変更します。
  5. Dockerサービスの再起動を行います。
  6. 設定変更を確認します。

現状の確認とサービスの停止

まず、現在のDocker設定とディスク使用量を確認し、Dockerサービスを停止します。

  • Dockerの保存先確認
docker info | grep "Docker Root Dir"

(デフォルトは /var/lib/docker)

  • Dockerサービスを停止します。
sudo systemctl stop docker docker.socket
  • Dockerサービスの停止を確認します。
systemctl status docker

inactive(dead)を確認します。

移行先ディレクトリを作成します。

大容量領域(今回は /home 配下)に新しい保存用ディレクトリを作成します。

  • ディレクトリ作成
sudo mkdir -p /home/docker/data

データの移行(最重要)

既存のイメージやコンテナデータを保持するため、rsync を用いてデータを同期します。
cp コマンドよりも、権限やタイムスタンプを正確に保持できる rsync を推奨します。
rsyncはRocky9に最初から入っているコマンドです。

  • /var/lib/dockerの中身を、新ディレクトリへコピー
sudo rsync -aqxP /var/lib/docker/ /home/docker/data/

-a: アーカイブモード(権限等を保持)
-x: ファイルシステム境界を越えない
注意: コピー元のパス末尾に / を付けることで、ディレクトリそのものではなく「中身」を転送先に展開します。

設定ファイルの変更 (daemon.json)

  • ファイルのバックアップを取ります。(凄く重要)

何かあったときの切り戻しのため。特に、後述するjsonの編集をミスると地獄行きの通過駅無しの特急が待っています。

sudo cp -pi /etc/docker/daemon.json /path/to/backup/directory/daemon.json.$(date +%Y%m%d)
  • ファイルのバックアップをdiffで取ります。
sudo diff -u /path/to/backup/directory/daemon.json.$(date +%Y%m%d) /etc/docker/daemon.json

一般ユーザが読み取れないディレクトリ構造も考慮して、念のためsudoをつけます。

→ エラーがなければバックアップ成功。ここでコピー元とコピー先を逆にしているのは編集後のdiffを取るためです。

  • Dockerに新しい保存先を認識させるため、/etc/docker/daemon.json を編集します。(エディタは宗教問題のため、自分の教義・信仰に沿ったものを利用してください)

変更例:
data-root オプションを追記します。
JSON形式のため、行末のカンマ(,)の有無に注意してください。

{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "data-root": "/home/docker/data"
}
  • 編集後の差分をdiffで確認します。
sudo diff -u /path/to/backup/directory/daemon.json.$(date +%Y%m%d) /etc/docker/daemon.json

以下のようになっていることを確認します。

-     "data-root": "/var/lib/docker"
+     "data-root": "/home/docker/data"

サービスの起動と確認

Dockerを起動し、設定が反映されているか確認します。

  • Dockerサービスを起動します。
sudo systemctl start docker
  • Dockerサービスの起動を確認します。
systemctl status docker

active(running)を確認します。

  • 設定反映の確認
docker info | grep "Docker Root Dir"

=> Docker Root Dir: /home/docker/data となっていれば成功です。

不要データの削除(任意)

動作確認後、元の /var/lib/docker を削除または退避させて、ルートパーティションの空き容量を回復させます。

安全のため、バックアップを取るか慎重に削除してください。この作業を行うときは深呼吸を3回ほど行い、飲み物を飲むなどして落ち着いてから行いましょう。

sudo rm -rf /var/lib/docker

結果

本対応により、ルートパーティションの圧迫が解消されました。

Before:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   70G   70G   20K 100% /

After:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   70G  6.0G   65G   9% /
/dev/mapper/rl-home  6.9T  198G  6.7T   3% /home

トラブルシューティング

  • SELinux: 起動に失敗する場合、SELinuxが非標準ディレクトリへのアクセスをブロックしている可能性があります。一時的に setenforce 0 で切り分けを行うか、適切なコンテキストを設定してください。
  • JSON構文エラー: daemon.json の記述ミス(カンマ忘れなど)があるとDockerが起動しません。編集後は慎重に確認を行いましょう。

RHEL系LinuxサーバにRTX 6000を認識させる。

※昨今のトレンドである「GPU前提のLinuxサーバ」つまり、AI環境に必須の

  • データセンタークラスのGPU
  • それをRHEL系Linuxに認識させ
  • 更にDockerというトレンドでも動かす

という難易度が高く――そして、インフラ屋にとって極上の素材を得る経験がありました。

そのときのメモです。(氷見の本マグロを捌くことになった調理師のような気分でした)

“逸般”の誤家庭的な環境

まず、これを一般家屋に置くと言うことはないでしょう。

  • OS:
    • Rocky Linux 9.x (Minimal Install)
  • Kernel:
    • 5.14.0-x (RHEL 9 Standard)
  • GPU:
    • NVIDIA RTX 6000 Ada Generation x 1
      • →2025/12/06時点でもちょっとした軽自動車が買えるやつです
  • Driver:
    • NVIDIA Driver 590.xx (Open Kernel Module)
  • Container Runtime:
    • Docker CE 27.x + NVIDIA Container Toolkit

前提環境の整備

  1. OSインストールを行います。(Rocky Linux Minimal)
  2. ネットワークの設定を行います。
  3. dnf updateを済ませます。

NetworkManagerによるネットワーク設定

固定IP化および自動接続設定を行う。

  • 接続プロファイル名の正規化 (デバイス名と合わせる)
sudo nmcli connection modify "Wired connection 1" connection.id eno2
  • 固定IP設定
sudo nmcli connection modify eno2 ipv4.addresses xx.xx.x.x/16
sudo nmcli connection modify eno2 ipv4.gateway Gateway IP
sudo nmcli connection modify eno2 ipv4.dns "DNS1 DNS2"
sudo nmcli connection modify eno2 ipv4.method manual
sudo nmcli connection modify eno2 connection.autoconnect yes

→ これをやっておかないと、再起動したときにNW設定が消えます。

  • 設定反映
sudo nmcli connection up eno2

システム更新とリポジトリ適用

RHEL 9 系でサードパーティ製パッケージを入れるため、これは必須です。特に、CRB (CodeReady Builder) の有効化を忘れると依存解決ができず、高性能GPUを認識させることができません。

  • dnf全更新
sudo dnf update -y
  • サーバ再起動
sudo reboot

→ カーネルアップデートも含まれるため。

  • CRB有効化 (旧 PowerTools)
sudo dnf config-manager --set-enabled crb
  • EPEL導入
sudo dnf install epel-release -y

NVIDIA Driver の導入

ここまで来たらいよいよ本命。(先のマグロの例に例えると、いよいよマグロの身に刃を当てていきます)

【重要】 RTX 6000 Ada はプロプライエタリ版ドライバではなく、Open Kernel Module (open-dkms) を要求します。これに気づかずハマりかけました。

依存関係の解決とリポジトリの導入。

  • 開発ツールの導入
sudo dnf groupinstall "Development Tools" -y
  • カーネルヘッダの導入
sudo dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r) -y
  • NVIDIA公式リポジトリ (RHEL9用) 追加
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

旧ドライバ/競合の排除

以前のインストール試行や(ハマったところ)、OSに入っているであろうGPUドライバを取り除かないと詰まります。

  • nvidia dkmsドライバのアンインストール
sudo dnf remove nvidia-driver kmod-nvidia-latest-dkms -y
  • nvidia dkmsドライバのリセット
sudo dnf module reset nvidia-driver -y

Open Kernel Module 版のインストール

  • dnf module機能を使って open-dkms ストリームを指定してインストール
sudo dnf module install nvidia-driver:open-dkms -y
  • サーバ全体を再起動してカーネルモジュールをロード
sudo reboot

ドライバ動作確認

nvidia-smi

-> `Driver Version: 590.xx / GPU Name: RTX 6000 Ada / VRAM: xxGB が表示されることを確認します。

コンテナ基盤の構築

筆者はコンテナが好みではないのですが、それはそれです。相手のオーダーに答えるのもまたお仕事。

Docker CE のインストール

ここではpodman ではなく Docker CE を採用しました。

  • Docker CEレポジトリ追加
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
  • Docker CEインストール
sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
  • Docker 自動起動有効化
sudo systemctl enable --now docker
  • 現在のユーザをDockerグループに加える
sudo usermod -aG docker $USER

NVIDIA Container Toolkit の導入

DockerコンテナでGPUが見えないと、せっかく「Dockerを入れろ」というオーダーが無になります。

  • Toolkitインストール
sudo dnf install nvidia-container-toolkit -y
  • Dockerランタイム設定 (daemon.jsonの更新)
sudo nvidia-ctk runtime configure --runtime=docker
  • Tookit/ランタイム反映
sudo systemctl restart docker

動作確認 (パススルーテスト)

コンテナ内部から GPU が見えるか確認します。

sudo docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

成功時、コンテナ内からホスト同様の nvidia-smi 結果が出力されれば動作完了です。

追加要素:最新トレンドに合わせた開発環境の用意。

言語ランタイム (Modern Runtime)の導入

OS標準を汚さず、最新の開発環境を整備する。

  • Node.js 22+:
    • NodeSourceリポジトリより導入。これは割愛です。(どっかしら探せば出てくるので)
  • Python 3.12:
    • Rocky Linuxは3.9。しかも、OSの核となっているプログラムなので、ソースコードを用いて altinstall (共存インストール) しないとサーバそのものが吹っ飛びます。

※実行例

  • 開発環境導入
sudo dnf install -y openssl-devel bzip2-devel libffi-devel zlib-devel readline-devel sqlite-devel tk-devel xz-devel
  • ソースコードダウンロード
wget https://www.python.org/ftp/python/3.12.8/Python-3.12.8.tgz
  • ソースコード展開
tar xzf Python-3.12.8.tgz && cd Python-3.12.8
  • ソースコードconfigure(最適化オプション)
./configure --enable-optimizations
  • CPUコアフルに用いての高速メイク
make -j $(nproc)
  • altinstall
sudo make altinstall

altinstallを入れないと上述したようにサーバが吹っ飛びます。

トラブルシューティング (Tips)

以下のエラーに出くわしたときの原因と対策です。

  • NVRM: requires use of the NVIDIA open kernel modules:
    • 原因: Ada世代のGPUに対し、従来のプロプライエタリドライバを入れたため。
    • 対策: dnf module install nvidia-driver:open-dkms を使用しました。
  • Secure Boot:
    • ドライバ導入前に BIOS/UEFI で Disabled になっていることを確認すること(署名周りのトラブル回避)。

RHEL系サーバ、実物環境下でのネットワーク設定

はじめに

GUIが多くなったとは言え、Linuxサーバは基本的にCLI(コマンドライン)・SSH接続によるリモート操作が基本です。この、CLIの環境下でのネットワーク設定という基本のメモです。

環境とやったこと

極めてよくあるユースケースです。即ち

「サーバ実機はこれである。ひとまず組織内(社内)ネットワークにつなげ」

という指令への対処。

  • 物理サーバ
    • 今回はVPSではありません。実機です。
    • その大きさ、重さを知るのもインフラ屋の醍醐味です。
  • Rocky Liunx 9.x
    • (RHEL系フォーク、ミニマルインストール)
  • ローカルNWにサーバのIPを割り当てる。
  • NW設定を有効化する。
    • 固定IP。クライアントならいざ知らず、サーバ運用は固定IPであるべきです。
    • IP: 172.xx.xx.xx/16 (/16はサブネットマスク255.255.0.0を意味します)
    • GW: 172.xx.254.254 (※これはあくまでも例です)
    • DNSサーバ/ドメイン:ローカルで定められているもの。

さっくりとした手順

ではありますが、かなり慎重に書いています。

  1. RockyLinuxサーバをMinimalでインストールします。
  2. サーバコンソールに直接ログインします。
  3. ネットワークインタフェースを確認します。
  4. nmcliによりネットワークを設定します。
  5. ネットワークインタフェースを有効化します。
  6. サーバを結線してリンクアップを確認します。
  7. 最初のdnf updateを行います。

RockyLinux 9.6インストール

インストール方法については割愛。GUI無しのMinimalをインストールします。というのも、多くのサービスが入ってしまうと、自分が管理しきれない部分が増えると共に、そこが脆弱性となるからです。

また、ここでは最初からネットワークにつなぎません。設置する組織によってはLAN接続も許可制になっているパターンが極めて多いです。(IPも指定されたものを使うというのが実情でしょう)

サーバコンソールにログイン

この段階ではrootでも構いません。何せ、物理的に言葉通りの意味で切断されているのですから。

物理ネットワークの確認

vpsと違い、最初からネットワークにつながっていません。当然、IPも振られていません。なので「どのLANポートを使うか?」から始まります。

nmcli

を実行します。これはNetwork Manager Command Line Interfaceの略であり、RHELサーバの肝と言えるネットワーク設定コマンドです。(普段Ubuntuサーバを使う筆者は少々混乱しました)

筆者環境では

  • eno2
  • eno3

がありました。ここではeno2を確認していきます。

ネットワーク設定

  • 現状確認
nmcli connection show

以下のような例が出てきます。

NAME     UUID                                  TYPE      DEVICE
eno2     UUID文字列                             ethernet  eno2
lo       UUID文字列                             loopback  lo
eno3     UUID文字列                             ethernet  eno3

この、eno2というポートを使います。

  • ※例外

もし、もし NAME 列に Wired connection 1 とあり、DEVICE 列が eno2 ならば、次の手順で名前を変更します。

  • ※例外時の実施- "Wired connection 1" を "eno2" にリネーム
sudo nmcli connection modify "Wired connection 1" connection.id eno2
  • IPとサブネット設定 (CIDR表記でスマートに)
sudo nmcli connection modify eno2 ipv4.addresses 172.xx.xx.xx/16

→ 実際に指定されたIPアドレスを入力します。このとき、二重チェックで「同一ネットワーク内にIPアドレスが無いか? / 打ち間違いがないか?」を確認しましょう。被ってしまうと単純な破滅が待っています。

  • ゲートウェイ設定
sudo nmcli connection modify eno2 ipv4.gateway 172.xx.254.254

こちらも同様。別のゲートウェイを設定していないかを確認。

  • DNS設定
sudo nmcli connection modify eno2 ipv4.dns "DNS1 IPアドレス DNS2 IPアドレス"

→ DHCPと異なり、固定IPはDNSサーバを指定します。組織内では冗長性のため複数あるケースがほとんどです。

  • ドメイン設定
sudo nmcli connection modify eno2 ipv4.dns-search "組織内ドメイン"

→ 組織内ドメインで、FQDNの名前解決を効率化するため。

  • メソッドを手動にしてIPアドレス固定
sudo nmcli connection modify eno2 ipv4.method manual
  • 【重要】自動接続をONにする (これを忘れると再起動後に死ぬ)
sudo nmcli connection modify eno2 connection.autoconnect yes

→ autoconnect no の状態だと、システムが再起動した後、NetworkManagerは設定ファイルは認識していますが、その接続を自発的に起動しません。つまり、何らかの事情でサーバそのものを再起動した場合、このネットワーク設定が断たれます。即ち、あらゆるネットワークから完全に切り離されます。

ネットワーク設定の有効化

ここまで来たらいよいよサーバにネットワークを認識させます。このコマンドの前に深呼吸をして落ち着きましょう。(サーバ室/データセンターからの離席を許されるならこの段階で)

  • 再起動して設定をロード
sudo nmcli connection up eno2
  • IPアドレスの確認
ip addr show eno2

→ インターフェース eno2 に正しいIPアドレス、ネットマスクが割り当てられたか。

eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
  • ルーティングの確認
ip route

→ デフォルトゲートウェイ(外部ネットワークへの出口)が正しく設定されたか。

IPアドレスが正しくても、どこへパケットを送るか(経路情報)がなければ、ローカルネットワーク外へは通信できません。

default via  172.xx.254.254 dev eno2

などの行がないと、外部環境は無意味です。初歩的ですが非常に詰まりやすいポイントです。

  • DNS設定の確認
cat /etc/resolv.conf

→ ネームサーバーと検索ドメインが設定ファイルに反映されたか。

nameserver: 設定した社内のDNSサーバーのIPアドレス(例: nameserver 192.168.1.53)が正しくリストアップされているか。
もしこれらが正しく反映されていなければ、名前解決ができず、Webサイトの閲覧やホスト名でのサーバーアクセスができなくなります。

サーバの結線

上記が確認できたら、サーバという鉄の箱を「ネットワークと通信ができる」状態へと落とし込みます。ここでも、単純ながら致命的なミスが待ち構えています。

以下を確認しましょう。

  • LANポートの接続先と接続元は合っているか?
    • 特に、LANポートの迷路とも言えるサーバ室やデータセンターではこれらを間違えると地獄が待っています。比喩的な意味では無く。
  • LANケーブルは断線が無いか?
    • 切り分けの手間を減らします。
  • ストレートとクロスを間違えていないか?
    • たまにありますが結構盲点です。

疎通確認

  1. Gatewayへの Ping:ping -c 4 172.xx.254.254
    • これが通れば、L2/L3(組織/社内ネットワークへの物理・論理接続)は成功しています。
  2. DNSサーバへの Ping:ping -c 4 [DNSサーバーのIP]
    • これが通れば、名前解決の準備OKです。
  3. 外の世界への Ping:ping -c 4 google.com
    • これで初めて「インターネット接続完了」です。

DNFアップデート

サーバ全体のLinuxシステムを「最新の状態にする」おまじないです。

sudo dnf update -y

ここでの注意点はトラフィック。大容量のデータがこのサーバに流れます。貧弱な回線ではたちまちパンクします。

Complete!と表示されたら、

sudo reboot

で物理的に再起動します。というのも、dnfアップデートはたいがいカーネルの更新も伴うからです。

この再起動後、「先ほどのネットワーク設定が活きているか? 失われていないか?」が伴い、初めてこのネットワーク設定という初歩的な設定が完了します。

Page 1 of 98

Powered by WordPress & Theme by Anders Norén