Rancherを使ってWebからコンテナ管理をできるようにした感想
以前書いた記事の環境でサーバを管理してたんですが、さすがに1つのcomposeファイルで管理するのはきつくなってきました。 そこで、ちゃんとコンテナオーケストレーションができるツールを入れようと考えるようになりました。
有名なのはk8sですが、そもそも本格運用したい訳ではなくて、単に「簡単に管理がしたい」という点で、rancher-serverからブラウザで管理ができるRancherを使うことに決定。
Rancherの動かし方等はggったら出てくるので、実際に動かしてどんな風に感じたかを書くことにします。 (なお、個人の趣味的なサーバなので、仕事で実際にやるのとは違います)
ざっくりとした感想
楽
とにかく楽ができます。
- ブラウザからポチポチして操作できる(これはRancherというより、rancher-serverの機能)
- 土日にアクセスが少し集中する時間帯等に、スマホのブラウザからポチポチするだけでいい感じにスケールしてくれる
- 個人の趣味でやってるサーバなのでやってないですが、複数ホスト間でいい感じにスケールしたりできるみたいです
- コミュニティの方が用意してくれているテンプレート等があるので、そこからgitlabやlet's encryptなんかをすぐに展開できる
ちょっと不満な点
rancherのイメージがなかなかでかい
- rancher-serverとrancher-hostを動かすだけで、アイドル時1Gくらいのメモリを持っていかれる
- 個人運用のサーバはこれが致命的(今回のサーバはそもそも2Gしかメモリがない)
- Rancher組み込みのLBに柔軟性がない
- SSL周り等を簡略化できるけど、HTTP/2に対応してなかったり、LBだけでリダイレクトできなかったりと機能不足と感じた
- 情報が(k8sとかと比べて)少ない
- あっても英語(ここでモチベと気力が結構持ってかれる)
まとめ
こまごましたところで不満は感じますが、それと引き換えに圧倒的に楽ができるというイメージです。
メモリに関しては、仕事ならそんなに気にならないと思いますが、個人でやってる身からすれば死活問題です。 もっとも、そもそも2Gというのがなかなかつらいので、そろそろ一つ上の4Gコースに変えようかなぁ...
GMT、UTC、UnixTimeって何が違うの？
この世界には時間が流れています
過ぎ去った過去は戻ってきませんし、すべての存在に等しく時は流れます
人の叡智は、そんな偉大で悠久の時をほぼ正確に刻む術を手に入れました。(水晶とか、原子とか、素粒子とか、光とか)
時のズレを検知して、地球上どこでも位置を測定することができるGPSは、時計測技術の極致とも言えます
時差
前置きはおいておいて...
この地球は時差が存在します
つまり、日本で朝9時でも、英国では真夜中の0時だったり…
要するに、日本で23時としても、英国ではアフタヌーンティーの真っ最中だったりする訳です
高度なリアルタイム通信網が地球全土を埋め尽くしている昨今、この時差はとても面倒です
なにせ、オンラインミーティングを15時からしようと決めていたのに、サンディエゴの同僚に電話したら「今何時だと思ってるんだ！」と、トラブルが起きるでしょう
(アメリカ太平洋標準時は日本標準時から-17時間)
それでは困るので、世界で統一的な基準となる時間という決まりが存在します
GMT
歴史的に海洋帝国として栄えていた大英帝国は、18世紀からその国内法で「グリニッジ天文台で太陽が南中する時刻を基準として標準時として扱う」と定められており、船乗りたちはそれをもとに生活をしていました
(流石に遠隔地では現地時間に合わせた生活をしていたようですが)
19世紀末には、電信等を使用する際の標準時として、グリニッジ標準時を基準として扱うことが国際的に決定します
つまり、
GMT = 「グリニッジ天文台で太陽が南中する時刻を基準にした時間」
と言えます
UTC
さて、それから技術は更に進歩し、原子にマイクロ波を浴びせたときに生じる振動を利用したり、光の波動によって作成された格子の中に原子を閉じ込めたりすることによって生じる振動などを利用したり、光の速度は常に一定という定理から「光が進む距離」を利用したりするなど、今では1京分の1秒の精度で時を測ることが可能になりました。
「じゃあ、それらを世界の時間の基準にすれば...」
確かに、微妙に観測しづらい南中時間より圧倒的に正確なんですが、少し困ったことに、地球の時点速度は地殻変動や潮汐力によって変動します
つまり、地球における1日という時間は、実は毎日微妙に違うという困ったことが分かってきました。
(実際に、大規模な地震で自転軸がずれて1日の長さが変わったり、潮汐力によって潮の満ち引きが起こることは有名です)
「これでは困る…けど、原子時計の正確さも欲しい…」
ということで、「セシウム原子を利用した原子時計を基準として、自転速度の変動によって起こる実際の南中時刻とのズレを、うるう秒を挿入することにより誤差±0.9秒以内に保つ」という決まりのもと協定世界時(UTC)が決められました
UnixTime
GMTとUTCは時刻ですが、一方でUnixTimeはコンピューター内部での時刻表現の一種です
現在ではコンピュータは必要不可欠で、コンピュータのない世界はもう想像できません
今日広く普及しているオペレーションシステムは、大体はUnixというオペレーションシステムの影響をとても強く受けています
このUnixは1970年頃に世に広く普及したのですが、Unix内部では「協定世界時の1970年1月1日0時0分0秒からの累計秒」で現在の時刻を保持する仕組みになっていて、これがUnixTime(または、Unix Epoch)と呼ばれる時刻表現の一種の決まりになっています
ここで重要なのが「協定世界時の」1970年1月1日0時0分0秒からの累計秒であるという点で、うるう秒等が差し込まれるとうるう秒の間だけUnixTimeの1秒は世界協定時の2秒になるという点
つまり、1998年の大晦日に差し込まれたうるう秒を例に上げると
世界協定時 1998年12月31日 23:59:59 → UnixTime 915148799
世界協定時 1998年12月31日 23:59:60 → UnixTime 915148800
世界協定時 1999年01月01日 00:00:00 → UnixTime 915148800
世界協定時 1999年01月01日 00:00:01 → UnixTime 915148801
ということになります
※UnixTimeはUTCやGMTと違い、条約や協定は存在しないため、システムによって実装が異なります
まとめ
- グリニッジ天文台を基準としたグリニッジ標準時(GMT)
- セシウム原子を利用した原子時計と、GMTを基準にした世界協定時(UTC)
- UTCを基準に、1970年1月1日0時0分0秒からの経過秒で表すUnixTime
時という一見計測しにくいものを、凄まじい精度で計測できるって、人間はすごい
白衣サーバーの構成
自分は白衣サーバというサーバーをConoHa VPS上で持ってますが、その構成についてちょっとメモ
スペック等
docker-composer.yml
version: "2"
services:
nginx:
image: nginx:alpine
container_name: nginx
ports:
- "80:80"
- "443:443"
volumes:
- "/home/kiridaruma/http/:/web/"
- "./nginx/nginx.conf:/etc/nginx/nginx.conf"
- "./nginx/conf.d/:/etc/nginx/conf.d"
- "/etc/letsencrypt/:/cert/"
links:
- php-fpm
- git
- bcdice-api
restart: always
php-fpm:
image: php:7.1-fpm
container_name: php-fpm
volumes:
- "/home/kiridaruma/http/:/web/"
- "./php-fpm/php.ini:/usr/local/etc/php/php.ini"
- "./php-fpm/www.conf:/etc/php-fpm.d/www.conf"
links:
- db
restart: always
db:
image: postgres:alpine
container_name: postgres
volumes:
- "./postgres/:/var/lib/postgresql/data"
ports:
- "5432:5432"
environment:
POSTGRES_PASSWORD: SECRET_PASSWORD
restart: always
git:
image: gitea/gitea
container_name: git
volumes:
- "./git/:/data/"
restart: always
bcdice-api:
image: ruby
container_name: bcdice-api
volumes:
- "/home/kiridaruma/http/bcdice-api/:/bcdice-api/"
restart: always
working_dir: "/bcdice-api/"
command: sh -c "bundle install && bundle exec rackup"
environment:
- RACK_ENV=release
各コンテナごとメモ
どうコンテナを組み合わせるのが良いのかは試行錯誤している最中なのでまだわからない。 ただ、今の所この構成が一番しっくりくる。
各ミドルウェアのconfig等はdocker-compose.ymlの直下に専用のフォルダを作って、それをvolumesでマウントさせるようにしいてる。
全体的なポイントとして、イメージはできる限り軽量なもの(alpine版など)を選ぶようにしている。
versionはよくわからない。
3まであるらしいけど、バージョンが上がると何が変わるんだろう？
とりあえず、今は2を使っている。
あと、restart: alwaysは大事。
(dnf updateを自動でする設定にしていて、Dockerの更新がかかって1週間ほどサーバが止まってたことがある)
Nginx
HTTPサーバ周りの軸になっている。
そのため、linksやvolumesがちょっと肥大化しつつある。(もうちょっとスッキリさせたいけど、仕方ないのかなと思いつつある)
他に特徴的なことといえば、TLS証明書はLet's Encryptで発行しているのでvolumesにその設定が入ってるくらい...?
PHP-FPM
本当はunixドメインソケットでNginxとのやり取りをさせたかったけど、何故かうまく動かない(おそらく、ソケットファイルの権限の問題)ので仕方なくtcpでやっている。 なんでも、unixドメインソケットのほうが効率が良いらしい。
ただ、各コンテナごとに環境が独立しているのでポート番号重複は全く考えなくて良いので少し楽。
DB(PostgreSQL)
自分はMySQL(MariaDB)しか使ったことがなかったけど、色々便利な機能が入ってるのでPostgreSQLにした。
今のところは使ってないけど、今後いろいろやる予定なので、それを見越して追加。
Git(Gitea)
外に出すのはマズイようなプロジェクト用。 個人でプライベートなGit(Githubライクな)サーバを持ってると、なかなか便利。
Gitサーバは
- バイナリファイル１つですぐ動かせるもの
- DBが必要ないもの
- 動作が軽めのもの
を考えて、GogsかGiteaか迷ったけど、Giteaを採用。
正直GogsとGiteaはほとんど同じだけど、何故かGiteaに(理由は覚えてない)。
BCDice-API(Ruby)
BCDice-APIは、TRPG用ダイスロールプログラム(ライブラリ)のBone&CarsをWebAPIとして動くようにしたもので、自分が開発しているOnset!用に使用している。
BCDice-APIはRuby製でSinatraで動いているみたい。
もともとimageはalpine版のRubyで動かそうとしていたが、bundle installでライブラリが足りなくてコケたので通常版(おそらくDebian)を使用。
ポートは9292で動いてるけど、どこで変えられるのか分からない。 とりあえず支障がないので9292で動かしている。
全体的なまとめ
Dockerは各コンテナごとに独立した環境があるのと、yamlでサーバの構成を書けるのでとても簡単で楽しい。
試行錯誤するときも、さっと試して動かなかったりエラーが出たりしたら直ぐに修正できるのもすごく楽。
ただ、journaldに大量のログが吐かれるので、そこでリソースを結構食われている。 逆に言うと、それ以外はそこまでリソースを食ってない。 メモリ2GBのサーバとしては結構うまく回せていると思う。
今後の改善点として
- 細々とした謎挙動の解決(unixドメインでNginxとPHP-FPMが繋がらない、BCDice-APIのポート設定等)
- 省メモリ化(各種configの調整)
- DockerやDocker-Composeの理解
を頑張りたいなぁと思っている。
このサーバーは仕事とかではなく、単純に趣味なので落ちても問題ないし挑戦できるのでとても楽しい。 メモリ2GBでこれだけやれるし、少ないメモリでいかに回すかを考えると結構面白い。
あなたも、VPSでサーバーを建てたいときはConoHaでどうですか？
ブログ移設について
今まで自前でWordpressを使ってブログをやってました。 が、サーバの移行をした際に何かが起こったらしく、ログインできなくなりました。 ということで、はてなブログに移行しました。
どうしてはてなブログか
という「なんとなく」で決めました。
実際に蓋を開けてみると、
というオチでした。
Wordpressになぜログインできなくなったか
もともと、WordpressのSQLite Integration というものを使用して、MySQLでなくSQLiteで稼働させてました。
ところが、サーバ移行(VPSのOS変更とDocker環境への移行)の際にSQLiteのプラグインの設定が壊れたらしく、DBエラーでログインできなくなりました。 コードを読んでもよくわからず、ggっても特に何もわからない(というか特殊ケースすぎて情報が出てこない)ので、思い切ってはてなブログに移行しました。
一応、ブログのシステムを自作しようとは考えたんですが、面倒なんで断念 (nodeでkoaを使ってゴニョゴニョしようと考えていた)
今後
今思えば、前のブログはほとんど更新してなかったなぁと思いつつ、
を書いて行こうかなと思ってます。
