Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Docker講習会
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
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
Slack上でインフラをトラブルシュートする! Agentic Platform Engineeringの第一歩
teru0x1
5
1.9k
開発効率と信頼性を両立する Ubieのプラットフォームエンジニアリング
teru0x1
0
700
マルチクラスタの認知負荷に立ち向かう! Ubieのプラットフォームエンジニアリング
teru0x1
4
5k
ブラウザの外側でWasmを使おう
teru0x1
0
410
スタブサーバ自動生成ツール 〜負荷試験をもっと楽に〜
teru0x1
0
2.1k
バッチシステムをクラウドネイティブにするために考えたこと
teru0x1
17
8.7k
クラウド環境をFargateに 移行して得た知見
teru0x1
0
1.7k
Goと定数 DMM.go #3
teru0x1
0
2.9k
はてなインターン2020成果発表
teru0x1
0
1.2k
Other Decks in Technology
See All in Technology
C#コードの結合を可視化する Roslyn解析による設計改善と リファクタリング判断
dora56
0
880
AWS FinOps Agent 結局何が得意なの?
siromi
0
210
企業の現実世界をグラフで写し取る
sansantech
PRO
0
160
AI臭い文章とは何なのか
nasuvitz
18
17k
Account Factory for Terraformによる 標準化されたアカウント発行の自動化
pensuke628
0
110
行動するAIのためのオントロジー | DevRev — Encraft #26.pdf
dvrv_tknrszk
1
510
OpenClawでAzure DevOpsのWiki更新を自動化する - クラウドAIだけでは届かない場所へ
yutakaosada
0
110
品質と信頼性を地続きにする
grimoh
3
1.3k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
16
120k
[Kiro Meetup #7] Kiro Crew Dive Deep
konippi
0
390
2026-09-26 Platform Engineering Kaigi 2026 インフラとアプリの境界線と委譲の設計 / Drawing the Infra and App Line
masasuzu
0
300
2026-09-18 gotanda.sre Terraformで複数環境作ったり、複数Stateに分割したりそれとTerragrunt / Terraform multi envs and multi states
masasuzu
4
760
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
33
5k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
440
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.3k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.6k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
440
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
560
How GitHub (no longer) Works
holman
316
150k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
370
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
290
Balancing Empowerment & Direction
lara
6
1.3k
The untapped power of vector embeddings
frankvandijk
2
1.9k
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