- imageからコンテナを作れるのは当然として、逆もできる
- コンテナの粒度
- やろうと思えば3層アプリケーションを同じコンテナで実行できるが…
- 密結合すぎてメンテしづらいとか、Dockerのメリットがだいぶ減るので、プロダクトとして使うならアンチパターン
- 検証だとこういった全部入りが便利
- コンテナ間でLinuxディストリビューションが違っても良い
- Dockerの大きな魅力の一つ
- RDBMSとかで気にする場面はあるらしい
- コンテナのライフサイクル
- 「作っては捨てる」
- 作成→起動→停止→削除
- アプリケーションデータはDockerをインストールしてるホストのディスクに保存する
-p 8080:80の意味
{ホストのポート番号}:{コンテナのポート}
- ホストのポートとコンテナのポート番号をマッピングしている
- httpd(apache公式イメージ)だと80番のポートで通信を待ち受ける
- ただlocalhost:80とかやっても通信できない
- 同じコンテナを水平スケーリングしたときにどのコンテナ宛かわからなくなる
- alpineイメージは一長一短
- 最大のメリットはイメージサイズが小さいこと
- ただデメリットもぼちぼち
- glibcが入ってない
- パフォーマス低下するケースがあったり、debian系で動いたもんが動かなかったり
- pakバージョンを固定できない
- dibian-slimイメージがalpineよりイメージサイズ大きいけどデメリット少なめで便利らしい
- ボリュームマウント2種類
- バインドマウントとボリュームマウント。docker実行環境上に保存するのがボリュームマウントの方
- イメージを作る方法2つ
- commitで作る
docker commit {コンテナ名} {書き出し名}
- Dockerfileから作る
docker build -t {書き出し名} {Dockerfileがあるパス（Dockerfileのパスではない}- Dockerfile内のパスはDockerfileがcd
- イメージを持ち運びたいケース
- 【背景】Dockerレジストリ経由以外の方法は？イメージファイルもDocker実行環境に格納されていて触れない
- 【方法】saveコマンドでイメージをtarファイル化してからlocaコマンド
docker save -o {ファイル名}.tar {イメージ名}-
docker load