Dockerfileの置き場所・管理場所を色々考えた
- Dockerfileをどこに置いて誰が管理するのが良いのか？という話
- Dockerを導入する前の構成
- Docker導入初期
- 中央管理により発生する問題
- アプリケーションのレポジトリに置くことにする
- 今後
- まとめ
Dockerfileをどこに置いて誰が管理するのが良いのか？という話
結論から言うと、各アプリケーションのレポジトリ直下に置いて置けばいいのではないか、と言うのが現状。
そんなん当たり前だろと思った方はそのまま読み飛ばしていただいて、自分の思考の備忘もかねて。
チーム構成とか、開発やデプロイで使っているツールとか、アプリケーションの数でこの辺りの判断は変化しそうだけど、自分がインフラエンジニアの立場として考えていたことをまとめていく。
Dockerを導入する前の構成
Dockerを導入する前は、サーバーの構成管理をansibleで行なっていた。
そのため、すべてのアプリケーションの構成情報は一元管理されて一つのレポジトリでインフラエンジニアが管理する形だった。
Docker導入初期
Dockerを最初に導入した時にはansibleの構成をそのまま引き継ぐことに。
つまり、各Dockerfileを一元管理してインフラエンジニアが責任を持ってメンテナンスするところから始まった。
サーバーを作るのはインフラ側の仕事だし、突然構成管理をDockerfileで開始するからアプリケーション側で持ってね、って言ってもそれはただの無茶振りになる。
各アプリケーションが利用するフレームワークがRuby on Rails一つで、一種類のDockerfileで全部カバーできたと言うのも一つの理由。
また、Dockerの初期導入はテスト環境から始めることが多い気がするが、テストやビルドのスクリプト自体も自作して一元管理していたため、Dockerfileもその流れで一元化されたのは割と自然な流れだったと思う。
中央管理により発生する問題
Dockerfileの多様化
当初は一種類でまかなえていたDockerfileもアプリケーションが複雑化する中で多種多様になってくる。
そうなると色々な種類のDockerfileを用意する必要が出てくる。
特に最近はやりのマイクロサービスみたいな構成になってくると結構種類が増える。
インフラ作業が律速になる可能性
上記のような状態になると、XXXと言うミドルウェアを利用したい、とか、xxxという言語で次のアプリを書きたいと言った要望毎に、Dockerfileを更新する作業が発生する。
時間がある時にはいいのだが、障害続きのようなタイミングだと開発サイドを待たせてしまうことになりかねない。
アプリエンジニアのDocker知識がつかない
今後は、Dockerで開発をすることが当たり前になると思うので、組織としてレベルを上げるならこういった懸念も生まれる。
アプリケーションのレポジトリに置くことにする
といった流れで、アプリ側にDockerfileを置くことにした。めでたし。
デメリット
とはいえ、デメリットはそれなりにあると思っている。
各自が自由にできるので、、、
一番の心配はこれ。
今まで管理していたOSやパッケージ周りを手放す不安。
まあでもこれは大丈夫。
開発サイドとよっぽと仲悪くない限り。
Dockerfile編集したらpull requestこっちにもレビュー送ってねーとか、そういったコミュニケーションができていれば全く問題ないと思う。
まあそもそも専売特許でもないので、みんなで管理したらいいと思う。普通に。
重複部分が生まれる
Dockerfileが各所にあるのでどうしても重複する箇所が生まれる。
一斉に編集できない
OSやパッケージ周りで何か問題があった時に、全てのアプリのDockerfileを一斉に修正する手間が大きくなる。
ただし逆に言えば、影響範囲を最小限に抑えて段階リリースできると言うメリットとも言えるので、一長一短。
今後
重複部分が重なる問題に関して、ある程度のレイヤーまでは作られているDockerfileを一つ作ってもいいかなと言う気はしている。
少なくとも、OSと根本的なパッケージ、アプリを動かすユーザーとアプリを置くディレクトリくらいはよっぽどこのことがない限り一緒のはずなので、それは独立して一つ作っても良さそう。
各アプリはそれをFROMで指定してから、あとは自分たちのオリジナルの記述を書いていく形で。
まとめ
という感じで、アプリケーション側にDockerfileを置くことにした。
何より開発側のエンジニアが興味を持ってDockerについて聞いてきてくれたりするのが地味に嬉しかったりする。
