Docker Compose 徹底解説

1. Docker Compose 徹底解説俺たちは雰囲気でコンテナを動かしている Sakura Internet, Inc. Masahito Zembutsu @zembutsu OSC 2019 Tokyo Spring #osc19tk Feb 22, 2019

2. このスライドは何？ 2 Docker Composeの「入門」をコンセプトとして、 ⚫ 基本となる Docker コンテナとイメージの違い ⚫ Docker Compose の基本概念と操作 ⚫ 便利なコマンドを紹介しています。ゴール：「DockerコンテナとDockerイメージとの違いを理解した上で、 Composeで複数のコンテナを操作できるようにする」 ※スライドそのままでは分かりづらい部分があるため、一部で公開時と異なる表現・補足説明を用いている場合があります。

3. 3 @zembutsu 前佛雅人 zembutsu@zembutsuBlog: https://pocketstudio.net Factorio大好き！ 2,500時間溶けた https://factorio.com/ さくらインターネット株式会社技術本部ミドルウェアグループ Technology Evangelist / Developer Advocate 最近は「石狩市への小学校プログラミング教育支援プロジェクト」にも所属しています。 https://prog-edu.sakura.ad.jp/

4. 4 http://docs.docker.jp/ Dockerのドキュメント日本語化や、黄色いコンテナ本でDocker部分の章を担当させていただきました。

5. お品書き • Docker の本質的な存在意義とは • Docker Compose とは何か？ • なぜ Docker Compose なのか？ • Docker Compose のセットアップと基本操作 • WordPress を Docker Compose で管理する例 • Docker Compose 活用のヒント(Tips) 5今日ここで共有させていただく内容は、こちらです。皆さまのご想像通りでしょうか？

7. Docker の本質的な存在意義 Why Docker? 7

8. Dockerとは？ 8 What is the Docker? １ Dockerコンテナは実行に必要な全てをパッケージして、簡単に動かせる 2 Dockerイメージは複数のイメージ・レイヤとメタ情報の積み重なり 3 コンテナのプロセスはデフォルトで isolate（隔離・分離）された状態 ⚫ イメージ・レイヤ（image layer）は読み込み専用 ⚫ 親子関係がある ⚫ イメージに対する変更はCopy on Write（CoW)処理が走る ⚫ コンテナ実行にはイメージが必要で、Docker Hubから得られる ⚫ コンテナ実行時のみ、読み書きが可能なレイヤを追加 ⚫ namespace（名前空間）でプロセス空間やファイルシステムやネットワーク等を分ける技術と、 cgroups（コントロール・グループ）でリソースの利用上限を指定 ⚫ コンテナはポートをデフォルトで開かない ⚫ ネットワークはブリッジ、ホスト、 noneの3種類 ⚫ ボリュームはコンテナ間でファイルシステムを共有できる。名前付き (named)とホスト・ボリューム ⚫ アプリケーションを簡単に開発し、移動し、実行するためのプログラムとプラットフォームを提供するのが Docker ⚫ クライアント・サーバ型 https://docker.com プロセスを簡単にコンテナ化（isolate）し、簡単かつ素早く開発・移動・実行できる「プラットフォーム」が Docker Containerization 「プロセス・ファイルシステム・ネットワーク・等々」に対して Namespace・Cgroup Build Ship Run

9. 9新しい概念が少しあるものの、Dockerやコンテナそのものは、実はシンプルです。

10. Docker 10 “Docker allows you to package an application with all of its dependencies into a standardized unit for software development.” www.docker.com 全ての依存関係をパッケージ化して、コンテナとして動かすまず、「Docker」そのものには、このような定義があります。

11. Docker 11 “Docker allows you to package an application with all of its dependencies into a standardized unit for software development.” www.docker.com 全ての依存関係をパッケージ化して、コンテナとして動かす Dockerイメージとして Linuxファイルシステムをポイントはファイルシステム、「/」以下の「/bin/」や「/var」等を「Dockerイメージ」にパッケージ化。

12. Docker 12 “Docker allows you to package an application with all of its dependencies into a standardized unit for software development.” www.docker.com 全ての依存関係をパッケージ化して、コンテナとして動かす Dockerイメージとして Linuxファイルシステムをその「Dockerイメージ」を「Dockerコンテナ」として動かす(run、走らせる）ことができます。

13. コンテナを実行？コンテナを走らせる？ 13ここで出てくる新しい概念が「コンテナ」として「動かす」です。コンテナとは一体何者なのだ・・・？ (((

14. 15 （物理または仮想）コンピュータ CPU メモリ記憶装置コンテナの前に、「プロセスの実行」をお復習い。コンピュータないしサーバの基本要素はこちら。

15. 16 （物理または仮想） Linux カーネル + システム・ライブラリ(libc)等コンピュータ CPU メモリ記憶装置オペレーティングシステム (OS)の領域「プロセスの実行」とは、記憶装置にあるOSファイルシステム上のファイル（プログラム）に、CPUとメモリを使えるようにします。

16. 17 （物理または仮想）ユーザ空間システム空間 Linux カーネル + システム・ライブラリ(libc)等コンピュータ CPU メモリ記憶装置オペレーティングシステム (OS)の領域プロセスプログラム設定ファイルソースコードデータ一般的なプロセス実行一般的なプロセス実行は、この図のような概念です。プログラムでプロセスを動かし、プロセスはOS上のファイルにアクセスできます。

17. 18 （物理または仮想）ユーザ空間システム空間 Linux カーネル + システム・ライブラリ(libc)等コンピュータ CPU メモリ記憶装置オペレーティングシステム (OS)の領域プロセスプログラム設定ファイルソースコードデータプロセス一般的なプロセス実行サーバ用とのLinux上では、１つのマシン上で、同時に沢山のプロセスが稼働できます。プロセス間で通信する場合もあります。

18. 19 （物理または仮想）ユーザ空間システム空間 Linux カーネル + システム・ライブラリ(libc)等コンピュータ CPU メモリ記憶装置オペレーティングシステム (OS)の領域プログラム設定ファイルソースコードデータコンテナは特別な状態のプロセスのこと isolate(隔離) プロセス isolate(隔離) プロセスそして「コンテナ状態」のプロセスは、isolate（隔離）された特別な状態のプロセスです。名前空間機能でプロセス空間、ファイルシステム等を分けて実行。

19. 20 （物理または仮想）ユーザ空間システム空間 Linux カーネル + システム・ライブラリ(libc)等コンピュータ CPU メモリ記憶装置オペレーティングシステム (OS)の領域プログラム設定ファイルソースコードデータコンテナは特別な状態のプロセスのこと isolate(隔離) プロセス isolate(隔離) プロセス名前空間(namespace)はLinuxカーネルの機能。これを、簡単に管理できるようにするツールかつプラットフォームが、Docker（エンジン）なのです。

20. 21 isolate(分離)する insulatus→isolated→isolate isle island アイソレート “名前空間”技術を使って namespace Dockerはisolate状態のプロセスを管理するもの。islateの語源はラテン語で、islandとも関連

21. 22つまり、断崖絶壁の孤島に自分だけ一人しかいない。そのような状況のプロセスがコンテナなのです。

22. PID名前空間 23 httpd PID 1 プロセスhttpd 名前空間プロセスruby 名前空間 ruby PID 1 chris.rb PID 2 名前空間は複数ありますが、分かりやすいのはPID。ここでは httpd,rubyどちらもPIDが「1」 namespaces 自らのPID名前空間内では

23. PID名前空間 24 httpd PID 1 プロセスhttpd 名前空間プロセスruby 名前空間 ruby PID 1 chris.rb PID 2 /sbin/init PID 1 containerd PID 5 httpd PID 6 ruby PID 7 chris.rb PID 8 alice PID 2 bob PID 3 PPID 1 PPID 1 PPID 4 PPID 5 PPID 5 PPID 7 PPID 1 dockerd PID 4 ですが、ホスト上では別の（本来の）PIDを持ち、通常のプロセス・ツリーの下で動作。

24. PID名前空間 25 httpd PID 1 プロセスhttpd 名前空間プロセスruby 名前空間 ruby PID 1 chris.rb PID 2 /sbin/init PID 1 containerd PID 5 httpd PID 6 ruby PID 7 chris.rb PID 8 alice PID 2 bob PID 3 PPID 1 PPID 1 PPID 4 PPID 5 PPID 5 PPID 7 PPID 1 dockerd PID 4 ホスト上には存在つまり、ホスト上では普通にプロセスが走っていますが、名前空間内では自分達しか見えない状態。外の世界が見えない井の中の蛙のような存在…

25. ファイルシステムを分ける (chroot) 26 ubuntuのファイルシステム … … centosのファイルシステム /etc /bin /etc /bin / / 次に分かりやすいのがファイルシステム。chrootの概念と同じ、特定のディレクトリをルートにします。そのプロセスを実行時に

26. ファイルシステムを分ける (chroot) 27 ubuntuのファイルシステム … … centosのファイルシステム /etc /bin /etc /bin / / /data/ubuntu /data/centos / /etc /data/bin あくまでも、OS上にファイルシステムがあり、そこをプロセスがchroot状態でマウントします。

27. ファイルシステムを分ける (chroot) 28 ubuntuのファイルシステム … … centosのファイルシステム /etc /bin /etc /bin / / /data/ubuntu /data/centos / /etc /data/bin ホスト上には存在そうすると、お互いのファイルシステム、つまりディレクトリやファイルを干渉できなくなるのです。

28. コンテナは特別なプロセスの状態 29 コンテナAのファイルシステム … … コンテナBのファイルシステム /etc (/data/ubuntu/etc) /bin (/data/ubuntu/bin) /etc (/data/centos/etc) /bin (/data/centos/bin) / / それでは、改めて、「コンテナの実行」とは名か。まず何らかのファイルシステムが存在していて、

29. コンテナは特別なプロセスの状態 30 コンテナAのファイルシステム … … コンテナBのファイルシステム /etc (/data/ubuntu/etc) /bin (/data/ubuntu/bin) /etc (/data/centos/etc) /bin (/data/centos/bin) / / httpd PID 1 プロセスA プロセスB ruby PID 1 chris.rb PID 2 コンテナB そこから「特別な状態」として複数の名前空間を分離し、chrootされた場所をマウント＆プロセス起動

30. コンテナは特別なプロセスの状態 31 コンテナAのファイルシステム … … コンテナBのファイルシステム /etc (/data/ubuntu/etc) /bin (/data/ubuntu/bin) /etc (/data/centos/etc) /bin (/data/centos/bin) / / httpd PID 1 プロセスA プロセスB ruby PID 1 chris.rb PID 2 コンテナA コンテナB 名前空間の isolate ・プロセス・ファイルシステム・ネットワーク・ホスト名・UID・GID ・プロセス間通信、等 cgroupでリソース制限・CPU ・メモリ・I/O ・ディスク・クォータ、等これがコンテナ状態として起動するプロセスであり、名前空間がisolate（隔離）された状態。ネットワークやUID、GIDやホスト名も分離さらにcgroup技術で、CPUやメモリといったリソースの制限もできる状態。

31. 32これが「コンテナ」です。コンテナを作るには、Docker以外にもLXCやOpenVZ等の実装があります。

32. 33 ユーザ空間システム空間 Linux カーネル + システム・ライブラリ(libc)等オペレーティングシステム (OS)の領域プログラム設定ファイルソースコードデータ Docker イメージ Dockerイメージを使って Dockerコンテナ（隔離状態）のプロセスを起動 Dockerはコンテナ管理プラットフォーム。設定ファイル、ソースコードなどを「Docker イメージ」にまとめて、実行します。このイメージを送受信する機能を持っています。

33. 34 ユーザ空間システム空間 Linux カーネル + システム・ライブラリ(libc)等オペレーティングシステム (OS)の領域プログラム設定ファイルソースコードデータ Docker イメージビルド pull Dockerイメージ Dockerイメージ ※異なるシステム、バージョン、ソースコード Dockerイメージを使って Dockerコンテナ（隔離状態）のプロセスを起動「docker pull」や「docker build」といった、簡単なコマンドを実行するだけで、Docker Hub （公式イメージ・レジストリ）から、自動で Docker イメージをダウンロードします。

34. 35 ユーザ空間システム空間 Linux カーネル + システム・ライブラリ(libc)等オペレーティングシステム (OS)の領域プログラム設定ファイルソースコードデータ Dockerコンテナプロセス Dockerコンテナプロセス Docker イメージビルド pull Dockerイメージ Dockerイメージ ※異なるシステム、バージョン、ソースコード Dockerイメージを使って Dockerコンテナ（隔離状態）のプロセスを起動あとは、Dockerイメージ内のファイルを使いプロセスを名前空間を分離した特別な状態で起動できるようにする。これがDockerの役割なのです。

35. Dockerはサーバ・クライアント型モデル 36 OS ( Linux ) 物理/仮想サーバ Docker エンジン ( dockerd デーモン ) Linux kernel コンテナコンテナコンテナリモート API docker クライアント TCP あるいは Unix ソケットドメイン containerd Runtime: runC (OCI規格準拠) ・docker コマンド Linux, Mac OS X, Windows ・Kitematic (GUI) Mac OS X, Windows ・Docker Compose ・Docker Swarm ちなみに、DockerそのものはDockerエンジンと呼ぶサーバ側プログラムと、CLIで構成。

36. 参考：Docker Engineのアーキテクチャ 37※ Docker Engine v1.11 以降ユーザ (docker CLI等) Docker Container Engine dockerd containerd (docker-containerd) shim (docker-containerd-shim) shim (docker-containerd-shim) shim (docker-containerd-shim) runC (runtime-runc) コンテナ Docker Image コンテナ Docker Image コンテナ Docker Image JSON/REST API CNCF/OCI業界標準規格に準拠 runC (runtime-runc) runC (runtime-runc) ｇRPC エンドポイント Docker Engine トップレベルのデーモン（Moby プロジェクトの成果物） Docker イメージに含むファイルを、パラメータに従い、コンテナとして実行コンテナを実際に作成・起動するランタイムのバイナリ・プログラムコンテナやイメージをはじめとし、ネットワーク、ストレージを管理する必要最小限のデーモンランタイムが実行したコンテナを管理細かく見ますと、このようなプログラムで構成

37. Dockerイメージはイメージ・レイヤの積み重ね 38 プログラムやライブラリとメタ情報（実行するプログラムやポートなど）さて、次は「Dockerイメージ」です。これは仮想マシン・イメージとは全く異なる概念です。

38. Dockerイメージはイメージ・レイヤの積み重ね 39 プログラムやライブラリとメタ情報（実行するプログラムやポートなど） Dockerイメージは、複数のイメージ・レイヤ(image layer)の組み合わせで、読み込み専用。１つ１つのイメージ・レイヤの実体は、ファイルシステム（ / 以下の /bin や /etc などのディレクトリやファイル）を tar アーカイブ化したものや、メタ情報（どのプログラムを自動実行するか、パラメータは何か、どのポートを公開するかなど）が記録。

39. Dockerイメージはイメージ・レイヤの積み重ね 40 利用者からは１つに見える親子関係プログラムやライブラリとメタ情報（実行するプログラムやポートなど）イメージ・レイヤは親子関係を持ち、複数のレイヤは利用時に１つのファイルシステムに見える。 ⚫ 一般的にDockerイメージは複数のイメージ・レイヤで構成 ⚫ 例えば、“nginx:latest” イメージを取得(pull)すると、親のレイヤ情報を持つレイヤも自動的に取得 ⚫ 結果として、利用者からは１つのDockerイメージを取得・実行するつもりでも、実際には複数のイメージ・レイヤをまとめて操作

40. Dockerイメージはイメージ・レイヤの積み重ね 41 利用者からは１つに見える親子関係プログラムやライブラリとメタ情報（実行するプログラムやポートなど）そして、親レイヤが共通の、別のイメージを作るのも簡単。共有部分はディスク容量を消費しません。派生も共有利用者からは１つに見える

41. Dockerイメージはイメージ・レイヤの積み重ね 42 利用者からは１つに見えるプログラムやライブラリとメタ情報（実行するプログラムやポートなど）仮想マシン・イメージであればコピーは数GBもあり、通常は時間もお金も掛かります。派生も共有利用者からは１つに見えるだから高速に移動できる・開発を高速化できるリソースを有効に使える “lightweight” な性質親子関係

42. 43ちなみに、イメージを作るにはコマンド「docker build」で、Dockerfileというファイルを用意します。 docker image build -t <IMAGE:TAG> . (docker build) これがDockerfileです。1行1行がイメージ・レイヤに相当します。このイメージは、上から順に、 ⚫ 「FROM」命令で「scratch」、何も無いイメージ・レイヤを作成 ⚫ 「ADD」命令で、ファイルシステムをイメージ・システムの中に入れる ⚫ 「CMD」命令で、イメージ使ったコンテナ実行時に、「/bin/sh」をデフォルトで実行する設定を指定しています。

43. 44 利用者からは１つに見える docker image build -t <IMAGE:TAG> . (docker build) ３つのイメージ・レイヤは、あくまで１つのDockerイメージが存在しているように見えます。

44. 45 利用者からは１つに見える docker image build -t <IMAGE:TAG> . (docker build) ３つのイメージ・レイヤは、あくまで１つのDockerイメージが存在しているように見えます。

45. 46 利用者からは１つに見える alpine docker image build -t <IMAGE:TAG> . (docker build) ３つのイメージ・レイヤは、あくまで１つのDockerイメージが存在しているように見えます。これはAlpine Linuxの Dockerfile でした。

46. 47 利用者からは１つに見える hello:v1 FROM alpine ENTRYPOINT ["/bin/echo"] CMD ["こんにちは！こんにちは！"] docker image build -t hello:v1 . (docker build) 今度は「alpine」という小さなLinuxディストリビューションを使う例です。「v1」とタグを付けます。

47. 48 hello:v1 FROM alpine ENTRYPOINT ["/bin/echo"] CMD [“おはよう！おはよう！"] hello:v2 docker image build -t hello:v2 . (docker build) 次に「v2」を作成。この時必要となるディスク領域は、「v1」との差分（画面青色のレイヤ）のみです。

48. Alpine Linux 49 https://www.alpinelinux.org

49. gliderlabs / docker-alpine 50 イメージ・レイヤ３つのレイヤで容量たったの5MB。 Alpine Linux の Dockerfile は、GitHub上で公開されています。

50. docker image pull (docker pull) 51 $ docker pull hello-world Using default tag: latest latest: Pulling from library/hello-world d1725b59e92d: Pull complete Digest: sha256:0add3ace90ecb4adbf7777e9aacf18357296e799f81cabc9fde470971e499788 Status: Downloaded newer image for hello-world:latest Docker Hub 自分でイメージを作らなくても、DockerHubからイメージのダウンロードも可能。 DockerHub とは、GitHubがソースコードを共有・公開・共同作業するための場所であるように、Dockerイメージを共有・公開・共同作業する場所です。

51. docker image pull (docker pull) 52 $ docker pull hello-world Using default tag: latest latest: Pulling from library/hello-world d1725b59e92d: Pull complete Digest: sha256:0add3ace90ecb4adbf7777e9aacf18357296e799f81cabc9fde470971e499788 Status: Downloaded newer image for hello-world:latest Docker Hub 大事なのは「library」が公式イメージ専用の名前空間で、セキュリティ上、公式のみ使うべきです。

52. 53 ⚫それでは、Docker コンテナと Docker イメージの違いって何？ ⚫どうして１つのマシン上でコンテナをたくさん起動できるの？

53. 54 ⚫それでは、Docker コンテナと Docker イメージの違いって何？ ⚫どうして１つのマシン上でコンテナをたくさん起動できるの？

54. Dockerコンテナ実行とは、イメージ内のプログラムを実行 55イメージ・レイヤは読み込み専用なので、レイヤで構成されるDockerイメージ全体も読み込み専用。

55. Dockerコンテナ実行とは、イメージ内のプログラムを実行 56 元のレイヤに対する変更情報を記録 Copy on Write の性質コンテナ実行時に、読み書き可能なコンテナ用のイメージ・レイヤを作成し、プログラムを実行します。 docker container run -it alpine (docker run) この例では、ベースとなるのが “alpine” Dockerイメージです（読み込み専用。一切変更できません。）変更できるのは、 “alpine” を親イメージ・レイヤとして情報を持っている、赤い部分の読み書き可能なレイヤ。（docker ps -aで確認でき、docker rm で消すのはこのコンテナ用レイヤです）ファイル変更時は、読み込み専用のイメージ・レイヤから一度ファイルをコピーする挙動が発生します。（これを、コピー・オン・ライトと呼びます）。

56. Dockerコンテナ実行とは、イメージ内のプログラムを実行 57 元のレイヤに対する変更情報を記録 Copy on Write の性質利用者からは１つに見える利用者からは１つに見えるだから高速に移動できる・開発を高速化できるリソースを有効に使える “lightweight” な性質コンテナ用レイヤも親子関係を持つため、同じイメージなら直ぐに起動し、容量も圧迫しません。

57. 58 技術と仕様 Technology Specification コンテナ Docker つまり、Linuxカーネルのコンテナ技術を、Dockerというプラットフォームで簡単に扱えるのです。

58. Dockerは構築・移動・実行のためのプラットフォーム 59 サービスを提供したい開発環境テスト環境準備環境本番環境都度、環境構築課題異なるOS環境課題都度、プロビジョニング課題動かない課題時間がかかる課題遅い課題面倒課題アプリを動かしたいコンテナ開発テスト準備本番

59. docker クライアント docker エンジン $ docker container run hello-world run Docker Hub pull レジストリ latest イメージタグ hello-world レポジトリ latest イメージタグ latest コンテナ化した hello-worldの実行 Hello from Docker. This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. 3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker Hub account: https://hub.docker.com For more examples and ideas, visit: https://docs.docker.com/userguide/ Dockerイメージを取得したり、共有するための「公開レジストリ」が「Docker Hub」。

60. ちなみにDockerのキャラクターの名前は “Moby” 61https://en.wikipedia.org/wiki/Moby-Dick 白鯨 – Moby-Dick モビーわたしです

61. Docker ネットワーク概要 Docker network 62

62. 63 ３つの Docker 標準ネットワークモデル bridge (bridge) host (host) none (null) ブリッジ(bridge0 …) veth eth0 ethX Dockerでコンテナを実行すると、プロセスの「ネットワーク」や「ホスト名」もisolate（分離）した状態で起動。

63. 64 ３つの Docker 標準ネットワークモデル bridge (bridge) ブリッジ(bridge0 …) veth eth0 ethX none (null) host (host) 複数のブリッジ（ネットワーク）を定義できるデフォルトのbridge0ブリッジは、旧仕様のネットワークで、挙動が異なるデフォルトは「ブリッジ」ドライバを使うネットワーク。docker network lsで３つのドライバが表示。

64. 65 ３つの Docker 標準ネットワークモデル bridge (bridge) host (host) none (null) ブリッジ(bridge0 …) veth eth0 ethX ホスト側のネットワークに直接接続ブリッジのオーバーヘッドがない一方で、セキュリティに対する考慮が必要ホスト側のインタフェースを直接使いたい場合、docker run のオプションで --network=host を指定

65. 66 ３つの Docker 標準ネットワークモデル bridge (bridge) host (host) ブリッジ(bridge0 …) veth eth0 ethX ネットワークを追加しない限り疎通できない none (null) ネットワーク・インターフェースを持たせない場合は、docker run のオプションで --network=none を指定

66. 67 ３つの Docker 標準ネットワークモデル bridge (bridge) host (host) none (null) ブリッジ(bridge0 …) veth eth0 ethX NAT (iptables) + docker-proxy ホストとネットワーク共通疎通しないコンテナはパブリックなIPアドレスを持ないホスト側のポート番号を重複して、コンテナのポート利用（マッピング）はできない動的なネットワークの追加・変更・削除これらネットワークはコンテナを停止・再起動しなくても、動的に着けたり（アタッチ）外したり（デタッチ）可能。

67. 68 コンテナは複数のネットワーク（ブリッジ）に接続できるブリッジ1(bridge) veth eth0 ethX 各ネットワーク内部では、動的なコンテナ名（サービス）の名前解決機能（サービス・ディスカバリ）を標準提供 eth0 eth1 eth0 ブリッジ2(bridge) veth192.168.0.1 172.18.0.2 172.18.0.3 172.19.0.2 172.19.0.3 172.19.0.1 172.19.0.0/16172.18.0.0/16 サービス・ディスカバリ連携の負荷分散また、複数のブリッジ・ネットワークを定義できます。内部では、コンテナ名で IPアドレスを名前解決できる

68. Docker ボリューム概要 Docker volume 69

69. 70 データの扱いコンテナA専用ファイル階層 File System … / /bin /etc /var コンテナB専用ファイル階層 File System … / /bin /etc /var hello.txt × HOST Root File System /var/lib/docker/overlay/ hello.txt ディレクトリはストレージドライバによって異なる A BUFS( Union File System ) コンテナA・B（のプロセス）は、お互いのファイルシステムを直接参照できません。

70. 71 データ・ボリュームコンテナA専用ファイル階層 File System … / /bin /etc /var コンテナからはUFSを通してデータ領域が見えるストレージ・ドライバのオーバヘッドを受けない複数のコンテナでボリュームを共有できる volume /data / ボリューム Volume /var/lib/docker/volumes/HOST Root File System コンテナは「ボリューム」と呼ぶ領域（ディレクトリまたはファイル）をマウントできる

71. 72 コンテナファイル階層 File System / UFS ( Union File System)… / /bin /var Docker イメージ Docker Image /var/lib/docker/image/ volume / ボリューム Volume /data コンテナ用イメージ層 Container’s Image Layer / /var/lib/docker/volumes//var/lib/docker/containers/ ReadOnly

72. 73 ボリュームは３分類ホストをマウント名前付きホスト上のディレクトリ /docker/data /data 名前無し volume ボリュームの実体は、ホスト上のディレクトリ /var/lib/docker/volumes ボリュームはコンテナ間でデータを共有できる volume /data /data /etc ボリュームとして、ホスト上のファイルを直接マウントできるだけでなく（ docker run -v ホスト側:コンテナ内）、ボリュームを複数のコンテナで共有可能。読み書きするデータは、通常このボリュームを作成し、利用する。

73. Docker Compose が必要な理由 Why? There are some reasons to manage containers. 74

74. 75 ⚫たくさんのコンテナを同時に実行するには？サーバは通常、ウェブやデータベースなど、複数のプロセスが動作。

75. 76 ふくすうのコンテナをきどうしようシステムコンテナコンテナシステムコンテナスケールしづらさ管理のしづらさから Dockerやk8sには向かないねプロセス A プロセス B プロセス C １つのコンテナに多くのプロセスを集約する手法もありますが、スケールしづらくなります。

76. 77 ふくすうのコンテナをきどうしようコンテナシステムコンテナソフトウェアごとにコンテナが別だからスケールしやすいし差し替えも簡単プロセス A コンテナプロセス B コンテナプロセス C アプリケーションコンテナプログラムごとにコンテナを分ける手法、これをアプリケーション・コンテナと呼ばれます。

77. 78 ふくすうのコンテナをきどうしようコンテナシステムコンテナソフトウェアごとにコンテナが別だからスケールしやすいし差し替えも簡単プロセス A コンテナプロセス B コンテナプロセス C アプリケーションコンテナ docker run … docker run … docker run … ただし、コンテナごとにコマンドを実行する必要があり、ます。この画面では３回の実行ですが、、、

78. 79 docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … docker run … もしもコンテナが 20こひつようなら ⚫ 環境構築が大変 ⚫ 環境の維持・再現が大変 ⚫ 本末転倒 20回実行する必要があり、これでは面倒。「簡単に扱うためのDocker」から乖離してしまいます。

79. 80 docker-compose up そこでコンポーズのでばん ⚫ 環境はYAMLで管理 ⚫ docker コマンドと類似利用者側のメリット： • compose ファイルがあれば、とにかく動くので（環境の再現性が高い）開発者側のメリット： • １つのマシン上で、複数の環境を切り替えやすいそこで出てきたのがCompose。dockerと似たコマンドを実行するだけで、まとめてコンテナを実行。

80. 81 コマンド? のごかんせい docker と docker-compose はコマンドの意味が近いため、docker に慣れていると楽しかも、Dockerのネットワークやボリュームも一緒に管理できる利便性

81. 82 ちなみに http://www.fig.sh 元々は「Fig」というプロジェクトでしたが、2014年にDocker社に買収されて名称変更。

82. 83 これはちがいますごめんなさい、ごめんなさい

83. 複数のコンテナを一括管理する Docker Compose Docker Compose 84

84. Docker Composeとは？ 85 What is Docker Compose? １ Composeはアプリケーションのサービスをファイルで定義する 2 Dockerコマンドと高い親和性があるため、学習コストが比較的に低い 3 Swarm モードにサービスをデプロイできるオーケストレーション機能 ⚫ docker-compose CLI のコマン体系は docker に準拠 ⚫ 例：「docker run -d」は「docker-compose up -d」 ⚫ Docker swarm モードを使えば、サービス状態を定義できるので常に期待状態を維持できる ◼ docker stack deploy ⚫ Ingress ネットワークの活用 ⚫ Compose ファイル (YAML形式) で Docker コンテナのサービスを定義できるため、再利用性が高い ◼ コンテナの状態 ◼ イメージ ◼ ネットワーク ◼ ボリューム ◼ メタ情報 https://github.com/docker/compose 複数のコンテナで構成するアプリケーションを定義と実行するためのツール multi-container applications define and run

85. 86 Mastodon Mastodonのように、複雑な構成のアプリケーションも、Docker Composeで利用できる

86. 87 redis :alpine postgres :alpine サービスサービスイメージイメージ nginx :alpine サービスイメージ gargron/mastodon :v1.4.6 サービスイメージ gargron/mastodon :v1.4.6 サービスイメージ gargron/mastodon :v1.4.6 サービスイメージ namshi/smtp :latest サービスイメージ https://github.com/tootsuite/mastodon ネットワーク 192.168.0.0/16 mastdon (external) ホスト側ネットワーク eth0等 mastodon_postgresmastodon_redis certbot (external) assets packs system volumevolume volume volume volume volume 80 443 80 443 services: volumes: networks: 特にネットワークやボリュームが混在する場合には有用

87. Docker Compose 活用場面 • 利用者視点 • 「docker-compose.yml」があれば、すぐに何でも実行できる • YAML形式で記述 • Docker Hub 公式イメージ上でサンプルが公開されている • PWD (Play With Docker という、無料で短時間利用できるクラウド上のリソース）でお試し • 開発者視点 • 環境の再構築が簡単 • バージョン違いの環境を作りやすい • １つのマシン上に、複数の環境を立ち上げられやすい 88適切に書いたYAMLファイルさえあれば、誰でも簡単に実行できるのが強み。しかも、環境まとめて。

88. Dockerのセットアップ 89 $ curl https://get.docker.com | head $ curl -fsSL get.docker.com -o get-docker.sh # sh ./get.docker.com # systemctl enable docker # systemctl start docker ※systemd系の場合 ※リポジトリの自動セットアップ ※コマンドの確認 Linuxで検証用途に手軽な方法 Dockerのセットアップはシンプルです。あるいはDocker for Mac/Winという選択肢も。

89. Docker Compose セットアップ方法 • Docker Desktop for Mac / Windows • docker-compose も同梱されているので、すぐに使える • Linux 版 • バイナリをリポジトリからローカルにダウンロードし、パーミッションを設定 • https://github.com/docker/compose/releases “Assets”からアーキテクチャごとにダウンロードできる Linuxは “docker-compose-Linux-x86-64” 90 curl -L https://github.com/docker/compose/releases/download/1.23.2/docker-compose-Linux-x86_64 ¥ -o /usr/local/bin/docker-compose chmod 755 /usr/local/bin/docker-compose Linuxは docker-compose のバイナリを、別途セットアップする必要があります。

90. Docker Composeを使うための基本ステップ 91 Compose ファイル docker-compose up YAML あるない Docker イメージない Dockerfileを作成 Compose ファイル作成ある「サービス」「ネットワーク」「ボリューム」などをYAML形式で記述した、Composeファイルが必要。

91. docker-compose.yml • 「サービス」「ネットワーク」「ボリューム」を定義 • image … イメージ IDやイメージ名 • build … Dockerfile のパス（イメージを構築する場合） • command … デフォルトの（イメージ実行時）コマンドを上書き • restart … コンテナの再起動ポリシー（例： always） • ports … ポートのマッピング • environment: , env_file: 環境変数の指定 92 services: networks: volumes: Docker Composeは「プロジェクト」を操作。プロジェクトを定義するのが、このComposeファイル。

92. 93 version: '3.1' services: wordpress: image: wordpress restart: always ports: - 8080:80 environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: exampleuser WORDPRESS_DB_PASSWORD: examplepass WORDPRESS_DB_NAME: exampledb db: image: mysql:5.7 restart: always environment: MYSQL_DATABASE: exampledb MYSQL_USER: exampleuser MYSQL_PASSWORD: examplepass MYSQL_RANDOM_ROOT_PASSWORD: '1' ◀ ネットワークやボリュームを使う場合、通常2以上 swarm modeにデプロイする場合は3を想定 WordPress公式の Docker Compose例 ◀ 使用するDockerイメージは「wordpress:latest」 ◀ サービスを定義 ◀ サービス「wordpress」 ◀ 停止時、常にプロセス再起動 ◀ ホスト側ポート8080を、コンテナ内ポート80に割り当て ◀ コンテナ内で使える環境変数を定義 ◀ 初回実行時rootパス自動生成 ◀ サービス「db」 ◀ サービス「db」で名前解決できる ◀ WordPress用のデータベース、ユーザ、ユーザのパスワードを定義 ◀ 使用するDockerイメージは「mysql:5.7」 ◀ 停止時、常にプロセス再起動 ◀ コンテナ内で使える環境変数を定義 ※ネットワークを定義していないが docker-compose up時に自動的に、このプロジェクト専用の bridge ネットワークが作成される。 ※wordpressとdbのコンテナ間はポートの公開を明示しなくても、同一 bridge ネットワークに所属しているため、お互い内部通信可能

93. 94 version: '3' services: web: image: zembutsu/docker-sample-nginx deploy: replicas: 3 resources: limits: cpus: "0.1" restart_policy: condition: on-failure ports: - "80:80" networks: internal: aliases: - frontend volumes: - /etc/localtime:/etc/localtime:ro networks: internal: ◀ ネットワークやボリュームを使う場合、通常2以上 swarm modeにデプロイする場合は3を想定「web」という名称のサービスを定義（内部ネットワークで名前解決できる）▶ ◀ 使用するDockerイメージ ◀ コンテナのレプリカ（複製）を３つ起動 ◀ CPUリソース制限 ◀ 再起動ポリシーを指定：障害時に再起動 ◀ ホスト側のポート80を、コンテナ内のポート80にマッピング ◀ 「internal」という名称のブリッジネットワークに接続し、 frontend というエイリアス（別名）を指定 ◀ ボリューム定義 /etc/localhost を読み込み専用で ◀ ネットワーク定義 internalという名称のブリッジ・ネットワーク ◀ docker stack deploy時の挙動別例：

94. 95 コンテナは複数のネットワーク（ブリッジ）に接続できるブリッジ1(bridge) veth eth0 ethX 各ネットワーク内部では、動的なコンテナ名（サービス）の名前解決機能（サービス・ディスカバリ）を標準提供 eth0 eth1 eth0 ブリッジ2(bridge) veth192.168.0.1 172.18.0.2 172.18.0.3 172.19.0.2 172.19.0.3 172.19.0.1 172.19.0.0/16172.180.0/16 サービス・ディスカバリ連携の負荷分散 Composeはプロジェクト単位でブリッジ・ネットワークを自動的に作成でき、ホスト側とのマッピングも設定可能。

95. Composeプロジェクトの「ネットワーク」定義 96 networks: external_network: internal_network: internal: true services: web: ... networks: hostnet: {} networks: hostnet: external: true name: host 「networks」でネットワークを定義。”external:true” は、この Compose プロジェクト外で（手動・自動的に存在しているネットワークと接続）。”driver: overlay”の場合、”internal:true”で、複数ホスト間をつなぐローカルネットワークも定義できる。

96. 97 ボリュームは３分類ホストをマウント名前付きホスト上のディレクトリ /docker/data /data 名前無し volume ボリュームの実体は、ホスト上のディレクトリ /var/lib/docker/volumes ボリュームはコンテナ間でデータを共有できる volume /data /data /etc コンテナ（のプロセス）でマウントするボリューム（領域）も、Composeで定義できる。

97. Composeプロジェクトの「ボリューム」定義 98 services: db: image: postgres:9.4 volumes: - db-data:/var/lib/postgresql/data volumes: - /var/lib/mysql - cache:/tmp/cache - ./configs:/etc/configs/:ro 「volumes:」に “- ディレクトリまたはファイル名”の場合は名前無し（volume idが割り振られる）。主に使い捨て用途 “- 名前:パス” は名前付きボリューム。ホスト上での管理を容易にするため（バックアップや参照で） “- パス:パス” はホスト上を直接マウント。 “:ro”は Read-Only オプション個々のサービスの中で定義する場合は、そのサービス（のコンテナ）だけが参照プロジェクト全体または個々のサービスに定義。毎回 docker volume create等の管理が不要に。

98. 動かし方や便利なコツ Run & Tips 99

99. Docker Compose Run & Tips • docker-compose up -d --build • docker-compose down -v –rmi all / local • docker-compose exec <サービス名> コマンド • docker-compose -f <ファイル名.yml> • docker-compose -p <プロジェクト名> • docker-compose --config • docker system prune • docker volume rm $(docker volume ls -q) 100compose を普段使う上で、よく使うコマンドは、このあたり。特に知らないうちにネットワークやボリュームが混在するときは prune（プルーン）コマンドで一斉掃除。 ◀ プロジェクト起動時、毎回Dockerfileをbuildする ◀ 停止時、イメージとボリューム全削除 ◀ デバッグ用途。コンテナ内で操作 ◀ 任意のYAMLファイルを指定可能 ◀ ディレクトリ名ではなく、任意のプロジェクト名を指定可能 ◀ 稼働しているプロジェクトの情報を、YAML形式で表示（間違って YAML を消した場合や、複数の YAML が混在し操作対象が分からなくなった時に重宝・・・） ◀ 不要コンテナ、中間イメージ、ネットワークを削除（-vでボリュームも） ◀ ボリュームの全削除

100. Compose ファイル形式バージョン • networks: volumes: は v2 , v3 で利用可能 • v3 を使うには Docker v1.13 以上 • Swarm mode を使うには v3 （同じオプションでも v2 と挙動が異なる） • 細かな差違はリファレンス https://docs.docker.com/compose/compose-file/ 101細かな挙動の違いはあるものの、docker stack コマンドで swarm 使わなければ、ほぼ考慮不要。

101. コンテナ内の環境変数 env_file & environment: 102 services: wordpress: image: wordpress restart: always ports: - 8080:80 environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: exampleuser WORDPRESS_DB_PASSWORD: examplepass WORDPRESS_DB_NAME: exampledb services: wordpress: image: wordpress restart: always ports: - 88:80 env_file: - wordpress.env WORDPRESS_DB_HOST=db WORDPRESS_DB_USER=exampleuser WORDPRESS_DB_PASSWORD=examplepass WORDPRESS_DB_NAME=exampledb 知っておくと便利なのが環境変数の定義方法。「enf_file:」で別ファイルにすると Compose ファイルと分離できる。セキュリティ上、考慮が必要な情報に対して有効。（間違って GitHub に push してしまうのを .gitignore で回避できる、、） wordpress.env の内容

102. args: はイメージ構築時の環境変数を定義 $ docker-compose build --build-arg="text=hello" 103 version: '3' services: apache: build: context: ./service-httpd/ dockerfile: Dockerfile.httpd args: - text=plain image: localhttpd:1.0 ports: - "80:80" FROM httpd:2.4-alpine RUN apk add tzdata && cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime && apk del tzdata ARG text RUN echo $text > /usr/local/apache2/htdocs/index.html コンテナの実行時ではなく、コンテナの build 時にのみ使う環境変数が「args:」で指定可能。 docker-compoes build時に --build-argを指定する方法と、 Composeファイルの中で「args:」を指定する方法がある。

103. オーケストレーションと Swarm mode Orchestration 104

104. Cloud Native 参照アーキテクチャ Networking Provisioning Runtime Orchestration & Management Application Definition / Development Compute Storage マイクロサービス・パターン分散オーケストレーションと管理コンテナ化インフラ ※ CNCFプロジェクトが定義する範囲外【参考】 https://github.com/cncf/presentations/blob/master/2016-software-circus/what-is-cloud-native/what-is-cloud-native.pdf 105 reference architecture 巷で話題のKubernetesとDocker（containerd）の関係性がこちら。

105. 106 ( ( ) Scheduling Cluster Management • Marathon, chronos • Docker swarm • Deis • fleet • Apache Mesos • DCOS (Mesosphere) Orchestration 複数のホスト・システム上を横断するアプリケーションをスケール（拡大・縮小）できる機能 ※コンテナに依存しない • Kubernetes • Docker Engine (swarm mode) + Docker Compose • Rancher • Nomad 設定ファイルをベースにサービスを定義・維持計算資源の抽象化「オーケストレーション」の領域は、KubernetesとDocker Engineの「swarm mode」が該当。

106. 従来のオーケストレーション 107 クラスタ一方通行従来はクラスタを構成するノードに対して、一方的なリソース要求が一般的。【参考】 https://www.slideshare.net/Docker/container-orchestration-from-theory-to-practice/7

107. 宣言型サービス・モデルのオーケストレーション 108 Declarative service model OD クラスタ Δ S D = 期待状態 O = オーケストレータ S = 状態 Δ = 状態から期待状態への収束フィードバック ⚫ レプリカ作成 ⚫ グローバル・サービス並列遅延変更可能【参考】 https://www.slideshare.net/Docker/container-orchestration-from-theory-to-practice/7 KubernetesやDocker swarm modeでは、定義した「あるべき状態」を自動的に維持する仕組み。

108. standalone swarm Docker Swarm vs Docker Swarm mode 109 SwarmKit Docker Engine Docker Engine Swarm マネージャ Swarm エージェント Swarm エージェント KVS リソース・プール管理 Docker Host Docker Host Swarm（クラスタ） Docker Engine Docker Engine Docker Engine swarm モード Docker Host Docker Host Docker Host Docker 1.12からクラスタ管理機能を内蔵管理用マネージャ・エージェントや KVS が別途必要「swarm mode」は、昔からある「Docker Swarm」（スタンドアロン）とは別モノ。

109. Swarm mode の構成要素 110 manager node worker node worker node swarm モード docker service や docker stack 等クラスタとサービスの管理コマンドを受け付けタスク (コンテナ) タスク (コンテナ) サービス docker service や docker stack 系コマンドの実行は、 kubectl と互換性を持つ ※ Docker for Mac で Experimental かつ Kubernetes 有効化の場合 Docker Engine Docker Engine Docker Engine swarm SwarmKit SwarmKit SwarmKit docker CLI - ネットワーク Ingress Network Routing Mesh Docker Compose YAML サービス定義 (option) docker コマンドを使い、分散環境でも簡単にアプリをスケールできる現在は、Dockerが入っていれば「docker swarm init」の実行で、直ちに有効化できる。

110. swarm mode のネットワーク機能 111 Multi Host Networking Worker node Worker node Worker node overlay network Ingress network コンテナ PublishPort Routing Mesh 80 443 80 443 80 443 負荷分散 swarmモードで便利なのは、複数のホスト間で共通ネットワーク(ingress)を自動生成。どのノードにアクセスがあっても、コンテナが動作しているノードに自動ルーティング。しかも、Docker Composeファイルがあれば、それを使ったデプロイも可能。サービス・ディスカバリ (動的な名前解決)

111. クラスタ初期化とサービス実行 swarm mode 112

112. Dockerのセットアップ 113 $ curl https://get.docker.com | head $ curl -fsSL get.docker.com -o get-docker.sh # sh ./get.docker.com # systemctl enable docker # systemctl start docker ※systemd系の場合 ※リポジトリの自動セットアップ ※コマンドの確認 Linuxで検証用途に手軽な方法 swarm modeを使うには、まず Docker Engine のセットアップが必要。準備はこれだけ。

113. クラスタ初期化と join 手順 114 manager ノード $ docker swarm init Swarm initialized: current node (hhzcdnj2r43ywjcmjcwbgvwa7) is now a manager. To add a worker to this swarm, run the following command: docker swarm join --token SWMTKN-1-0w2m8k41xh1tbapub….. <IP_ADDR>:2377 To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions. worker ノード $ docker swarm join ¥ --token SWMTKN-1-0w2m8k41xh1tbapub….. <IP_ADDR>:2377 managerのIPアドレスとポート This node joined a swarm as a worker. それから「docker swarm init」でクラスタを初期化。ノードの追加は「join」で。マネージャに対してのみ docker stack コマンドで操作可能。ここに出てくる文字列をワーカノードで実行

114. クラスタ join 時のトークン確認 115 manager $ docker swarm join-token worker To add a worker to this swarm, run the following command: docker swarm join --token SWMTKN-1-0w2m8k41xh1tbapubwl7sd7j7x….. <IP_ADDR>:2377 manager $ docker swarm join-token manager To add a manager to this swarm, run the following command: docker swarm join --token SWMTKN-1-0w2m8k41xh1tbapubwl7sd0m0….. <IP_ADDR>:2377 ノード追加時のコマンドを忘れてしまった場合は、このコマンドで確認。

115. クラスタ状態確認 116 manager $ docker node ls $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS hhzcdnj2r43ywjcmjcwbgvwa7 * node-01 Ready Active Leader $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS hhzcdnj2r43ywjcmjcwbgvwa7 * node-01 Ready Active Leader znmguxtqwywhja9chkkaa6a7y node-02 Ready Active 2mgqqmgt0dlv9zc932nz9rkat node-03 Ready Active あとは、ノードの状態を確認したり、

116. Compose file でサービス作成・操作 117 manager $ vi docker-compose.yml version: '3' services: web: image: zembutsu/docker-sample-nginx deploy: replicas: 3 resources: limits: cpus: "0.1" restart_policy: condition: on-failure ports: - "80:80" networks: internal: aliases: - web volumes: - /etc/localtime:/etc/localtime:ro networks: internal: $ docker stack deploy -c ./docker-compose.yml demo Creating network demo_internal Creating service demo_web $ docker stack ls $ docker stack ps demo $ docker service scale demo_web=5 $ docker service stop demo $ docker stack rm demo サービスのデプロイも行えるようになる。

117. 詳しい手順は、チュートリアルやドキュメントを 118 ⚫ Swarm mode overview | Docker Documentation https://docs.docker.com/engine/swarm/ ⚫ Get Started, Part 3: Services | Docker Documentation https://docs.docker.com/get-started/part3/ Docker for Mac/Windows では、swarm modeがすぐにご利用できます。また、今後の方向性としては Compose on Kubernetes [1]との連携により Kubernetes クラスタ上で Compose ファイルを使ってデプロイする方法もあり、引き続き Compose 周辺プロジェクトの動きには注目です。 [1] https://github.com/docker/compose-on-kubernetes

118. まとめ 119

119. Dockerとは？ 120 Why Docker? １ Dockerコンテナは実行に必要な全てをパッケージして、簡単に動かせる 2 Dockerイメージは複数のイメージ・レイヤとメタ情報の積み重なり 3 コンテナのプロセスはデフォルトで isolate（隔離・分離）された状態 ⚫ イメージ・レイヤ（image layer）は読み込み専用 ⚫ 親子関係がある ⚫ イメージに対する変更はCopy on Write（CoW)処理が走る ⚫ コンテナ実行にはイメージが必要で、Docker Hubから得られる ⚫ コンテナ実行時のみ、読み書きが可能なレイヤを追加 ⚫ namespace（名前空間）でプロセス空間やファイルシステムやネットワーク等を分ける技術と、 cgroups（コントロール・グループ）でリソースの利用上限を指定 ⚫ コンテナはポートをデフォルトで開かない ⚫ ネットワークはブリッジ、ホスト、 noneの3種類 ⚫ ボリュームはコンテナ間でファイルシステムを共有できる。名前付き (named)とホスト・ボリューム ⚫ アプリケーションを簡単に開発し、移動し、実行するためのプログラムとプラットフォームを提供するのが Docker ⚫ クライアント・サーバ型 https://docker.com プロセスを簡単にコンテナ化（isolate）し、簡単かつ素早く開発・移動・実行できるプラットフォームが Docker Containerization 「プロセス・ファイルシステム・ネットワーク・等々」に対して Namespace・Cgroup Build Ship Run

120. Docker Composeとは？ 121 What is Docker Compose? １ Composeはアプリケーションのサービスをファイルで定義する 2 Dockerコマンドと高い親和性があるため、学習コストが比較的に低い 3 Swarm モードにサービスをデプロイできるオーケストレーション機能 ⚫ docker-compose CLI のコマン体系は docker に準拠 ⚫ 例：「docker run -d」は「docker-compose up -d」 ⚫ Docker swarm モードを使えば、サービス状態を定義できるので常に期待状態を維持できる ◼ docker stack deploy ⚫ Ingress ネットワークの活用 ⚫ Compose ファイル (YAML形式) で Docker コンテナのサービスを定義できるため、再利用性が高い ◼ コンテナの状態 ◼ イメージ ◼ ネットワーク ◼ ボリューム ◼ メタ情報 https://github.com/docker/compose 複数のコンテナで構成するアプリケーションを定義と実行するためのツール multi-container applications define and run

121. 122

122. Q&A • 何か気になるところはありますか？ • https://slideshare.net/zembutsu • Dockerドキュメント日本語訳 http://docs.docker.jp • Docker Composeドキュメント日本語訳 http://docs.docker.jp/compose/ • 公式ドキュメント https://docs.docker.com 123