いまさらDocker

俺は政治的な思想に関しては保守なんかクソくらえゴミとしか思ってないんですが、こと技術に関してはかなり保守的だったりする。

で、いまさらDockerに入門するなどしたので、その過程で気になったこととか。

Docker入門

世の中のDocker入門記事、Dockerに関するポエムを書いてるだけで実際に必要な運用面の話がなかったりするので、そういうのを書きます。

(使い方なんか公式ドキュメント読めばいいし、コンテナの理屈や仮想化方式の違いなんか1回聞けば分かるでしょ？どいつもこいつも同じ話ばっかりしやがって、ねぇ？)

ちなみに単一の物理/仮想サーバーにDocker Engineをインストールして自分で運用するという状況での話です。GKEみたいなマネージド環境で同じ話が当てはまるかは知らない。

念のため、この記事を書いているのはいまさらDockerに入門したド素人であることをお忘れなく。

運用関連

まずはコンテナより外側、OSとか運用の話

ホストOS

ホストOSは普通にUbuntuとかDebianで良いんじゃないかと思う。

世の中にはCoreOSみたいなコンテナ専用OSとかあるけど、普通のOSと色々違って癖が強い。

Dockerを学びたい訳であって、コンテナ専用OSについて学びたい訳ではないので普通に使い慣れたOSで良い。

まぁなんでも好きなものを使えばいいです、LinuxでDockerを動かしてしまえばそこから先は全部一緒。

GUIは要らない

最初はPortainerみたいなGUIツールで使いたいなと思ったりしますが、実際にやってみるとあんまり便利じゃなかったりする。

なんだかんだサーバー上でコマンド打ったりファイルを編集したりすることの方が多いので、GUIツールで操作できてもそこまで嬉しくない。

GUIで出来ることはコマンドでも出来るし、GUIオプション選ぶよりコマンドライン引数で渡すほうが楽だったりする。

コンテナのアップデート

コンテナイメージが更新された時はdocker pullでイメージを再度pullして、コンテナをrm->runで作り直せばOK。

……というのを手動でやるのはダルい、Unattended-Upgradesみたいなのが欲しくなってくる。

これに関してはWatchtowerというOSSがあるので、それを利用すれば自動更新できる。

(もちろんアップデートするスクリプトをcrontabで定期実行してもOK)

イントラで使ってるだけなら気が向いたときに更新したのでも良いとは思う。

バックアップ

バックアップは非コンテナ時と同じ。

ファイルをrsyncでコピーしたり、データベースならmysqldumpでダンプしたり……

コンテナといえども所詮はプロセスなので、いつもと同じようにファイルコピーでバックアップしたのでOK

コマンドはホストOS側から実行する方が良いと思う、コンテナ側だとコマンドがない時があるので。

(上で「ホストOSはUbuntuとか普通のOSで良いんじゃない？」と書いたのはこういう理由もある)

監視

Dockerサーバーのホスト側にzabbix-agentなどをインストールしたので良いと思う。(もちろんZabbix以外でも同じ)

特権を与えたコンテナでzabbix-agentを動かしてもいいけど、エージェントでシェルスクリプトが動作するときになどにコマンドがなくて困ったりする可能性があるのでホスト側に入れた方が素直で分かりやすい。

コンテナで動かしてるとHDDのSMARTとかCPUのセンサー情報取りたい時どうするんだ？みたいになる。そもそもHDDやセンサーというホストに依存する物をコンテナで扱うのは違う気がするし。

Kubernetesやらなきゃダメ？

ネット見てると発言力の強い人たちがコンテナ=Kubernetesかの如くKubernetes連呼してるので勘違いしがちだけど、無理にKubernetesでやる必要はないと思う。

最初は普通にDockerをやったので良い。サーバーが複数台あったり、大規模なアプリケーションになってきたりしてDockerだけで扱うのが難しくなってきてからKubernetesを始めたのでも遅くはない。

非Kubernetes(Dockerだけ)でコンテナを運用してる人だってたくさんいる。そういう人達は発言力がないので、非Kubernetesの話が聞こえてこないというだけ。

強い人の発言力が大きくなりがちだから、そうでない人の声が聞こえてこなくなって、「このくらい出来て当たり前」みたいに感じて苦しくなったりする。これインターネットの悪い所。

強い人の意見だけで生きてたら「出来るのは当たり前」みたいに感じたりするけど、そんな事はない。出来ない人だって世の中にはたくさん居る。意味のない比較で苦しむのはやめましょう。

……って、そんな事を話してるんじゃない。

自分の環境がGKEみたいなKubernetesを簡単に使える環境ならKubernetes使った方が良いと思うけど、そうでないなら無理しなくてもいい。必要になってからでOK

コンテナ関連

次はコンテナの内側、設定とかの話。

タイムゾーンどうするの？

じみ～～～に厄介なのが、コンテナ内のタイムゾーンの設定。

まず最初に試したいのが、環境変数でTZ=Asia/Tokyoを渡す方法(docker run -e TZ=Asia/Tokyo)、公式コンテナ系だと上手くいく物が多い。

それでダメなら、動かそうとしているアプリケーションにタイムゾーンを指定するオプションがないか確認する。アプリケーションによってはOSとは別にタイムゾーンを設定できたりする。

それでもダメなら、ホスト側の/etc/localtimeや/usr/share/zoneinfo/Japanをコンテナ内の/etc/localtimeにマウントしてみる。

これでダメならコンテナに直接手を加えたり何かをインストールしたりする必要が出てくる。それかUTCのまま使うか……

設定ファイルどうやって配置するの？

設定ファイルを配置したいときは、ホスト側にファイルを配置してからコンテナにマウントするのが簡単だし分かりやすい。

アプリケーションによっては設定ファイルではなく引数で渡せたりする(MySQLとか)。それで問題ないならそれでもいい。

コンテナによっては他の方法が使えたりもする。

コンテナ起動してから中に入って書き換えたりはしない。

設定ファイルの管理はどうするの？

設定ファイルはGitで管理するとイイカンジ。

設定ファイルやdocker-compose.ymlを一緒に同じリポジトリに入れてGitで管理する。

ホスト側でgit pullして必要ならコンテナ再起動するだけ、サーバー入れ替えになってもgit pullしてコンテナ起動で完了。

バージョン管理できるから不具合があってもGitの機能で設定を元に戻すだけ。

つまり

「ゆるくやりましょう」

 - サーバー Docker