カテゴリー: nextcloud Page 1 of 7

NextcloudアップデートとDBバックアップを行うBashスクリプトの解説

Nextcloudのアップデートは、それほど頻繁に行う作業ではありません。しかし、だからこそ毎回「あれ、このコマンド実行したっけ?」となりがちです。

筆者自身も、メンテナンスモードの切り替えやデータベースのバックアップなど、手順を一つひとつ確認しながら作業していました。そこで「毎回やることはスクリプトに任せよう」と考え、更新前のバックアップから updater.phar の実行までを一通り補助する Bash スクリプトを作成しました。

今回は、そのスクリプトの仕組みを紹介します。

動作環境

動作を想定している環境は以下の通りです。

  • Ubuntu 20.04 LTS / 22.04 LTS / 24.04 LTS
  • MySQL または MariaDB
  • PHP / Bash
  • root 権限(sudo)
  • Apache実行ユーザ: www-data

Ubuntu系で一般的な構成であれば、そのまま利用できるようになっています。

スクリプト本体

最初に環境に合わせて、スクリプト冒頭の変数だけ変更します。

NC_DIR="/var/www/html/nextcloud"
NC_USER="www-data"

DB_NAME="nextcloud"
DB_USER="nextcloud"

BACKUP_DIR="/var/backups/nextcloud"

続いて実行権限を付与します。

chmod +x nextcloud_update.sh

最後に sudo で起動します。

sudo ./nextcloud_update.sh

途中では

  • データベースパスワード
  • 各ステップへ進むかどうか

を対話形式で確認します。

確認しながら進められるので、完全自動化というより「操作ミスを減らすための半自動化」という位置付けです。

Bashで自動化というと「全部ワンコマンドで終わらせる」方向へ行きがちですが、個人的にはサーバーの更新作業はそこまで割り切らない方が安心だと考えています。

特に Nextcloud のアップデートは、途中で状況を確認したくなる場面も少なくありません。

そのため、このスクリプトでは各工程ごとに確認を挟み、「人が判断するところ」と「機械に任せるところ」を分ける構成にしました。

毎回同じ手順を思い出しながら実行するより、確認すべきポイントだけに集中できるので、更新作業はかなり気楽になります。

以下がスクリプト全文です。

#!/bin/bash
# ==============================================================================
# Nextcloud Update & Database Backup Script
# ==============================================================================

set -euo pipefail

# --- 変数定義(環境に合わせて変更してください) ---
NC_DIR="/var/www/html/nextcloud"
NC_USER="www-data"
PHP_BIN="php"

# DB設定
DB_NAME="nextcloud"
DB_USER="nextcloud"
DB_HOST="localhost"
BACKUP_DIR="/var/backups/nextcloud"

# --- ユーティリティ関数 ---
log_info() {
    echo -e "\n\e[34m[INFO]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1"
}

log_warn() {
    echo -e "\e[33m[WARN]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1"
}

log_error() {
    echo -e "\e[31m[ERROR]\e[0m $(date '+%Y-%m-%d %H:%M:%S') - $1" >&2
}

ask_proceed() {
    local prompt_msg="${1:-次のステップに進みますか?}"
    while true; do
        read -rp "👉 ${prompt_msg} [y/N]: " answer
        case "${answer}" in
            [yY]|[yY][eE][sS])
                return 0
                ;;
            [nN]|[nN][oS]|"")
                log_warn "ユーザーにより処理が中断されました。"
                exit 1
                ;;
            *)
                echo "'y' または 'n' を入力してください。"
                ;;
        esac
    done
}

# --- 前提チェック ---
# root 権限チェック(sudo 経由を含む root 以外は即時終了)
if [ "${EUID}" -ne 0 ]; then
    log_error "このスクリプトは root 権限で実行する必要があります。(例: sudo $0)"
    exit 1
fi

log_info "前提条件と実行権限を確認しています..."

if [ ! -d "${NC_DIR}" ]; then
    log_error "Nextcloudディレクトリが見つかりません: ${NC_DIR}"
    exit 1
fi

if ! command -v mysqldump &> /dev/null && ! command -v mariadb-dump &> /dev/null; then
    log_error "mysqldump または mariadb-dump コマンドが見つかりません。"
    exit 1
fi

mkdir -p "${BACKUP_DIR}"

# ==============================================================================
# Step 1: データベースパスワードの取得と認証確認
# ==============================================================================
log_info "【Step 1】データベース情報の入力"
read -rsp "🔑 DBユーザー (${DB_USER}) のパスワードを入力してください: " DB_PASS
echo

# パスワードの疎通確認
if ! MYSQL_PWD="${DB_PASS}" mysqladmin -h "${DB_HOST}" -u "${DB_USER}" ping &>/dev/null; then
    log_error "データベースへの接続に失敗しました。パスワードまたはホスト設定を確認してください。"
    exit 1
fi
log_info "データベースへの接続を確認しました。"

# ==============================================================================
# Step 2: メンテナンスモードの有効化
# ==============================================================================
log_info "【Step 2】メンテナンスモードの有効化"
ask_proceed "メンテナンスモードをONにしますか?"

sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode --on
log_info "メンテナンスモードを有効化しました。"

# スクリプト異常終了時にメンテナンスモード解除を促すトラップを設定
cleanup() {
    if [ $? -ne 0 ]; then
        log_warn "エラーが発生したため処理を停止しました。"
        log_warn "必要に応じてメンテナンスモードを解除してください:"
        log_warn "sudo -u ${NC_USER} ${PHP_BIN} ${NC_DIR}/occ maintenance:mode --off"
    fi
}
trap cleanup EXIT

# ==============================================================================
# Step 3: DBバックアップの実行(インラインパスワード処理)
# ==============================================================================
log_info "【Step 3】DBバックアップの実行"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_backup_${TIMESTAMP}.sql.gz"

ask_proceed "DBバックアップを開始しますか? (保存先: ${BACKUP_FILE})"

# dumpコマンドの判定(MariaDB/MySQL互換)
DUMP_CMD="mysqldump"
command -v mariadb-dump &> /dev/null && DUMP_CMD="mariadb-dump"

# MYSQL_PWD環境変数を使用することで、psコマンド等へのパスワード露出を防止
if MYSQL_PWD="${DB_PASS}" ${DUMP_CMD} -h "${DB_HOST}" -u "${DB_USER}" --single-transaction --quick "${DB_NAME}" | gzip > "${BACKUP_FILE}"; then
    log_info "バックアップが正常に完了しました: ${BACKUP_FILE}"
else
    log_error "バックアップ処理中にエラーが発生しました。"
    exit 1
fi

# ==============================================================================
# Step 4: updater.phar によるアップデート実行
# ==============================================================================
log_info "【Step 4】updater.phar の実行"
log_warn "updater自体の対話プロンプトが表示されます。画面の指示に従って操作してください。"
ask_proceed "updater.phar を起動しますか?"

cd "${NC_DIR}"
sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/updater/updater.phar"

# ==============================================================================
# Step 5: 状態の確認とメンテナンスモードの調整
# ==============================================================================
log_info "【Step 5】最終確認とメンテナンスモードの解除"

current_mode=$(sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode)
echo "現在の状態: ${current_mode}"

if echo "${current_mode}" | grep -q "enabled"; then
    read -rp "👉 メンテナンスモードをOFF(解除)にしますか? [y/N]: " unfreeze
    if [[ "${unfreeze}" =~ ^[yY]$ ]]; then
        sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" maintenance:mode --off
        log_info "メンテナンスモードを解除しました。"
    else
        log_warn "メンテナンスモードを維持したまま終了します。"
    fi
fi

# ==============================================================================
# Step 6: バージョン確認
# ==============================================================================
log_info "【Step 6】バージョンの確認"
sudo -u "${NC_USER}" "${PHP_BIN}" "${NC_DIR}/occ" status

log_info "すべての更新手順が完了しました。"
trap - EXIT

このスクリプトで重視したこと

単にコマンドを並べるだけではなく、「途中で失敗しても致命傷にならないこと」を意識しています。

set -euo pipefail

Bashスクリプトでは定番ですが、非常に重要です。

  • コマンドが失敗した
  • 未定義変数を参照した
  • パイプラインの途中でエラーが発生した

このような場合は、その時点で処理を停止します。

「バックアップに失敗したのに、そのままアップデートが続く」といった事故を防ぐためです。

root権限の確認

EUID を利用して、root 権限以外では実行できないようにしています。

sudo ./nextcloud_update.sh

以外の実行方法では即座に終了します。

パスワードをコマンドラインへ残さない

昔ながらの

mysqldump -pPASSWORD

という書き方は、ps コマンドなどからパスワードが見えてしまいます。

そこで本スクリプトでは

MYSQL_PWD

環境変数を利用しています。

賛否のある方法ではありますが、少なくともコマンドライン引数へ平文パスワードを残すより安全です。(なお筆者は別スクリプトを利用していますが、それはまた別のお話)

trapによる復旧案内

一番怖いのは

  • メンテナンスモードON
  • エラー発生
  • そのまま終了

というパターンです。

そこで trap cleanup EXIT を利用し、異常終了した場合は

occ maintenance:mode --off

を案内するようにしています。

「解除方法を忘れた」という事態を防ぐための保険です。

実行の流れ

処理は次の順番で進みます。

1. 前提条件の確認

まずは

  • root権限
  • Nextcloudディレクトリ
  • mysqldump または mariadb-dump

の存在を確認します。

ここで問題があれば、それ以上処理は進みません。

2. データベース接続の確認

パスワードを入力したあと、

mysqladmin ping

で接続テストを行います。

アップデート直前になって認証エラーが発覚するより、最初に確認してしまった方が安心です。

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

occ maintenance:mode --on

を実行します。この操作の前にも確認プロンプトを表示するため、誤操作を防げます。

4. データベースをバックアップ

バックアップには

  • mysqldump
  • mariadb-dump

のどちらか利用可能な方を自動で選択します。

取得したSQLは、そのまま gzip 圧縮して保存します。

nextcloud_backup_20260821_153000.sql.gz

のように日時付きファイルになるため、履歴も管理しやすくしています。

5. updater.phar を起動

Nextcloud標準の

updater.phar

を実行します。ここから先はNextcloud側の対話画面になりますので、画面の案内に従って更新を進めます。

6. 最終確認

更新後は

  • メンテナンスモードの状態確認
  • 必要ならOFFへ変更
  • occ status

まで実行します。最後に現在のバージョンが表示されれば、一通りの更新は完了です。

さっくりとしたまとめ

サーバー運用では「バックアップを取ってから更新する」は当たり前ですが、人間は当たり前ほど慣れてしまうものです。だから私は、忘れない仕組みを作るようにしています。

「運用者は呼吸するかのようにできる。だが、第三者に任せられるか? すっごく焦ってるときに緊急アップデートをした時は?」のためにも、確実に動く仕組みは大切というお話でした。

Nextcloudにプロキシサーバを設定。

xtcloudサーバのあるネットワークがプロキシー配下にあったため

  • Nextcloudの管理画面がサーバやアプリのアップデートを検知できない
  • ネットと通信するアプリがNextcloudと通信できない

状況が発生。それを修正します。

やることは単純です。

「configファイルの修正」

OSはUbuntuです。

手順

config.php の場所を確認する

Nextcloudのインストール方法によって、設定ファイルの場所が異なります。一般的な場所は以下の通りです。

  • 手動インストール(Apache/Nginx)の場合:
    • /var/www/nextcloud/config/config.php
    • 筆者環境 /home/www-data/nextcloud/config/config.php
  • Snapでインストールした場合:
    • /var/snap/nextcloud/current/nextcloud/config/config.php

2. 設定ファイルのバックアップ

  • 設定ファイルバックアップ
sudo cp -pi /home/www-data/nextcloud/config/config.php /path/to/backup/config.php.$(date +%Y%m%d)
  • 設定ファイルのバックアップ確認
sudo diff -u /path/to/backup/config.php.$(date +%Y%m%d) /home/www-data/nextcloud/config/config.php

エラーがないことを確認します。ここで~sudo~をつけるのは、一般権限では読み込みすらできないからです。

3. プロキシ設定を追加する

上記ファイルを$CONFIG = array ( の中に、以下の3行(プロキシの設定)を追記します。既存の設定項目の末尾() の手前)に追加してください。 当然ながら管理者権限が必要です。

  'proxy' => '192.168.1.50:8080', // 自分の環境に合わせます。
  'proxyuserpwd' => '', // もしプロキシに認証(ユーザー名:パスワード)が必要ならここに記述
  'noproxy' => array('localhost', '127.0.0.1'), // プロキシを通さないローカルアドレス

【設定例】全体のイメージ

<?php
$CONFIG = array (
  'instanceid' => 'ocxxxxxxxxxx',
  'passwordsalt' => 'xxxxxxxxxxxxxxxxxxxxxxxxxx',
  // ・・・(中略)・・・
  'trusted_domains' => 
  array (
    0 => 'localhost',
  ),
  'datadirectory' => '/var/www/nextcloud/data',
  'dbtype' => 'mysql',

  // ここに追記します
  'proxy' => '192.168.1.50:8080',
  'proxyuserpwd' => '',
  'noproxy' => array('localhost', '127.0.0.1'),
);

設定後、ファイルを保存します

  • 設定ファイルの修正確認
sudo diff -u /path/to/backup/config.php.$(date +%Y%m%d) /home/www-data/nextcloud/config/config.php
+  'proxy' => '192.168.1.50:8080',
+  'proxyuserpwd' => '',
+  'noproxy' => array('localhost', '127.0.0.1'),

など、追加したプロキシ設定が追加されていることを確認します。

4. Webサーバー(またはPHP)の再起動

設定を反映させるため、Webサーバーを再起動します。

  • Apacheの場合:
sudo systemctl restart apache2
  • Nginx / Apache + PHP-FPMの場合:
sudo systemctl restart nginx
sudo systemctl restart php8.x-fpm  
  • Snapインストールの場合:
sudo snap restart nextcloud

接続テスト

設定完了後、Nextcloudの管理者画面にブラウザからログインし、以下の項目を確認してください。

  1. 「管理者設定」>「概要」 を開き、インターネット接続に関するエラー(「このサーバーにはインターネット接続がありません…」など)が消えているか確認。
  2. 「アプリ」画面 を開き、外部のアプリストアから新しいアプリの一覧が正常にロードされるか確認。

NextcloudのタスクとiOSのリマインダを認識させる

Nextdloudを更に統合プラットフォームとして使うため、以下の手順が必要でした。

環境

Nextcloud側

  • Ver 33
  • Nextdloud Task (標準アプリ)
  • Ubuntu 24.04
  • PHP-FPM 8.3
  • Apache 2.4
  • MySQL 8
  • ※二要素認証あり
  • ※外部からアクセスできる環境にあること

iOS側

  • iOS 26.42
  • iPhone Air

さっくりとした手順

  1. Nextdloud側でアプリパスワードを作ります。
  2. iOS側でアカウントを競ってします。

Nextcloud側でのアプリパスワードの設定

  1. 個人設定 > セキュリティに遷移します。
  2. デバイスとセッションの一番下、アプリ名というところに適当な名前を付けます。iOSリマインダー
  3. 新しいアプリパスワード作成をクリックします。このパスワードは一度しか表示されません。控えておきます。(一番手っ取り早いのはそのパスワードをコピーして、Nextdloud Talk等で貼り付けること。ただし、Nextdloud全てにアクセスできるパスワードです。設定後、速やかにTalkから削除しましょう。

iOS側での連携

  1. iPhoneの「設定」>「リマインダー(またはアカウント)」>「CalDAVアカウントを追加」の画面を開きます。
  2. 以下のように設定します。
    1. サーバ: 自分のNextdloudのドメイン
    2. アカウント:自分のNextdloudのアカウント
    3. パスワード:先ほど生成したアプリパスワード
    4. 設定:自分が覚えやすいもの
  3. 設定後「次へ」をタップして、エラーがないことを確認します。

連携の確認

Nextdloud側で適当なタスクを作成して、iOS側で表示されることを確認します。

iOSの「リマインダー」に、Nextdloudで設定したタスクが表示されることを確認します。

iOS側で適当なタスクを作成して、Nextdloud側で表示されることを確認します。

iPhoneの画像データを自宅内のNextcloudに一括送信。

連休で家にいる中でないとできない作業でした。

事前準備

  1. Nextcloud(宅内)のセットアップができている。
  2. NextcloudサーバとNASをNFSでマウントしている。(書き取り可能になっている)
  3. iPhoneにNextcloudアプリを入れ、同じNW内にあるNextcloudと連携が取れている。

2,019年からのiPhoneデータ。相当に苦労しました。

自動アップロード設定画面を開く

Nextcloudアプリの自動アップロード機能を有効化するしていきます。

Nextcloudアプリ右下「その他(…)」 → 「設定」 → 「自動アップロード」

の画面を開きます。

カメラロールの自動アップロードを有効化

iPhoneの写真アプリ内の画像・動画をNextcloudへ自動送信するため「カメラロールをアップロード」をオンにします。

必要に応じて「新しい写真のみ」「すべての写真」などの範囲を選択します。(筆者は全ての写真を選択)

保存先フォルダを指定(重要)

誤ったフォルダを選ぶと整理が崩れるため、最も重要なステップです。

  1. 「リモートフォルダ」をタップ
  2. 事前に作成した NAS側の外部ストレージフォルダ を選択しました。

必要に応じて「カメラロール」専用フォルダをNextcloud側で作っておきましょう。

同期条件を設定して安定性を確保

筆者は「Wi-Fi使用時のみ」をオンにしました。というのも、このNextcloudは完全に宅内で運用するからです。

初回のみ:自動ロックの解除

これがハマりポイントでした。

iPhoneの

設定 > 画面表示と明るさ > 自動ロック

に選び「なし」に変更。その上で先のiPhoneのNextcloudアプリを開きっぱなしにしておきます。

可能であればワイヤレス充電でつけっぱなしにしておくと良いでしょう。

参考までに、宅内無線LAN環境、45,000枚ほどの画像の転送に10時間ほどかかりました。

※この作業が終わったら自動ロックの設定を元に戻すのを忘れないようにしましょう。

Ubuntu26.04でNextcloudをインストール。(Apache/MySQL/PHP8.5-FPM)

概要

  • Ubuntu 26.04
  • Apache

をインストールした状況で、「PHP-FPM」を稼働させた上でNextcloudをインストールしていくためのメモです。

この手順はゴールではなくスタートです

  • 本手順は「構築した」という始まりに過ぎません。
  • 「動く」手順ではありますが「初期設定」は以下が絡むため、これ以上に厄介です。
    • 初期設定
    • メール設定
    • redis設定
    • 各種セキュリティ
    • ログ設定
    • アプリのチューニング…
  • インターネット環境だろうとローカルだろうと、「データを取り扱う器」を構築した以上、データ保全という義務と責任がこれから重くのしかかります。
  • 本手順で「めんどくさい」と思った方は素直にOneDrive/GoogleDrive/Dropboxをお使いください。その方があなたもデータも幸せです。(実際、筆者が使ってるGoogle AI proなら月額2900円で5TBも利用可能です!)

再掲:Nextcloudというかサービス運営者に必要なのは「資格」ではなく「責任」です。

Ubuntu24.04のインストール時にも言いましたが、この理論は未だに私の中では真理です。

巷では「○○の資格があればこの運用は」的な話があるようですが:そもそも運用の方針を取り違えていると思います。

「救急戦隊ゴーゴーファイブ」に曰く

「資格? 馬鹿野郎、誰もそんなもの持ってねぇんだ! いいか、あるのは責任だけだ。戦う責任! あの子を傷つけちまった責任! そいつを果たすには、この地球を守るしかねぇんだ!」

私が言いたいことはこれに尽きます。

なぜ mod_php ではなく PHP-FPM を使うのか?

パフォーマンスとリソース効率を向上させるためです。

従来のmod_phpでは、PHPがApacheの全プロセスに組み込まれるため、画像ファイルのリクエストのようなPHPが不要な処理でもメモリを消費し、無駄が多くなりがちでした。

一方、PHP-FPMはPHPの処理をApacheから完全に独立させた専門のプロセスとして管理します。ApacheはPHPが必要なリクエストだけをPHP-FPMに中継するため、サーバー全体の動作が軽量かつ高速になります。

前提

  • OS: Ubuntu 26.04 LTS
  • → SSH接続できること。
  • ※root権限を持っていること。
  • この権限を持っていない場合、ここから先の設定はできません。
  • データベース: MySQL 8.0
  • Webサーバー: Apache 2.4
  • 実行ユーザーはwww-data
  • ホームディレクトリを /home/www-dataにしています。自分の環境に合わせてください。
  • ドメインとSSL/TLS証明書: 準備済みであること

筆者の好みでaptitudeを用いています。必要に応じてaptをご利用ください。

さっくりとはならない手順

  1. パッケージをインストールしていきます。
  2. PHP-FPMの設定を行います。
  3. PHPのパフォーマンス設定を行います。
  4. MySQLでDB設定を行います。
  5. NextcloudのDBを設定します。
  6. Apacheバーチャルホストの設定を行います。
  7. バーチャルホストの設定を有効化します。
  8. 設定の有効化とサービスの再起動を実施します。
  9. Webブラウザで初期インストールを行います。

必要なパッケージのインストール

PHP本体、PHP-FPM、Nextcloudが必要とする各種PHPモジュールをインストールします。

sudo aptitude install php php-fpm php-opcache php-pdo php-bcmath php-calendar php-ctype php-fileinfo php-ftp php-gd php-intl php-json php-mbstring php-mysql php-posix php-readline php-sockets php-bz2 php-tokenizer php-zip php-curl php-iconv php-xml php-imagick php-gmp php-apcu memcached

バージョンを確認します。

php -v

表示例

PHP 8.5.4 (cli) (built: Apr  1 2026 09:36:11) (NTS)
Copyright (c) The PHP Group
Built by Ubuntu
Zend Engine v4.5.4, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.4, Copyright (c), by Zend Technologies

※Ubuntu 26.04はリポジトリを追加するまでもなくPHP8.5がインストールされます。※

PHP-FPMとApacheの連携設定

従来の mod_php を無効化し、PHP-FPMとの通信に必要な proxy_fcgi モジュールなどを有効化します。

  • mod_phpを無効化(もしインストールされていれば)
sudo a2dismod php
  • 必要なモジュールを有効化
sudo a2enmod proxy_fcgi setenvif header rewrite

PHPのパフォーマンス設定

Nextcloudのパフォーマンス向上のため、PHPのメモリ制限、OPcache、APCuを設定します。

  • php.ini の設定 (memory_limit)
sudo sed -i 's/memory_limit = .*/memory_limit = 512M/g' /etc/php//fpm/php.ini
  • OPcacheとAPCuの有効化

Nextcloud推奨の設定値を /etc/php//mods-available/ に作成・適用します。

  • OPcache設定
cat <<- __EOF__ | sudo tee /etc/php//mods-available/opcache.ini
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
  • APCu設定
cat <<- __EOF__ | sudo tee /etc/php//mods-available/apcu.ini
[apcu]
apc.enabled=1 apc.shm_size=32M apc.ttl=7200 apc.enable_cli=1 apc.serializer=php __EOF__
  •  設定の有効化
sudo phpenmod opcache apcu

このphpenmodがハマりポイントでした。従来の ln -sではなく、専用コマンドを用いることでfpm / cli / apache-mod でも安定した運用が可能になります。

データベースの作成

Nextcloudが使用するMySQLデータベースと専用ユーザーを作成します。

  • MySQLにrootでログイン
mysql -u root -p

以下のSQLコマンドを実行します。YOUR_STRONG_PASSWORD は必ず強固なパスワードに変更してください。

CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'YOUR_STRONG_PASSWORD';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Nextcloudプログラムの配置

Nextcloud本体をダウンロードし、Webサーバーからアクセスできる場所に配置します。

  • 作業ディレクトリへ移動
cd /tmp && pwd

任意のディレクトリを指定します。

  • 最新版をダウンロードして展開
wget https://download.nextcloud.com/server/releases/latest.zip
unzip latest.zip
  • 展開したファイル一式をWeb公開用ディレクトリに移動
sudo mv nextcloud /home/www-data/
  • 所有者をWebサーバーの実行ユーザーに変更
sudo chown -R www-data:www-data /home/www-data/nextcloud

Apacheバーチャルホストの設定

Nextcloud用のApache設定ファイルを作成します。ここでPHP-FPMとの連携設定を組み込みます。

  • ログディレクトリの作成
sudo mkdir /var/log/nextcloud
  • ログディレクトリをwww-dataに修正。

これは、後のメンテナンス性を高めるためです。

sudo chown www-data:www-data /var/log/nextcloud
  • 設定ファイルの作成
/etc/apache2/sites-available/nextcloud.conf

を、teeで一気通貫で作ります。

# 【】内はご自身の環境に合わせてください
cat <<- __EOF__ | sudo tee /etc/apache2/sites-available/nextcloud.conf
<VirtualHost *:80>
    ServerName 【hoge.example.com】
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName 【hoge.example.com】
    DocumentRoot 【/home/www-data/nextcloud】

    CustomLog /var/log/nextcloud/nextcloud_access.log combined
    ErrorLog /var/log/nextcloud/nextcloud_error.log

    <Directory 【/home/www-data/nextcloud】>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>

    # PHP-FPM連携設定
    <FilesMatch \.php$>
        # SetHandlerで、phpファイルのリクエストをPHP-FPMのソケットに渡す
        SetHandler "proxy:unix:/var/run/php/php8.5-fpm.sock|fcgi://localhost/"
    </FilesMatch>

    # --- SSL設定 ---
    SSLEngine on
    Protocols h2 http/1.1
    SSLCertificateFile 【/etc/certs/hoge.example.com.crt】
    SSLCertificateKeyFile 【/etc/private/hoge.example.com.key】
    # 中間証明書が別に提供されている場合はこちらを有効化
    # SSLCACertificateFile 【/etc/certs/hoge.example.com.CA.crt】

    # --- 推奨SSL/TLS設定 ---
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     on
    SSLCompression          off
    SSLSessionTickets       off

    # --- セキュリティヘッダー ---
    Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    Header always set Referrer-Policy "no-referrer"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Permitted-Cross-Domain-Policies "none"
</VirtualHost>
__EOF__

※ こちらもMod_Securityによる連携は可能です。

設定の有効化とサービスの再起動

  • 作成したサイト設定を有効化
sudo a2ensite nextcloud.conf
  • 構文チェック
sudo apache2ctl configtest

Syntax OK と表示されることを確認

  • fpm/apacheサービスを再起動
sudo systemctl restart php8.5-fpm.service
sudo systemctl restart apache2.service
  • fpm/apache再起動確認
systemctl status php8.5-fpm.service
systemctl status apache2.service

active (running)と表示されていれば正常です。

Webブラウザでのセットアップ

最後に、Webブラウザで https://【設定したドメイン】 にアクセスし、画面の指示に従ってNextcloudの初期設定を完了させます。

  • 管理者ユーザーのユーザー名とパスワードを入力
  • データベース情報を入力
  • データベースのユーザー名: nextcloud
  • データベースのパスワード: データベースのパスワード
  • データベース名: nextcloud
  • データベースのホスト名: localhost (または localhost:3306)

これで、PHP-FPM上で動作するNextcloud環境の構築が完了します。

Ubuntu26.04にPHP8.5/PHP8.5-FPMをインストール。

概要

Ubuntu 26.04でWebアプリ(Nextcloudを想定)を動かす際の柱であるPHPのインストールを行います。

盛大にはまったポイント

2026/04/23にリリースされた26.04。導入されるミドルウェアの最新性がキモでした。

筆者が前項でやったレポジトリ追加は「26.04には対応してない。そもそもミドルウェアが合ってない」など言われましたが、
「リポジトリを追加するまでもなく最新版がインストールされる」ことに気づきませんでした。

さっくりとした手順

  1. システムを最新化します。
  2. PHP 8.5本体を導入します。
  3. 必須モジュールをインストールします。
  4. PHP-FPMを導入します。
  5. 高速化設定を行います。(OPcache, APCu周り)
  6. 設定を反映します。

システムの更新

まずは標準リポジトリを最新の状態にします。

sudo aptitude update

PHP 8.5 本体と Redis サーバーのインストール

メタパッケージ(バージョン指定なし)を使用することで、OSが最適な 8.5 系を自動選択します。

sudo aptitude install php php-fpm php-common php-cli php-readline redis-server

当初筆者はPHP8.4を選択していたのですが、そこが盛大なはまりポイントでした。(PHPの動向を追っていなかったという失態もあります)

Nextcloud 必須・推奨拡張モジュールのインストール

Nextcloudの動作に不可欠なモジュール群を一括で導入します。

sudo aptitude install php-{bcmath,bz2,curl,gd,gmp,intl,ldap,mbstring,mysql,sockets,xml,zip,imagick,redis,apcu,memcached}

Apache 連携設定 (PHP-FPM版)

Apacheで PHP 8.5 を FPM 経由で動作させる設定です。

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.5-fpm
sudo systemctl restart apache2

5. PHP 8.5 高速化設定 (OPcache / APCu)

Nextcloudの警告を消し、パフォーマンスを最大化するための設定です。

  • OPcache設定の作成
cat <<- __EOF__ | sudo tee /etc/php/8.5/mods-available/opcache.ini > /dev/null
; configuration for php opcache module
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__

→ 既にあるファイルを上書きます。(切り戻し想定せず)

  • APCu設定の作成
cat <<- __EOF__ | sudo tee /etc/php/8.5/mods-available/apcu.ini > /dev/null
extension=apcu.so
[apcu]
apc.enabled=1 apc.shm_size=32M apc.ttl=7200 apc.enable_cli=1 apc.serializer=php __EOF__

 設定の有効化

sudo phpenmod opcache apcu

このphpenmodもハマりポイントでした。従来の ln -sではなく、専用コマンドを用いることでfpm / cli / apache-mod でも安定した運用が可能になります。

サービスの再起動と確認

sudo systemctl restart php8.5-fpm
sudo systemctl restart redis-server
sudo systemctl restart apache2
  • バージョンの確認
php -v

with Zend OPcache v8.5.4 等 と表示されれば正解です。

備考:PHPを用いるWebアプリ設定の確認

Apacheの各サイト設定ファイル (/etc/apache2/sites-available/*.conf) 内で、必ず 8.5 のソケットを指定してください。

<FilesMatch \.php$>
&nbsp; &nbsp; SetHandler "proxy:unix:/var/run/php/php8.5-fpm.sock|fcgi://localhost/"
</FilesMatch>

これを入れないと、

The requested URL was not found on this server.   
    
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

の非情なるメッセージが返ってきます。

Nextcloud Ver 32にアップデート後、高性能バックエンドのDockerをアップデート。

警告: 実行中のバージョン: 2.0.4~docker; サーバーはこのTalkバージョンの全ての機能をサポートしていません。欠落している機能: chat-relay

と出たので、それに対応していきます。

環境

  • Nextcloud 33.0
  • Dockerを利用して高性能バックエンドサーバ(Signaling Server)を構築。構築手順
  • それ以外はLAMP環境。
    • Apache 2.4
    • MySQL
    • PHP-FPM
    • その上でNextcloud

アップデートは、こちらの手順で、コマンドラインから行いました。

その後、管理画面で上記のエラーが出たという次第です。

やっぱり必要なフェイズ・ゼロ

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

  • NextcloudのアップデートによりDockerコンテナもアップデートが必要。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる
    など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

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

さっくりとした手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Dockerの設定ファイルを修正します。
  3. Dockerコンテナを最多値揚げします。
  4. Nextcloudのメンテナンスモードを無効化します。
  5. エラーの解消を確認します。

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

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

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

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

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

設定ファイル (server.conf) の構成

  • ファイルのバックアップ
sudo cp -pi /hoge/docker/files/nextcloud-signaling/server.conf /path/to/backup/directory/server.conf.$(date +%Y%m%d)

自分の環境に合わせます。

  • ファイルのバックアップ確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf

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

  • server.confファイル修正

chat-relay 機能を有効にするため、以下のように項目を付け加えます。

  • [chat] セクション(新規追記)
[chat]
enabled = true

追記したら保存を行います。

  • ファイル修正確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf

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

+ [chat]
+ enabled = true

Docker アップデート・再起動

これが地味にハマりました。古い docker-compose (v1.29.x等) を使用している環境だと、イメージのメタデータ構造の違いによるエラー(KeyError: 'ContainerConfig')が発生。

それを避けるための手順です。

  • 最新イメージの直接取得

docker-compose を介さず、Docker本体で最新イメージをプルする。

sudo docker pull strukturag/nextcloud-spreed-signaling:latest
sudo docker pull nats:2.9
  • 不完全なコンテナの掃除

作成失敗などで残った残骸を削除し、競合を防ぐ。

sudo docker container prune -f
  • コンテナの起動
sudo docker-compose up -d

Nextcloudのメンテナンスモードの無効化

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

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

Nextcloud管理画面での反映

Nextcloudの「設定」>「Talk」にある高性能バックエンド設定で、URL横の「チェックマーク(保存)」を押し、chat-relayAvailable features に含まれたことを確認して対処完了です。

改めて思ったこと

Dockerは確かに便利な代物ですが、管理が複雑になっていくというのが難点。それ故、Dockerは最小限にして登録していきたいものです。

Nextcloud、ドメイン変更時のメモ。

正直、かなり甘く見ていました。

やろうとしたこと

a.hoge.comというサブドメインでNextcloudを立ち上げて運用していたのですが、唐突にexample.comというネイキッドドメインで運用しようとしたのがきっかけ。

当初の手順

  1. DBバックアップ
  2. 設定ファイルバックアップ(apacheバーチャルサイトとNextcloudのconfファイル)
  3. 新DNSレコード変更
  4. apacheバーチャルサイトのURL変更およびSSL証明書の差し替え
  5. NextcloudのconfファイルのURL変更
  6. Apache / PHP-FPM再起動

まではすんなりいきました。

URL変更後の苦行

Nextcloudは単なるファイルストレージではなく、統合コラボスイート。非常に多岐にわたって運用していたんだと改めて痛感。

  • デスクトップクライアント
  • スマートフォンアプリ
  • ブックマークの変更

がそれなりにヘビー。それ以上にヘビーだったのが

  • 高性能バックエンド
  • AppAPI

の設定変更を忘れていたことでした。

DBと参照ディレクトリ変更の更なる苦行

また、動作確認後、「DBの向き先とNextcloud格納ディレクトリが新ドメインに即していない」ことがわかり、

  1. apacheのconfファイルをいったん無効化
  2. 再度DBバックアップ(サイト名などを変えていたため)
  3. DB及びユーザー新規作成作成
  4. 再バックアップしていたDBから新DBにデータ流し込み
  5. Nextcloud格納ディレクトリを-pirオプションをつけてコピー&リネーム
  6. Nextcloudのconfigを修正。DBのユーザ名とDB名を新しく作成したDBに変更
  7. ログ格納ディレクトリを新規作成、www-dataに所有者変更
  8. apacheのconfファイルの格納ディレクトリとログ格納ディレクトリの向き先変更
  9. /etc/logrotate.d配下のローテーションを新しいログ格納ディレクトリに変更
  10. apacheのconfファイル有効化
  11. apache再起動
  12. Nextcloudのcronを新ディレクトリに合わせる

までやって、完全移行が完成しました。

「サーバリプレースとどう違うのか」レベルではありましたが、うまくいって良かったです。

詳細な手順は相当なボリュームになりそうなので、様子を見て描いていきます。

Nextcloud Client 4.0.5アップグレードの失敗時の対応。

ローカルサーバに設置されているNextcloudを利用するためのデスクトップクライアント。

自動更新するはずが、以下のメッセージが出て

「再起動してアップデート」をクリックしても同じエラーが発生。

これの対処のメモです。

参考手順(というよりもリリース)

対処手順

タスクバーから「Nextcloudを終了」でアプリを終了します。

Nextcloud クライアント公式に飛びます。

v4.0.6以降をダウンロードして、インストーラーを実行します。

インストール終了後、上記エラーが出ないことを確認します。

メモ

  • クライアントを上書きするだけなのでデータや設定が吹き飛ぶことはありません。
  • 対処しないと延々と上記エラーが出続けてフラストレーションがたまります。
  • Nextcloudの設定に問題があるわけでもありません。

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は、本当に必要な画面表示の時だけ働けば良くなったので、サーバー全体が静かになり、反応速度(レスポンス)が向上します。

Page 1 of 7

Powered by WordPress & Theme by Anders Norén