Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Docker講習会
Search
teru0x1
March 06, 2020
Technology
180
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Docker講習会
teru0x1
March 06, 2020
More Decks by teru0x1
See All by teru0x1
開発効率と信頼性を両立する Ubieのプラットフォームエンジニアリング
teru0x1
0
620
マルチクラスタの認知負荷に立ち向かう! Ubieのプラットフォームエンジニアリング
teru0x1
4
4.9k
ブラウザの外側でWasmを使おう
teru0x1
0
400
スタブサーバ自動生成ツール 〜負荷試験をもっと楽に〜
teru0x1
0
2.1k
バッチシステムをクラウドネイティブにするために考えたこと
teru0x1
17
8.6k
クラウド環境をFargateに 移行して得た知見
teru0x1
0
1.7k
Goと定数 DMM.go #3
teru0x1
0
2.8k
はてなインターン2020成果発表
teru0x1
0
1.2k
入門QUIC
teru0x1
0
610
Other Decks in Technology
See All in Technology
タスクの複雑さでモデルを選ぶ ── Thompson Samplingで動かす“トークン/コスト最適化
satohy0323
0
570
LLM/Agent評価:トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜
takkuhiro
1
230
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
AIレビューはどこまで任せられるのか?自動化と人が背負うレビューの境界
sansantech
PRO
3
1.1k
ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略
srenext
0
820
AI時代の闇と光
tatsuya1970
0
110
生成AI×AWS CDK×AWS FISで"振り返れる"ミニGameDayをつくろう
yoshimi0227
1
410
オブザーバビリティ、本当に活用できてる? 〜API連携×生成AIで成熟度を自動評価〜
dmmsre
1
3.6k
Amazon EVS で VCF 9.0 / 9.1 のサポート開始まとめ
mtoyoda
0
310
ボーイスカウトルールでメモリやスキルを改善しよう
azukiazusa1
4
1.5k
AIコード生成×サプライチェーン攻撃 — PHPが直面する“二重の信頼問題
shinyasaita
0
210
Playwright × AI Agent でE2Eテストはどう変わるか AI駆動テストの可能性と実用検証の結果
taiga7543
1
350
Featured
See All Featured
Designing for Performance
lara
611
70k
Between Models and Reality
mayunak
4
370
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
340
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.2k
Building AI with AI
inesmontani
PRO
1
1.1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
120k
Into the Great Unknown - MozCon
thekraken
41
2.6k
The Invisible Side of Design
smashingmag
301
52k
Utilizing Notion as your number one productivity tool
mfonobong
4
430
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
Typedesign – Prime Four
hannesfritz
42
3.1k
Transcript
Docker 講習会 ⽬的 Docker すごいって思ってもらう Docker こわくないって思ってもらう Docker 使っても良いかもって思ってもらう 1
Docker とは? コンテナ型仮想環境の構築・管理ツール コンテナ型仮想化って? 「コンテナ」という独⽴した区画を作成し,そこで仮想環境 を作る技術 VM ほどしっかりと分離されていない VM: ホストOS
からは別のマシンとして⾒える コンテナ: ホストOS からはプロセスとして⾒える 2
とりあえず使ってみよう (vm)$ sudo docker run -p 8080:80 nginx:1.17-alpine ブラウザで, localhost:8080
を開いてみよう このnginx はどこで動いている? 3
仮想環境をなぜ使うのか ホスト環境との分離のため 依存ソフトウェアのバージョン衝突防⽌ 複数プロジェクト同⼠でDB ,設定の混在防⽌ 開発者間での環境共有のため 仮想環境を渡すだけですぐ開発開始できる デプロイの容易さのため 仮想環境ごとデプロイすれば楽 4
. . . . 別に Docker じゃなくても普通の VM で 良いのでは?
5
Docker をなぜ使うのか コンテナ型仮想化 軽量(すぐ起動,すぐ終了,サイズ⼩) 強⼒なエコシステム 多様な周辺ツール クラウドによるマネージドサービス 6
Docker のキホン Docker イメージ コンテナのもと. Docker コンテナ 仮想環境を動かすもの.Docker イメージから⽣成される. この2
つはオブジェクト指向でいうクラスとインスタンスの関係に似 ている.これからイメージとコンテナの関係をつかんでいこう 7
Docker イメージを確認しよう (vm)$ sudo docker images REPOSITORY TAG IMAGE ID
CREATED SIZE nginx 1.17-alpine 48c8a7c47625 5 weeks ago 21.8MB 先ほどの docker run は「イメージを取得してコンテナを⽣成,起動」 するコマンド 8
コンテナを起動 $ sudo docker run -d -p 8080:80 --name myserver
nginx:1.17-alpine "-d" と"--name [name]" オプションがつきました. コンテナを確認してみよう $ sudo docker container ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 756632c14e60 nginx:1.17-alpine "nginx -g 'daemon of…" 17 seconds ago Up 16 seconds 0.0.0.0:8080->80/tcp myserver 9
コンテナに⼊ろう コンテナ内部に⼊ってみよう. $ sudo docker container exec -it myserver sh
/ # コンテナ内部の / ( ファイルシステムルート) に移動しました. ホストOS とはファイルシステムが分離されているのがわかります. 10
コンテナ内部の OS.. ? (container)/ # cat /etc/os-release NAME="Alpine Linux" ID=alpine
VERSION_ID=3.10.4 ... Alpine Linux は⾮常に⼩さなLinux ディストリビューションで,よく Docker イメージに利⽤されます. コンテナ内部でホストとは別のOS が動いているように⾒えますが,実 際はそのように⾒せかけているだけです. 参考: https://qiita.com/kirikunix/items/33414240b4cacee362da 11
コンテナ内部に変更を加える / # echo "helloooo" >> /usr/share/nginx/html/index.html / # exit
index.html はnginx で配信されているファイルです. >> でファイルに 追記しています ブラウザに反映されていますか? 12
もう 1 つコンテナを起動しよう $ sudo docker run -d -p 8081:80
--name myserver2 nginx:1.17-alpine イメージは同じ nginx:1.17-alpine です. 名前は myserver2 -p に指定するのは 8081:80 に注意してください. 13
ブラウザで確認 localhost:8080 と localhost:8081 を⾒⽐べてみよう 14
わかったこと イメージはコンテナの" もと" イメージからコンテナをたくさん⽣成できる イメージさえ渡せば,同じ環境を作成できる コンテナ同⼠は独⽴している コンテナ内部で変更を加えても,イメージには影 響しない コンテナ内部で⾊々変更するべきでない 15
仮想環境をなぜ使うのか(再掲) ホスト環境との分離のため 依存ソフトウェアのバージョン衝突防⽌ 複数プロジェクト同⼠でDB ,設定の混在防⽌ 開発者間での環境共有のため 仮想環境を渡すだけですぐ開発開始できる デプロイの容易さのため 仮想環境ごとデプロイすれば楽 16
今更だけど今⽇のシステム構成 Docker をVM (Ubuntu Xenial) 上で動かしている Docker はLinux 上の⽅が良い感じに動くので 厳密にはLinux
でしか動かない Vagrant: Virtualbox のような仮想化ソフト(ハイ パバイザ)の構成ツール Vagrantfile にポート転送の設定を書いてるのでホ ストから疎通できるようになってます 17
イメージを作る コンテナをいじるのが良くないことがわかった じゃあ,イメージごといじれば良い! 作り⽅ Dockerfile を書いてビルドする コンテナから⽣成する 18
Dockerfile イメージの設計図 記述すること ベースにしたいイメージ イメージ作成時に実⾏したいコマンド コンテナ実⾏時に実⾏したいコマンド などなど 19
Dockerfile ⾒てみる VM の /vagrant/hello-dockerfile/Dockerfile をみてみよう FROM nginx:1.17-alpine FROM: ベースとなるイメージを指定
COPY ./nginx.conf /etc/nginx/nginx.conf COPY: ホストのファイルをコンテナへコピー 20
RUN set -x &&\ apk --update add openssl &&\ ...(omitted)
chmod 400 /etc/nginx/server_private.key RUN: イメージ作成時に実⾏するコマンド ここで⽣成したファイルなどはイメージに含まれる CMD ["nginx", "-g", "daemon off;"] CMD: コンテナ起動時に実⾏するコマンド 21
イメージを作る(ビルド) $ cd /vagrant/hello-dockerfile $ sudo docker build -t hoge/myserver:1.0
. タグは[Dockerhub のユーザー名]/ イメージ名: バージョン で作るのが 普通 Dockerfile の"RUN" で指定したコマンドが⾛りました.できたイメー ジを $ sudo docker images で確認してみよう 22
コンテナ起動 これはさっきと同様 $ sudo docker run -d -p 4443:443 --name
https-server hoge/myserver:1.0 警告画⾯が出たら"thisisunsafe" とタイプする 23
Dockerhub docker イメージがたくさんアップロードされてる 24
Dockerfile を作ってみよう ⾃分で作成したイメージもFROM でベースに指定できる FROM hoge/myserver:1.0 RUN apk --update add
sl ... 25
multi stage build ( 1/2 ) go/Dockerfile # ビルド⽤のイメージ FROM
golang:1.14-alpine as builder WORKDIR /go/src/app COPY ./main.go . RUN GOOS=linux GOARCH=amd64 go build -o /go/bin/app # 実⾏⽤のイメージ FROM alpine:3.11 COPY --from=builder /go/bin/app /go/bin/app RUN addgroup --system myapp &&\ adduser --no-create-home --disabled-password --system --ingroup myapp myapp USER myapp ENTRYPOINT [ "/go/bin/app" ] 26
multi stage build ( 2/2 ) FROM golang:1.14-alpine as builder
... COPY --from=builder /go/bin/app /go/bin/app コンパイルさえできれば後は処理系が必要ない場合に使う ( 例: golang, C++, Rust, webpack) ビルド⽤と実⾏⽤のイメージを分離できる $ sudo docker images | awk '{print $1 ":" $7}' | grep go hoge/goapp:13.1MB # こちらだけサーバにデプロイすればOK golang:369MB # これはもう必要ない 27
おまけ RUN addgroup --system myapp &&\ adduser --no-create-home --disabled-password --system
--ingroup myapp myapp USER myapp CMD や ENTRYPOINT : 指定したコマンドは実⾏ユー ザがroot セキュリティ上良くない USER 実⾏ユーザを変更 システムユーザを作成して実⾏している 28
実際, Docker はどういうところで使う のか ? ここまでで基礎は⼤体OK 使われ⽅をいくつか紹介 29
ユースケース 1: 実⾏環境を使いたい 環境構築がめんどくさいツールを使う時,誰かが Dockerhub にイメージをUP していることがある ただし,安易にイメージを信頼するのはセキュリティ上良く ない $
cd bookmaker $ sudo docker run --rm -v `pwd`:/work nuitsjp/mdview ./work/build.sh -v: ホストのディレクトリをコンテナにマウント イメージ名の後に実⾏コマンドを⼊⼒できる 30
31
ユースケース 2 jupyter notebook ブラウザで実⾏できるPython のREPL 環境 データサイエンスやML の⼈が良く使う $
sudo docker run --rm -p 8080:8888 -v `pwd`:/home/jovyan/work jupyter/base-notebook 32
ユースケース 3: web web 開発では複数のコンテナを動かしたいことがほとんど(1 サービ ス1 コンテナが原則) フロントエンド⽤サーバ アプリケーションサーバ
DB => docker-compose を使う 33
docker-compose 複数のコンテナをまとめて管理するツール /web/docker-compose.yaml を⾒てみよう 34
version: '3' services: server: ... db: ... volumes: - db-store:/var/lib/mysql
... volumes: db-store: db-store はホストのディレクトリになる. 実体は /var/lib/docker/volumes/web_db-store/_data にある 35
server └── server ├── Dockerfile # 開発⽤Dockerfile ├── Dockerfile.prod #
本番⽤Dockerfile ├── main.go └── tmp 開発⽤: ファイルの変更をウォッチして⾃動ビル ド 本番⽤: ビルドするだけ 36
compose 起動 $ sudo docker-compose up -d $ sudo docker
images や $ sudo docker-compose ps で確認してみよう コンテナを削除して,再起動してみよう.DB のデータはどうなります か? 37
まとめ イメージからコンテナを(複数)⽣成できる コンテナに変更を加える事は普通しない イメージをDockerfile から作って共有しよう docker compose を使って複数コンテナ管理 さあ,次は君の番! 38