1. はじめに
dockerやdocker-composeを使って、チームで使うサービス(re:dash）を運用したら、
バージョンアップとかガンガンできるだろうし、バックアップもリストアも自由自在ヒャッハーできるしょ！
と思って使いはじめたが、やりたいことができずきハマった、データ保存先について整理した記事です。
”保存”に特化しているため、dockerがほかの仮想マシンと比較してどうかなどの、メリットとデメリットなどを記載はしません。だって面倒くry。
この記事を読むと、dockerのデータを”保存”しているのか、イメージを理解できようになります(たぶん)。
2. dockerがデータを"保存"するモノとは
データを”保存"する「イメージ」「ボリューム」「コンテナ」の概念について、まとめます。
概念が違うものなので、並べることが適切ではないかもしれませんが、保存を理解するためには必要なので、並べて書きます。
※ Dockerfile, docker-compose.yml と記載したものは設定ファイル名の例です。
実際には変更が可能なため、正しくありませんが便宜的に上記表現で記載しています。
2.1 イメージ
Dockerfileで定義された、「docker image」で管理される領域、またはDocker Hubなどのサービス可能に登録されたものです。
どのような構成、何をインストールしておくか、といったことを”保存”できます。
2.2 ボリューム
データを"保存"するデータ領域のことを指します。ボリュームといっても、コンテナ内部(Dockerfile volumeコマンドなど）と外部マウント(docker run -v xxx:yyyy）の２つのことが混同されて記述されている記事があるため、注意が必要です。
外部マウントのボリュームは、dockerサービス内で定義されたボリューム(docker volume createや他のコンテナのボリュームなど）と、dockerのホストのデータ領域の、いずれかを指定することができます。
簡単な図にまとめると、以下のようなイメージです。
※注意 正確にはボリュームをマウントする指示をせずに実行した場合には、dockerのvolumesに実体が作られ、--rmオプションなどがついてると自答削除できるので、図ではわかりやすさのため、コンテナ内にあるように歪曲して記載しています。
2.3 コンテナ
イメージに対して「docker run」を実行して作られる、コンテナとよばれるインスタンスのことを指します。
このインスタンスには、起動中、停止中の状態をもち、docker start, docker stopなどで、開始、停止をコントロールできます。
起動中の場合に、イメージで作ったサービスが利用できるようになります。
起動時に、マウントする先を明示的におこなっていない場合、コンテナで作成されたボリュームは、起動したコンテナが削除されるまで”保存”できます。その状態で、うっかり、「docker rm コンテナ」としてしまうと、
保存されたデータが削除され、泣くことができます。
3 データの保存先について（考察）
サービスとして提供するのであれば、dockerのボリューム領域（docker volume createで作った領域）か、ホストのデータ領域を使うのが賢明だと思います。
ただし、dockder for windows (desktop 2.3.0.3, engine 19.03.8, compose 1.25.5)では、
ボリュームに対して権限を設定しようとするとうまくいかない不具合があるため、アプリによっては、dockerのボリューム領域を使う必要があります(postgresの公式イメージのdataフォルダなど)。
そのため、現状でバックアップまで考えた運用については、ホスト領域とdockerのボリューム領域をマウントして、コピーするだけの仮想コンテナを作ってあげるなど工夫が必要そうです。
※ 実はそれでも権限周りはいけてなく、現状ではlinuxの上に構築するほうが無難です。
4 おわりに
dockerについて勉強をはじめて、1か月たたない初心者なので、もし間違いがあったら、指摘をお願いします。