Docker:【先入観なくせば】理解への近道
目次
はじめに
Dockerを理解の方向性
- VMwareなどの仮想化基盤と切り離して考える
- 新しいものを触っている感覚を持つ
- MW（特にDatabase）を触っている感覚に近い
仮想環境に当てはめてはいけない理由
- 想像を超える状況が起こっているように見える
- Dockerは非常にシンプルなのに、混乱して理解が進まない
- 例えば、
- Linuxなどのサーバー環境をDockerイメージやコンテナとして実体化する
- 簡単に作れるのでいくつも試作する
- 混乱の例
- 数十個も仮想環境があるなんて考えられない
- たくさんあって設定ドキュメント作れないのでどんな設定か分からない
Dockerでの環境構築の役割分担
役割分担のイメージ
- AI開発では
- 精度のいいモデルを研究開発する人
- それらをうまく使って製品化（実装）する人 に分かれる
- Dockerでも
- みんなが使えるような便利なもの（イメージ）を作る人
- 用意されてるイメージを使ってカスタマイズする人 に分かれる
はじめにDockerを触るのは
- ゴール
- 用意されているイメージを使う
- 多少、カスタマイズできるようになる
- 例えば、
- ベースのイメージはDocker HUBから持って来て利用する
- ちょっとカスタマイズして自作の環境を作る
- 自作の環境でアプリが動作するか確認する
- Webサーバーを起動してブラウザでページを表示する など
Dockerの4つの機能
Dockerイメージの説明
- 作り方
- イチから作らない
- ベースイメージがあってそれを利用して作る
- ベースイメージはDocker HUBにいっぱい転がっている
- メンテナンス
- 更新ではなくどんどん新しいものを作る
- 次々に新しいバージョンとして保存される
- 使わない（使えない）イメージは適宜掃除する
- イメージに取り込むファイル
- カレントディレクトリにあるファイルがすべて取り込まれる
- なので、イメージ作成コマンドを実行時に気を付ける
- そのディレクトリにあるファイルは必要なものだけ？
Dockerファイルの説明
- 概要
- 環境構築手順
- イメージのカスタマイズ方法を書く
- どんなことを書く？
- ベースイメージは何？
- インストールするアプリは？
- 最初に何を動かす？
- 外部とのコミュニケーションはどうする？
- 書き方
- Dockerファイルでのみ使うコマンドがある
- RUN、COPY、ENV、WORKDIR、CMDなど
- コマンドで書かれた指示通りにDockerイメージが作成される
- Dockerファイルでのみ使うコマンドがある
- 内容の確認は？
- 文法チェック
- コンパイル時にチェックされる
- ちゃんと動く？
- 結果がすぐ見れない
- Dockerコンテナとして実体化しないと確認できない
- 文法チェック
- 難易度
- やや難しい、ちょっと面倒
- 記載ルール理解する
- 作る環境をイメージする
- コンテナとして実体化して確認する
- やや難しい、ちょっと面倒
- がんばりどころ
- Dockerファイルが書けるようになればDockerイメージ作成できるようになる
- 期待通りに動くようにがんばる（バグつぶし、リトライ、繰り返し）
Dockerコンテナの説明
- 概要
- 軽い
- Dockerイメージの実体だけどただの箱
- 本体はやっぱりDockerイメージ
- 実体化して処理が終われば勝手に止まる
- 実体化した時のコマンドが履歴として残る
- 使ってみると
- ただのコマンドみたいな感じ
- 使い終わればただのゴミ
- コマンド履歴は適宜掃除しないといけない
（履歴を残さないオプションがある）
Composeファイルの説明（ちょっと曖昧）
- 概要
- システムの顔
- 見取り図
- Dockerとは別にインストール必要
- どんな時に触る？
- システム構築時
- 構成変更
- 扱いにくそう
- 入れ替えたら動かなくなったとか…
- Compose自体が環境依存ファイル…
- 後からこのファイル触るときって、ドキドキするんだろうな…
その他
- セキュリティ
- 通常のサーバと同様
- Dockerファイルの気づき
- requirements.txtが大切
- 必要なものがパッと分かるかが重要
- 流用できる
- ベンダが提供したものをカスタマイズ
- ENVとかRUNとかCMDは大体同じになる、多分