稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

じゃんくはっく
じゃんくはっく

SLAって知ってる?

聞いたことはあるけど、品質の合意だっけ?

ぴー
ぴー
じゃんくはっく
じゃんくはっく

そうそう!稼働率のSLA99.95%とかって意味でよく使われてるよね。99.95%稼働してるってことは1ヶ月で約21分はダウンしたってこと。

それを自宅サーバでがんばってみるのね!

ぴー
ぴー

目標を持つのは、大事だよなということで、せっかく自宅サーバを運用しているので遊び感覚で、稼働率SLA99.95%を目指してみることにします。今、検討しているsite24x7のサービスは、この稼働率を算出する仕組みもあるようです。

SLA99.95%とはどのくらいダウンが許されるのか?

稼働率 => 月間ダウンタイム計算ツール

https://cloned.jp/sla-calc/

こんな便利な計算サイトがありました。ここで計算してみると、99.95%とは1ヶ月に21.6分以内であればOKということです。年間だと、262.8分(4.4時間)以内であればOK。

じゃんくはっく
じゃんくはっく

少ないような多いような、う〜ん。あまり体感できないね!

1ヶ月に21.6分しか休憩できないって思うとぞっとするわ!

相当なブラック企業よ!

ぴー
ぴー
じゃんくはっく
じゃんくはっく

・・・なんか、すごく大変な気がしてきた!w

site24x7で、SLA設定をしてみる!

現在、検討中の監視サービス・site24x7は、目標のSLAを設定できます。世界各地の拠点、8箇所から1分間隔で監視しています。そこから算出してくれる大変、便利な機能です。設定は、管理>SLA設定 から行えます。

営業時間は設定していませんので、24時間が対象ということです。

現在の稼働率はどのくらい?

まだ、9/20から始めたので1ヶ月は経過していませんが現状は以下の通りです。

9/21と23日に停止時間があり、落ちていた時間は8分40秒ということです。現在は、99.852%の稼働率ということがわかりました。

評価期間・1ヶ月でSLAをチャレンジ!

良い目標ができたので、とりあえず1ヶ月後の10/20にSLA目標が達成できるかチャレンジしてみようと思います。今のところ、8分40秒ダウンしていますので、あと猶予は約12分間です。あと25日間で12分ダウンさせなければSLA99.95%を達成できます。

 うーん、こうして計算してみると結構大変な気がします。まず、1台のスマホサーバでやっているのでダウンしたら12分なんてあっという間でしょう。あと寝ている時間とかに、ダウンしたら終わりですね。年間を通じて、99.95%を維持しようとするなら、ロードバランサーや複数台構成が必須だと思います。停電っていうのもありますしね。スマホ自体は電池があるから無停電電源装置がついているようなものですが、ルータ周りやHUBなど対応する必要がありそうです。

やるしかないでしょ!期待してるわよ。

ぴー
ぴー

まとめ

だいぶ煽られていますがまとめます。今回、なんとなくわかったのは以下ですね。

・稼働率SLA99.95%とは1ヶ月に21.6分以内であればOK
・1年なら、262.8分(4.4時間)以内であればOK
・監視サービス・site24x7は、サイトを客観的に見るために有用だ
・監視サービス・site24x7(有料版)は、SLA目標を設定できレポートが作れる

あとがき

こうして自分で体験してみると結構大変そうだなって思いました。また1ヶ月後に具体的な数字が出るのでそこで、何かまた発見があるかもしれません。

余談ですが、世界各地8箇所から応答時間をモニタリングしていますが、なんと国内からよりもロサンゼルスからが一番品質が良いようです。

東京など国内は、ロスからのように平坦ではないです。今、InterLinkのPPoEのIP固定使っています。国内のほうが速いだろうと思っていましたがこれは以外な発見でした。site24x7のサービス、すごく良いと思います。

Termuxネイティブ環境でWordPressのバックアップをどうするか考える。その2

じゃんくはっく
じゃんくはっく

GoogleDriveの版数管理を今日はテストしてみるよ!

版数って、バージョンとかってこと?

ぴー
ぴー
じゃんくはっく
じゃんくはっく

そうそう、同じファイルを上書きすると過去の変更前の状態に戻せる機能だよ。詳細はここ見てね。

なんとなくわかった! けど、バックアップと関係あるの?

ぴー
ぴー

この版数管理、実は前から気になっていたんですよね。今日はテストがてら、この機能をtermuxから、GoogleDriveなどクラウドストレージにコピーや同期させる rclone を使って実際に試してみたいと思います。

テストするクラウド環境の用意

クラウドは、GoogleのGoogle Apps(グーグルアップス)にします。gpl.jpドメインは、ここに関連付けてありますので1つ新規のアカウントを用意しました。

15GBの保存容量がありますね! また何も保存していない状態です。

rcloneという、すごいやつをTermuxに入れる!

rcloneは、以下のオフィシャルサイトにもarm用がビルドされていてダウンロードできますが、これはtermux では使ってはいけません。

Rclone Download v1.53.1

https://rclone.org/downloads/

なぜなら、名前解決の仕組みが違うからです。Termux にはバイナリが用意されていますので、pkg installで入れておきます。

$ pkg install rclone
::
$ rclone --version
rclone v1.53.1-DEV
- os/arch: android/arm64
- go version: go1.15.2

なぜ、こっちを使うのかと言うと名前解決の方法が違うからです。termuxパッケージのrcloneを使わないと、認証するとき、エラーになりますので。筆者は、ここで途方に暮れました。

rcloneとgoogle driveの初期設定

先ほど用意した、GoogleDriveのアカウントを使えるようセットアップします。

Google Drive

https://rclone.org/drive/

ここに詳しく書いてありますが、要点は1つ。リモートでセットアップしている場合は、以下の選択肢を n として作業しているPCのブラウザから Googleにログインしてverification codeを入力しましょう。

Remote config
Use auto config?
 * Say Y if not sure
 * Say N if you are working on a remote or headless machine
y) Yes (default)
n) No
y/n> n

以下のリンクを作業しているPCのブラウザで開き認証します。認証するとverification codeが出るのでこれを、貼り付けます。

Please go to the following link: https://accounts.google.com/o/oauth2/auth?access_type=offline&client_id=(省略)
Log in and authorize rclone for access
Enter verification code> ここに認証したコードを

確認は、このコマンドでリモート名称一覧が出てきます。この名称は rclone コマンド中に使うので短く覚えやすいのが良いかなと思います。今回は、01bupとしてみました。

$ rclone listremotes
01bup:

設定ファイルはホームディレクトリの以下にあります。

$ tree .config/rclone/
.config/rclone/
└── rclone.conf

rcloneを使ってみる

まず、何もGoogleDriveには入っていませんが一覧を出してみます。

$ rclone ls 01bup:
$ 

ではディレクトリを作ってみましょう。

$ rclone mkdir 01bup:hackgpljp 

確認。

$ rclone lsd 01bup:
          -1 2020-09-24 17:46:29        -1 hackgpljp
または、
$ rclone lsf 01bup:
hackgpljp/

ちゃんと作られているか、ブラウザでも見て見ましょう。

おお〜! ちゃんとディレクトリが作られていますね。

テストコードでファイルの履歴を作ってみる

同じファイル名を更新していくと、版ができるので確認してみたいと思います。tmpディレクトリを作り、そこで作業します。

$ cd
$ mkdir tmp
$ cd tmp
$ pwd
/data/data/com.termux/files/home/tmp

テストプログラムを作ります。今回は、test.shとしてこのような内容にしました。

$ cat test.sh 
#!/bin/bash

PATH=$PATH:/data/data/com.termux/files/usr/bin:/data/data/com.termux/files/home/bin
BACKUP=/data/data/com.termux/files/home/tmp
TXTFILE=a.txt
DRIVENAME=01bup
CPATH=hackgpljp

echo '' >> $BACKUP/$TXTFILE
max=30

for ((i=0; i < $max; i++)); do
    echo $i ":" `date +'%H:%M:%S.%3N'` >> $BACKUP/$TXTFILE
    echo "rclone sync start : "$i  `date +'%H:%M:%S.%3N'`
    rclone sync $BACKUP/ $DRIVENAME:$CPATH
    echo "rclone sync end   : "$i  `date +'%H:%M:%S.%3N'`
    sleep 1
done

動作概要としては、以下となります。

・a.txt に、日付ファイルを追記して、rcloneで同期させる
・回数は、30回(つまり、版が30個できる)
・rclone syncがどのくらい時間がかかるか前後で時刻を出しておく

やっと実験です。tmpディレクトリにはテストPGしかまだありません。

$ ll
total 24K
drwx------  2 u0_a364 u0_a364 4.0K Sep 25 02:51 ./
drwx------ 24 u0_a364 u0_a364 4.0K Sep 25 02:51 ../
-rwx------  1 u0_a364 u0_a364  490 Sep 25 02:51 test.sh*

では、動かしてみましょう!

$ ./test.sh 
rclone sync start : 0 03:00:19.515
rclone sync end   : 0 03:00:24.202
rclone sync start : 1 03:00:25.237
rclone sync end   : 1 03:00:28.314
::(省略)
rclone sync start : 5 03:00:43.284
2020/09/24 18:00:43 Failed to create file system for "01bup:hackgpljp": couldn't find root directory ID: googleapi: Error 403: Rate Limit Exceeded, rateLimitExceeded
rclone sync end   : 5 03:00:43.915
::(省略)
rclone sync start : 8 03:00:54.008
2020/09/24 18:00:54 Failed to create file system for "01bup:hackgpljp": couldn't find root directory ID: googleapi: Error 403: Rate Limit Exceeded, rateLimitExceeded
rclone sync end   : 8 03:00:54.603
::(省略)
rclone sync start : 29 03:02:24.355
rclone sync end   : 29 03:02:27.609

一部、Rate Limitのエラーが出ていますね。テストPGは1秒の待ち時間を入れてありますが、速すぎると制限にひっかかるのでしょうか。rclone syncの処理時間は、このくらいのテキストサイズで3秒〜5秒くらいのようです。

気になることはいろいろありますが、GoogleDriveにバックアップされたか見て見ましょう。

$ rclone ls 01bup:hackgpljp
      531 a.txt
      490 test.sh

ちゃんと、ローカルのtmpディレクトリ が同期されていますね。

ブラウザーでも見て見ましょう。

大丈夫そうです。a.txtを右クリックして「版を管理」から版数が保存されているか確認してみます。

おー! 版は現行版を含めて28個ありました。途中2回失敗していたからですね。では、1つ目の版をダウンロードしてみてみましょう。

ちゃんと、最初の1回目のタイムスタンプだけでしたね!

では、1つだけ古い28版を見て見ましょう。

最新のは、29 こ目のタイムスタンプがあるやつなので、ちゃんと1つ前にアップロードされたファイルのようです。

版は100個以上になるとどうなるのか?

先ほどの、ダイアログ中に版は100個まででそれ以上は削除される可能性があると書いてありました。

「a.txt」の旧版は、保存してから 30 日間経過した場合、または保存した版が 100 個に達した場合に削除される可能性があります。削除されないようにするには、ファイルのコンテキスト メニューで [この履歴を削除しない] を選択します。

どうなるか実験してみましょう。テストプログラムをb.txtとして、回数は110回の上書き保存としてみます。

$ ./test.sh 
rclone sync start : 0 03:22:16.889
rclone sync end   : 0 03:22:20.567
::
rclone sync start : 109 03:30:25.700
rclone sync end   : 109 03:30:29.008

今回はレートリミットのエラーは出ませんでした。ブラウザーで履歴を見て見ます。

ふむふむ! 版は100までしかないですね。このファイルを見てみます。

108のタイムスタンプなので、最新の1つ前ですね。では、版1を見てみます。

あー、なるほどですね。100個以上前の版は流れているようです。

まとめ

今回、簡単な実験からなんとなく雰囲気がつかめました。

・rclone syncで同期されるが、3〜5秒と同期するファイルサイズにより時間はそれなりにかかる。
・あまり短い間に、上書きするとレートリミットの制限にひっかかるようだ。
・版数は、ちゃんと保存されていて100個を越えると一番古いのが流れる。

容量節約してバックアップを効率的に保存しておくってことだったのね! やっと意味がわかった〜!っていうか、せこいこと考えるわね!

ぴー
ぴー

あとがき

おそらく30日を越えると、履歴は消えるのでしょう。どのように消えるのか興味はあります。また、削除したくない場合は、「この履歴を削除しない」にチェックを入れておけば大丈夫のようですが、まだ未確認です。これを確認するには、30日以上かかりますので。

 でもまぁ、うまく使えば、ログや画像ファイルなどバックアップデータを1日1回、同じファイル名で保存すれば、30日前までは引っ張ってこれるみたいなので容量は節約できそうですね。

Termuxネイティブ環境でWordPressのバックアップをどうするか考える。その1

じゃんくはっく
じゃんくはっく

今日も自宅サーバいじるよ〜!

ほんと、好きねぇ〜。今日は何するんですか〜?

ぴー
ぴー
じゃんくはっく
じゃんくはっく

好きというか、まだ設定いろいろあってw。とりあえず、バックアップをどうしようかなと。

プラグインとか便利なのあるでしょ?あれじゃだめ?

ぴー
ぴー

はい、ぴーちゃんの言う通り便利なプラグインがあります。

超有名なWordPressバックアッププラグイン

この2つが特に有名じゃないでしょうか?

UpdraftPlus WordPress Backup Plugin

あと、これ。

BackWPup – WordPress Backup Plugin

前者のUpdraftPlusは、一度使ったことがあります。通常ならこれでバックアップはOKじゃないでしょうか。でも、今回はちょっと自宅サーバ構成に難があって、自分のドメインに自分でアクセスできない問題があります。

自分のドメインに自分でアクセスできない問題!

これはつまり、https://hack.gpl.jp や、https://hack.gpl.jp で自分自身にアクセスできないということです。こういう場合、WordPressのcronやジェットパックなどいろんな部分で問題が発生します。これは、wp-cliで診断すると以下のようになります。

$ wp cron test
Error: WP-Cron spawn failed with error: cURL error 28: Connection timed out after 3000 milliseconds

この、cURL error 28 エラーはいろんなケースで出るのですが自分の場合は、登録されているURLに自分自身でアクセスできないことが原因です。この問題の根本は以下で紹介しています。まだ解消していません。

ポートフォワードの経路で、Uターン NATとかヘアピンNATが使えないルータの場合のあれこれ

https://hack.gpl.jp/2020/09/07/ポートフォワードの経路で、uターン-natとかヘアピ/

この解消はまた別の機会にやるとして、今回はこういう中途半端な環境で wp-cronが動作しない中、どうやってバックアップを行うかという感じです。

さて、どんな方法があるの?

王道としては、バックアップスクリプトを書いて、どこかクラウドストレージへコピーする方法です。データベースと、WordPress側で更新される画像など uploads以下にできるファイル、またカスタマイズするテーマなどもバックアップしておきたいです。それらをスクリプト中に記載してLinuxのcronで実行するという、めんどくさいやり方です。世の中、便利になりすぎてこういうスクリプト書くのが面倒になってきています。

バックアップ方針とTermux環境で使えそうなツール

バックアップ方針は、やってる最中に気が変わるとして、下調べしてみると必要なツールは以下となりそうです。

・クラウドへのバックアップ 
 → GoogleDriveにバックアップしたい
 → rcloneがある!
・uploadsは差分バックアップしたい
 → rsyncがある
 → Termuxもバイナリがある
・全部、スクリプトで書くと面倒
 → wp-cli を使って、プラグインと併用してみる
・DBは30日分保存、uploadsは差分保存

幸い、Termuxのバイナリにはこれらのツールが揃っていることがわかりました。rclone は、今回はじめて使います。

Rclone syncs your files to cloud storage

https://rclone.org/

まとめ

今回、なんとなくわかったのは以下となります。

・WordPressのcronは、自己のURLで自分自身をcurlで叩いている。
・それが出来ないと、cURL error 28のエラーが発生する。
・wp-cliで、wordpress の jobを linux の cron で叩けば動く
・クラウドへの保存ツールは、rcloneで解決

あとがき

まぁ、そもそもネットワーク構成をちゃんとやって自分自身をちゃんと参照できるようにしないとだめだよなーと。ただ、NATとポートフォワードをしていて内部LAN側に違うポートで提供している環境は他にもあると思うので、もしかすると誰かの参考になるかなとも。たぶん、その2へ続くと思います。

無料の外部から監視するサービスを使って見た!site24x7

前回、事前に調査した4つの監視サービスを検討してみました。この中では格段に操作と設定がしやすかった、site24x7 というサービスを紹介することにします。なぜ、このサービスなのかと言うと4つのサイトに同時にサインアップして実際に使ってみたのですが、説明書も何も見ずに最後まで設定できたからです。

site24x7の有料プランでできること

Site24x7 プラン比較

https://www.site24x7.jp/packs-comparison.html

詳細はこの表の通りですが、無料プランと有料プランの格差がありますよね?有料は7000円〜となっていますが、実は10ドルで出来そうな感じです。後ほど紹介しますね。

さて、無料プランではWEBの死活監視ができ、アラートはメールで可能。ステータスページは有料と違い、グラフが表示できるダッシュボードが公開できない。という内容です。有料と無料では、公開できる情報(グラフ)が違います。実際にこのサイトで公開している監視グラフのページを見てもらうほうが理解が速いかなと思います。

有料プランのグラフ

このサイトの監視状況 有料プラン(1ヶ月ほど無料)

https://hack.gpl.jp/status/

上記リンクは、有料プランが終わったときには見れないのでスクリーンショットをつけておきます。有料プランはカスタマイズしたグラフをダッシュボードに作り、それを共有することが可能です。

いろんなグラフが作れますが、上から「応答時間詳細」でこれは東京リージョンからのものです。その下が、「ページ読み込み時間詳細」です。どちらも、DNSや接続時間など詳細に出ています。

応答時間詳細は、各所にヒゲ状に突出している部分がありますね。また、ページ読込時間を見ると夜間帯は安定していますが、昼間はギザギザしていますね。

次は、「スループット」と「各ロケーションからのSSLハンドシェイク時間」です。200kb/secくらい最高で出ていますが、平均値は120kb/secくらいですね。WEBデータのような小さいデータの転送は速度があまり出ないのかな?

SSLハンドシェイクの時間は、各拠点からのものでこの拠点は世界中から8箇所まで選べます。国内だと東京・長野・大阪が選べました。

最後の図は、「ロケーションごとのページ読み込み時間」です。面白いことに東京よりも、シンガポールからのほうが速そうです。また、意外にもニューヨークやロサンゼルスからも遅くはありません。有料プランは、これ以外の数多くの機能があり全部は紹介しきれませんが、概ね有益だなと感じました。例えば、証明書期限チェックやドメイン更新期限チェックなどあります。面白いなと思ったのは、Tracerouteによるネットワークパス分析です。

ロスからと東京からのホップ数(ざっくり言えば、ルータ越えの数)はそう変わりないみたいw また、深センからはいろんな経路があるんだな! ということがわかりました。

site24x7の10ドルの有料プラン!

これだけ、いろいろな機能ができるなら検討してもいいかもしれません。このサービスの価格は、有料にするとお幾らなんでしょうね?

はい、最初に見てもらった価格表はPro〜7000円から有料とありましたが、なんとスターターという有料プランもあるようです。これは日本円だと毎月払いで2000円、ドル払いだと10ドルと記載されています。

可能かどうかは不明ですが、ドル建ての支払いのほうがお得な気がします。月払い10ドルならアリかもですね。この表中にある、詳細監視というのは、以下のことです。四角枠で囲った部分、これは欲しいですね。

ブラウザーと記載してあるものは、時系列でその時の読込にかかった状態が記録されています。例えば、2020/09/22 2:55 の東京からの読込が10秒ほどかかっている部分があります。

これは、ブラウザーからの読込は以下のようになっていました。

つまり、JSの読込が遅いのか? あるいは、画像の読込が遅いのか? あるいはジェットパックで画像置き換えられたCDNが悪いのか? などが各拠点から時系列でわかってしまいます。すごいですね!

site24x7の無料プランは・・・?

無料プランでは、有料プランでできるダッシュボードのグラフを共有することはできませんでした。グラフが見たければ、管理パネルにログインしていれば以下のように見えます。

計測地点は、シアトル(US)からのみです。試験を行う間隔は10分となりそれ以下はできません。死活監視のみとなり、無料プランでグラフはこれ以外は登録できないようです。シアトルからの監視ですが、まぁ十分でしょうか。有料プランで出来たブラウザからの読込はサポートしていません。
 なお、グラフの共有(ダッシュボード)はできず、公開できるのは、ステータスページで、StatusIQ というサービスを使って行えるようです。これも実際に見てもらったほうが速いです。以下に、このサイトの状態を貼ってあります。

NetWork Status FreePlan

https://hack.gpl.jp/network-status-freeplan/

グラフは出すことができず、サービスが生きているか死んでいるかを表示するものみたいですね。

なお、WEBサイトを登録するときの画面は以下のようになります。

あとがき

最初、WEBを監視するだけだと思っていましたが関連するサービスがたくさんあって、このサービスは今後検討してみたいなと思いました。しかし、スマホサーバを外部から10ドル払って監視する価値がどのくらいあるのかまだ未知数です。

監視できる事は豊富で、コスパ的に見れば、類似サービスの中では突出しているようにも思えます。多少味付けは違いますが、マカレルよりいい機能があるかな!と感じています。でも、マカレルはLINE通知があるので好きなんです。

site24x7で、まだ試していないのはLinuxのリソースを監視するサービスです。これもエージェントがtermux で動作するのかどうかわかりません。Termuxネイティブ環境は何かと制約があるのです。もし、うまくいったら、また続報があるかもです。

このブログは、スマートフォンの中に引越ししました!

えっ? と思われた方もいるかもしれませんが、このジャンクハックブログは引越ししました。それもスマートフォンの中にいます!

なんで、引越しをしたの?

はい、結論から言いますと今まで使っていたWordPress.comのパーソナルプランの料金が上がったからです。月額400円から500円で年間一括6000円となります。まぁ、100円くらい良いんですがなんとなく、年間で6000円かーと思いましてね。

今から2年ほど前、 WordPress.com 上のパーソナルプランっていうところを使い始めていました。

Linuxエンジニアがサーバを作らず結局、WordPress.com の有料プランに入ることにしたよ

https://hack.gpl.jp/2018/10/17/20181017/

レンタルサーバはたくさんあるんですが、WordPressのオートマチック(Automattic Inc.)がやっているサービスです。ビジネスプランまで契約しようかと当初は思っていましたが、このブログがそんな人気が出るわけでもなくチマチマとパーソナルプラン(当初月額400円)でやっていました。

更新期限が10月中旬ということもあって、2、3ヵ月前から自宅サーバを検討していました。ご興味があるかたは、以下から検索してね。(検索システムも速くしてあります)

Termuxとか、自宅サーバ関連

https://hack.gpl.jp/?s=Termux+自宅サーバ

月に500円、年間6000円支払うなら電気代に払って自宅サーバでブログを楽しみたいな! と思ったのであります。

スマホの中に引越しとは?

 はい、このブログはスマホの中から今見ているみなさんに提供しているんです。信じられませんよね!w

これは、Termux というAndroidアプリがありまして、それがつまりは Linuxなんですよね。正確にいえば、Android自体がLinux Kernelを採用したOSなんで、その上でLinux環境を構築するアプリなんです。

で、その環境にWEBサーバやら、データベースサーバやらを作り、WordPressを動作させているんです。回線は、普通のNTTの光回線に InterLinkのIP固定サービスでやっております。いわゆる自宅サーバというやつですね。

あとがき

これで、Pluginもテーマファイルもやりたい放題です。

ぴー
ぴー

やっぱりWordPressはカスタマイズしたいよね!

とりあず、今日は引越ししたよ! というネタをあげたかったので以上にします。またねー。

WordPressのコマンドラインツール、wp-cliを使ってみたら便利だった!

存在は知っていましたが使ってみると便利でした。

WP-CLI は WordPress を管理するためのコマンドラインインターフェースです。

https://wp-cli.org/ja/

つまり、こんなことが出来ます。

$ wp plugin list
+----------------------------------------+----------+--------+---------+
| name                                   | status   | update | version |
+----------------------------------------+----------+--------+---------+
| akismet                                | active   | none   | 4.1.6   |
| amp                                    | active   | none   | 2.0.1   |
| autoptimize                            | active   | none   | 2.7.7   |
| jetpack                                | active   | none   | 8.9     |
| jquery-manager                         | active   | none   | 1.10.6  |
| line-auto-post                         | active   | none   | 1.0.1   |
| litespeed-cache                        | inactive | none   | 3.4.2   |
| multiple-domain-mapping-on-single-site | active   | none   | 1.0.4   |
| ultimate-addons-for-gutenberg          | active   | none   | 1.17.0  |
| word-balloon                           | active   | none   | 4.12.0  |
| wordpress-importer                     | active   | none   | 0.7     |
| wpfront-scroll-top                     | active   | none   | 2.0.2   |
| duplicate-post                         | active   | none   | 3.2.5   |
+----------------------------------------+----------+--------+---------+

シェルが使える環境だったら使わないと、もったいないですね!

インストール抜粋

Termux環境でも使えるか試してみました。要件はさきほどのリンクに記載してありますがPHP5.4〜とUNIX系の環境だそうです。WordPressは、3.7〜。

ステップ1

適当なディレクトリを作っておきます。例では、home直下にtmpディレクトリを作りそこで作業します。まず、wp-cli.phar をダウンロードします。

cd
mkdir tmp
cd tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

ステップ2

一応、確認です。

php wp-cli.phar --info

以下のような感じで出力されました。

OS:	Linux 4.14.141+ #1 SMP PREEMPT Wed May 6 10:13:36 CST 2020 aarch64
Shell:	/data/data/com.termux/files/usr/bin/bash
PHP binary:	/data/data/com.termux/files/usr/bin/php
PHP version:	7.4.10
php.ini used:	/data/data/com.termux/files/usr/lib/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/data/data/com.termux/files/home/tmp
WP-CLI packages dir:	
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.4.0

ステップ3

実行権限をつけて、パスが見えるところに移動。

chmod +x wp-cli.phar
mv wp-cli.phar $PREFIX/bin/wp
::(ちゃんと見えるか確認)
$ which wp
/data/data/com.termux/files/usr/bin/wp

ステップ4

タブ補完できるようにしておきます。

cd
mkdir bin
cd bin
wget https://raw.githubusercontent.com/wp-cli/wp-cli/v2.4.0/utils/wp-completion.bash

vi ~/.bash_profile

以下を追記

source /data/data/com.termux/files/home/bin/wp-completion.bash

反映しておきます。

source ~/.bash_profile

確認

$ wp ※ここでタブキーを押してみると以下が表示されます。
cache              cron               help               menu               post-type          shell              theme 
cap                db                 i18n               network            rewrite            sidebar            transient 
cli                embed              import             option             role               site               user 
comment            eval               language           package            scaffold           super-admin        widget 
config             eval-file          maintenance-mode   plugin             search-replace     taxonomy           
core               export             media              post               server             term 

ステップ5

実際に使ってみましょう。WordPressのプラグインがあるディレクトリに移動します。以下は、プラグインの一覧を出すコマンドです。

$ wp plugin list
+----------------------------------------+----------+--------+---------+
| name                                   | status   | update | version |
+----------------------------------------+----------+--------+---------+
| akismet                                | active   | none   | 4.1.6   |
| amp                                    | active   | none   | 2.0.1   |
| autoptimize                            | active   | none   | 2.7.7   |
| jetpack                                | active   | none   | 8.9     |
| jquery-manager                         | active   | none   | 1.10.6  |
| line-auto-post                         | active   | none   | 1.0.1   |
| litespeed-cache                        | inactive | none   | 3.4.2   |
| multiple-domain-mapping-on-single-site | active   | none   | 1.0.4   |
| ultimate-addons-for-gutenberg          | active   | none   | 1.17.0  |
| word-balloon                           | active   | none   | 4.12.0  |
| wordpress-importer                     | active   | none   | 0.7     |
| wpfront-scroll-top                     | active   | none   | 2.0.2   |
| duplicate-post                         | active   | none   | 3.2.5   |
+----------------------------------------+----------+--------+---------+

お〜! これは便利ですね。いろんな使い方があるので、以下をみてみてくださいね。

WP-CLI Quick Start

https://make.wordpress.org/cli/handbook/guides/quick-start/

いろいろ便利な使い方があると思うので、備忘録:〜 で紹介していきたいと思います。

あとがき

やっぱり自宅サーバでWordPressをLinuxにホスティングしてみると、面白い発見がいろいろありますね。今まで、使わなかったいろんな方法があると夢が膨らみます。例えば、テスト環境なんかも簡単に作れそうですね。あるいは、差分を取って slack に投稿しておけば自動アップデートで何がどうなったかもわかると思います。アイデア次第ですね。