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

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

© SIOS Technology, Inc. All rights Reserved. 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

© SIOS Technology, Inc. All rights Reserved. コンテナとは︖ 4 Internal
Only ίϯςφͱ͸ʁ コンテナとは、平たく⾔ってしまえば、単なるプロセスです。

Only Կ͕Ͱ͖Δͷʁ OSの中にOSが⽴てられます。 $FOU04 ϗετ04 8FCαʔόʔ༻$FOU04 σʔλϕʔε༻$FOU04 ϑΝΠϧαʔόʔ༻$FOU04 似たようなのに仮想化ってあったような・・・。

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

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

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

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

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

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

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

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

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

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

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のプロセスしかないです。

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(コンテナ)を作ります。

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

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

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

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

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

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$

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

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

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のインストール

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

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

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です。

© SIOS Technology, Inc. All rights Reserved. Dockerのネットワーク 31 Internal
Only Dockerのネットワークは以下のようになっています。

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

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

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

Only Netowork Namespaceがあると。。。

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

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

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

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

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

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が出来ました。

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

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

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 br-veth2 up # ip link set br-veth3 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アドレスの付与

Only こうなります。

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 ・・・以下略・・・

Only GoogleのパブリックDNSにPing打ってみます。 # ip netns exec ns1 ping 8.8.8.8 connect: Network is unreachable

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

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

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

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

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

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

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のアドレスに変更するという内容です。

Only 再び動作確認︕︕ # ip netns exec ns1 ping 8.8.8.8 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 ・・・以下略・・・

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

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

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

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

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

Only docker0というのは、Dockerをインストールしたときにデフォルトで作成される仮想スイッチです。特に何も指定せずコンテナを作成すると、このdocker0に接続されます。新しく2つのコンテナを作成したので、「veth9f0eb93」「veth7010a0b」という新たに 2つの仮想NICが出来上がっています。 # ip addr show ・・・略・・・ 5: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 valid_lft forever preferred_lft forever 32: veth9f0eb93@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 valid_lft forever preferred_lft forever 34: veth7010a0b@if33: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 valid_lft forever preferred_lft forever

Only docker0の仮想スイッチに接続されている仮想NICを⾒てみます。確かに先程の「veth9f0eb93」「veth7010a0b」という仮想NIC がdocker0という仮想スイッチに接続されているのがわかります。 # ip link show master docker0 32: veth9f0eb93@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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

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

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

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

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

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

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

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

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

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

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

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

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

Only 開発環境 ϓϥΠϕʔτ ϦϙδτϦ ここをKubernetesにします。システム管理者 Kubernetes ᶃ ᶄ ᶅ ᶆ

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

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

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

More Decks by Noriyuki TAKEI

Other Decks in Technology

Featured

Transcript