TL;DR
Mysqlのバージョンが低すぎるためだと推測されますが、Wiki.jsをAzure web AppsのMysql in Appをデータベースとして実行しようとしてもマイグレーションに失敗して起動しません。
動機
Herokuの無料プランに私用のWiki.jsを置いていましたが、Herokuが無料プランを終了するということで、移行先を探していました。
Fly.ioなども良いかなと思っていたのですが、Wikiの規模がそこそこある(500ページ以上)せいかDB, App双方メモリ不足で落ちまくるので諦めました。
そんな中、wiki.jsのRequirementsを眺めていると、MySQLも対応のDBの中に入っていることに気づき、どうせ私用のWikiなのでMySQL in Appを試してみようと考えたのですが、ここからが悪夢の始まりでした…
落とし穴
落とし穴1. MySQL in AppはWindows環境でしか選択できない
デプロイ時には何も表示されず、デプロイしてからコンソールに飛ぶとグレーアウトしているので気づきにくいですが、MySQL in AppはWindows環境を選択した場合にしか有効にすることができません。
逆に言うと、Linux、Docker環境を選択した場合は使うことができません。
落とし穴2. MySQL in Appの認証情報を取得するには一手間必要
MySQL in AppはWebアプリと同じホストで実行されます。これは自動で行われるため、認証情報やポートはプログラムから取得する必要があります。
これは、環境変数MYSQLCONNSTR_localdb
、或いはD:\home\data\mysql\MYSQLCONNSTR_localdb.ini
、D:\home\data\mysql MYSQLCONNSTR_localdb.txt
から取得することができますが、形式がかなり特殊です。
具体的には、以下のような形式の情報が降ってきます。
1
|
Database=localdb;Data Source=127.0.0.1;User Id=azure;Password=password
|
これを自力でパースする必要があります。
PHPの例は巷に転がっていますが、例えばWiki.jsを起動したい場合は
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
//entrypoint.js
const { spawn } = require('child_process');
console.log("=== Start of entrypoint.js ===");
console.log(new Date());
const db = process.env.MYSQLCONNSTR_localdb;
console.log("Raw value of MYSQLCONNSTR_localdb: " + db);
const host = "127.0.0.1";
const port = /^.*Data Source=.*:([0-9]*);.*$/.exec(db)[1];
const name = "localdb";
const user = "azure";
const pass = /^.*Password=(.+?)$/.exec(db)[1];
console.log("===\nRegex result:\nhost: " + host + "\nport: " + port + "\nname: " + name + "\nuser: " + user + "\npass: " + pass + "\n===");
const child = spawn("node", ["server"], { env: {
...process.env,
DB_TYPE: "mysql",
DB_HOST: host,
DB_PORT: port,
DB_USER: user,
DB_PASS: pass,
DB_NAME: name
}});
console.log("===\nprocess cwd:" + process.cwd() + "process id:" + process.pid + "\nchild process id:" + child.pid);
child.stdout.on('data', (chunk) => {
console.log(chunk.toString());
})
|
とするなどして(コードは即席で書いたものなのであくまで例としてご覧になり、汚さに関してはご容赦ください)アプリケーションに合った方式でパラメーターを渡してあげる、もしくはアプリケーション自体を改造する必要があります。
なおこの例ではWiki.jsに環境変数で情報を渡していますが、ymlに設定を記述して渡してあげることもできるかと思います。
なお、環境変数で情報を渡す場合は、公式Dockerイメージにあるconfig.ymlのように
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
port: 80
bindIP: 0.0.0.0
db:
type: $(DB_TYPE)
host: '$(DB_HOST)'
port: $(DB_PORT)
user: '$(DB_USER)'
pass: '$(DB_PASS)'
db: $(DB_NAME)
storage: $(DB_FILEPATH)
ssl: $(DB_SSL)
ssl:
enabled: $(SSL_ACTIVE)
port: 443
provider: letsencrypt
domain: $(LETSENCRYPT_DOMAIN)
subscriberEmail: $(LETSENCRYPT_EMAIL)
logLevel: $(LOG_LEVEL:info)
logFormat: $(LOG_FORMAT:default)
ha: $(HA_ACTIVE)
|
といった感じで編集してあげる必要があります。
落とし穴3. Web.configが必要
IISを長くやっている方はご存知かもしれませんし、公式ドキュメントにもバッチリ書いてありますが、web.config
という設定ファイルが無ければnodeアプリケーションを起動することができません。
具体的には(と言っても公式の例をコピペしただけですが)、
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
<?xml version="1.0" encoding="utf-8"?>
<!--
This configuration file is required if iisnode is used to run node processes behind
IIS or IIS Express. For more information, visit:
https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config
-->
<configuration>
<system.webServer>
<!-- Visit http://blogs.msdn.com/b/windowsazure/archive/2013/11/14/introduction-to-websockets-on-windows-azure-web-sites.aspx for more information on WebSocket support -->
<webSocket enabled="true" />
<handlers>
<!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
<add name="iisnode" path="entrypoint.js" verb="*" modules="iisnode"/>
</handlers>
<rewrite>
<rules>
<!-- All other URLs are mapped to the node.js site entry point -->
<rule name="DynamicContent">
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
</conditions>
<action type="Rewrite" url="entrypoint.js"/>
</rule>
</rules>
</rewrite>
<!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin"/>
</hiddenSegments>
</requestFiltering>
</security>
<!-- Make sure error responses are left untouched -->
<httpErrors existingResponse="PassThrough" />
<!--
You can control how Node is hosted within IIS using the following options:
* watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
* node_env: will be propagated to node as NODE_ENV environment variable
* debuggingEnabled - controls whether the built-in debugger is enabled
See https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config for a full list of options
-->
<!--<iisnode watchedFiles="web.config;*.js"/>-->
</system.webServer>
</configuration>
|
のように起動するjsファイルを指定してあげる必要があります。
万が一起動にカスタムコマンドが必要な場合は、az
cliから
1
2
|
#!/bin/sh
az webapp config set --resource-group yourgroup --name yourapp --startup-file "node entrypoint.js"
|
のようにstartup fileを指定してあげればよいかと思います。
マイグレーションの失敗
ここまでの落とし穴をうまく乗り越えても、一向に起動する気配はありません。
ログを見ると、
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
=== Start of entrypoint.js ===
2022-11-17T17:25:52.943Z
Raw value of MYSQLCONNSTR_localdb: Database=localdb;Data Source=127.0.0.1:50912;User Id=azure;Password=****
===
Replace result:
host: 127.0.0.1
port: 50912
name: localdb
user: azure
pass: *****
===
===
process cwd:D:\home\site\wwwrootprocess id:16332
child process id:18740
Loading configuration from D:\home\site\wwwroot\config.yml...
OK
2022-11-17T17:25:56.669Z [MASTER] [32minfo[39m: =======================================
2022-11-17T17:25:56.677Z [MASTER] [32minfo[39m: = Wiki.js 2.5.291 =====================
2022-11-17T17:25:56.678Z [MASTER] [32minfo[39m: =======================================
2022-11-17T17:25:56.678Z [MASTER] [32minfo[39m: Initializing...
2022-11-17T17:26:16.477Z [MASTER] [32minfo[39m: Using database driver mysql2 for mysql [ OK ]
2022-11-17T17:26:16.489Z [MASTER] [32minfo[39m: Connecting to database...
2022-11-17T17:26:16.818Z [MASTER] [32minfo[39m: Database Connection Successful [ OK ]
[33mmigration file "2.2.17.js" failed[39m
[33mmigration failed with error: UPDATE pageHistory AS h1 INNER JOIN pageHistory AS h2 ON h2.id = (SELECT prev.id FROM (SELECT * FROM pageHistory) AS prev WHERE prev.pageId = h1.pageId AND prev.id < h1.id ORDER BY prev.id DESC LIMIT 1) SET h1.versionDate = h2.createdAt - You can't specify target table 'h1' for update in FROM clause[39m
2022-11-17T17:26:47.059Z [MASTER] [31merror[39m: Database Initialization Error: UPDATE pageHistory AS h1 INNER JOIN pageHistory AS h2 ON h2.id = (SELECT prev.id FROM (SELECT * FROM pageHistory) AS prev WHERE prev.pageId = h1.pageId AND prev.id < h1.id ORDER BY prev.id DESC LIMIT 1) SET h1.versionDate = h2.createdAt - You can't specify target table 'h1' for update in FROM clause
|
マイグレーションに失敗しています。
ここでMySQLのバージョンを確認すると、
1
|
D:\Program Files (x86)\mysql\5.7.9.0\bin\mysqld.exe
|
はい、5.7系です。
8系ですらありません。
因みに公式としては8系からの対応で、5.7系はLimited supportということになっているそうですが、次回のメジャーアップデートではPostgres以外対応しないと明記してあるあたり、気力はなさそうですね…
マイグレーションを修正すれば動作する望みは残されていますが、そこまでしてMySQL in AppでWiki.jsを動かしたいかと問われると時間の都合上そうも言ってられない現実がある(し、次回のアップデート時に困ることが容易に予測される)ためここで作業を切り上げることにしました。
目的は達成されずとも中身の構造を深く知れただけでも満足、ということにしておきます。
おまけ
az
cliで最近はAzureに関する様々な操作を実行できるようになっていて便利ですね。
例えば公式では
nodejsのWindowsインスタンスで利用できるバージョンを確認したい場合
1
2
|
#!/bin/sh
az webapp list-runtimes --os windows | grep NODE`
|
といったコマンドが紹介されています。
他にも
アプリケーションログを確認したり
1
2
|
#!/bin/sh
az webapp log tail --resource-group yourgroup --name yourapp
|
設定を変更したり
1
2
|
#!/bin/sh
az webapp config appsettings set --resource-group yourgroup --name yourapp --settings SCM_DO_BUILD_DURING_DEPLOYMENT=false
|
デプロイをしたり
(最近はほぼほぼCI/CDだと思うので、このコマンドは使う機会があまりないかもしれません)
1
2
|
#!/bin/sh
az webapp deploy --resource-group yourgroup --name yourapp --src-path wikijs.zip
|
といった操作が実行できるようになったようです。
自動化の幅が広がりますね。