よくわからないことを刷り込まれている人が大杉漢方です。
aptでもyumでも、昔はCD-ROMやDVD-ROMでバイナリパッケージが流通してました。
同じようにgemsでもpipでもオフラインで使えるのが当たり前です。
ただ、なんでもオフラインで済むのかというと、例えばSSL(TSL)の証明書ルートなんかはアップデートできないとまずいです。組み込み系の製品でときどきやらかすものがありますよね。
さて、Dockerイメージもおなじです。何とかの一つ覚えで、
docker build
するだけなわけがないですよ。
数十年お世話になっております、とほほのページから引用しておきます。
Docker export/import/save/loadコマンド
何が言いたいかというと、Dockerイメージを誰かが作ったら、それをVirtualBoxの仮想ディスクイメージみたいにみんなで使いまわして運用するパターンもありうるってことです。
イメージサイズがでかすぎるとかいう人は、docker buildでどれくらいダウンロードしているか、理解できていない人ですよね。(イメージサイズの方が総ダウンロードサイズよりも小さいと言っているわけではない点に注意)
個人的にはローカルにイメージリポジトリを運用することをお勧めします。そうしたらFROMのところにOurCompanysFullStackみたいに書けて、
- Dockerfileをいじっていい感じにする人たち
- docker pullでイメージを引っ張ってきて使う人たち
と分業できますから。
実際、商用OSの開発環境なんかでDockerのイメージファイルを流通させてますよ。動作保証する環境をイメージファイルで配ればサポートが楽になりますし、エンドユーザの環境構築をサポートしていられないですよね。世の中には、apt install build-essentialも知らないでLinuxプログラマと踏ん反りかえっている人もいるんですから。それでもDockerが動かない系の問い合わせには対応しないといけないわけですが。
Dockerfileを流通させてもいいですが、そもそもパッケージなんて、バグがみつかりゃとたんに依存関係なんてめちゃくちゃになるわけで、ある日うまくbuildできたDockerfileやレシピファイルなんて、ノウハウ記事と同じであっというまに陳腐化してしまうわけで。
package-lock.jsonと同じでしょ。Aliceのpackage-lock.json を見ても、Bobの環境でnpm installが失敗する原因は解消しませんて。
Dockerfile内のapt installでインストールするパッケージのバージョンをひとつひとつ書いていく、という間抜けな運用もみたことがありますが、書いたとて、いつまで有効なの？という問題は解決できませんよね。
一方、イメージ化したら、とりあえず同じ状態で動きますよ、という話です。（ホストのカーネルのバージョンを上げたりするときには要注意）それを管理するための仕組みも提供されているってことです。
で、docker-hubのプライベートリポジトリのことだと早合点しないでほしいのです。
