世界一わかりみの深いコンテナ＆Docker＆Kubernetes入門

© SIOS Technology, Inc. All rights Reserved.
世界⼀わかりみの深い
コンテナ＆Docker⼊⾨
武井宜⾏

View Slide

About me
2
Internal Only
BCPVUNF
Noriyuki TAKEI
෢Ҫ ٓߦ
Information
• サイオステクノロジー株式会社
• クラウドネイティブアプリケーション
• 千葉県在住
Favorites
• Azure
• Squash
• Sweets
blog
https://tech-lab.sios.jp/
core skill
Azure Kubernetes Service
Docker

View Slide

コンテナとは︖
3

View Slide

4
Internal Only
ίϯςφͱ͸ʁ
コンテナとは、
平たく⾔ってしまえば、
単なるプロセスです。

View Slide

5
Internal Only
Կ͕Ͱ͖Δͷʁ
OSの中にOSが⽴てられます。
$FOU04 ϗετ04

8FCαʔόʔ༻$FOU04
σʔλϕʔε༻$FOU04
ϑΝΠϧαʔόʔ༻$FOU04
似たようなのに
仮想化ってあっ
たような・・・。

View Slide

6
Internal Only
Ծ૝Խͱͷҧ͍
ホストOS
HyperVisor
OS OS
プロセス
プロセス
プロセス
プロセス
Docker
Engine
プロセスプロセス
Ծ૝Խ
ίϯςφ
プロセス
プロセス
プロセス
プロセス
コンテナはOSが
不要な分だけ
⾼速︕︕

View Slide

7
Internal Only
Ծ૝Խͱͷҧ͍
ホストOS
HyperVisor
OS OS
プロセス
プロセス
プロセス
プロセス
Docker
Engine
プロセス
プロセス
プロセス
プロセス
カーネル
Docker上のプロセスとホストOS上のプロセスはカーネルを共有します。

View Slide

8
Internal Only
以下のような2つのアプリケーションを⼀つの
ホストOS上に構築することを考えてみます。
var
www
html
/
echo “hoge”;
?>
ΞϓϦ
app.phpの
所有者は
www-data(id=33)
app.php
var
www
html
/
echo “fuga”;
?>
ΞϓϦ
app.phpの
所有者は
www-data(id=33)
app.php

View Slide

9
Internal Only
ホストOS
HyperVisor
OS
var
www
html
/
echo “hoge”;
?>
ΞϓϦ
app.phpの
所有者は
www-data(id=33)
app.php
OS
var
www
html
/
echo “fuga”;
?>
ΞϓϦ
app.phpの
所有者は
www-data(id=33)
app.php
仮想化だったら簡単︕︕

View Slide

10
Internal Only
ホストOS
Docker Engine
var
www
html
/
echo “hoge”;
?>
ΞϓϦ
app.phpの
所有者は
www-data(id=33)
app.php
var
www
html
/
echo “fuga”;
?>
ΞϓϦ
app.phpの
所有者は
www-data(id=33)
app.php
コンテナではどうやるの︖
ユーザー名
かぶってるし
ファイル名
かぶってるし

View Slide

11
Internal Only
そこで
コンテナでは超重要な概念である
の出番です。
namespace

View Slide

12
Internal Only
OBNFTQBDFͱ͸ʁ
プロセス、ファイル構造、ユーザーID、グループIDなどを⼀つのOSの中で分離す
る技術である。
プログラム⾔語の中ではよく登場する概念である。Javaのパッケージと⾔う概念と
にているものがあり、同⼀の名称を使いたい場合(例えばUser.java)、namespace
を分けると実現可能となる。
package jp.sios.funcA
User.java
package jp.sios.funcB
User.java
コンテナのコアテクノロジーであるnamespaceという技術は2006年あたりにLinux
カーネルに実装された技術であり、最新の技術ではない。

View Slide

13
Internal Only
ホストOS
apache(親)
apache(⼦) apache(⼦)
pid 1
/
www
html
ファイル
システム
initプロセス
pid 2
プロセス
namespace A
apache(親)
/
www
html
プロセス
ファイル
システム
pid 1
pid 3
namespace B
pid 2 pid 3 pid 2 pid 3
namespaceが異なれば同
じファイル名やディレクト
リが⼀つのOS上に作れる。
pid 1

View Slide

14
Internal Only
ホストOS
apache(親)
pid 1
/
www
html
ファイル
システム
initプロセス
pid 2
プロセス
namespace A
apache(親)
/
www
html
プロセス
ファイル
システム
pid 1
pid 1
pid 3
namespace B
pid 2 pid 3 pid 2 pid 3
このnamespace
で区切られた部分
がコンテナ

View Slide

15
Internal Only
では
namespace(コンテナ)
を
作ってみよう

View Slide

16
Internal Only
# ps ax
PID TTY STAT TIME COMMAND
1 ? Ss 0:03 /sbin/init
2 ? S 0:00 [kthreadd]
4 ? I< 0:00 [kworker/0:0H]
6 ? I< 0:00 [mm_percpu_wq]
7 ? S 0:00 [ksoftirqd/0]
8 ? I 0:01 [rcu_sched]
…………
# unshare --mount-proc -p --fork /bin/bash
# ps ax
PID TTY TIME CMD
1 pts/0 00:00:00 bash
11 pts/0 00:00:00 ps
namespaceを作成する前は、
プロセスがたくさんあります。
namespace作成にはunshareコマンドを使います。
namespaceを作成したあと
は、プロセス空間が別になる
ので、bashのプロセスしか
ないです。

View Slide

17
Internal Only
参考︓コンテナ技術⼊⾨
https://employment.en-japan.com/engineerhub/entry/2019/02/05/103000
$ ROOTFS=$(mktemp -d)
$ CID=$(sudo docker container create centos:centos7)
$ sudo docker container export $CID | tar -x -C $ROOTFS
$ ln -s /usr/local/bin/bash $ROOTFS/bin/bash
$ sudo docker container rm $CID
$ UUID=$(uuidgen)
$ sudo cgcreate -t $(id -un):$(id -gn) -a $(id -un):$(id -gn) -g cpu,memory:$UUID
$ cgset -r memory.limit_in_bytes=10000000 $UUID
$ cgset -r cpu.cfs_period_us=1000000 $UUID
$ cgset -r cpu.cfs_quota_us=300000 $UUID
$ CMD="/bin/sh"
$ cgexec -g cpu,memory:$UUID \
unshare -muinpfr /bin/sh -c "
mount -t proc proc $ROOTFS/proc &&
touch $ROOTFS$(tty); mount --bind $(tty) $ROOTFS$(tty) &&
touch $ROOTFS/dev/pts/ptmx; mount --bind /dev/pts/ptmx $ROOTFS/dev/pts/ptmx &&
ln -sf /dev/pts/ptmx $ROOTFS/dev/ptmx &&
touch $ROOTFS/dev/null && mount --bind /dev/null $ROOTFS/dev/null &&
/bin/hostname $UUID &&
exec capsh --chroot=$ROOTFS --drop=cap_sys_chroot -- -c 'exec $CMD'
"
ファイルシステムやユーザー空間まで分けた実⽤的なCentOS7のnamespace(コ
ンテナ)を作ります。

View Slide

18
Internal Only
ホストOS
namespace
/
先のコマンドは、以下の2つのことを
実施しています。
bin
etc
var
log
spool
・・・
/
bin
etc
var
log
spool
・・・
CentOS7の動作
に必要なファイ
ルを取得
namespaceの作
成

View Slide

19
Internal Only
こんなにたくさんの
コマンド打つの
めんどくさい・・・

View Slide

20
Internal Only
Dockerを使えば解決
たった1⾏のコマンドで、
先程のダラダラ⻑いコマンドと同じことが
実現出来ます。
$ docker run -it centos:centos7 /bin/bash

View Slide

21
Internal Only
namespaceの作成その他コンテナ作成に必要な
もろもろのコマンドの簡略化
コンテナを作成するの必要なOSのイメージを
Docker Hubからダウンロード
つまり
Dockerで実現できることは
主に以下の2つ

View Slide

22
Internal Only
ところで
Docker Hubって
なに︖

View Slide

23
Internal Only
%PDLFS)VCͱ͸ʁ
%PDLFS)VC
CentOS
6
/
bin
etc
・・・
7
/
bin
etc
・・・
8
/
bin
etc
・・・
Ubuntu
16.0
/
bin
etc
・・・
18.0
/
bin
etc
・・・
19.0
/
bin
etc
・・・
etc
・・・
bin
etc
・・・
8
/
bin
etc
・・・
CentOS
ホストOS
namespace
$ docker run -it centos:centos8 /bin/bash
ダウンロードしてくるイメー
ジを指定
イメージをダウ
ンロード
1$

View Slide

24
Internal Only
Dockefileを
使うと
コンテナをカスタマイズ
できます︕︕

View Slide

25
Internal Only
Dockerfile
FROM centos:centos7
RUN yum –y install httpd
CentOS7のイメージにApacheをインストールしてみます。そのた
めのDockerfileは以下のとおりです。
CentOS7のイメージをダウンロード
Apacheをインストール

View Slide

26
Internal Only
%PDLFS)VC
CentOS
6
/
bin
etc
・・・
7
/
bin
etc
・・・
8
/
bin
etc
・・・
etc
・・・bin
etc
・・・
7
/
bin
etc
・・・
CentOS
ホストOS
namespace
$ docker build -t web.
イメージをダウ
ンロード
Dockerfileを作成し、以下のコマンドを実⾏すると、CentOS7のイ
メージ上にApacheがインストールされたコンテナが作成されます。
1$
var
httpd
Apacheの
インストール

View Slide

27
Internal Only
etc
・・・bin
etc
・・・
7
/
bin
etc
・・・
CentOS
ホストOS
namespace
$ docker push XXX.azurecr.io/web:1.0
さらに作成したコンテナをもとにプライベートリポジトリにオリジナ
ルイメージとしてプッシュ出来ます。
1$
var
httpd
ϓϥΠϕʔτ
ϦϙδτϦ
web
etc
・・・bin
etc
・・・
1.0
/
bin
etc
・・・
var
httpd

View Slide

28
Internal Only
さらにプライベートリポジトリにプッシュしたイメージを他の開発者
に配ることも出来ます。
ϓϥΠϕʔτ
ϦϙδτϦ
web
etc
・・・bin
etc
・・・
1.0
/
bin
etc
・・・
var
httpd
։ൃऀ"
։ൃऀ#
։ൃऀ$

View Slide

29
Internal Only
Dockerfile
FROM centos:centos7
ENV idp_version=3.4.6
# Inatall the libraries neccesary for building Shibboleth IdP
RUN yum -y update && \
yum -y install wget java-1.8.0-openjdk
# Download Shibboleth IdP
RUN wget -q https://shibboleth.net/downloads/identity-provider/$idp_version/shibboleth-identity-
provider-$idp_version.tar.gz && \
tar -zxvf shibboleth-identity-provider-$idp_version.tar.gz -C /opt && \
ln -s /opt/shibboleth-identity-provider-$idp_version/ /opt/shibboleth-idp
COPY bin/ /usr/local/bin/
RUN chmod 750 /usr/local/bin/init-idp.sh
もっと複雑な環境を構築するためにDockerfileです。

View Slide

Dockerのネットワーク
30

View Slide

31
Internal Only
Dockerのネットワークは以下のようになっています。

View Slide

32
Internal Only
こう考えるとわかりやすい︖Dockerのネットワークを物理サーバ
ーに置き換えてみました︕︕

View Slide

33
Internal Only
Network
Namespace
ルーティングテーブルなどネットワークを動作させる
のに必要な機能が完全に分離された環境を作るための
ものです。
Dockerのネットワークを構成しているコアな技術は以下の3つ︕︕
仮想スイッチ
PC内で物理のL2スイッチと同じように振る舞うのが
仮想スイッチと⾔われるものです。これもカーネルが
持っている機能で、ip linkコマンドで作成することが
できます。
仮想
ネットワーク
インターフェース
仮想的なネットワークインターフェースで、ip link
addコマンドで作成することができます。

View Slide

34
Internal Only
Netowork Namespaceってなに︖Network Namespaceがない状
態で仮想NICを2つ作ると。。。

View Slide

35
Internal Only
Netowork Namespaceがあると。。。

View Slide

36
Internal Only
実際にネットワークを作ってみましょう︕︕Dockerコマンドを使
うとラクチンですが、あえてそれは使わないでやってみます。でも
いまから説明することは、知らないうちにDockerコマンドが裏側
でやっています。今回のゴールは以下のネットワークを作成するこ
とです。

View Slide

37
Internal Only
最初はなにもない以下のような状態です。

View Slide

38
Internal Only
Network Namespaceを作成します。
# ip netns add ns1
# ip netns add ns2
Network Namespaceが出来
ました。

View Slide

39
Internal Only
次に仮想スイッチを作成します。
# ip link add br0 type bridge
仮想スイッチが出来ました。

View Slide

40
Internal Only
以下の仮想ネットワークインターフェースを作成します。
ns-veth1
先程作成したNetwork Namespaceであるns1の⽅に接続
される仮想NIC
br-veth1
ns-veth1とペアで作成され、仮想スイッチに接続される仮
想NIC
ns-veth2 先程作成したNetwork Namespaceであるns2の⽅に接続
される仮想NIC
br-veth2
ns-veth2とペアで作成され、仮想スイッチに接続される仮
想NIC
rt-veth 物理NICとルーティングされる仮想NIC
br-veth3
rt-vethとペアで作成され、仮想スイッチに接続される仮想
NIC

View Slide

41
Internal Only
# ip link add name ns-veth1 type veth peer name br-veth1
# ip link add name ns-veth2 type veth peer name br-veth2
# ip link add name rt-veth type veth peer name br-veth3
仮想NICが出来ました。

View Slide

42
Internal Only
Network Namespaceに仮想ネットワークインターフェースを接続
します。
# ip link set ns-veth1 netns ns1
# ip link set ns-veth2 netns ns2 接続出来ました。

View Slide

43
Internal Only
仮想スイッチに仮想ネットワークインターフェースを接続します。
# ip link set dev br-veth1 master br0
接続出来ました。

View Slide

44
Internal Only
仮想NICと仮想スイッチをUpをしたり、IPアドレスを付与したり
します。
# ip netns exec ns1 ip link set ns-veth1 up
# ip netns exec ns2 ip link set ns-veth2 up
# ip link set rt-veth up
# ip link set br-veth1 up
# ip link set br0 up
# ip netns exec ns1 ip addr add 192.168.0.1/24 dev ns-veth1
# ip netns exec ns2 ip addr add 192.168.0.2/24 dev ns-veth2
# ip addr add 192.168.0.100/24 dev rt-veth
■ 仮想NICと仮想スイッチのUp
■ IPアドレスの付与

View Slide

45
Internal Only
こうなります。

View Slide

46
Internal Only
動作確認します。
# ip netns exec ns1 ping 192.168.0.2
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.071 ms
・・・以下略・・・

View Slide

47
Internal Only
GoogleのパブリックDNSにPing打ってみます。
connect: Network is unreachable

View Slide

48
Internal Only
IP転送が有効になっていない
原因は以下の3つ・・・
Network Namespace内で
デフォルトゲートウェイが設定されてない
NATされていない

View Slide

49
Internal Only
IP転送が有効になっていない

View Slide

50
Internal Only
IP転送が有効になっていない → これで解決︕︕
# echo 1 > /proc/sys/net/ipv4/ip_forward

View Slide

51
Internal Only
Network Namespace内でデフォルトゲートウェイが設定されてな
い
ここをns1とns2のデ
フォゲにする必要がある。

View Slide

52
Internal Only
, 2., 25

Network Namespace内でデフォルトゲートウェイが設定されてな
い → これで解決︕︕
# ip netns exec ns1 ip route add default via 192.168.0.100
# ip netns exec ns2 ip route add default via 192.168.0.100

View Slide

53
Internal Only
NATされていない
ns1というNetwork Namespaceから8.8.8.8あてのパケットの送信元IPアドレ
スと宛先IPアドレスは以下のようになっています。
送信元IPアドレス 192.168.0.1
宛先IPアドレス 8.8.8.8
このアドレスでは外部ネットワークへは届きません。送信元IPアドレスがプライ
ベートアドレスだからです。インターネットに出るときには、送信元を物理NIC
のIPアドレスに変換する必要はあります。つまりNATする必要があります。
送信元IPアドレス物理NICのIPアドレス
宛先IPアドレス 8.8.8.8

View Slide

54
Internal Only
NATされない → これで解決︕︕
# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
ルーティングが終わった後に、送信元が192.168.0.0/24で、かつeth0という
ネットワークデバイスから出ていくパケットの送信元アドレスをeth0のアドレ
ス、つまり物理NICのアドレスに変更するという内容です。

View Slide

55
Internal Only
再び動作確認︕︕
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=127 time=12.9 ms
・・・以下略・・・

View Slide

56
Internal Only
ちなみに外部ネットワークへのパケットはこのように流れています。
まずNetwork Namespaceのns1から出たパケットは、宛先が
192.169.0.0/24宛ではないので、先程設定したデフォルトゲート
ウェイの設定により、rt-veth(192.168.0.100)に向かいます。

View Slide

57
Internal Only
IP転送の設定によるrt-vethから物理NICにルーティングされます。

View Slide

58
Internal Only
iptablesコマンドで⾏ったNATの設定により、送信元IPアドレスが
物理NICのIPアドレスに変換されます。

View Slide

59
Internal Only
パケットがインターネットに出ていきます。

View Slide

60
Internal Only
ちなみにDockerなら以下のコマンドで⼀発でネットワーク構築で
きる︕︕
# docker run -it -d --name test01 centos:centos7
# docker run -it -d --name test02 centos:centos7

View Slide

61
Internal Only
docker0というのは、Dockerをインストールしたときにデフォル
トで作成される仮想スイッチです。特に何も指定せずコンテナを作
成すると、このdocker0に接続されます。新しく2つのコンテナを
作成したので、「veth9f0eb93」「veth7010a0b」という新たに
2つの仮想NICが出来上がっています。
# ip addr show
・・・略・・・
5: docker0: mtu 1500 qdisc noqueue state UP
group default
link/ether 02:42:be:19:a5:0e brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:beff:fe19:a50e/64 scope link
32: veth9f0eb93@if31: mtu 1500 qdisc noqueue
master docker0 state UP group default
link/ether fa:43:35:64:5a:8b brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::f843:35ff:fe64:5a8b/64 scope link
34: veth7010a0b@if33: mtu 1500 qdisc noqueue
master docker0 state UP group default
link/ether 2e:f1:f5:7d:0f:0e brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::2cf1:f5ff:fe7d:f0e/64 scope link

View Slide

62
Internal Only
docker0の仮想スイッチに接続されている仮想NICを⾒てみます。
確かに先程の「veth9f0eb93」「veth7010a0b」という仮想NIC
がdocker0という仮想スイッチに接続されているのがわかります。
# ip link show master docker0
32: veth9f0eb93@if31: mtu 1500 qdisc noqueue
master docker0 state UP mode DEFAULT group default
link/ether fa:43:35:64:5a:8b brd ff:ff:ff:ff:ff:ff link-netnsid 0
34: veth7010a0b@if33: mtu 1500 qdisc noqueue
master docker0 state UP mode DEFAULT group default
link/ether 2e:f1:f5:7d:0f:0e brd ff:ff:ff:ff:ff:ff link-netnsid 1

View Slide

63
Internal Only
では、各コンテナのデフォルトゲートウェイも調べてみましょう。
docker inspectコマンドでコンテナの詳細情報を⾒ることが出来ま
す。–formatオプションを使うと、出⼒する情報を整形出来ます。
デフォルトゲートウェイの情報のみを出すように整形してみます。
# docker inspect --format '{{.NetworkSettings.Gateway}}' test01
172.17.0.1
# docker inspect --format '{{.NetworkSettings.Gateway}}' test02
172.17.0.1

View Slide

仮想化との違い
64

View Slide

65
Internal Only
開発環境の構築を例に
仮想化との違いを
考えてみます。

View Slide

66
Internal Only
Ծ૝Խͷ৔߹
package jp.sios.funcB
User.java
開発環境
システム管理者
システム構成が変更になったので、開発
エンジニアの⽅は、この⼿順書に従って、
環境を変更して下さーい。

View Slide

67
Internal Only
Ծ૝Խͷ৔߹
開発環境
あれ、開発環境がうまく動かない・・・。
あっ、⼿順書通りに実施していなかっ
た・・・。

View Slide

68
Internal Only
ίϯςφͷ৔߹
開発環境
Dockerイメージダウ
ンロード
ϓϥΠϕʔτ
ϦϙδτϦ
Dockerイメージから
コンテナを⽣成
システム構成が変更になっ
たDockerイメージをレポジ
トリからにプッシュ

View Slide

69
Internal Only
コンテナを⽤いると開発環境の構築において以下のようなメリットが
あります。
開発者のPCにDockerさえインストールされていれ
ば、イメージをダウンロードするだけで環境ができ
あがるので、ミスがない
コンテナはカーネルを含まず軽量なのでダウンロー
ドが速い。よって可搬性がよい。

View Slide

70
Internal Only
開発環境だけでなく
本番環境にも
コンテナを持っていたら
便利だと思いませんか︖

View Slide

71
Internal Only
開発環境
Dockerイメージダウ
ンロード
ϓϥΠϕʔτ
ϦϙδτϦ
修正したDockerイ
メージをプッシュ
システム構成が変更になっ
たDockerイメージをレポジ
トリからにプッシュ
本番環境
Dockerイメージから
本番環境のコンテナ
を⽣成
ᶃ
ᶄ ᶅ
ᶆ

View Slide

72
Internal Only
開発環境
ϓϥΠϕʔτ
ϦϙδτϦ
①〜④はOSまで含む環境
なので、開発環境でも本番
環境でも、その動作に違い
はない。
本番環境
ᶃ
ᶄ ᶅ
ᶆ

View Slide

73
Internal Only
つまり、本番環境にコンテナを⽤いると、以下のようなメリットがあ
ります。
本番環境も検証環境も、OSまで含めた同じイメー
ジを使うので、全く同じように動作する。仮想化で
ありがちな、本番環境と検証環境の動作の差異がな
い。
コンテナはホストOSのカーネルを共有し、OSのイ
メージのみのため、サイズが⼩さく、可搬性がよい。
リポジトリからのダウンロードもすぐに終わる。

View Slide

74
Internal Only
でも、本番環境では
いろんなことを
考慮しなければ
なりません。

View Slide

75
Internal Only
例えば、、、
負荷分散
無停⽌更新
監視
ネットワーク管理(ルーティングなど)
他にもたくさん、、、、

View Slide

76
Internal Only
それ、全部
Kubernetes
が解決します︕︕

View Slide

77
Internal Only
開発環境
ϓϥΠϕʔτ
ϦϙδτϦ
ここをKubernetesにします。
Kubernetes
ᶃ
ᶄ ᶅ
ᶆ

View Slide

さいごに
78
Internal Only
ؔ࿈ϒϩά
【連載】世界⼀わかりみが深いコンテナ & Docker⼊⾨
https://tech-lab.sios.jp/archives/18811

View Slide

ご清聴ありがとうございました

View Slide

世界一わかりみの深いコンテナ＆Docker＆Kubernetes入門

世界一わかりみの深いコンテナ＆Docker＆Kubernetes入門

Noriyuki TAKEI

More Decks by Noriyuki TAKEI

Other Decks in Technology

Featured

Transcript