Heroku でやるにも規模が小さいけど、sleep 時間だけが課題になるアプリが欲しくなってきたので、とにかく運用、管理に手間を掛けずに似たようなことができないか調べてみたら Dokku というものを見つけたので、現時点でのメモ。
現状は
- まだ production では使っていない
- 対象バージョンは 0.5.6
書いてる人のやったことや背景。
- とにかくサーバ管理に手間を掛けたくない
- Docker には興味なくはないけど、そこ突っ込む時間はない
- Vagrant + Ubuntu 14.04 で試してみた
- 最初の Web UI での設定ミスってもあとでなんとかなる
- Dokku を試すには Vagrant と ssh の理解があれば Docker はそんなに分かってなくても大丈夫っぽい
間違ってたらツッコミお願いします。
メモなので、これ読んで勉強になるかっつーとたぶん厳しいです。
Dokku
Dokku - The smallest PaaS implementation you've ever seen
Docker で mini-Heroku のようなものを作るから Dokku という名前なのかな。
Linux 上に Docker と Heroku Buildpack を使って git push だけでアプリの実行環境を作って deploy することができるもの。
アプリは複数動かすことができ、Nginx を router として使っている。port 変更と Virtual Host の二つの方法で 1ホスト上の複数のアプリへのアクセスルートを確保している。
Vagrant + Ubuntu 14.04 で試した話は割愛
面白い部分はない。
ざっくり所感
Heroku のような手軽さは欲しいがそんなに本格的なコストを掛けるほどのものではない場合は VPS + Dokku というのも一つの方法のように見える。日本リージョンのサーバ(さくらとか)なら Heroku よりレスポンスは早いし。(Heroku の Tokyo リージョンは手軽さのうえにおもてなしが揃ってる Heroku Enterprise のものなので、極小規模アプリだけの話だとさすがに選択肢に入れられない。)
ただし、Heroku はよく分からないから Dokku を試してみよう、みたいなのは勧めない。絶対に逆がいい。Heroku を知っていれば Dokku の可能性を感じることができるし、限界も容易に想像がつく。
気づいたこと
Dokku 0.3(2013-12), 0.4(2015-09)辺りで大きな変更が入っている。ちょっと前の話を前提にすると全然噛み合わない可能性あり。
自分の場合は Docker にはあんまり興味ないので生々しい部分は触れずに興味を持った点などを挙げてみる。
- heroku コマンドのように外から管理コマンドを実行することはできない
- Docker環境というかサーバ管理の最初の課題はストレージ
- Webアプリでストレージを生々しく使いたくなるのはログ、画像などのアップロード機能、DBMS
multi buildpacks 対応
以前は plugin で実現していたようだが、0.3 のどこかで追加されたっぽく、0.5.6 の時点では何も設定せずに multi buildpack が使えた。
ただし 2016-05 時点での Heroku のようにきれいな UI があるわけではなく、multi buildpack が出たての時のように
.buildpacks
というファイルを用意する方式でイケる。
DBMS
DBMS は小規模なら plugin で直接ホスト上に構築しても問題なし。あとは backup などを自動化しておけ。
それでまかなえないなら本格的な DBMS サービスを追加して別ホストにした方がいいと思うけど、それならアプリケーションサーバも見直した方がいいと思う。
cron
cron は dokku user の cron をそのまま使う。ただし cron の管理しにくさはみんな気づいてるわけだ。
webhook plugin はあるので、UI が欲しい場合はそっち使ってもいいかも
nickstenning/dokku-webhooks: A dokku plugin for triggering external webhooks.
One-off process
Dokku - The smallest PaaS implementation you've ever seen
dokku run と dokku enter がキモなのかも。
log
logsprout というものがある
gliderlabs/logspout: Log routing for Docker container logs
ので、外部のサービスに投げちゃうのがよさそう。
Papertrail - cloud-hosted log management, live in seconds
とか。
- Sending Dokku Container Logs to Papertrail - Michael Bianco
- Using logspout to get Docker container logs into Papertrail. · Darron Froese
GitHub Flow
手軽なものほど自分以外も deploy できてほしい。
pull-req が扱えて CI/CD サービスと組み合わせて GitHub Flow でいいかな。
その他諸々メモ
最初に Web UI でセットアップできるのは便利なようで、特に最初は何を入れるのが正しいか分からないので、間違えた時にどうしたらよいかを中心に設定ファイルの場所をメモ。
Virtual Host と DNS
0.5.6 のタイミングから dokku.me ドメインが登録され、正引きで 10.0.0.2 が返ってくる。古いドキュメントや「試してみた」系の記事ではこれは押さえられていないが、この IP アドレスは以下のように使える。
Vagrant で試す際にはゲストOSに 10.0.0.2 でアクセスできるように(例えば HostOnly IP を)設定しておくと、Virtual Host でアプリを動かしやすくなる。
要は Dokku 本家の動かしている xip.io みたいなもん。
※ もちろん 10.0.0.2 の 1つしか IP アドレスがないので同時に動かす Dokku ホストは1つしか作れないし、たまたま自分のネットワークでこの IP アドレスが使えない可能性はある。
したがってこれでもう hosts や xip.io とはおさらばさ、とは言えない。そういうノウハウもあった方がよい。
関連リンクはここ。
基本の場所
/home/dokku
ssh
Web UI で入れる deploy 用の key はここに入る
/home/dokku/.ssh/authorized_keys
Vagrant でのテストならこいつに vagrant の insecure_private_key の public key を与えても ok
Virtual Host 方式かどうかを後から切り替える
node.js - Dokku change settings after install - Stack Overflow
以下のファイルが関係している。
- /home/dokku/VHOST
- /home/dokku/ENV
Virtual Host 方式でない場合は以下の設定が行なわれている状態。
config:set NO_VHOST
こうなっていると deploy 時に Nginx の port がランダムに割り当てられる。
したがって後から Virtual Host 方式にするにはアプリに対して以下のように変更するとよい。
- `config:unset NO_VHOST`
- `config:set DOKKU_NGINX_PORT=80`
Buildが通らない場合
Dokku の実行にはメモリ 1GB 以上推奨で、それ未満の場合は swap を追加しろとドキュメントにある。
Dokku - The smallest PaaS implementation you've ever seen
その他
New Relic
Application Performance Management & Monitoring | New Relic
サーバ管理はしたくないけどサービスの状況は知りたい。そんな時に便利なのが New Relic なのは皆さんご存知の通りですね。
管理UI
あるにはあるけど、セットアップに手間が掛かると本末転倒なので、まだ試してない。
aramirez92/quais: Web UI Manager for dokku
SMTPとか
SendGrid には無料範囲はないので AWS SES とかかな? SMTP 用意するのもアリだけど monitoring が面倒で、どうしたものか。
Nginx でやる? さすがになぁ。
結論出てない。Google Apps あるならそっちに任せるでもいいのかな。
あと plugin チェック
- dokku/dokku-maintenance: BETA: dokku plugin that gives the ability to manage application maintenance mode
- dokku/dokku-letsencrypt: BETA: Automatic Let's Encrypt TLS Certificate installation for dokku
- dokku/dokku-http-auth: BETA: dokku plugin that gives the ability to manage HTTP basic auth for an application
おまけ
Buildpack という考え方は PaaS ではポピュラーらしく、これには慣れておいた方がよさそう。
ひしめき合うOpen PaaSを徹底解剖! PaaSの今と未来
Dokku を知ったのはこの資料でした。感謝。
ポイントは xinetd を再起動したいんじゃなくて、そこから起こしてるプロセスを再起動したいってとこ。
軽く調べたけどよく分からず、なんか面倒くさいから kill -HUP したらそれきり帰ってこなくなってしまった。
でもまぁ xinetd が監視してんだからそれで別に困らないわけだけど。
※ 自分で検索してもこのページが見つかるし、referer を見ても情報を探してる人がそれなりにいそうなので書いておくと、たぶん
xinetd を kill -SIGHUP
でいいような気がする。xinetd の設定変更を反映する。そもそも上の記述は xinetd 経由にしてるはずの daemon プロセスが自分一人で起き続けている段階で何かがおかしい。
あるいは多くの Linux では
/etc/init.d xinetd (restart|reload)
でイケるはず。
Lotus1-2-3 の日本語データ。
早いうちに(って今どきないか?)Lotus で作ったデータは Excel か CSV に変換しておけってことか。
休みの日に激減するってーことはやっぱ感染した企業 PC が spam なのかワームなのか分からないメールを大量に発信してるってことか。
逆に spam 業者ってあんまりいないのかな? 少なくとも日本ほど真面目に(?)はやってないのかもなぁ。
あれ。待てよ。そうするとオレのアドレスが海外の業者に収集されてるってことか。あー .com ドメイン?
まだ見てないけど充実してそう。ただし、Home と Front の違いが分からないとか Front のレイアウトが決して見やすくはないとか、注意すべき点はありそう。
ずーーーーっと気にはなっていたが、いったいどうやって対処していたのか思い出せなかった PukiWiki の tracker プラグインのリストテーブルのヘッダの表示が乱れる件に対処。
これは
- tracker プラグインが自分自身へのリンクの生成に(PukiWiki の設定ファイルの)$script を利用している。
- $script には本来 http:// からのスクリプト設置場所を書くべきなのだが、PukiWiki のほとんどの動作ではここは URI スキームもホスト名も必要ない
- スキームやホストを書かずにいると http でも https でもアクセスできるようになったり、portforward 経由でもアクセスできるので都合がよい
- よって書かない(これはオレ方針)
- しかし tracker プラグインではこの $script を PukiWiki の alias に利用できる文字列として利用する
- よってリストのヘッダの表示がおかしくなる
という問題。しかし
function replace_title() の一部を以下のように
787c787
< global $script;
---
> $self = 'self:';
821c821
< return "[[$title$arrow>$script?plugin=tracker_list&refer=$r_page
&config=$r_config&list=$r_list&order=$r_order]]";
---
> return "[[$title$arrow>$self?plugin=tracker_list&refer=$r_page
&config=$r_config&list=$r_list&order=$r_order]]";
修正し、InterWikiName に
[./ self] raw
を追加することで、対処できる。InterWikiName にこんな記述ができるのもたぶん PukiWiki 独自。
diff は 1.4.2 のもの。
しかし $script の仕様を変更して本体を直してくれるのがいちばんいいんだけどなぁ。というか $script って要らないよね。まぁ作業量がどんくらいになるのかよく分からないのに効果はそんなにないって意味では、
すでに PukiWiki を動かすサイトが固定している開発チームには何のメリットもない
んだけどね。