Docker
https://gyazo.com/30873fb115f555003dcd524cd5b8d4b2
概要
元々docker内のプログラムだったが、コンテナの標準化で分離された
dockerd自体はDockerfileの解釈やvolume/networkなどのリソース管理を担当している
dockerd自体はCRI互換ではない
dockershimはCRIをdockerd向けに翻訳するコンポーネント
dockerはCRI互換じゃないけど内部のcontainerdはCRI互換だからdockerのレイヤが不要なので削除したというだけの話
docker daemonは実行にルート権限が必要
セキュリティ的なウィークポイント
ルート権限が必要ないようなコンテナエンジンとかの開発も進んでる
コンテナはイメージというスナップショットから(隔離環境で)起動したプロセス
dockerコンテナは一つのコマンドをフォアグランドで動かすように設計されている
フォアグランドのプロセスがないとコンテナは終了する
tail -f /dev/nullみたいな技でバックグラウンドでしか動かせないコマンドも動かせる
CMDで定義したものがコンテナ内でのPID1
コンテナが停止する時
コンテナ内のPID1が終了した時
コンテナ内のプロセスが全てバックグラウンドになった時
アーキテクチャ
Dockerクライアント
Dockerエンジン
Dockerレジストリ
https://gyazo.com/b6005b1eccd2e733c48b64374ccedfe3
https://gyazo.com/4a4856df418ea804ec43a1cd82c5dfcb
Dockerはクライアント・サーバー
https://gyazo.com/faa1295a05261a0257bec23993926973
docker daemonは
リモートにある場合はhttpsで受け取る
hiroki.iconホストの中か外かで通信方式が異なるのがポイントだね
なんとなくローカルからのcliもlocalhost的なdocker daemonウェブサーバーみたいなところへのhttpリクエストで通信しているのかと思ってた
Dockerを開発環境として使う
開発に必要な環境のimageを決める
自分の開発ディレクトリを決める
コンテントと開発ディレクトリをマウントする
必要であればdocker-compose.ymlに定義
開発はホストで行い、コンパイルやビルドはコンテナで行う
コマンド
コマンドを調べる
docker container run --help
コンテナから抜ける
control + P control + Q
hiroki.iconこれよく忘れる
-i標準入力を受け取る-t仮想端末をコンテナに割り当てる
docker run -it busybox sh
起動中のコンテナを強制的に削除
docker container rm -f コンテナID
--nemaコンテナ名を指定 -hホスト名を指定
docker container run --name dorothy -h hostname -it busybox sh
-dバックグランドで起動 -e環境変数を設定する
docker run --name mymariadb -e MYSQL_ROOT_PASSWORD=hoge -d mariadb:tag
バックグラウンドのコンテナへの接続
docker container attach コンテナ名/コンテナID
docker container exec -it コンテナ名 /bin/bash
attachはコンテナの標準入力に接続する→exitで離脱するとコンテナが停止する
execはコンテナ内で任意のコマンドを実行できる→exitで抜けてもコンテナは停止しない→安全
-vホストのディレクトリをコンテナに見せる
docker run -it --rm -v $(pwd):/app:ro hiroki1117/sbt
hiroki.iconコンテナで開発するときは$(pwd)はよく使うよ、:roと合わせて使うとreadonly
--mount type=bind,src=ホストのディレクトリ,dst=コンテナのディレクトリ
こちらの方が可読性が高い
docker run -it --rm --mount type=bind,src=$(pwd),dst=/in_busybox,readonly busybox sh
ボリュームの基本操作
作成
docker volume create my_vol
削除
docke volume rm my_vol
マウント
--mount type=volume,src=ボリューム名,dst=コンテナのディレクトリ
-v ボリューム名:/コンテナのディレクトリ
hiroki.icon-vの方がお手軽だからこっち使うのが話早いかね
--volumes-from コンテナ名 指定したコンテナと同じマウントをする
/icons/point.iconデータ専用コンテナパターン
これによって複数マウントするようなコンテナを量産するようなユースケースに可読性が高くなる
データのマウントだけをまとめたコンテナを定義する
他のコンテナは--volumes-fromでそのコンテナを指定すればいい
inspect 調査する
docker image inspect イメージ名
docker container inspect コンテナ名
docker volume inspect ボリューム名`
Dockerイメージのビルド
docker image build -f ./Dockerfile -t myimage:hoge --build-arg myarg=sample .
-fビルド用のDockerfileを指定する
t イメージ名にタグを指定する
--build-arg Dockerfileにビルド時に渡す引数を指定
hiroki.iconあるある：最後の . (カレントディレクトリの意)を忘れる
イメージ名/タグの変更
dokcer tag IMAGE_ID IMAGE_NAME:TAG