⚓

Dockerって何？って聞かれたときの解説、の解説

2021/05/25に公開

8件

Docker

tech

Discussion

kaya

いつも有用な記事ありがとうございます。
誤字報告です。

Write onece, Run anyware → Write once, Run anywhere
2箇所DockerがDokcerになってる

なんでZennは編集リクエスト機能ないのだろうと思ったら、
記事がGit管理だからそっちに訂正投げてくれってシステムなのですね。
私がこの記事のRepository見逃してたらすみません。

koduki

読んでいただきありがとうございます！＆誤字の指摘ありがとうございます。修正しました。
なるほど、編集リクエストが無いのはそういう。。。私はGithub管理にはしてなかったですがそっちのが良いのかな

inductor

いくつか気になったことがあるので書き残しておきます。

WindowsコンテナはOCI互換ではないかのような記述が見受けられますが、間違っていると思います。こちらのドキュメントのrunhcsの箇所を御覧ください。
もう一つ重要な点としてDockerは具体的な実装としてのDockerとは別にOCI系コンテナの総称としても使われます。例えば本番環境でDockerを使う事はそんなに多くなく実は別のコンテナを使ってるのですが便宜上「Dockerを使ってる」と言ったりします。とありますが、私にはあまり分かりませんでした。これって具体的にどういう環境のことでしょうか？
k8sは本質的にPaaSなどのクラウド環境を作る基盤という特性が強いので自力で運用しようとするとかなりのパワーを使います。そのためKNative/Cloud RunやHerokuのようなPaaS/CaaSレベルに仕立てたものかFargateやGKE Autopilotのようにフルマネージドなk8sとありますが、Cloud RunとHerokuはKubernetesベースなんでしょうか？自分は知らなかったので、もし参考文献があったら知りたいです。それからKnativeに関してはSelf hosted clusterにデプロイするのであればクラスター運用は避けられないのでここでの言及は不適切に思いました。
cri-oはその登場経緯からしてk8sで動かすことを目的として作られました。そのため軽量でk8sで動かすことに特化しているのでやはりこちらも本番環境で人気があります。CRI-Oの本番利用例をOpenShift以外の文脈で聞いた覚えがないのですが、どこかで事例発表があったのであれば知りたいです。私の知る限り少なくともGKE, EKS, AKSではContainerd/Dockerがサポートされている認識です。
FirecrackerはランタイムではなくMicroVM技術です。コンテナを動かすための方式、という表現もミスリーディングだなと思いました。ref. Firecracker はコンテナランタイムではありません

全体的に主観で書かれているのか事実に基づいているのかがわからない箇所が多く、参考文献等があると嬉しいなぁと思いました（勘違いだったらすみませんが、私が過去に作成したスライドや文章によく似た箇所がいくつかあるなと思ったので、念のため）

koduki

コメントありがとうございます。いつも記事拝見させて頂いています。

WindowsコンテナはOCI互換ではないかのような記述が見受けられますが、間違っていると思います。こちらのドキュメントのrunhcsの箇所を御覧ください。

厳密に言えばWindows ContainerというOCIに準拠したWindowsのコンテナもありますが、これは逆にWindowsでしか動かないのでそこまで利用はされていません。（OCI準拠かはさておきWindowsの内部では割とコンテナは使われてます。WSL2とかDefender Application Guardとか）

たぶん、こちらの記述ですよね？ WindowsコンテナがOCI互換ではないと書いたつもりはなく、多くの人は（VMのイメージで）Linuxが動くことを期待するだろうから「OCI準拠のWindowsコンテナ」はあまり使われていない、という意図でした。実際、Docker/k8sで「Windowsコンテナ」を積極的に使ってる事例はあまり知らないので。個人的にはちょっと興味もありますが。
その上で括弧の中でOCI準拠かさておき。。と書いてるのはWSL2やDefender Application GuardはWindowsのコンテナ技術を利用していますがそのAPIがOCIに準拠してるかは確認できなかったからです。その必要が無いので違う気がしていますが未確認なので少しあいまいな表現をしていました。いずれにしても「Windowsコンテナ」がOCIに準拠してないまがい物だ、的な意図は無いです。その点は私の表現力の問題ですね。

以上が執筆時点での認識ですが、共有頂いたドキュメント読むとhyperv isolationでLinuxを動かしたときもOCI準拠という扱いになるのですね。この構成があることは認識してましたがコンテナ単独ではないのでそれそのものはOCI準拠ではない（正確にはVMの上のLinuxでOCI準拠のコンテナを動かしている）と認識していました。OCIって別にコンテナに限定しないのですね。これは私の不勉強です。ご指摘ありがとうございます。ちょっと記事をよく読んで本文の表現考えます。

２．もう一つ重要な点としてDockerは具体的な実装としてのDockerとは別にOCI系コンテナの総称としても使われます。例えば本番環境でDockerを使う事はそんなに多くなく実は別のコンテナを使ってるのですが便宜上「Dockerを使ってる」と言ったりします。とありますが、私にはあまり分かりませんでした。これって具体的にどういう環境のことでしょうか？

自分の認識ではGKEでは少なくとも1.19以降はcontainerdですしOpenShiftはcrioですし、それ以外でもcontainerdはk8sでのランタイムとして広く使われている認識です。そうした 「k8sで利用しているランタイムがDockerではない環境」 でも「本番でDockerを使っている」と言う事はしばしばあると思います。これは正しい表現では全くありませんが発言者が認識してなかったり、便宜上よりOCIやcontainerdより浸透している言葉である 「Docker」 という単語を選ぶことはしばしばあります。良し悪しは別として。なので 「OCI系コンテナの総称としても使われます」 と記載しました。

ただ、特に統計とか取ったわけでもなく単純に身近な事例からコメントしたので、現時点ではほとんどのk8s環境はdockerをランタイムとして使っているなら書いてることと違うのでそこは訂正したいと思います。

k8sは本質的にPaaSなどのクラウド環境を作る基盤という特性が強いので自力で運用しようとするとかなりのパワーを使います。そのためKNative/Cloud RunやHerokuのようなPaaS/CaaSレベルに仕立てたものかFargateやGKE Autopilotのようにフルマネージドなk8sとありますが、Cloud RunとHerokuはKubernetesベースなんでしょうか？自分は知らなかったので、もし参考文献があったら知りたいです。それからKnativeに関してはSelf hosted clusterにデプロイするのであればクラスター運用は避けられないのでここでの言及は不適切に思いました。

Cloud RunはKNativeベースなので普通に考えればバックエンドはk8sかと思います。

Herokuは残念ながら知りませんが恐らくdynoを動かしてる基盤をベースにしてると想像できるので別な気がしますね。

ただ、ここで言いたかったのはk8sをセルフホスティングして運用する以外にも**「コンテナの運用」** をする方法がある、と言いたかっただけでk8sのマネージドサービスであるか否かは問題にしていません。コンテナの活用とk8sの運用を常にセットの組み合わせと考えて欲しくなかったからです。

KNativeがクラスタ運用不可避の観点はおっしゃる通りですね。書きながら「アプリのデプロイが簡単」というアプリの視点と「インフラの運用が簡単」というインフラの視点がちょっと混ざってましたね。筋がぶれるのでこれは消しときます。

cri-oはその登場経緯からしてk8sで動かすことを目的として作られました。そのため軽量でk8sで動かすことに特化しているのでやはりこちらも本番環境で人気があります。 CRI-Oの本番利用例をOpenShift以外の文脈で聞いた覚えがないのですが、どこかで事例発表があったのであれば知りたいです。私の知る限り少なくともGKE, EKS, AKSではContainerd/Dockerがサポートされている認識です。

私もOpenShiftくらいしか言われてみると知らないですね。 OpenShiftという一応メジャーなプロダクトで利用されているからの表現でしたが、OpenShift自体がGKE, EKS, AKSに比べて利用例が少ないので「人気があります」と言う表現は誤解があるという事ですかね？　特段containerdより使われてるとか言う意図もありませんし修正しておきます。

FirecrackerはランタイムではなくMicroVM技術です。コンテナを動かすための方式、という表現もミスリーディングだなと思いました。ref. Firecracker はコンテナランタイムではありません

これに関してはおっしゃる通りランタイムではなくMicroVMだと思ってますし書いてるつもりですね。
> micro-VMとも呼ばれる非常に小さなVMを起動しその上でコンテナを動かすのに必要最小限のLinuxを動かす方式
ミスリーディングを誘いたいわけではないので懸念されてる部分は訂正したいのですが、「コンテナを動かすのに必要最小限のLinux」が正確ではないとかでしょうか？

＞全体的に主観で書かれているのか事実に基づいているのかがわからない箇所が多く、参考文献等があると嬉しいなぁと思いました（勘違いだったらすみませんが、私が過去に作成したスライドや文章によく似た箇所がいくつかあるなと思ったので、念のため）
参考文献は確かにあった方が良いですね。後ほど可能な範囲で足しておきます。今回の動画及び記事作成で意識的にinductorさんの記事やスライドを参照したところは多分なかったと思いますが、むしろ普段から読ませて頂いてるので結果として似たところはたくさんある気がします！

以上、修正は後ほどやりますが取り急ぎコメントだけ。

inductor

Cloud RunはKNativeベースなので普通に考えればバックエンドはk8sかと思います。

憶測の域を出ないのでなんとも言えないなというふうには思いました。例えばgVisorはOSSではOCI compliantなランタイムですが、Googleの内部ではOCIではないランタイムとして動くような匂わせをする文献をいくつか見かけたことがあります（ちょっとすぐには思い出せませんが）。また、BorgもLinux containerではあったとしてもOCI互換かどうかまでは少なくとも公開資料には出ていないので、この点においてGoogle内部で使われる技術と外に出ている技術が一致するとも限らず、私は少なくとも断言できないものであると考えています。

koduki

一応下記を見るとCloud Run on AnthosはKNativeをGKE上で動かしてるようですね。
https://cloud.google.com/anthos/run

とはいえフルマネージド版をどうしてるかは確かに言及がないので、そちらはKNativeのI/FでBorgを動かしてる可能性は確かに否定はできないですね。Anthos向けにCloud RunなどK8s互換のI/Fは推し進めてるようには見えますが、Googleならマネージド側はユーザ向けI/Fだけ互換にして中身はBorgとOmega（今もOmegaが最新かは知らないですが）で動かすとか普通にやりそうな気もしますし。

Hiroshi Koyama

有用な記事をありがとうございます。拝見して、「Java EEとかに慣れてる人だったら「war=docker, k8s=weblogic/glassfishととりあえず思ってください」という事が多いかな。」に違和感を覚えました。

war=docker の部分がファイルアーカイブ=ソフトウェアとなっているからだと思います。あと、k8s=weblogic/glassfish は前者の右辺と左辺に対しての対応が違っていないでしょうか。

Java だったら、jar は Docker イメージ、JavaVM が Docker というメタファが使えそうですが、war は難しいですね... たとえば、war(JavaEEだとear?)=Docker イメージ、war を動作させるために必要なもの=Docker、war アプリを管理するために必要なもの=k8s といった対応とかでしょうか。

war を動作させるために必要なものは「JavaVM+アプリケーションサーバの war 実行用機能」、war アプリを管理するために必要なものは「アプリケーションサーバの war 管理用機能」でしょうか。とすると、とりあえずということなら、「ear=Docker イメージ、glassfish=Docker、OpenShift=k8s」あたりでも良いのかもしれません。

koduki

war(あるいはear)=dockerの部分はDockerイメージで書いていたのでファイルアーカイブという意味では同じですね。ただ普通に文章が分かりづらいですね。力不足です...

war(JavaEEだとear?)=Docker イメージ、war を動作させるために必要なもの=Docker、war アプリを管理するために必要なもの=k8s といった対応とかでしょうか。

なるほどですね。はい、概ねおっしゃるイメージで、もう少しいうとwar/ear=Dockerイメージ、warを動作させるのに必要なもの(JVMやGrizzlyとかWeldとか)=Docker(正確にはcontainerdやrunc)、war アプリを管理するために必要なもの(Glassfish等の管理コンソールやJMXやデプロイ周りやクラスタリング等など)=k8s という感じですね。
おっしゃる通り、OpenShiftは管理のレイヤーなのですが今となってはk8sそのものだし、少しストーリ的には異なるかなー、と。

メタファーとして被せてみましたが、厳密には一致しないところはるかもですねー。