2015-01-27 introduction to docker

1

Introduction to Docker

By @uzyexe Jan 27, 2015

Shuji Yamada

@uzyexe

2

whoami

2

3

Paradigm Shift

https://www.flickr.com/photos/shawnclover/6287072270/

https://www.flickr.com/photos/shawnclover/6287072270/

4

ユーザークライアントのパラダイムシフト1995 2015

Mobile or

Tablet devices

Thick and fatclient

5

ユーザークライアントのパラダイムシフト1995 2015

Mobile or

Tablet devices

Thick and fatclient

6

インフラ環境のパラダイムシフト1995 2015

Monothilic many Resources

インフラ環境のパラダイムシフト1995 2015


7

Defined-stack: - OS - Middle-ware - Runtime - etc...

8

サービススタックのパラダイムシフト1995 2015

best servicesand

best app

From 1995 to 2015

9

Thick Thin

Defined-Stackbest services

and best app


1995 2015

IaaSInfrastructure as a Services

10

Host

PaaSPlatform as a Services

Build

&

IaaSがもたらしたパラダイムシフト• あらゆる意味でハードだったインフラに対して柔軟性をもたらした

• セルフサービス：自分自身で自由にインフラ構成を作れる

• オンデマンド課金：使った分だけ課金

• APIセントリック： APIを活用することでCI/CDや運用自働化やinfrastructure as a codeを実現。

• プラガブル：各種ストレージやネットワーク、データベースやネームサーバなどを好きなように統合連携できる。

11

PaaSがもたらしたパラダイムシフト• サービス開発にアジャイリティ（迅速性）をもたらした。

• オンデマンド課金：使った分だけ課金

• インフラの抽象化：アプリケーション開発に専念できる。

• APIセントリック： APIを活用することでCI/CDや運用自働化を実現。一方で、NoOps（運用技術者不要論）の登場。

• プラガブル：各種サードパーティサービスを好きなように統合連携できる。

12

13

Container

https://www.flickr.com/photos/dahlstroms/3144199355/

https://www.flickr.com/photos/dahlstroms/3144199355/

最新のコンテナ技術がもたらすパラダイムシフト

• より迅速にアプリケーションをスケールアウトできるようになる。

• アプリケーションをコンテナにパッケージングすることで、世界中のほとんどのコンピューティングリソース上で再現可能かつ再利用可能なイメージを迅速にプロビジョニングできるようになる。

• 1-Role/1-VM => 1-Role/1-Contaienr、環境構築に必要なリソースが省力化され、従来の仮想マシンよりも高効率な収容構成が可能になる。

14

15

Tim

e to

pro

visi

on

物理サーバ仮想マシン（VM）コンテナ

4~72時間

5~15分5~30秒

インスタンスの立ち上げまでにかかる平均的な時間

15

hello world$ time docker run debian echo "hello world" Unable to find image 'debian:latest' locally debian:latest: The image you are pulling has been verified 1aeada447715: Pull complete 479215127fa7: Pull complete 511136ea3c5a: Already exists Status: Downloaded newer image for debian:latest hello world

real 0m15.250s user 0m0.050s sys 0m0.027s

16

# Not have an local image

hello world$ time docker run debian echo "hello world" hello world

real 0m0.169s user 0m0.009s sys 0m0.010s

17

# Have a local image :)

Image size is light weight

18

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE postgres latest 2389997c2ef2 3 days ago 213.3 MB nginx latest 90081fa15a0c 3 days ago 91.62 MB mysql latest 335228ceb173 3 days ago 282.6 MB debian latest 4d6ce913b130 8 days ago 84.98 MB centos latest 8efe422e6104 2 weeks ago 210 MB fedora latest 834629358fe2 3 weeks ago 241.3 MB busybox latest 4986bf8c1536 3 weeks ago 2.433 MB ubuntu latest ed5a78b7b42b 4 weeks ago 188.3 MB

19

未回答不明

10,000 ~

5,000 - 9,999

2,000 - 4,999

500 - 1,999 100 - 499

~ 100 < 100100-499

500-19992000-49995000-9999

10000 >不明未回答 2.0%

8.0%8.5%4.9%8.4%

16.9%23.0%

28.3%

企業におけるサーバ台数

http://www.slideshare.net/realgenekim/2014-state-of-devops-findings-velocity-conference

http://www.slideshare.net/realgenekim/2014-state-of-devops-findings-velocity-conference

20

スケーラビリティ

21

スケーラビリティ高効率

22

スケーラビリティ高効率

汎用性

On

23

Cloud?

24

Cloud?

Bare-metal?

25

Cloud?

Laptop?

Bare-metal?

26

27

CloudLaptop Bare-metal

28

On


29


On

30

Game Change

https://www.flickr.com/photos/mattmflickr/7461949414/

https://www.flickr.com/photos/mattmflickr/7461949414/

ワークフローにどのような変化が起こるか？

• アプリケーションやミドルウェアを簡単にイメージ化できる。（ChefやPuppetなどの高機能で複雑なデプロイツールのコード簡略化を併せて実現できる。）

• デザイナーでもローカルPC上で開発環境を再現したコンテナを起動して、コンテナ上でデザインをコーディングできる。

31

コンテナが世の中のDevにもたらす変化• より手軽で、より壊しやすく、より柔軟な環境を手にいれることができるようになる。

• 自身でコンテナを構築し、自身のローカル環境上でアプリケーションを手軽に実行することができるようになった。

• コンテナが実行される『場所』のインフラ特性を気にしなくても良くなった。

• 引き換えに、コンテナの構築方法や操作手法を習得する必要がある。

32

コンテナが世の中のOpsにもたらす変化• よりセットアップしやすく、よりメンテナンスしやすい環境を手にいれることができるようになる。

• 膨大で煩雑なセットアップスクリプトを書いて『イメージ』を作成しなくても良くなった。

• Devが作ったコンテナイメージをサーバ上に直接展開できるようになり、アプリケーションのセットアップコストが削減された。

• 引き換えに、大量のコンテナの管理操作手法を習得する必要がある。

33

DevとOpsに共通して課される役割• VMよりも処理性能的なオーバーヘッドが少なく、ランニングコストを削減できるコンテナ技術を活用してシステムを構築するスキルが求められる。

• VMよりも迅速にアプリケーションを展開できるコンテナを活用して、従来よりも高速にサービスを構築するスキルが求められる。

• コンテナ技術を活用して、従来のワークフローを改善するスキルが求められる。

34

35

Learning Step

https://www.flickr.com/photos/nomadic_lass/6820209341/

https://www.flickr.com/photos/nomadic_lass/6820209341/

学習ステップ

1. Dockerで遊んでみる。

2. 本格的に利用する場合の課題を考えてみる。

3. 本格的に使ってみる。

36

stage1. Dockerで遊んでみる

• 自身の環境でDockerを動かしてみる。

• 自身の環境でDockerコンテナのイメージを作ってみる。

• ネームスペースやcgroupsなどのLinux由来の特徴を理解する。

37

stage2. 本格的に利用するときの課題• データの永続化

• イメージの正当性確認

• イメージ転送の暗号化

• 監視、ロギング

• 複数台のコンテナ管理

• アップデート

38

stage3. 本格的に使ってみる• コンテナ複数台のスタティックなオーケストレーション

• CircleCIやDrone.ioとのCI/CD連携

• aufs, btrfs, devicemapper

• Capabilities

• セキュリティ

• Networking (iptabels, bridge, pipework, ...)

• レポジトリ39

Future stage• DockerUI, Panamax, Rancher.io

• CoreOS (etcd+fleet+flannel), Atomic Host

• DockerSwarm

• Mesos+docker, Consul+docker, kubernetes, Helios, ...

• Deis, Flynn, ...

• Rocket, ...

40

41

https://www.flickr.com/photos/yukop/11941236015/

https://www.flickr.com/photos/yukop/11941236015/

コンテナ技術の代表的な特徴• どこでも同じ動作をする。

• versionに依存しない。

• OSディストリビューションに依存しない。

• 特定のモジュールに依存しない。

• VM(仮想マシン)よりもオーバヘッドが少ない。

42

Dockerコンテナの特徴• コンテナ＝ホストから分離されているプロセス（ネームスペース）

• 各コンテナはホストOSのkernelを共有する。

• コンテナから見えるデバイスはエミュレーション動作ではない。

• 実際にほとんどの環境上でコンテナを動かせる。 Linux, Windows, OSX... Cloud, Server, Windows PC, Macbook, RaspberryPi...

43

44

Docker Engine

HyperVisor

GuestOS

Server

GuestOS

GuestOS

App-1

App-2

App-1

App-1’

App-3

App-4

App-1

App-2

App-1

App-1’

App-2

App-3

DockerType-1

HyperVisor

OS

HyperVisor

Server

App-1

App-2

App-1

App-1’

App-3

App-4

Type-2HyperVisor

Bins/Libs Bins/LibsBins/Libs Bins/Libs

Bins/Libs Bins/Libs

Bins/Libs Bins/Libs

GuestOS

GuestOS

GuestOS

OS

Server

コンテナに何を入れればいいの？• コード

• ライブラリ

• バイナリ

• アプリケーション

• データ

• その他、なんでも

45

コンテナを何に使えばいいの？• webアプリケーション

• APIバックエンド

• データベース（SQL, NoSQL）

• メッセージキュー

• アプリケーションのビルド環境

• その他、なんでも

46

47

On


Dockerを動かすために必要な環境

• Linux or Mac OSX or Windows # 64bit only

• Linuxの場合はkernel 3.8 以上 ( or RHEL kernel 2.6.32以上)

48

Dockerのインストール

49

$ sudo apt-get update $ sudo apt-get install docker.io

$ sudo yum install docker

# Firstly, you need to ensure you have the EPEL repository enabled. $ sudo yum install docker-io

• Ubuntu 14.04

• RHEL7/CentOS7

• RHEL6/CentOS6

or Boot2Docker for Windows

50

or Boot2Docker for Mac OS X

51

Docker Platform• Linux環境上で動作するアプリケーションのコンテナ化

• コンテナの実行とコンテナの各種リソース制御

• コピー·オン·ライトなファイルシステムを活用したプロビジョニング

• 簡単にコンテナイメージを構築するための手法の提供 (Dockerfile)

• コンテナイメージを世界中に共有できる環境の提供 (DockerHub)

52

Dockerfile• Dockerfileはコンテナイメージを構築するためのレシピ。

• FROMでベースイメージを宣言する。

• RUNでアプリケーションセットアップ用のコマンドを宣言する。

• CMDで実行コマンドを宣言する。

• EXPOSEで開放ポートを宣言する。

53

# vim Dockerfile FROM ubuntu:14.04

RUN apt-get update RUN apt-get install -y nginx RUN echo ‘Hi, hello my container’ / > /usr/share/nginx/html/index.html

CMD nginx -g “daemon off”

EXPOSE 80

典型的なDockerfileのサンプル






54




EXPOSE 80







55




EXPOSE 80







56




EXPOSE 80







57




EXPOSE 80


EXPOSE• EXPOSEは明示的に宣言しなくても構わない。

• runするときに、-p 80:80という感じでポートを明示して指定してあげるだけでもポートは割り当てられる。

• -PオプションはEXPOSEしているポートをすべて割り当てる。

• --link は連携対象のコンテナを指定するとEXPOSE宣言しているポートに接続するための環境変数を付加してコンテナを起動するオプション。

58

Build caching• build実行時にはDockerfileの行単位でビルドキャッシュが生成される。 • 次回build実行時はキャッシュが利用され、変更差分のみビルドされる。

• キャッシュが存在しない行以降はキャッシュが利用されない。 • ADD行は前回ビルド以降に対象ファイルの変更があった場合においてはキャッシュが利用されない。その場合、以降の行も引き続きキャッシュが利用されないのでADD行の埋め込み位置には注意が必要。

• apt-get updateなどのキャッシュも残る。--no-cacheを指定しないと次回のビルド実行時に最新の状態にアップデートされない。

59

Docker Hub

60

Docker Hub

61

Automated Build

62

Automated Build

63

Docker Registry’s• DockerHub以外にもDockerイメージを保管するためのレジストリサービスが存在する。

• DockerHub (official)

• Quay.io

• Google Container Registry

• $(docker pull registry)

64

65

Dockerfile Docker Image

build Push Provisioning

Case1

• Very simple

• At first, it docker build very slowly,but after some caching, it build much faster

Docker Hub

66

Docker Image

Dockerfile Docker Hub

Push

Automated Build

Push

Push

GitHub or

Bitbucket

Provisioning

Case2

• Outsource your docker build

• GitHub or Bitbucket-like

• Automated build is very slow...

67

Docker Base Image

Dockerfile Docker Hub

Push

Automated Build Push

Hook

GitHub

Dockerfile

Docker Image

Build

FROM <Base Image>

Case3

Containerized

Commit Push

Docker Hub

Provisioning

Docker Image

Patch

• Incremental update pattern

• Minimize the build process

• It fast

Container in Machine

Rebuild-pattern VS Upgrade-pattern• Rebuild (Immutable-like)

• 更新の都度、Dockerfileをbuildして最新版のイメージを作成。

• 冪等性を担保しやすい。

• 変更内容の影響を受けるスコープが大きい。

• 工夫しないとbuild完了までに時間がかかる。

• 設定が複雑なコンテナや頻繁な更新が必要なコンテナには不向き。

68

Rebuild-pattern VS Upgrade-pattern• Upgrade (Patch-like)

• 開発用コンテナにログイン作業するなどして最新の状態に更新。

• 最新の状態に更新されたコンテナを都度commitしてイメージ化。

• 最新イメージはイメージレポジトリにpushしてバージョン管理。

• build待ちの時間を最小限に抑制できる。

• 充分なテストを準備していたとしても、冪等性は担保しにくい。

69

Dockerコミュニティの規模• 10,000,000+ download

• 75,000+ repogitories on DockerHub

• 150+ Meetup Groups in 50 countries

• 740+ contributors

• 50,000+ third-party projects on GitHub

• 100+ user-generated case studies available from companies

70

https://www.docker.com/company/aboutus/

https://www.docker.com/company/aboutus/

ChangeLog• v0.1.0 (2013-03-23), initial public release

• v0.2.0 (2013-04-23), automatic bridge setup

• v0.3.0 (2013-05-06), volume

• v0.4.0 (2013-06-03), API, docker build

• v0.5.0 (2013-07-17), host volume, UDP ports

• v0.6.0 (2013-08-22), privileged mode

71

ChangeLog

72

• v0.7.0 (2013-11-25), links, storage drivers(aufs, DM, vfs)

• v0.8.0 (2014-02-04), BTRFS, OSX CLI, ONBUILD, ADD cache

• v0.9.0 (2014-03-10), libcontainer, Execution Drivers

• v0.10.0 (2014-04-08), TLS API Supports

• v0.11.0 (2014-05-07), SELinux, DNS links, --net=host

• v0.12.0 (2014-06-05), pause/unpause

ChangeLog

73

• v1.0.0 (2014-06-09), Production support

• v1.1.0 (2014-07-03), .dockerignore, commit, logs --tail

• v1.2.0 (2014-08-20), auto-restart policies, capability

• v1.3.0 (2014-10-14), docker exec, docker create

• v1.4.0 (2014-12-11), overlayfs

• v1.5.0-rc1 (2015-1-22), IPv6, docker rename

v1.0.0 ~ v1.5.0-rc1• .dockerignore, 特定のファイルやディレクトリを無視

• docker logs, コンテナのログを表示

• --restart=alway/no/on-failure, コンテナの自動再起動ポリシー

• --cap-add/cap-drop, Linux Kernel Capability

• --device=, 利用するデバイス名指定

74

v1.0.0 ~ v1.5.0-rc1• docker exec, 起動中コンテナへのログイン機能

• docker create, コンテナ作成コマンド（起動はしない。）

• Signature (official image only)

• --security-opts (SELinux/AppArmor)

• overlayfs support

• IPv6 support

75

76

Architecture

https://www.flickr.com/photos/laughingsquid/5283377604/

https://www.flickr.com/photos/laughingsquid/5283377604/

Dockerデーモンの役割

• コンテナとイメージの管理、ビルド

• embedded CLI talking to the API

• HTTP API (over UNIX or TCP socket)

77

docker.sock• -d付きで起動したdockerはTCPソケット、またはUNIXドメインソケットで起動され、コンテナを起動するためのデーモンになる。

• socketへの書き込みにはroot権限、もしくはdockerグループの権限を必要とする。

• TCPソケットの場合でもUnixドメインソケットの場合でもHTTP APIとして動作する。

• ほぼRESTfulな実装なので、curlとかでjsonを引き渡せば動く。

78

Dockerの実行ドライバー• Dockerの実行ドライバーはオプションで指定可能。

• lxc (=legacy)

• native (=libcontainer) (default)

• あえてlxcを選ぶ理由がない限りは、libcontainerのほうが挙動も安定していて安全。

79

libcontainer• コンテナを実行するためのGo製のドライバーパッケージ。

• namespaces, cgroups, capabilitiesなどのLinuxネイティブコンテナのための機能を実装したビルトイン可能なライブラリ。

• LXCユーザーランドは未使用。

• 現在のDockerはLXCが必須ではなくなっている。

80

docker server (docker daemon)

docker API server

network driver

81

Container

libcontainer

docker.sock

exec driver(native or lxc)

(docker build...) (docker run...) (docker pull...)

API CLI

Docker Daemon

Docker Container

Engine

rootfs (aufs, btrfs, devicemapper...)

graph driverDriverother drivers...

Dockerfile Registry(DockerHub, etc...)

Doc

ker E

ngin

eClient

コンテナはとても軽量

• だってプロセスみたいなものなんだもん。

• プロセスっていうことは？

• ノートPC上でも10～100台くらいのコンテナを動かせる。

• サーバ上なら1000台以上のコンテナを動かせる。

82

本当にオーバーヘッドないの？• Yes。コンテナはnativeな速度で動く。

• コンテナ上で動くプロセスはホスト上でダイレクトに動いてる。

• CPUの処理性能はnativeな速度。

• メモリの処理性能はnativeな速度。

• ネットワークのI/O性能はブリッジなどを経由すると遅くなる。

83

対応ファイルシステム• Dockerコンテナは各種ファイルシステムに対応している。

• AuFS

• Btrfs

• DeviceMapper (Direct LVM, Loop LVM)

• VFS

• overlayfs

84

主要なストレージドライバ

• 主要なOSとデフォルトのストレージドライバの対応関係

• Ubuntu/Debian: aufs

• RHEL/CentOS: devicemapper (loop-lvm)

• CoreOS: overlayfs

85

--netオプション• --net=bridge, Linux Bridge(docker 0)経由の通信。ホスト側で自動的にNAPTされ、グローバルと通信できる。(default)

• --net=container, 他のコンテナとNICを共有する。IPアドレスとMACアドレスも同一のアドレスを共有する。

• --net=none, NICを利用しない。

• --net=host, ホストのすべてのネットワークをnativeに利用する。

86

Host Serverveth veth veth

ネットワーク

87

--net=bridge

Container Container

--net=container

Container

--net=none

Container

eth0 (veth)

--net=hostContainer

Bridge (docker0)

eth0

Container

eth0 (veth)

eth1 (veth)

Network Port Mapping• コンテナにはランダムなポートがマッピングされる。(default)（下図において、コンテナのPort 5000はホストのPort 49154にマッピングされている。）

88

49154

Brid

ge 5000

eth0

Host Container

$ docker run -d --name=myapp -P training/webapp python app.py $ docker port myapp 5000/tcp -> 0.0.0.0:49154

Network Port Mapping• ただし、DockerfileでEXPOSEを宣言していないコンテナの場合は、明示的に-Pオプションを指定しても無視される。

89

Brid

ge

eth0

Host Container

$ docker run -d --name=myapp -P busybox yes $ docker port myapp

Network Port Mapping• -pオプションでポートマップを指定することも可能。（下図において、コンテナのPort 5000はホストのPort 5000にマッピングされるよう明示的に指定している。）

90

5000

Brid

ge 5000

eth0

Host Container

$ docker run -d --name=myapp -p 5000:5000 training/webapp python app.py $ docker port myapp 5000/tcp -> 0.0.0.0:5000

Network Port Mapping• -pオプションでポートマップを指定することも可能。（下図において、コンテナのPort 5000はホストのPort 15000にマッピングされるよう明示的に指定している。）

91

15000

Brid

ge 5000

eth0

Host Container

$ docker run -d --name=myapp -p 15000:5000 training/webapp python app.py $ docker port myapp 5000/tcp -> 0.0.0.0:15000

Network Port Mapping• DockerfileでEXPOSEを宣言していないコンテナの場合でも、明示的に-pオプションを指定するとポートマッピングされる。

92

5000

Brid

ge 5000

eth0

Host Container

$ docker run -d --name=myapp -p 5000:5000 busybox yes $ docker port myapp 5000/tcp -> 0.0.0.0:5000

Network Port Mapping• --net=hostオプションを指定するとコンテナはホストのネットワークを利用する。その場合、DockerfileでEXPOSEを宣言しているポートがホスト上でListenを開始する。

93

5000

eth0

Host

Container

$ docker run -d --name=myapp --net=host training/webapp python app.py $ docker port myapp

Brid

ge

Host Server

use pipework

94

Bridge (docker0)

Container

eth0 (veth)

veth

--net=bridgepipework br1 ...

eth1 (veth)

Bridge (br1)

Container

eth0 (veth)

--net=bridgepipework br1 ...

eth1 (veth)

Container

eth0 (veth)

--net=bridgepipework eth1 ...

eth1

mac

vlan

eth0 eth1

veth veth veth veth

ネットワークパフォーマンス• Linux Bridge経由の通信：ごく僅かなオーバヘッドが発生する。

• iptables経由の通信：ごく僅かなオーバーヘッドが発生する。

• コンテナ間通信：大きいオーバヘッドが発生する。

• --net=host：nativeな速度で動作する。

• SR-IOV：nativeな速度で動作する。

• macvlan：nativeな速度で動作する。

95

ネームスペースの分離• Dockerコンテナはホストとはネームスペースが分離されている

• PID: Process IDs

• Mount: mount points

• Network: network access

• UTS (Unix Time-sharing System) : hostname, domainname

• IPC: Inter-Process Communication

• User: User and Group IDs

96

PIDネームスペースの分離

97

$ ps auxww | wc -l 102

$ docker run -it ubuntu /bin/bash root@cdaa11112f53:/# ps auxww | wc -l 4

Mountネームスペースの分離

98

$ cat /proc/mounts | wc -l 31

$ docker run -it ubuntu /bin/bash root@43b9f12ca56b:/# cat /proc/mounts | wc -l 17

Networkネームスペースの分離

99

# ip addr show | egrep "UP|inet" 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN inet 127.0.0.1/8 scope host lo 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000 inet 153.120.104.254/24 brd 153.120.104.255 scope global eth0 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000 inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1 4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN inet 172.17.42.1/16 scope global docker0

$ docker run -it ubuntu /bin/bash root@8fbffca705a2:/# ip addr show | egrep "UP|inet" 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo 17: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default inet 172.17.0.4/16 scope global eth0

UTSネームスペースの分離

100

$ hostname test.example.com $ domainname example.com

$ docker run -it ubuntu /bin/bash root@8fbffca705a2:/# hostname 8fbffca705a2 root@8fbffca705a2:/# domainname example.com

http://example.com

IPCネームスペースの分離

101

$ ipcs

------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x0052e2c1 0 postgres 600 48 5 0x00000000 229377 s-yamada 700 1694000 2 dest

$ docker run -it ubuntu /bin/bash root@c739668e223a:/# ipcs

------ Message Queues -------- key msqid owner perms used-bytes messages

Userネームスペースの分離

102

$ docker run -it ubuntu /bin/bash root@c739668e223a:/# id -a uid=0(root) gid=0(root) groups=0(root)

• コンテナのUIDは実際にはホストのUID1000番台以降にマッピングされる。

cgroups• Dockerはcgroupsに対応している。

• cpu • cpuset • memory • blkio • devices • network • freezer

103

cgroupsによるリソース制限• libcontainerはcgroupsの一部機能のみ対応。

• libcontainerをcgroupsにほぼ対応させるには、systemdと連携させるのが現在のベストプラクティス。

• RHEL7のdockerはsystemdと連携してcgroupsを取り扱える。

• その他の手段：https://github.com/ibuildthecloud/systemd-docker

104

https://github.com/ibuildthecloud/systemd-docker

メディアアクセス制御機能• Linux Kernel Capabilities

• Drop mout capabilities

• Enable what a task needs

• Grsecurity and PaX

• SELinux

• AppArmor

105

106

Kernel

Server

Containers

NameSpaces• UTS• IPC• PID• User• Network• ...

cgroups• memory• cpu• blkio• devices• network• .....

NamespaceUbuntu base

nginx

NamespaceDebian base

Rails

NamespaceCentOS base

Apache2MySQLpostgresql

Host

Network• veth• bridge• iptables• ...

Storage• aufs• btrfs• devicemapper• overlayfs• ...

Security• SElinux• apparrmor• capability• Grsecurity• PaX

...

Docker EngineDocker

OS

チュートリアル

107

https://www.docker.com/tryit/

https://www.docker.com/tryit/

コンテナにしておくと少しでも便利になるケース

• ちょっとしたOSの動作確認。

• 構成管理ツールを使うとセットアップが煩雑なアプリケーション。

• 桁違いな並列度が必要とされるアプリケーション。

• 手軽にパッケージインストールできない実行バイナリのビルド。

• Cronで定期的に動くスクリプト。

108

コンテナを使わないほうがいいケース• ステートフルなwebアプリケーション。

• 堅牢なデータ永続化が必須なアプリケーション。

• シビアなI/O処理性能やパケット処理が必要なアプリケーション。

• 頻繁にクラッシュするアプリケーション。

• アプリケーションのアップデート方法を一切検討していない場合。

• 障害の発生やデータロストを前提として考慮していない場合。

109

複数台のプロビジョニング• 自身でコンテナを定義する場合

• Docker Compose(Fig), Maestro-NG, Ansible, Chef, etc... • APIライク

• Mesos(+ Marathon), Kubernetes, Helios • PaaSライク

• Flynn, Deis, CloudFoundry, Dokku, Tsuru, OpenShift • OpenStack (because OpenStack can do everything!)

110

ログのルーティング

• 数台のコンテナ相手ならjournarlctlだけでも頑張れる。

• 数十台のコンテナ相手になってくると、volumeコンテナに集約しつつ、rsyslogで飛ばすだけでも頑張れなくもないけどツラい。

• 手軽にスケールしそうなのは、LogSpout + fluentd + LogEntires or elasticserch?

111

コンテナの監視に関する課題• リソース（CPU, Mem, trafic）の可視化は必要。

• 最低限の外系監視（Ping, HTTP, HTTPS, TCP/UDP）も必要。

• コンテナ自体がプロセスみたいなものなのでプロセス監視は概ね不要。

• その他、コンテナの種類に応じて各種リソースの監視が必要。

• 各種レスポンス・遅延、各種サイズ、同時接続数。

• 比較的手軽なエージェントはsensuとdatadogくらい？

• とは言うものの、コンテナの場合は監視の必要がないアプリケーションも多い・・・

112

ストレージの外部化• ボリュームコンテナを作成して利用すればUID/GIDは崩れない。

• 手法を誤るとUID/GIDのマッピングが崩れる。

• 特定の要件においてのみ有効なワークアラウンド

• /var/lib/dockerを専用のストレージにmountする。

• 対象コンテナに特定のストレージを専用に割り当てる。

113

セキュリティ• 当然、Dockerでも脆弱性を突かれて、最悪の場合はホストのroot権限を奪取される可能性はある。

• これは、Docker単体で防ぎきれる問題とは考えないほうがいい。

• 悪意ある第三者に脆弱性を突かれたとしても、SELinuxやAppArmorを適切に設定していれば被害は最小限に食い止められる。

• これはKVMのような仮想化技術やLinuxの各種デーモンでも同じ。

114

その他の補足とか• buildするときやpullするときはキャッシュに注意する。

• 挙動が怪しいときは--no-cacheを指定してbuildする。

• pullしてきたイメージが古い内容だと思ったら、イメージのハッシュとタイムスタンプを確認する。

• Dockerデーモンが中途半端にdownしていないか注意する。

• 最悪、Dockerデーモンを再起動してみる。

• 稀に、自分のローカルPCでbuildしたときとDockerHubでAutomated buildしたときとでは微妙に挙動が異なるアプリケーションもあったりする・・・

115

その他の補足とか• 別に1コンテナあたり1アプリケーションでなくてもいい。

• コンテナに固定IPアドレスを振るのは結構手間。

• コマンドを駆使すればもっと複雑なこともできるんだろうけど手間・・・

• 中途半端に残っているコンテナやイメージは自分で消すしかない・・・

• データの永続化が必要なものはコンテナ内以外の場所に保存したほうがいい。ブロックストレージでもS3でもRDSでもいい。

• そういうコンテナはLXCでコンテナ化しちゃうのだってありだと思う。

116

117

in

UseCase

Server Newreliccontainer

Send Status

Newrelic

118

*.tf CI-Service(CircleCI, travis)

Push Test

GitHub

UseCase

ssh&&

*.tf pull

apply

DNS-Service (Route53, DNSimple)

Terraformcontainer

119

UseCase

ssh-keychain servercontainer

Online-Storage (Amazon S3, etc...)

POSTClient

GET, POST

ServerGET, POST

What?

120

それ普通のサーバでもできるよ• Yes, コンテナが果たす役割はアプリケーションと何ら変わらない。

• でも、アプリケーションがDockerイメージによってパッケージ化されることでセットアップが迅速かつ簡単になったり、異なるサーバへのアプリケーション移行作業も比較的容易になった。

• コンテナとしてパッケージをあらかじめイメージ化することで、アプリケーションセットアップ作業のムダと各作業者ごとの作業のムラを省いてる。

121

• 従来型のサーバ管理やアプリケーションからの思考転換が必要。

• コンテナ型技術のアーキテクチャ自体への理解。

• アプリケーション設計と構成管理手法の転換。

• Container != Server

• ただし、従来的なLinuxシステム管理や、細かなチューニング作業から逃げきれるわけではない。

まとめ

https://www.flickr.com/photos/kzys/838011150/122

https://www.flickr.com/photos/kzys/838011150/

• 動かすだけなら簡単。だけど、まだ全然枯れてない。

• 日本語ドキュメントが少ない。

• 管理ツール類やサービスが揃いきっていない。

• 自分で調べて自分で組み立てたりしないといけないことが多い。

• たぶん、この資料自体もすぐに古い内容になってしまう。

まとめ



• もう十分にトレンドっぽいし、今後のデファクトスタンダードになることも規定路線っぽいけど、Dockerはまだまだ国内の一部のエンジニアにしか知られていない。（と思う。）

• 本格的なデファクトスタンダードになるには、より多くの貢献者とエネルギーがDockerには必要。

• 未来の貢献者は誰？YOUでしょ？

まとめ



125

FAQ?



2015-01-27 introduction to docker

Technology