OSS GROWIの保守、してますか？

はじめに

OSSのWikiツールGROWIは、docker composeを使うと簡単に立ち上げることができます。とても便利なWikiなので試した方は多いと思いますが、保守まで意識して運用している方はどのくらいいらっしゃるのでしょうか。

公式のドキュメントには最小限の説明があるだけなので、やってみると保守は結構大変でした。ここでは蓄積したデータを失わないための保守について説明します。

前提

この記事ではgrowi-docker-composeでGROWIインスタンスを構築している場合を対象とします。
各モジュールを個別にセットアップして構築した場合には参考にならないかもしれません。

保守の方針

蓄積したデータを失わなず使い続けることを目標とします。

• 短期的にはデータのバックアップ
• 長期的にはGROWIインスタンスの引っ越し

GROWIインスタンスを引っ越しできる状態にするためには最新のバージョンに上げておくのが基本です。GROWIのバージョンアップは頻度が高いのですが、私は約1か月遅れ以内で追いつくように運用を心がけています。v7.4.x→v7.5.xのように2桁目が上がった時はバージョンアップしておくのが望ましいと思います。

1. バックアップ

まず、不測の事態に備えるために現状のGROWIデータをバックアップしましょう。GROWIのエクスポート機能を使って手動で行う方法と、MongoDBのデータを自動バックアップする方法があります。

GROWIのエクスポート・インポートは同じバージョンのGROWI同士の必要があるのでご注意ください。（バージョンを合わせ技は後述します）

2. OSのアップデート

Ubuntu上でGROWIを構築していると、Ubuntuのアップデートが毎週のようにあります。GROWIのメンテ以前にOSのアップデートも必要ですので、手順を簡単に触れておきます。

1. OSを再起動することをGROWIユーザにアナウンスして、編集を終了してもらう
2. GROWIをメンテナンスモードにする(*)
3. GROWIを停止する

$ cd /opt/growi
$ sudo docker compose stop

4. Ubuntuをアップデートして再起動する

$ sudo apt update
$ sudo apt upgrade -y
$ sudo apt autoremove
$ sudo reboot

5. GROWIを再起動する

$ cd /opt/growi
$ sudo docker compose start

6. GROWIのメンテナンスモードを解除する(*)
7. アップデート終了をユーザーにアナウンスする

自分の職場では利用者が少なく編集頻度も低いので、(*)のGROWIのメンテナンスモードは省略しています。（8割方記事編集しているのが自分だけ...）

3. GROWI最新版の確認

GROWIの最新リリースを月1くらいはチェックをしましょう。だいたい2週間ごとに更新があります。最新バージョンをチェックするには、GROWIの適当な記事に次のコードを付け加えておくと良いと思います。

[![GitHub Releases](https://img.shields.io/github/release/weseek/growi.svg)](https://github.com/weseek/growi/releases/latest)

上記は以前のバージョンでルートページにあったコードです。これをバージョンチェック用の記事に埋め込んでおけば最新バージョンが表示され、それをクリックするとGitHubのリリースページが表示されます。（こんな感じ↓）（GROWIアプリじゃなくcoreリリースが表示されることもあります）

4. growi-docker-composeの差分確認

公式のドキュメントにはバージョンアップ手順として

$ cd /opt/growi
$ sudo git pull
$ //以下省略

と書かれていますが、いきなりgit pullするのはお勧めしません

git pullを実行すると、docker-compose.ymlなどが最新の内容に更新されます。これにより、MongoDBやElasticsearchなどのイメージタグが変更され、意図しないバージョンアップになる可能性があります（MongoDBがいきなりバージョンアップするのはまずい）。そのため、まずは最新版との差分を確認し、何が新しくなるのかを把握した上で更新手順を考えましょう。

growi-docker-composeの構成の確認は、下記のリンクで更新有無を確認すると良いと思います。

growi-docker-compose - The fastest way to boot All-in-One GROWI

それ以外の方法として、別ディレクトリに最新GROWIをgit cloneしておくのもよいと思います。（例えばGROWIを立ち上げる時、/opt/growi_latestというディレクトリも作成しておきます）

例えば、

$ cd /opt
$ sudo git clone https://github.com/growilabs/growi-docker-compose.git growi
$ sudo git clone https://github.com/growilabs/growi-docker-compose.git growi_latest
$ tree
/opt
├── growi         ← 本番環境用
└── growi_latest  ← 最新版確認用

としておいて、GROWI最新バージョン確認は

$ cd /opt/growi_latest
$ sudo git pull

でgrowi-docker-composeに更新があるかを見てみます。更新があった場合は現行のGROWIの設定と比較します。

比較するのは、docker-compose.ymlやディレクトリ構成などです。
./docker-compose.yml を比較

$ diff /opt/growi/docker-compose.yml /opt/growi_latest/docker-compose.yml

./docker-compose.yml ファイルで注目すべきは各モジュールのバージョンです。

version: '3'

services:
  app:
    image: growilabs/growi:7 ## ここ！
    ports:
//
  mongo:
    image: mongo:8.2 ## ここ！
    # For MongoDB 6.x
    # image: mongo:6.0
//
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:9.3.3 ## ここ！
    # For Elasticsearch 8.x
    # image: docker.elastic.co/elasticsearch/elasticsearch:8.19.14
    environment:

//
  pdf-converter:
    image: growilabs/pdf-converter:1 ## ここ！
    restart: unless-stopped

dockerが引っ張ってくるimageのバージョンが現行のGROWIから上がっている場合、バージョンアップが生じます。GROWIの場合、互換性のある古いバージョンがコメントアウトされているので、今使用しているモジュールのimageがコメントに含まれているなら、バージョンアップしても大丈夫です（MongoDBだけはダメです。今のバージョンのコメントを解除して、新しい方をコメントアウトしてください）
また、それ以外のdockerで実行するコマンドなどの修正がある場合、変更箇所の反映が必要になることもあります。

5. バージョンアップ(MongoDB以外)

MongoDBのバージョンを上げる場合は後述しますので、それ以外の

• GROWIアプリ
• Elasticsearch
• PDF-Converter

をバージョンアップする手順を説明します。
1.GROWIの実行を停止、コンテナ削除

$ cd /opt/growi
$ sudo docker compose down

2.バージョンアップ対象のimage削除

$ sudo docker images
IMAGE                                                ID            DISK USAGE  CONTENT SIZE
docker.elastic.co/elasticsearch/elasticsearch:9.3.3  bff1a79d2502  2.17GB      737MB
growilabs/growi:7.5.5                                d89dc1c0fde6  2.21GB      395MB
growilabs/pdf-converter:1                            794846014ac1  1.95GB      509MB
mongo:8.2                                            1286be0f9860  1.3GB       341MB
$
$ sudo docker rmi <image>

削除するアプリのイメージ<image> に入るのは、上記の例だと
docker.elastic.co/elasticsearch/elasticsearch:9.3.3
growilabs/growi:7.5.5
growilabs/pdf-converter:1
などです。バージョンアップ対象のイメージを指定して削除して下さい。IMAGEの名称（ex. growilabs/growi:7.5.5)か、ID(ex. d89dc1c0fde6)で指定して削除します。（古いimageを残してもディスクスペースを占める以外の問題はないです）

3.docker-compose.ymlの、対象アプリのバージョンを最新のものに修正
4.imageおよびコンテナ作成と再実行

$ sudo docker compose up -d

GROWIのドキュメントでは、ざっくり

• docker compose stop #コンテナ停止
• docker compose rm app #アプリ削除
• docker rmi growilab/growi:7 #イメージ削除
• docker compose build #イメージおよびコンテナ再構築
• docker compose up -d #再起動

という手順になっていますが、docker compose down で他のアプリのコンテナを削除しても、イメージが残っていればコンテナ再構築は一瞬ですから、まとめてdocker compose downする方が（どのアプリをバージョンアップする場合にも適用できるので）楽だと思います。またdocker compose buildしなくても、docker compose up -dすればコンテナが再構築されますので不要です。

6. MongoDBのバージョンアップ

MongoDBのバージョンアップを行う際は、MongoDBのコマンドを叩いてバージョンを一つずつ上げて行くこともできますが非常に煩雑です。なので、GROWIのデータアーカイブ・データインポート機能を利用することをお勧めします。

ポイントは、MongoDBのバージョンが違っても、GROWIアプリのバージョンが同一であればデータアーカイブ・データインポートが可能だということです。

ざっくりした手順：

1. GROWIのバージョンを固定
2. データアーカイブ機能でデータをエクスポート
3. ダミーGROWIインスタンスを作成し、データインポートできることを確認
4. 本番環境を削除
5. 本番GROWIインスタンスを最新MongoDBで起動し、データインポート
6. 本番環境が正常な事を確認したらダミーGROWIは削除

1. GROWIのバージョンを固定

現行のGROWIアプリはほぼ最新にアップデートされていることとします。バージョンアップされていない場合は（新しいバージョンのMongoDBのに対応したGROWIバージョンまで）バージョンアップしてください。
今、GROWIアプリがv.7.5.7だったとします。そしたら、docker-compose.ymlのGROWIを7→7.5.7に書き換えて固定します。

$ cd /opt/growi
$ sudo docker compose down
$ sudo docker rmi <growiのアプリimage名>

でいったんGROWIのimageを消去し、

version: '3'

services:
  app:
    #image: growilabs/growi:7 ## ここを
    image: growilabs/growi:7.5.7 ## こうするとv7.5.7を明示的に指定できる
    ports:
//

とバージョンを固定して

$ cd /opt
$ sudo docker compose up -d

でv7.5.7のバージョンを指定したイメージを作っておきます。

2. データアーカイブ機能でデータをエクスポート

GROWIに管理者でログインし、設定からデータアーカイブ機能でアーカイブを作成し、ローカルにダウンロードします

3. ダミーGROWIインスタンスを起動し、データインポートの確認

いきなり本番環境で作業する前に、新しいMongoDBを使用するダミーのGROWIインスタンスを起動し、データインポートできて正常に利用できる事を確認します。本番環境に影響が出ないように、現行GROWIとは別のPCやVMでダミーGROWIを立ち上げることをお勧めします。

ダミーGROWIは、上記で固定したGROWIのバージョンと同じバージョンで、MongoDBだけ新しいものにしてインスタンスを作成してください。
ダミーGROWIが起動したら、現行のGROWIに管理者でログインし、メンテナンスモードにしてからデータインポートを実行してください。管理者IDは元のGROWIの管理者ID/メールアドレス/パスワードをお勧めします。

ダミー環境で無事データインポートできたら、本番環境に着手します。

4. 本番環境を削除

本番GROWIのコンテナ、イメージ、ボリュームを全部削除してまっさらにします。

$ cd /opt/growi
$ sudo docker compose down -v
$ sudo docker system prune
$ sudo docker images  # imageが残っていれば sudo docker rmi <image名>
$ sudo docker volume ls # volumeが残っていれば sudo docker volume rm <volume名>

docker compose downに -v をつけるとコンテナと一緒にボリュームを消去します。
イメージ、ボリュームが消えた事を確認し、残っているようでしたら手動で削除してください。(--forceオプションを指定するなど）

5. 本番GROWIインスタンスを起動し、データインポート

docker-compose.ymlを編集し、MongoDBのバージョンを上げてからdocker compose up -dでGROWIを起動し、エクスポートしたデータを転送してデータインポートする。
ダミーGROWIでの作業と同じ事を本番GROWIで行います。
データインポート後、検索インデックスを再構築します。

6. 本番環境が正常な事を確認したらダミーGROWIは削除

以上で終了です。お疲れ様でした。

GROWIのデータアーカイブ・データインポート機能を使わず、MongoDBをコツコツバージョンアップする方法もありますが、リクエストがあれば追記するかもしれません（二度とやりたくない...）