社内WiKiにGrowiを立てた
社内WiKiを立ち上げることになり、いろいろと調べた結果、活発にバージョンアップをしている、Growiを使用することに。
まずは、社内の仮想サーバ上CentOS作って立てました。
この時は、何も考えず、手順通りにDocker-Composeを使い、何ら問題なく試用開始。
使ってみて便利なので、本稼働させることに。
より安全で容量の大きなサーバで運用したかったので、丁度会社で購入した、QNAP NAS上に展開することに。
ContainerStation の罠(Growi v4.5)
そもそもDockerを理解していないのがまずいのですが、ContainerStationの作成機能で、検索して出てきたweseek/growiをインストール。
ほどなくして、立ち上がってきたので使いかけたときに、検索できないことに気づきました。
あ、Elasticsearch入れないといけないんだな。と理解し、同じく検索して出てきたものをインストールたものの、連携の仕方がわからないため、頓挫。
やっぱり、Docker-Composeでインストールしなきゃダメか…ということで、
作成のアプリケーションの作成(Docker-Compose)を行うことに。
特にGrowiはDocker-Composeで完結せず、サブフォルダのDockerファイルを見たりしているので厄介でしたが、思いつくままやってみたところ、うまくいきました。
QNAPにエクスプローラでアクセスし、Containerフォルダ直下にGrowiフォルダを作成して、
のZipの中身をすべていれました。
docker-compose.ymlの中身を
アプリケーションの作成に書きこんで、YAMLを検証し、作成。
紆余曲折あり、下記のようにすることでうまくいきました。
ファイルの実態をフルパスで書くとうまくいきました。
dockerfileの指定は、相対で良かったのかも。
フルパスは、誤ったファイル指定をすることで推測ができると思います。
あと、アプリケーション名はすごく重要なので、ちゃんと覚えておきましょう。
version: '3'
services:
app:
build:
context: /share/CACHEDEV1_DATA/Container/growi
dockerfile: /share/CACHEDEV1_DATA/Container/growi/Dockerfile
ports:
- 3000:3000 # localhost only by default
links:
- mongo:mongo
- elasticsearch:elasticsearch
depends_on:
- mongo
- elasticsearch
environment:
- MONGO_URI=mongodb://mongo:27017/growi
- ELASTICSEARCH_URI=http://elasticsearch:9200/growi
- PASSWORD_SEED=changeme
# - FILE_UPLOAD=mongodb # activate this line if you use MongoDB GridFS rather than AWS
# - FILE_UPLOAD=local # activate this line if you use local storage of server rather than AWS
# - MATHJAX=1 # activate this line if you want to use MathJax
# - PLANTUML_URI=http:// # activate this line and specify if you use your own PlantUML server rather than public plantuml.com
# - HACKMD_URI=http:// # activate this line and specify HackMD server URI which can be accessed from GROWI client browsers
# - HACKMD_URI_FOR_SERVER=http://hackmd:3000 # activate this line and specify HackMD server URI which can be accessed from this server container
# - FORCE_WIKI_MODE='public' # activate this line to force wiki public mode
# - FORCE_WIKI_MODE='private' # activate this line to force wiki private mode
entrypoint: "dockerize
-wait tcp://mongo:27017
-wait tcp://elasticsearch:9200
-timeout 60s
/docker-entrypoint.sh"
command: ["yarn migrate && node -r dotenv-flow/config --expose_gc dist/server/app.js"]
restart: unless-stopped
volumes:
- growi_data:/data
mongo:
image: mongo:4.4
restart: unless-stopped
volumes:
- mongo_configdb:/data/configdb
- mongo_db:/data/db
elasticsearch:
build:
context: /share/CACHEDEV1_DATA/Container/growi/elasticsearch
dockerfile: /share/CACHEDEV1_DATA/Container/growi/elasticsearch/Dockerfile
environment:
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms256m -Xmx256m" # increase amount if you have enough memory
- LOG4J_FORMAT_MSG_NO_LOOKUPS=true # CVE-2021-44228 mitigation for Elasticsearch <= 6.8.20/7.16.0
ulimits:
memlock:
soft: -1
hard: -1
restart: unless-stopped
volumes:
- es_data:/usr/share/elasticsearch/data
- /share/CACHEDEV1_DATA/Container/growi/elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml
volumes:
growi_data:
mongo_configdb:
mongo_db:
es_data:
出来上がったコンテナ群をチェックして開始。
無事立ち上がり、めでたしめでたし。
バージョンアップの試練(Growi v4.5 -> v5)
しばらくバタバタしていて、
本稼働には至ってなかったので、使うための準備。
確認すると、メジャーバージョンアップしていた！
まだ本稼働してないから、今の間に練習しとかなきゃ。
ということで、やってみる。
公式ガイドでは、下記のように案内されていた。
特に、Docker-Composeの場合は、下記の手順でのこと。
コマンドなら、そのままなんだろうけど、ContainerStationなんで、GUIからどうやれば!?
と検索すると、下記にあたった。
なんでも、コンテナを停止して、消してやれば良いとのこと。
なので、コンテナ停止 -> コンテナ削除
イメージも消した方が良いかな？と思ったので、イメージも削除。
ただし、mongodbは手をつけず、アプリケーション名_appとアプリケーション名_elasticsearchを削除。
コンテナ削除しないと、このあたりのは削除できなかった。
最初と同様に、
のZipの中身をすべて、前回のフォルダと同じ名前のところにいれました。
念のため、前の分はリネームしました。
docker-compose.ymlを確認すると、まったく変わっていなかったので、
前回と全く同じものを流し込み。
この時に、アプリケーション名も前回と同じものをいれました。
おそらくこれにより、ボリュームに保存されているデータが引き継がれるのでは？
と踏んでいました。
作成を押したあと、コンテナの起動を行い、しばらく待つと、ちゃんとデータが引き継がれたGrowiが立ち上がりました。
v4.5からv5へのバージョンアップでしたので、データのコンバートが必要とのこと。
コンバートも無事に終わり、アップデート完了しました。
あと何回かバージョンアップして確実性を確認したいところ。
最後に
Dockerわからんけど、なんとかなった。