Dockerで小さく社内サービスを動かすTips


最近(といっても1年前の話ですが)、本業の事務所内で使うサービスの実行環境をdockerに置き換えました。サービスは内製ではなくて、例えばgiteaとかのプロジェクト管理ツールとか、既成のもののことです。

今までKVMなどのハイパーバイザーVMで、Linuxイメージ作成→必要なサービスのインストールをしてましたが、dockerが扱えることで、ホストマシンがそこまで強くなくても動くサービスが増えそうだったので、思い切って(訓練としても)VM環境を全てやめてDockerに移行しました。

今動かしているサービスは、全部docker-compose.ymlを書いて管理してます。それをGitリポジトリで管理して、docker-compose.ymlが増えたり変更したりは世代管理しています。

Docker自体は何度か使ったことがあったのですが、日頃から動かす運用として気になったところをメモしておきます。


※2023-07-23 この時点で、docker-compose.ymlというファイル名ではなく、compose.ymlというファイル名が推奨になったそうです。しかし私も同行がちゃんと追えてないので、ここではdocker-compose.ymlとしています。 参考: 雰囲気でDocker Composeを触っている状態から脱するために調べたこと(2023) - Synamon’s Engineer blog

ホストマシンが起動したらDokerイメージも起動させる

ホストマシンを何らかの理由(メンテとか雷近いので安全を兼ねて)止めたあと起動したらDockerイメージも起動させたいです。これはDockerの機能としてあり、docker-compose.ymlにrestart: alwaysを書くと、ホストマシンが起動したらDockerイメージも起動するようになります。

もう一つの設定で、restart: unless-stopped がありますが、これは最後に手動でDockerイメージを止めたときには起動しないようになります。どちらかというとこちらの方が好みなので、いつもこの設定を書いてます。

バックアップをどうするか?

Dockerはコンテナ型の仮想環境と言われることがありますが、コンテナ環境(containerdとか)はまた別の話で、Docker自体は環境構築の手順を記述したものと認識してます。

なので環境自体は割と簡単に作ることができます(とりあえず触ったらできるようになったw)動いてよかったーとはなるのですが、そこで扱われたデータはどうするのかです。データの保管ができないと普段から扱うことは難しいです。

Docker自体にはイメージを動かした後にいい感じでデータは保持してくれません。ただデータの保管の仕組み(永続化)として、データボリュームという概念があります。 データの保管はホストマシンのストレージやホストマシンを経由してネットワークのデバイスへ渡すことができます。ホストマシンでネットワークストレージをマウントできれば大体は保存できると思います。

【Docker】Data Volumeで永続データを扱う | amateur engineer's blog

事務所にはNASがあるので、ホストマシンからNFSでマウントして、そこにデータを保存するようにしました。NFSのマウント自体は/etc/fstabに書いておけば、ホストマシンが起動したら自動でマウントされるようになります。

ここまでが、普段使うサービスのデータの保管方法です。次にそのバックアップをどうすればいいかです。NASのバックアップシステムの恩恵もある程度は受けられますが、データの定期的なバックアップは一応欲しくなります(多重化の意味合いでも)

これは普通にバックアップのソリューション的なものがあればそれを使うでよさそうでしたが、Dockerイメージを止めないで動いているサービスのデータをバックアップするのはちょっと怖いです。

これは定期的なサービス停止→バックアップタスクを実行 を行えば良いです。そのアイデアをDockerで一緒に行えるDockerイメージがあったのでご紹介。

GitHub - offen/docker-volume-backup: Backup Docker volumes locally or to any S3, WebDAV, Azure Blob Storage or SSH compatible storage

こちらのDockerイメージを使うと、Dockerのサービスを止めてデータボリュームを世代バックアップを行い、その後またDockerサービスを起動するということができます。 まさに欲しかったもので早速使ってみてますがいい感じです。

NASに毎日バックアップが取られるようになりました。普段の運用的には毎日1週間ぐらいあれば十分と判断しているのでこのぐらいにしてます。サービスのデータが重いと時間もそれなりにはかかってしまいますし。

細かいTipsですが、複数のDockerイメージをバックアップするときは、ラベル分けを行う必要があります。サービスごとにラベル名を用意すれば大丈夫でした。

※この方法は、このイメージ公式の方法です。composeのラベル自体は汎用的なオプションで、バックアップDockerイメージ側がそのラベルをみて対象を判断しているそうです。汎用的なラベルの意味については以下を参考
参考: https://docs.docker.jp/v1.12/compose/compose-file.html#labels

Dockerの状態をGUIで見る

PortainerというWEBサービスを使ってみてます。OSSのKubernetesクラスタの監視ツールらしいです。ビジネス版もありそちらは有料。CE版がOSSです。

portainer/portainer: Making Docker and Kubernetes management easy.

これは特段と困る話はないのですが、Dockerコマンドを使って作業しなくても、GUI上からDockerイメージへコマンドを動かしたり、ログを見れたりする便利ツールです。

Dockerコマンドをある程度覚えたのであんまり必要はないのですが、やっぱりこういうのを入れたくなる性分でしてw

まとめ

バックアップと日頃の状態がすぐにみられるとサービス運用する上では問題なくなると思います。このほかにも、Dockerのサービス提供はポートベースなので、それをどうにかする話もやりたいですね(いわゆるリバースプロキシちゃんと分ける話)

Dockerこわい怖いと思ってましたが、扱えるようになるとこの上なく便利だなーと思いつつ、最近触れてなかったので、次は内製サービスを動かすときのDockerイメージを作ることをトライしていこうかと。

(実は今普通にKVM自体が欲しい状況だったりして、DockerとKVM同時に動かすことができるのか考えています。ネットワーク周りでハマりそうな話があったのですが、もうちょっと調査しつつです)