Tag: Docker

タグ・月別アーカイブ

Let's encrypt + nginx で momo 環境を https 化した話

chrome では WebXR Device API は https でないと有効にならないようなので、さっくりと試してみた。

対象は WebRTC Native Client Momo の提供する、test モードでの http, WebSocket です。

作業内容としては、証明書を取得する+nginxでリバプロする、その二点だけです。

証明書の取得

みんな大好き Let's encrypt です。

いやもう大好きです。期限が短いから自動更新せざるを得ないし、自動更新作ってしまえば運用楽だし。無料だし。

certbot あたりが有名どころですが、lego を使いました。
環境は閉じている方が楽なので Raspber Pi Zero で動作させます。
そのため Mac からクロスコンパイルします。

$ git clone https://github.com/go-acme/lego.git
$ cd lego
$ export GOOS=linux
$ export GOARCH=arm
$ export GOARM=6
$ make build

strip するのが面倒なので、予め strip しておきましょう。

--- a/Makefile
+++ b/Makefile
@@ -23,7 +23,7 @@ clean:

 build: clean
        @echo Version: $(VERSION)
-       go build -v -ldflags '-X "main.version=${VERSION}"' -o ${BIN_OUTPUT} ${MAIN_DIRECTORY}
+       go build -v -ldflags '-s -w -X "main.version=${VERSION}"' -o ${BIN_OUTPUT} ${MAIN_DIRECTORY}

 image:
        @echo Version: $(VERSION)

今回は DNS サーバーは AWS/Route53 を使いました。

クラウド破産しないように、Route53 用の IAM を作成しておきましょう。

export AWS_ACCESS_KEY_ID=AXXXXX
export AWS_SECRET_ACCESS_KEY=XXXXX
export AWS_HOSTED_ZONE_ID=XXXXX
export AWS_REGION=us-east-1

# 初期化
./lego --accept-tos --path=./letsencrypt --email="mail@address" --dns="route53" --domains="*.foobar.com" run
# 更新
./lego --accept-tos --path=./letsencrypt --email="mail@address" --dns="route53" --domains="*.foobar.com" renew --days 30

実行に成功したら、上の例では ./letsencrypt/certificates/ 以下に証明書が保存されています。

一般的には cron, CronJob で実行したりとか、コンテナの中に入れたりとか、renew したら Message 投げるとかすればいいんじゃないですかね。

今回はロボ用なのであまり考えません。

nginx の設定

みんな大好きかもしれない nginx でのリーバスプロキシです。wss も対応していてよかった。

/etc/nginx/nginx.conf

events {
  worker_connections 768;
}

http {
  upstream momo {
    server localhost:8000;
  }

  map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
  }

  server {
    listen       443;
    server_name  xxx.foobar.com;

    ssl on;
    ssl_certificate /xxx/letsencrypt/certificates/xxx.crt;
    ssl_certificate_key /xxx/letsencrypt/certificates/xxx.key;

    access_log /dev/null;
    error_log /dev/null;

    location /ws {
      proxy_pass http://momo;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_read_timeout 86400;
    }

    location / {
      proxy_pass http://momo;
    }
  }
}

上で取得した証明書を使います。server_name に対応する Route53 のエントリは手動か自動かで作っておきます。

おわりに

無事 Raspberry pi zero 上に https でアクセスできるようになりました!

lego repository にある Dockerfile を少々改変し、QNAP/docker-compose 用の環境もついでに作りました。こちら

Container Station API

Container Station (QNAP) に Web API あるのですね。
本当、知らないことだらけです。

http://qnap-dev.github.io/container-station-api/system.html

login して session cookie をもらう形式(かつexpireが短い)なので、admin の ID/pass をシリアライズする必要はありますが、terraform 化できそうな感じですね

Golang の勉強がてら作り始めた Container Station の状態表示 CLI

https://github.com/Bugfire/qnapcc

Golang は初めて書くのでいろいろおかしいかもしれません。

QNAP日記 2019-09-30

家で動かしている QNAP を色々更新していました。

Refactoring

QNAP 屋内サービスのコード・構成のリファクタリング

  • docker-compose を使うように変更
  • docker-compose で syslog に投げる
  • JavaScript で作ったものを TypeScript にリファクタリング
  • npm package の update, http から axios への書き換え
  • Dockerfile で マルチステージビルドを使って image の削減
  • TypeScript で共通処理部分を切り出し

みたいなことをしていました。

Pi2B to Nature Remo

今まで、特に意味もなく Raspberry Pi 2B の USB 温度計で部屋の温度をとって DB に放り込んでいました。それを今回 NAS 側に移しました。

温度取得を QNAP の Docker + Nature Remo の方の API に切り替えた結果、湿度と照度を追加で取得できるようになりました。

地味に unbound が動いていた (dns blacklist を作っていた) のに気が付いていなくて、突然名前が引けなくなって、急遽ルーターの設定を変更。

uptime が 1000 日以上だったので、トラブルもなく安定してよく動いていたな、と思いました。(Security update は置いておいて)

hardware EOL and new device

過去の構成は:

  • TS-259Pro - Surveillance Station & DB & Backup
  • TS-651 - Docker & FileSharing

購入してから6年くらいの TS-269Pro の EOL が近づいて来ていたので、TS-453Be を購入しました。新構成は:

  • TS-651 - Surveillance Station & DB & Backup
  • TS-453Be - Docker & FileSharing

TS-453Be を SSDx2 の構成にしたら、11~13W くらいの電力消費におちつきました。CPU を全然回していないとはいえ、最高ですね?

TS-651 は SSDx2 HDDx2 で 37W くらいです。SSDで電気代が月500円安くなったとして、5年で3万円、過去の書き込みレートだと 60G/day くらいだったので、1年で21TBW、5年なら100TBW、TBW的にはいけそうですが、まだまだ容量単価がつらい。
(TimeMachine 等の Backup も兼ねているので、あまり容量を削れない)

Surveillance Station の課金が別 NAS に移行できないので、QVR Pro を試しているのですが重いねコレ...。

メモリー追加

ついでに、両方ともメモリーを 16G にしました。Container も Surveillance もメモリ喰いですし。

メモリーはだいすきな SanMax の DDR3L-1866 の 8Gx2 です。もちろん QNAP での動作保証はありません。

SanMax (サンマックス)
SMD-N16G28CTP-18ML-D-BK

よくセールになっていますね。

10GbE

去年末に購入した MacMini の 10GbE が一度も使われていないので、Hub 共々買い揃えたいと思いつつもまだ高いし、消費電力凄そうで躊躇してます。

DockerCompose on QNAP

ContainerStation

QNAP の ContainerStation をとても便利に使っていたのですが、Deploy のたびに設定 (UIからVolume等) をしたりとか、複数の Container が協調するのがめんどいというか、DockerCompose したいよなあ、と思って VPS を借りてみたりしましてました。

ところが、DockerCompose 対応してる、ということに、最近ようやく気が付きました(最初からあった?)。

DockerCompose == APP

QNAP 用語的には、docker-compose は APP ということみたいです。

Docker 社の作っている app plugin とは別物っぽいです。

APP は二通りの作成方法があるようです。

  • ライブラリ(初期設定なら https://github.com/qnap-dev/container-apps/tree/2.0) をつかう
    templte/*/wizard でメニュー設定と、docker-compose.yml の項目への binding が定義できるようだ。
  • 自分で設定する(作成の所のアプリケーションの作成ボタンから docker-compose.yml を編集して追加できます)
    docker-compose.yml に即値で書いていく。

自分は後者を使いました。設定項目が全て手の中にあるのでバックアップ・履歴管理も楽だし。(docker-compose.qnap.yml で commit しています、詳細な設定・秘密情報は Volume に置く方針です)

注意としては、build エントリがあると失敗するので、消しておきます。なければ image を自動的にダウンロードして実行します。

image の更新

なお、概要タブの Container/APP 一覧から、編集ボタンを押すと既存の APP の yml の編集ができ、適用 すると自動的に更新されます。

tag を :latest にした場合は 適用 を実行したところで、既存の latest を更新してくれないので、image を削除する必要があります。参照されていると削除できないので、面倒です。普通に versioning しましょう。