Growi運用
- Ubuntu 24.04環境でのGrowi 7.0.23→7.1.0へのバージョンアップ
- Growiで全文検索できないときの対処(ElasticSearchに伴うプラグインアップデート)
- growiのバージョンアップ/ダウングレード手順。(v7.1.0未対応)
- Growi v7.xでページ編集時に空白になる問題に対処(Apache リバースプロキシのWebSocket設定)
- Ubuntu 20.04 / nginx環境でgrowiをv6.x→v7.0.xにアップグレード。(nginxリバースプロキシのWebSocket設定)
- Growi v7.1.xのアップグレード手順
Ubuntu 24.04環境でのGrowi 7.0.23→7.1.0へのバージョンアップ
Ubuntu 7.1.0はかなり大きめの仕様変更がありました。
https://github.com/weseek/growi/releases/tag/v7.1.0
いくつかハマったポイントがありましたが、「自分はこの手順でうまくいった」 というメモを残します。
バージョンアップ前環境
- Ubuntu 24.04
- Mongodb 6.0.19
- npm 10.9.0
- node v20.18.0
- yarn 1.22.22
- Growi 7.0.23
以下の手順に沿ってインストール済みです。
https://barrel.reisalin.com/books/growi/page/ubuntu2404growi-v7v710
バージョンアップ後環境
- Ubuntu 24.04
- Mongodb 6.0.19
- npm 10.9.0
- node v20.18.0
- pnpm 9.12.3
- Growi 7.1.0
ここで分かるように、パッケージ管理がyarnからpnpmへと変わっています。
さっくりとした手順
- Growiサービスを停止します。
- Growiのディレクトリを退避します。
- 新たにgit cloneを行います。
- チェックアウトを行います。
- pnpmのインストールを行います。
- アプリのビルドを行います。
- Growiスタートアップスクリプトをコピーします。
- Growiサービスを起動します。
- バージョンアップを確認します。
なぜか通常のgit checkoutはビルドがうまくいきませんでした。
Growiサービスの停止
- Growiサービス停止前確認
systemctl status growi.service
active(running)
を確認します。
- Growiサービス停止
sudo systemctl stop growi.service
- Growiサービス停止後確認
systemctl stop growi.service
inactive(dead)
を確認します。
Growiディレクトリの退避
- ディレクトリ退避
筆者環境は/home/www-data/growi
です。
sudo mv /home/www-data/growi /path/to/backup/directory/growi_org
- ディレクトリ退避確認
ls -l /path/to/backup/directory/growi_org
ファイル一覧が参照できることを確認します。
Growiデータの新規取得
- git clone
sudo git clone https://github.com/weseek/growi /home/www-data/growi
※任意のディレクトリを指定します。
- ディレクトリ移動
cd /home/www-data/growi && pwd
先ほどcloneしたディレクトリですが、退避前のディレクトリと同じことを確認します。
Growi v7.1.0をチェックアウト
- チェックアウト
sudo git checkout -b v7.1.0 refs/tags/v7.1.0
- lfs pull
sudo git lfs pull
pnpmパッケージのインストール
- npm install
sudo npm install -g pnpm
- インストール確認
pnpm --version
9.12.3
を確認(2024/11/02現在)
Growiインストール
- lfs pull
sudo git lfs pull
- pnpmインストール
sudo pnpm install
※ マシンスペックによっては相当時間がかかります
※ Done in 【時間】と書かれていたらアップグレード完了です
- ビルド
sudo npm run app:build
退避させたGrowiから起動スクリプトのコピー
筆者のように、起動スクリプトをGrowiのインストールディレクトリに仕込んでいる場合の手順です。
- スクリプトコピー
sudo cp -pi /path/to/backup/directory/growi_org/growi-start.sh /home/www-data/growi/
それぞれ、バックアップしたディレクトリとcloneしたディレクトリです。
- コピー確認
ls -l /home/www-data/growi/growi-start.sh
ファイルがあることを確認します。
growiサービスを起動します。
- 再開前のステータス確認
systemctl status growi.service
inactive (dead)を確認します
- サービス再起動
sudo systemctl start growi.service
※ 完全に起動していないと、アクセスしても503エラーが発生します。
- 再開後のステータス確認
systemctl status growi.service
サービススクリプトを[growi]にしている場合
active (running)を確認します
バージョンアップを確認します。
- ブラウザから設定したgrowiのドメイン/IPにアクセスします。
- 画面下部にあるバージョンが7.1.0であることを確認します。
Growiで全文検索できないときの対処(ElasticSearchに伴うプラグインアップデート)
概要
サーバのパッケージアップデート後、Growiで全文検索ができない現象が発生しました。
状況確認
- elasticsearch状況確認
systemctl status elasticsearch.service
- 状況確認結果
● elasticsearch.service - Elasticsearch
Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2023-08-09 20:32:57 JST; 12min ago
Docs: https://www.elastic.co
Process: 992 ExecStart=/usr/share/elasticsearch/bin/systemd-entrypoint -p ${PID_DIR}/elasticsearch.pid --quiet (code=exited, status=1/FAI>
Main PID: 992 (code=exited, status=1/FAILURE)
8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]: at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:1>
8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]: at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAware>
8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]: at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:11>
8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]: at org.elasticsearch.cli.Command.main(Command.java:77)
8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]: at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:125)
8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]: at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:80)
8月 09 20:32:56 chisato.lyco.reco systemd-entrypoint[992]: For complete error details, refer to the log at /var/log/elasticsearch/elasticsea>
8月 09 20:32:57 chisato.lyco.reco systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE
8月 09 20:32:57 chisato.lyco.reco systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
8月 09 20:32:57 chisato.lyco.reco systemd[1]: Failed to start Elasticsearch.
lines 1-17/17 (END)
→ ElasticSearchがうまく稼働していない事象を確認。
原因調査
- ElasticSearchのログ確認
sudo tail -50 /var/log/elasticsearch/elasticsearch.log
- ログ抜粋
[2023-08-09T20:32:56,947][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [chisato.lyco.reco] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalArgumentException: Plugin [analysis-icu] was built for Elasticsearch version 7.17.10 but version 7.17.12 is running
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:173) ~[elasticsearch-7.17.12.jar:7.17.12]
と、パッケージ更新時にElasticSearchが上がったのに、その中のプラグインが対応していないためこの事象が発生です。
対処
- 入っていたプラグインをアンインストール
- 最新バージョンのプラグインを再インストール
- プラグイン再インストール後にElasticSearch起動
と、割と単純な作業です。
- プラグインのアンインストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji
- プラグインの再インストール
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji
- ElasticSearch起動
sudo systemctl restart elasticsearch.service
環境によってはサービス起動まで時間が掛かります
- ElasticSearch起動確認
systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch
Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-08-09 20:53:39 JST; 27s ago
Docs: https://www.elastic.co
Main PID: 2930 (java)
Tasks: 93 (limit: 9152)
Memory: 786.6M
CGroup: /system.slice/elasticsearch.service
├─2930 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.tt>
└─3114 /usr/share/elasticsearch/modules/x-pack-ml/platform/linux-x86_64/bin/controller
8月 09 20:53:14 chisato.lyco.reco systemd[1]: Starting Elasticsearch...
8月 09 20:53:39 chisato.lyco.reco systemd[1]: Started Elasticsearch.
起動を確認。
Growiで事象の解消確認
- Growiアプリにブラウザでアクセスします。
- 管理者権限でログインします。
- 設定>Elasticsearch管理を進み、以下のように接続されていればOKです。
growiのバージョンアップ/ダウングレード手順。(v7.1.0未対応)
概要
Wikiツールとして有効に利用しているgrowi。そのバージョンアップ及びダウングレード方法のメモです。
※これは、単にgitのみの手順です。他にシステム要件(他のミドルウェアのバージョンアップや切り戻しなど)がある場合は、それも合わせて実施することを注記いたします。
前提
- 既にgrowiをインストールしていること。
- systemdによってサービス化されていること。
- 最新版や安定版がリリースされていることを以下のサイトで確認していること。
※備考
本手順はv7.1.0には未対応です。
手順
さっくりとした手順
- growiのサービスを停止します。
- gitコマンドで最新版を引っ張ります。
- アップグレードを行います。
- growiのサービスを再開します。
- アップグレードされたことを確認します。
growiサービスを停止します
- growiのステータス確認(停止前)
systemctl status growi.service
※ サービススクリプト名は自分の環境に合わせます。
※ active(running)を確認します
- growiのサービス停止
sudo systemctl stop growi.service
- growiのステータス確認(停止後)
systemctl status growi.service
inactive (dead)を確認します
growiディレクトリに移動します
cd /opt/growi
自分の環境に合わせます。
リリースタグを確認します。
- リリースタグ取得
sudo git fetch --tags
- リリースタグ確認
sudo git tag -l
スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。
チェックアウトとインストールを行います。
- 変更を一時的に退避
sudo git stash
- チェックアウト
sudo git checkout 【バージョン】
- yarn
sudo yarn
※ マシンスペックによっては相当時間がかかります
※ Done in 【時間】と書かれていたらアップグレード完了です
- ビルド
sudo yarn app:build
growiサービスを起動します。
- 再開前のステータス確認
systemctl status growi.service
inactive (dead)を確認します
- サービス再起動
sudo systemctl start growi.service
※ 完全に起動していないと、アクセスしても503エラーが発生します。
- 再開後のステータス確認
systemctl status growi.service
サービススクリプトを[growi]にしている場合
active (running)を確認します
バージョンアップを確認します。
- ブラウザから設定したgrowiのドメイン/IPにアクセスします。
- 画面下部にあるバージョンがチェックアウトしたバージョンであることを確認します。
Growi v7.xでページ編集時に空白になる問題に対処(Apache リバースプロキシのWebSocket設定)
事象の内容
- Growiのバージョンをv6.3.5→v7.0.11にアップグレード後、既存のページを編集しようとすると編集エリアが空白になってしまう。
- 新規ページを作成する際に、テンプレートが適用されない。
Wikiとしては致命的な弱点だったため、やむなくv6.3.5に戻したという経緯があります。
ですが、回避策が見つかりましたのでメモとして残します。
事象が発生した環境
- Ubuntu 22.04
- Apache 2.4
- Growi v7.0.11をDockerではなくオンプレ環境で利用。
- Apacheによるリバースプロキシを設定
備考
この事象は、以下で回避されました。
- Ubuntu 24.04
- Apache 2.4
- Growi v7.0.23
同一事象をネットで確認。
- [7.0.0]データ移行機能を使用した後、記事の編集内容が失われる #8677
How to reproduce? (再現手順)
2台のHostPCでそれぞれGrowiを立ち上げています。A環境・B環境と呼称します。
「データ移行」機能を用いて、A環境からB環境にデータをインポートする B環境のGrowiに他のPCからアクセスする 記事の編集画面を表示する
What happens? (症状)
記事の編集画面が白紙になっており、そのまま保存しても記事の内容が失われる(添付画面参照)
と、事象が一致。
事象の原因
上記issueのツリーに
私の環境でも編集画面が空白になる現象が観測されました。
私は https-portal を使ってデプロイしているのですが、 growi-docker-compose/examples/https-portal にある WEBSOCKET: 'true' の環境変数を設定し損ねていたのが原因でした。 私の環境では、これを設定すると通常通り編集を行えることを確認しております。逆に、コメントアウトすると空白に戻ります。
とあります。
これを原因と断定し、対処に臨みます。
筆者が実施したのはオンプレ(Apacheによるリバースプロキシ)での対処です。
対応方法のさっくりとした手順
- 現状のgrowiのリバースプロキシの設定を確認。
- 設定ファイルのバックアップ。
- 設定ファイルを修正。
- 修正を反映。
- 事象の解決確認。
参考にしたURL
How to Reverse Proxy Websockets with Apache 2.4
現段階でのリバースプロキシの設定を確認します。
- Apacheのバーチャルファイルを確認
cat /etc/apache2/sites-available/growi.conf
自分の環境に合わせます。
- 内容の一部抜粋
# socket.io の path を rewrite する
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/socket.io [NC]
RewriteCond %{QUERY_STRING} transport=websocket [NC]
RewriteRule /(.*) ws://localhost:3000/ [P,L]
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
設定そのものはgithubのgrowi公式ドキュメントに沿ったものでしたが、これが引っかかっていたようです。
設定ファイルのバックアップを取ります。
- バックアップ
sudo cp -pi /etc/apache2/sites-available/growi.conf /path/to/backup/directory/growi.conf.$(date +%Y%m%d)
ファイル名は自分の環境に合わせます。適宜、任意のバックアップディレクトリを指定します。
- バックアップ確認
diff -u /path/to/backup/directory/growi.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi.conf
差分が無いこと(エラーがないこと)でバックアップを確認します。
ファイルを修正します。
上記の設定ファイルを教義・信仰に沿ったエディタで編集します。(要管理者権限)
- 削除する内容
# socket.io の path を rewrite する
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/socket.io [NC]
RewriteCond %{QUERY_STRING} transport=websocket [NC]
RewriteRule /(.*) ws://localhost:3000/ [P,L]
- 削除した箇所に追記する内容
# WebSocketのための設定
RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule /(.*) ws://localhost:3000/$1 [P,L]
編集後、差分を取ります。
- 差分確認
diff -u /path/to/backup/directory/growi.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi.conf
- 差分結果
- # socket.io の path を rewrite する
- RewriteEngine On
- RewriteCond %{REQUEST_URI} ^/socket.io [NC]
- RewriteCond %{QUERY_STRING} transport=websocket [NC]
- RewriteRule /(.*) ws://localhost:3000/ [P,L]
+ # WebSocketのための設定
+ RewriteEngine On
+ RewriteCond %{HTTP:Upgrade} =websocket [NC]
+ RewriteCond %{HTTP:Connection} upgrade [NC]
+ RewriteRule /(.*) ws://localhost:3000/$1 [P,L]
設定を反映します。
- 構文確認
sudo apache2ctl configtest
Syntax OK
を確認します。
- Apache再起動前確認
systemctl status apache2.service
active (running)
を確認します。
- Apache再起動
sudo systemctl restart apache2.service
- Apache再起動後確認
systemctl status apache2.service
active (running)
を確認します。
事象の解決を確認します。
上記、設定を行ったGrowiサイトにアクセスします。
編集後、左ペイン(エディタ部分)がそのまま残っていれば対処完了です。
Ubuntu 20.04 / nginx環境でgrowiをv6.x→v7.0.xにアップグレード。(nginxリバースプロキシのWebSocket設定)
概要
長らくUbuntu 20.04で動かしているgrowi。こちらもv7.0.xにアップグレードできることを確認しました。
Apacheと同様、nginx環境でも、WebSocketを適切に設定する必要がありました。
環境
- Ubuntu 20.04
- Growi v6.3.5
- 非Dockerのオンプレ環境
- nginx( この手順に則ってgrowi v6をnginxのリバースプロキシで動かしていました)。
さっくりとした手順
- nodeのアップグレードを行います。
- growiサービスを停止します。
- growiのバージョンアップを行います。
- growiサービスを再開します。
- nginxのリバースプロキシ設定を書き換え、nginxサービスの再起動を行います。
- バージョンアップを行います。
nodeのアップグレード
node -v
v18.16.0
はGrowi7系の対象外だったので、nodeを最新安定版に変えるところからスタートします。
- n packageのインストール
sudo npm install -g n
- nでnode 20系の安定版をインストール
sudo n --stable
- バージョンアップ確認
node -v
20.15.0
を確認します。
growiのアップグレード前のサービス停止
- growiのステータス確認(停止前)
systemctl status growi.service
※ サービススクリプト名は自分の環境に合わせます。
※ active(running)を確認します
- growiのサービス停止
sudo systemctl stop growi.service
- growiのステータス確認(停止後)
systemctl status growi.service
inactive (dead)を確認します
growiのアップグレード
- growiディレクトリの移動
cd /opt/growi
自分の環境に合わせます。
- 必要パッケージのインストール
sudo aptitude install git-lfs
git-lfs
を入れないとclone/build時に画像が表示されません。
- lfs -pull
sudo git lfs pull
- リリースタグ取得
sudo git fetch --tags
- リリースタグ確認
sudo git tag -l
2024/06/30現在のv7系最新版、v7.0.11があることを確認しました。
- gitのバージョンを一時的に退避
sudo git stash
- チェックアウト
sudo git checkout 【バージョン】
上述した通り、v7.0.11
を入力しました。
- yarn
sudo yarn
v6.xよりも時間がかかります。
- アプリのビルド
sudo yarn app:build
こちらも時間がかかります。
アップグレード後のgrowiサービス開始
- 再開前のステータス確認
systemctl status growi.service
inactive (dead)を確認します
- サービス再起動
sudo systemctl start growi.service
- 再開後のステータス確認
systemctl status growi.service
サービススクリプトを[growi]にしている場合
active (running)を確認します
nginxのバーチャルファイルを編集
v7.xは、WebSocketによる通信設定を正常に行わないと既存ドキュメントの編集ができません。(編集画面が空白になります)
そのため、nginxの設定を見直します。
- 既存のgrowiバーチャルファイルを退避
sudo mv /etc/nginx/sites-available/growi.conf /path/to/backup/directory/growi.conf.$(date +%Y%m%d)
大幅に変更する必要があるため、cpではなくmvします。
- 新規の設定ファイルを作成
【】内を自分の環境に合わせます。
cat <<- __EOF__ | sudo tee -a /etc/nginx/sites-available/growi.conf
upstream growi {
server 【growiのIPアドレス】:3000;
}
server {
listen 80;
server_name 【サーバ名】;
server_tokens off;
return 301 https://$host$request_uri;
access_log 【growiのアクセスログのフルパス】;
error_log 【growiのエラーログのフルパス】 warn;
}
map $http_upgrade $connection_upgrade {
default Upgrade;
'' close;
}
server {
listen 443 ssl;
server_name 【サーバ名】;
server_tokens off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ciphers 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;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security 'max-age=63072000';
ssl_certificate 【サーバ証明書のフルパス】;
ssl_certificate_key 【サーバ秘密鍵のフルパス】;
access_log 【growiのSSLアクセスログのフルパス】;
error_log 【growiのSSLエラーログのフルパス】 warn;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://growi;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 900s;
}
}
__EOF__
こちらの設定ファイルはGrowiの公式ドキュメントに沿ったものです。
- nginxの構文チェック
sudo nginx -t
-
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
-
nginx: configuration file /etc/nginx/nginx.conf test is successful
を確認します。
- nginx再起動
sudo systemctl restart nginx.service
バージョンアップ確認
- 設定したgrowiのサイトにアクセスします。
- チェックアウトしたバージョンであることを確認します。
- 既存のページにアクセスし、編集できること(編集画面が白くならないこと)を確認します。
Growi v7.1.xのアップグレード手順
概要
V7.1.xからパッケージ管理がyarnではなくmnpmに変更されました。
その手順に合わせたメモです。
前提
- 既にgrowiをインストールしていること。
- systemdによってサービス化されていること。
- 最新版や安定版がリリースされていることを以下のサイトで確認していること。
※備考
v7.0.x以前はyarnを用います。
手順
さっくりとした手順
- growiのサービスを停止します。
- gitコマンドで最新版を引っ張ります。
- アップグレードを行います。
- growiのサービスを再開します。
- アップグレードされたことを確認します。
growiサービスを停止します
- growiのステータス確認(停止前)
systemctl status growi.service
※ サービススクリプト名は自分の環境に合わせます。
※ active(running)を確認します
- growiのサービス停止
sudo systemctl stop growi.service
- growiのステータス確認(停止後)
systemctl status growi.service
inactive (dead)を確認します
growiディレクトリに移動します
cd /opt/growi
自分の環境に合わせます。
リリースタグを確認します。
- リリースタグ取得
sudo git fetch --tags
- リリースタグ確認
sudo git tag -l
スペースで確認していき、上記リリースサイトと同じバージョンがあることを確認します。
チェックアウトとインストールを行います。
- 変更を一時的に退避
sudo git stash
- チェックアウト
sudo git checkout 【バージョン】
- pnpm install
sudo pnpm install
- ビルド
sudo npm run app:build
growiサービスを起動します。
- 再開前のステータス確認
systemctl status growi.service
inactive (dead)を確認します
- サービス再起動
sudo systemctl start growi.service
※ 完全に起動していないと、アクセスしても503エラーが発生します。
- 再開後のステータス確認
systemctl status growi.service
サービススクリプトを[growi]にしている場合
active (running)を確認します
バージョンアップを確認します。
- ブラウザから設定したgrowiのドメイン/IPにアクセスします。
- 画面下部にあるバージョンがチェックアウトしたバージョンであることを確認します。