Dockerの役割と管理主体
こんにちは、シニアソフトウェアエンジニアのriddleです。このポッドキャストは、IT業界の話やキャリア、自分たちの困った話、またマネジメントや採用みたいな、いろんな話についてしていくポッドキャストになっています。
今回は、Dockerってアプリエンジニアとインフラエンジニアのどっちが対応するものなんだろうという疑問がね、流れていたので、回答したいと思います。
自分のスタンスとしては、両方できる方がいいよねっていうのが答えです。 その上で、Dockerがどこの部分を指しているのかによるんですけれども、ちょっと深掘って見ていきたいと思います。
開発の現場におけるDockerっていうのは、Dockerファイルがあって、あとは開発環境上で動かすDocker Composeのファイルだったり、実際のDocker Runのコマンド、
またその作ったイメージを格納するイメージのレジストリだったり、それを起動する環境ですね。 AWSだったらECSとかEKS、
Google CloudだったらCloud RunとかGKEとかありますよね。 もしくはDockerを自力でホスティングしているような環境あるかもしれませんが、そういう場合だったらそこの環境の用意もあると思います。
では一つずつ見ていきましょう。まずDockerファイルを用意するのは誰かっていう話になるんですけれども、これは規模とかにもよるような気がしていて、
ある程度例えばDockerファイルを共通化して運用しているとか、共通利用するものがあるみたいな場合は、インフラとかSREとかプラットフォームエンジニアリングチームがやったりすることはあると思いますが、
まあ別にバックエンドとかアプリケーションのエンジニアがやっても全然問題ないかなと思いますね。
所詮ベースイメージを指定して、パッケージ指定して、自分たちのソースコードを置いて、ビルドしたりコンパイルしたりとか、いくつかの作業を含めた上でイメージを作るというだけの話なので、
そんなに難しい話でもないですし、どっちでもいいんじゃないかなと思います。 また開発環境でDocker RunをするとかDocker Composeをするっていうのは、
もうバックエンドエンジニアが全部やればいいんじゃないかなと思います。 自分たちで使うデータベースとかその他のレジスとかね、そういうものをアップして
Docker Composeとして一緒に立ち上げるみたいなことは自分たちがやりやすいようにやればいいかなと。 そこからイメージのレジストリに送るところのパイプラインとか、
イメージレジストリの管理みたいなところはインフラチームにお願いしていいかなと思います。 やっぱりコンテナのイメージをこううまくセキュアに担保するというか、
イメージのスキャナーで脆弱性がないかをチェックしたりとか、Sボムみたいなものをチェックしてみたいなものとか、いろいろ考えることはセキュリティ上あったりするので、
そういうところまでバックエンドエンジニアとかプロダクトを作っているエンジニアがチェックしようと思うと結構大変なので、そこからは任せてよいかなと思います。
続いてそこから先のデプロイですね。 これもチームの規模にもよるんですけども、インフラとかSREというチームがいればそこにデプロイを任せていいかなと思います。
Kubernetesみたいな話になってくると、ドッカーじゃなくてコンテナでやつで動かすんで、基本ドッカーを管理するってことはないんですけれども、
そこでねうまく起動できるようにするとか、Podの設定をするとか、そういったところは基本的にはインフラのチームがやっていいんじゃないかなと思います。
部分的にね、環境変数とかパラメーターとかそういうものを指定するところだけバックエンドエンジニアがやるっていうのもありかなと思うので、
そういう区分けがいいんじゃないかなと思います。 ということで今回はドッカー、もしくはコンテナですかね、その文脈においてどっちのエンジニアがどこやるんだ
Dockerの重要性と挑戦
みたいなところの区分けがよくわかんないよという内容を回答しました。 ドッカーはいろんなレイヤーに足を出していて結構複雑なように見えますし、
実際複雑なんですけれども、現代のソフトウェア開発においては必須のツールとなっているので、どの分野のエンジニアであったとしても構造を理解して使えるようになっていく
っていうのが一番良いかなと思います。 どっちが良いかで揉めてたら自分で巻き取ることで自分の評価も上がると思うので
ぜひ挑戦してみてください。 このポッドキャストはハッシュタグLITで皆様からの感想やコメント募集しております。
またチャンネルの概要欄にありますgoogleフォームのリンクからもコメント募集しています。 ありがとうございました。
