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
610
マルチクラスタの認知負荷に立ち向かう! 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
600
Other Decks in Technology
See All in Technology
AI-DLCを “そのまま導入しなかった”話 ~組織に合わせてアジャストした 私たちの実践共有~
hiroramos4
PRO
0
210
Kiro Ambassador を目指す話
k_adachi_01
0
110
フィジカル版Github Onshapeの紹介
shiba_8ro
0
290
Kubernetesにおける学習基盤とLLMOpsの概要
ry
1
320
スタートアップにAmazon EKSは早すぎる? マルチプロダクト戦略を加速する Platform Engineeringの実践 / Is Amazon EKS Too Soon for Startups? Practical Platform Engineering to Accelerate a Multi-Product Strategy
elmodev09
0
370
脱SaaS!FDEを支えるプロビジョニングと分離設計
knih
0
240
攻撃者視点で考えるDetection Engineering
cryptopeg
3
2k
アジャイルな経理と Claude Code と経営の未来
kawaguti
PRO
3
160
【2026年版】 ベクトル検索とEmbedding最前線
mocobeta
16
4.4k
【Cyber-sec+】経営層を"動かす"ための考え方
hssh2_bin
0
200
日本 Fintech 未来予測レポート 2027〜2028年(手動編集版)
8maki
1
2.5k
2026TECHFRESH畢業分享會 - 葬送的通靈師:化系統與用戶雜訊成行動訊號
line_developers_tw
PRO
0
1.3k
Featured
See All Featured
Technical Leadership for Architectural Decision Making
baasie
3
420
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
300
Designing for Timeless Needs
cassininazir
1
260
Become a Pro
speakerdeck
PRO
31
6k
It's Worth the Effort
3n
188
29k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Scaling GitHub
holman
464
140k
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
620
Design in an AI World
tapps
1
250
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
The Pragmatic Product Professional
lauravandoore
37
7.3k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
71
40k
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