Dockerの基本的な話

グリー社内勉強会「Mini Tech Talk」発表資料 (20150327)

Dockerの基本的な話 / 足立 紘亮(@foostan)

※「Mini Tech Talk」とは、グリー社内で毎週金曜のランチタイムを利用して開催されている技術勉強会です

Transcript

1. Dockerの基本的な話 GREE Mini-tech talk #76 Infrastructure Service Unit 足立 紘亮
2. 話すこと - Dokcerの基本的な使い方 - Dockerの利用事例 - Docker関連ツールの紹介 - Dockerの問題点と今後の課題
3. Dockerとは？
4. DOTCLOS BECOMING DOCKER, INC. • https://blog.docker.com/2013/10/dotcloud-is-becoming-docker-inc/ • http://blog.dotcloud.com/dotcloud-paas-joins-cloudcontrol 社名変更(dotcound, inc. -> docker, inc.) PaaS事業売却 dotCloudで利用されていたDockerを切り出して社名を変更 その後、dotCloudを売却し、Docker, Inc. はDockerに専念
5. https://www.docker.com/ より転載
6. Docker Engine Docker Hubができるまで `Docker` と呼ばれていたもの (現在も単に `Docker` というとこれを指すことが多い) 特徴 アプリケーションのパッケージング アプリケーションを隔離空間で実行
7. パッケージング • ランタイム、ミドルウェア、アプリケーションをひとまとめにする (Docker imageを作る) • Docker imageはDocker Engineがあればどこでも動かせる ◦ 物理/VM、開発環境/本番環境、オンプレ/クラウドなどの環境に縛ら れない
8. 隔離空間で実行 • Namespaceによる隔離 ◦ PID: プロセス空間の隔離 ◦ MNT: ファイルシステムのマウント空間の隔離 ◦ IRC: 共有メモリやセマフォなどの隔離 ◦ UTS: uname() システムコールで取得できる情報の隔離 ◦ NET: ネットワークの隔離 • Cgroupによる隔離 ◦ cpu ◦ cpuset ◦ memory ◦ device 参考: http://blog.etsukata.com/2014/05/docker-linux-kernel.html
9. https://www.docker.com/whatisdocker/ より転載 VMとの違い • VM: `マシン` を仮想化して、その上 にGuestOSをインストールしアプ リを動かす • Docker(コンテナ): 実行空間を隔離 してアプリを動かす • VMの良いところ ◦ 物理と同様の使い勝手 • Dockerの良いところ ◦ 軽量 ◦ 速い ◦ オーバーヘッドが少ない
10. Docker Hub Docker, Inc. が運営する公式のDokcer Reposioty 特徴 Docker imageの共有 Automated Builds
11. 共有 • 100(2015/03/27現在)の公式(Docker, Inc.が作成した)イメージ • ベンダー謹製イメージ(e.g. Oracle http://www.oracle.com/us/corporate/press/2415507 ) https://registry.hub.docker.com/
12. Automated Builds • GitHubにDockerfileを設置 • Pushでフックされて自動ビルド -> 共有
13. Dockerの使い道
14. どのような用途で使われている か • Continuous Integration ◦ テスト(CI)を回すときに利用する事例 ◦ 依存しているライブラリやソフトウェアをパッケージ ングしておいて、クリーンな環境でのテストを瞬時に 行う • Easy Application Deployment ◦ デプロイを簡易化する事例 ◦ パッケージングされたイメージをアップロードして起 動するだけで済む 参考: https://www.docker.com/resources/usecases/
15. どのような用途で使われている か • Distributed applications to scale ◦ マイクロサービスと合わせる事例 ◦ 多くのサービスを容易にスケール可能としている • Platform-as-a-Service (PaaS) ◦ PaaSで提供するライブラリやソフトウェアをパッケー ジングしておいて、瞬時に提供することが可能 参考: https://www.docker.com/resources/usecases/
16. • サブドメインと立ち 上げるブランチを指 定すると、そのサブ ドメインのURLで開 発環境がたちあがる $ curl http://docker.myapp.example.net/api/launch ¥ -d subdomain=cool ¥ -d branch=feature/cool-cool-cool ¥ -d image=myapp:latest http://tech.kayac.com/archive/mirage_for_docker.html より転載 Dockerで非エンジニアでも開発環境を上げ下げできる、 mirageというツールを作りました(面白法人カヤック様)
17. Dockerでffmpegもimagemagickも怖くないという話(クックパ ッド様) • 動画変換の仕組みでDockerを利用 • 動画変換にはコンパイルやセットアップが面倒とされている、 ffmpegとimaemagickを利用している • Dockerにてこれらがセットアップ済みのイメージを作成して、イ ンスタンスを作成する際にpullして使っている • DockerイメージはJenkinsでCIしていて常に最新の状態が維持され る 参考: http://techlife.cookpad.com/entry/ffmpeg_and_imagemagick_setup_with_docker
18. Dockerの始め方
19. Mac/Windowsでとりあえず使うためには • Boot2Docker ◦ Virtual Box上にDocker用VMを立ち上げる ◦ API経由でMac/Windowns上でDockerが動いているように見せてる • Vagrantで任意のOS + Docker Provisioner ◦ Docker Provisionerで起動時(provision)に最新のDockerがインスト ールされる ◦ Dockerのインストールにそこそこ時間がかかる • VagrantでCoreOS ◦ CoreOSは標準でDockerが入っている(後述)
20. Dockerの使い方
21. DEMO: nginxを起動してみる $ docker run -d -p 10080:80 nginx $ docker exec -it {コンテナID} /bin/bash docker-demo $ echo "Hello Docker." > /usr/share/nginx/html/index.html docker-demo $ exit $ curl 127.0.0.1:10080 Hello Docker!
22. DEMO: MySQLを起動してみる $ docker run -e MYSQL_ROOT_PASSWORD="pass" -p 13306:3306 -d mysql $ mysql -h 127.0.0.1 -P 13306 -uroot -ppass
23. DEMO: JIRAを起動してみる $ docker run -d -p 10081:8080 atlassian/jira $ curl 127.0.0.1:10081
24. DEMO: Imageを作ってみる $ vim Dockerfile FROM golang WORKDIR /go RUN go get github.com/hashicorp/consul WORKDIR /go/src/github.com/hashicorp/consul RUN make ENTRYPOINT ["consul"] $ docker build -t consul . ~ 省略 ~ $ docker run -i --rm consul
25. Docker向け軽量OS
26. メリット • 最低限のパッケージで構成されている ◦ インストールや設定の作業時間が短い ◦ ベースOSのディスク使用量が少ない ◦ セキュリティーアップデートなどの運用負荷が少ない • 最低限のサービス（機能）のみが動作する ◦ ベースOSのCPU、メモリ等のリソース使用量が少ない ◦ サービスが少ないため、脆弱性のリスクが軽減される • リソースの空き容量が多くなる ◦ より多くのコンテナを起動できる http://thinkit.co.jp/story/2015/03/06/5672 より転載
27. 特徴 • パッケージの管理コマンドが存在しない Docker向けOSには、パッケージ管理コマンド（yumやapt）が存在しない。これは機能を追加する際には、パッケージのインスト ールではなく、コンテナを起動して実現することが前提となっているためと考えられる。この一般的なOSとの差異は、基本点に 全てのDocker向けのOSに共通する概念である。 • ファイルシステムの大部分が読み込み専用 ベースOSのファイルシステムは、コンテナを格納する領域以外の大部分が読み込み専用となっている。これも前項の前提と同じ で、必要な機能はコンテナの起動で実現するため、更新が不要なベースOS部分を保護するためにこのようになっていると考えら れる。 • Dockerを管理するための必要なコンポーネントが標準で提 供されている 必要なコンポーネントは（一部を除き）標準でインストールが行われる。Dockerのみではなく、Docker実行環境およびコンテナ の管理を行うコンポーネント群が自動でインストールされるのも、大きな特徴となっている。コンテナの可用性についての製品は、 製品ごとに独自の取り組みが行われており、他ベンダーの製品も積極的に利用されている。たとえばProject Atomicでは、Google が開発するKubernetesが選択されている。 http://thinkit.co.jp/story/2015/03/06/5672 より転載
28. 代表的なOS - CoreOS - CoreOS, Inc. - https://coreos.com/ - Project Atomic - Red Hat, Inc. - http://www.projectatomic.io/ - Snappy Ubuntu Core - Canoncial UK Ltd. - http://developer.ubuntu.com/en/snappy/
29. https://coreos.com/ より転載
30. https://coreos.com/ より転載
31. https://coreos.com/ より転載
32. https://coreos.com/ より転載
33. Dockerのマルチホスト利用
34. Dockerをシングルホストで動かす場合 proxy app db slave cache log db master - ◦ 単純で構築が用意 - ☓ 非冗長 - ホストが落ちればすべて落ちる - 負荷分散できない
35. proxy app cache - ◦ 耐障害性の向上 - ◦ 負荷分散可能 - ◦ 1コンテナあたりのリソース増加 - ☓ 構成が複雑 Dockerをマルチホストで動かす場合 db slave proxy app app db master log db slave cache log
36. - コンテナ間の通信はどのようにおこなうか - どこにどのコンテナを動かすか - どこでどのコンテナが動いているのか 構成が複雑になって考えることが増える proxy app cache db slave proxy app app db master log db slave cache log
37. コンテナネットワークはホストと分かれている ホストを跨いでコンテナ間通信したい コンテナ間の通信はどのようにおこなうか
38. c - 仮想的なネットワークを内部に持っている - docker0ブリッジでホスト側と繋がっている コンテナネットワークはホストと分かれている c eth0 veth0 veth1 172.17.0.2 172.17.0.3 172.17.42.1 docker0
39. c - 仮想ネットワークのサブネットを分ける必要がある - パケット転送するような仕組みが必要 ホスト間を跨いでコンテナ間通信したい c eth0 veth0 veth1 172.17.0.2 172.17.0.3 172.17.42.1 docker0 c c eth0 veth0 veth1 172.17.0.2 172.17.0.3 172.17.42.1 docker0
40. 各ホストで起動するコンテナを分散させたい 負荷に応じて起動するコンテナの数を制御したい どこにどのコンテナを動かすか
41. proxy cache 各ホストで起動するコンテナを分散させたい db app db master log proxy app db cache log db master - 良い例: 各ホストにコンテナが分散されている - 悪い例: 1ホストにコンテナが集中している
42. 負荷に応じて起動するコンテナの数を制御したい - 低負荷時 - 高負荷時 proxy cache db app db master log proxy cache db app db master log proxy db app app cache log
43. ホストを気にせずコンテナにアクセスしたい 複数のコンテナを抽象化して扱いたい どこにどのコンテナが動いているか
44. ホストを気にせずコンテナにアクセスしたい - 動的にコンテナを起動した場合、どこで起動し ているか把握するのは難しい - ホストを指定しないでアクセスしたい proxy1 db slave1 app2 db master1 log1 Host1 Host2 Host3 cache2 cache1 log1 db slave2 app1 proxy2 app3
45. 複数のコンテナを抽象化して扱いたい proxy service app service db-s service db-m service cache service log service c c c c c c c c c c c c c c c c
46. Dockerオーケストレーション
47. マルチホストを想定したDocker関連ツール - Kubernetes - Fleet (CoreOS + etcd) - Docker Machine / Swarm / Compose オーケストレーションツール
48. http://kubernetes.io/ Kubernetes
49. Kubernetes - 複数のコンテナをマルチテナ ントに適切に自動配置する - ホストの増減にともなってコ ンテナの再配置する - 複数のコンテナを Pod/Controllerで集約 - Pod/Controllerはラベルで管 理する - Podへのエンドポイントをサ ービスとして定義する http://kubernetes.io/ より転載
50. 複数のコンテナを抽象化して扱いたい proxy service app service db-s service db-m service cache service log service c c c c c c c c c c c c c c c c
51. proxy service app service db-s service db-m service cache service log service c c c c c c c c c c c c c c c c Pod/Controller/Serviceによるコンテナの抽象化
52. Kubernetesの設定例 frontend-service nginx Host1 Host2 Host3 frontend nginx frontend nginx frontend 192.168.0.10:8080
53. - pod - イメージ: nginx - port: 80 - label: frontend - container - pods数: 3 - selector: frontend - label: frontend (※ 一部省略)
54. - service - selector: frontend - ip: 192.168.0.10 - port: 8080
55. Dockerの問題点と課題
56. Dockerfileの問題点と課題 - 複数のDockerfileを継承できない - Fromで指定できるのは一つだけ - ファイルの分割が出来ない - 独自フォーマット - Dockerfileの再現性が担保されない - 同一のDockerfileから同じイメージが出来ると は限らない 参考: http://deeeet.com/writing/2015/02/17/docker-bad-points/
57. セキュリティ面の課題 - Dockerはデーモンが常に動いている - デーモンは root 権限である必要がある - APIによって外部から操作できる(ただしAPIはデ フォルトではoff) 参考: http://deeeet.com/writing/2015/02/17/docker-bad-points/
58. DockerHubの問題点と課題 - DockerHubには誰でもイメージをアップロード出来る - 悪意のあるイメージがアップロードされる可能性が ある - 悪意があるかどうかの判断は実際に起動するまでわ からない - docker pull するとイメージのダウンロード及び展開 まで行われる - ダウンロードが遅い - 海の向こう側でホストされているので速度が出ない 参考: http://deeeet.com/writing/2015/02/17/docker-bad-points/
59. Dockerの今後
60. Docker, Inc の今後について - 以前まではシンプルな Docker Engine の開発に注力し ていた - 今後は、Docker Machine / Swarm / Composeといった、 Dockerをより良く利用するためのツールが増えていく と考えられる - Kitematicを買収するなどして、GUIツールの開発も進 めていくのでは
61. AppContainer / Rocket - Dockerの問題点や今後の方針を疑問視していた CoreOSが発表したもの - AppContainer - コンテナイメージの仕様 - 標準化を視野に入れている - Dockerイメージからの変換が可能 - Rocket - AppContainerを動かすための実装 - 機能面でDockerに劣っているため、これからといっ た印象
62. まとめ - Dockerをとりあえず使ってみることは簡単 - 実際の利用事例はそこまで多くない(表に出てないだ け？) - プロダクションで利用する場合はマルチホストを考慮し た設計や整備が必要 - Dockerに縛られず、Rocketやその他類似ツールの動向 もチェックしておく必要がある
63. 社内でDocker勉強会やってます に関す る 時間: 毎週木曜日18:30~19:30 ~ 新規参加者歓迎 ~