cronファイルの設定をコンテナ内ではなく、ホスト側でファイルを持って行うことに対してのメリットが理解できておらず、自分なりに調べてみたのでその備忘録
コンテナ内でcronファイルを編集する場合
コンテナ内でcronファイルを編集する場合は、コンテナに入りcronファイルを編集してcronデーモンの再起動し、設定を反映という手順を踏む。
ホスト側でcronファイルを編集する場合
ホスト側でcronファイルを編集する場合は、crontabファイルを作成して、そこに設定を記述します。そして、Dockerfile内でホスト側のcrontabファイルの内容をコンテナ内のcronファイルにコピーすることで設定を反映させる。
ホスト側でcronファイルを編集するメリット
これらを踏まえて、ホスト側でcronファイルを編集するメリットを出してみる。
- バージョン管理
- 再利用
- ビルドでの自動反映
バージョン管理
crontabファイルをGitなどのバージョン管理などで、ホスト側で管理することでファイルの変更履歴や差分の確認を行うことができるようになる。
そして、Dockerfile内ではCOPYコマンドを使用して、ホスト側のcrontabファイルの内容をコンテナのcronファイルにビルド毎に反映させる（変更を反映というよりは、毎回新規にファイル作成）ので、ビルドすることでコンテナ内のcronファイルを直接変更した結果よりもホスト側のファイル内容が優先されます。そのため、意図しないコンテナ側での変更も即座に修正できる。
再利用
同じ記述のcronファイルなら、その他のコンテナでも再利用できそう。
ビルドでの自動反映
前述で述べた、コンテナ内で編集する方法とホスト側で編集する方法のやり方の違い。
コンテナ内でcronを編集するとcronデーモンの再起動とビルドの両方を行う必要がでてくるが、ホスト側で編集を行うとビルドを行うことで、コンテナ内のcronファイルに設定が反映される。
Dockerfileの設定はホスト側のcrontabファイルのパスとコンテナ内のcronファイルのパスを記載してCOPYコマンドで記述する。UNIX/LINUXシステムに合わせて、改行の書式も変更した新しいcrontabファイルを作成。パーミッションの設定なども行い、コピー元のcrontabファイルを削除。ビルドでの自動反映が行える。
さいごに
これらを踏まえるとホスト側で管理する方が圧倒的に良いですね。
個人的な備忘録で理解に間違いなどあるかもしれませんが、その際はお手柔らかにお願いします！！
その他もなにかメリットがあるのでしょうか。。？