最近（といっても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イメージがあったのでご紹介。
こちらの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
- Portainerを使ってDockerコンテナの管理環境をつくってみた｜トレンドコラム｜GPUサーバープラットフォームの設計/構築なら「技術力」のNTTPC
- 参考: Portainer〜OSSのコンテナ管理GUI〜 | OSSのデージーネット
まとめ
バックアップと日頃の状態がすぐにみられるとサービス運用する上では問題なくなると思います。このほかにも、Dockerのサービス提供はポートベースなので、それをどうにかする話もやりたいですね（いわゆるリバースプロキシちゃんと分ける話）
Dockerこわい怖いと思ってましたが、扱えるようになるとこの上なく便利だなーと思いつつ、最近触れてなかったので、次は内製サービスを動かすときのDockerイメージを作ることをトライしていこうかと。
（実は今普通にKVM自体が欲しい状況だったりして、DockerとKVM同時に動かすことができるのか考えています。ネットワーク周りでハマりそうな話があったのですが、もうちょっと調査しつつです）