実用Docker入門

社内勉強会用に作った資料です。

Transcript

1. 実用Docker入門 K’AWAILLY カワイリー・ジャパン
2. 今日話すこと • Docker(コンテナ技術)を学ぶ必要性 • Dockerの仕組み(ざっくり) • Dockerの基礎知識 • Dockerを運用するうえで重要そうなこと • 良いDockerfileの書き方 • 最後に
3. Docker(コンテナ技術)を学ぶ 必要性
4. 最近の技術トレンドに求められているコト CI/CD マイクロサービス クラウド DevOps 必要 動作環境の統一 拡張性 アプリ環境の携帯性 デプロイ高速化 IaC
5. Docker(コンテナ技術)はうまく使えば それらの要求を満たせる
6. みんながDockerを使えるとどんなメリットが？ - アプリ構成の見える化 - デプロイが楽に - 新人の環境構築を高速化 - 本番環境・開発環境の差異を減らす
7. Dockerの仕組み(ざっくり)
8. Dockerはコンテナ型仮想化 ハードウェア OS&カーネル コンテナ管理プロセス (Docker daemon) コンテナ （仮想環境） コンテナ操作プロセス (Docker client) UNIX Socket プロセス コンテナ操作コマンド
9. 仮想化ソフト・仮想ハードウェアが介在しない ＋ ハードウェア・OSのシュミレーションが不要 オーバーヘッドが少ない コンテナ型仮想化のメリット
10. あれ、 仮想化してないよね？
11. 実はLinuxのnamespaceという機能で ホストとコンテナを隔離している。
12. namespaceを使った隔離のイメージ 参考：https://gihyo.jp/admin/serial/01/linux_containers/0002 hogehoge.txt index.html kawasaki.txt namespaceAの プロセス namespaceBの プロセス /var/www/html /var/www/html
13. Dockerの基礎知識(ざっくり)
14. Dockerはコンテナの中でアプリを動かす
15. コンテナを作成&起動はdocker runコマンド 参考：https://docs.docker.com/engine/reference/commandline/run/ -p ホスト側:コンテナ側 で、指定したポートを繋げる
16. コンテナを作成&起動はdocker runコマンド 参考：https://docs.docker.com/engine/reference/commandline/run/ --name [コンテナ名] で、コンテナに名前をつける
17. コンテナを作成&起動はdocker runコマンド 参考：https://docs.docker.com/engine/reference/commandline/run/ 最後にコンテナを作成する元の イメージを決める。 [イメージ名:イメージタグ] と指定できる。必須
18. やった！仮想化って簡単！
19. いやいや、イメージって何よ イメージ＝仮想環境のISOイメージ的なもの コンテナ＝イメージを元に作られた動作する仮想環境のこと コンテナ イメージ 参考：https://docs.docker.com/engine/docker-overview/#images
20. 参考：https://docs.docker.com/engine/reference/commandline/run/ httpd:2.4.41-alpineというイメージを使っている。 イメージが自PCに無いとリモートレジストリから勝手に取ってくる。
21. リモートレジストリ is 何 自PC外にあるイメージが置いてあるところ。 公開・非公開のレジストリがある。 Node.jsコンテナ作りたい けど、イメージがローカル に無い・・・ ローカル 参考：https://docs.docker.com/engine/docker-overview/#docker-registries
22. リモートレジストリ is 何 必要なイメージがローカルにない時は、 リモートレジストリから取得できる Dockerhubにあった！ 使おう！！ 参考：https://docs.docker.com/engine/docker-overview/#docker-registries Dockerhub
23. イメージは自分でも作成できる イメージはDockerfileを通して作成することができる。 イメージを 作成する手順 Dockerfile 出力 イメージを作るコマンド イメージ完成 読込
24. イメージを作る時はdocker buildコマンド イメージに名前をつけるときに書く。 [イメージ名]:[タグ名]としてタグ付けできる。 タグを指定しない場合は暗黙的にlatestタグのイ メージを作成・置き換えする。 参考：https://docs.docker.com/engine/reference/commandline/build/
25. イメージを作る時はdocker buildコマンド ビルドコンテキストを指定する。必須 指定したディレクトリにDockerfileを置く必要があ る。 ここで指定したディレクトリ以下のファイルがビル ド時に読み込まれる。 参考：https://docs.docker.com/engine/reference/commandline/build/
26. docker buildに必要なDockerfileの書き方 イメージを作成する元になる イメージを指定する。 参考：https://docs.docker.com/engine/reference/builder/
27. docker buildに必要なDockerfileの書き方 イメージの環境変数を 設定する。 参考：https://docs.docker.com/engine/reference/builder/
28. docker buildに必要なDockerfileの書き方 イメージ作成に必要な コマンドの実行 参考：https://docs.docker.com/engine/reference/builder/
29. docker buildに必要なDockerfileの書き方 コンテナ起動時に 実行するプロセスの指定 参考：https://docs.docker.com/engine/reference/builder/
30. docker runコマンドでも 起動時に実行するプロセスを指定できる 最後の引数に、コンテナ起動と同時に 実行するプロセスを指定できる。
31. コンテナは停止しても残ってる コンテナを停止しても、コンテナ自体は残り続ける。 が、コンテナを削除するとコンテナ内の情報は全て消えてしまう。 コンテナの一覧を取得するコマンド -aで停止中のコンテナも表示
32. 停止したコンテナを再起動するとき -a で標準出力+標準エラー出力を割り当てる -i で標準入力を割り当てる
33. 停止したコンテナを再起動するとき コンテナID or コンテナ名を割り当てる
34. Dockerを運用するうえで重要 そうなこと
35. Dockerコンテナは基本ステートレスにする いつ壊れてもいいように状態を持たないようにする。 ユーザーテーブル id name password 1 takashi ae04b12df1ec コンテナを消すと・・・
36. Dockerコンテナは基本ステートレスにする いつ壊れてもいいように状態を持たないようにする。 ユーザーテーブル id name password 1 takashi ae04b12df1ec コンテナ内のデータも消える
37. 永続データが必要なら docker run時にホスト側のボリュームをコンテナにマウント して永続化しよう。 ホスト環境 ユーザーテーブル id name password 1 takashi ae04b12df1ec 共有
38. docker runでホスト側ディレクトリのマウント -v [ホスト側Dir]:[コンテナ側Dir] でホスト側とコンテナ側でディレクトリの共有 が可能。 参考：https://docs.docker.com/engine/reference/commandline/run/
39. 1つのコンテナで担うのは1つの役割 役割ごとにコンテナを分けると、 スケールイン・アウトも柔軟にできる。 java appコンテナ DBコンテナ httpコンテナ
40. 1つのコンテナで担うのは1つの役割 このコンテナは • DBサーバ • httpサーバ • java appアプリサーバ という複数の役割を持つ。 だめなパターン
41. 1つのコンテナで担うのは1つの役割 tomcatのバージョンが上がり、 コンテナの再起動が必要 MySQLやhttpdも再起動する ことに だめなパターン
42. 1つのコンテナで担うのは1つの役割 役割ごとにコンテナを分けると、 バージョンアップの影響がほかのコンテナに 及ばない。 java appコンテナ DBコンテナ httpコンテナ
43. アプリ実行に必要なファイルは全てイメージに入れる コンテナ内ファイルシステム • main.class • index.jsp • ... アプリの実行を外部環境に依存させないことで、 アプリ環境の携帯性を上げる。
44. アプリの設定変更を柔軟に行えるようにする 例えば・・・ コンテナ内ファイルシステム hogehoge.properties ホスト環境 hogehoge.properties
45. 軽量なDockerイメージを作る Dockerイメージを取得するのにか かる時間 アプリを起動するのに かかる時間 デプロイするのに かかる時間 Dockerイメージを軽量化して、 なるべくデプロイにかかる時間 を減らそう
46. メインプロセスはコンテナ起動時に実行する DockerfileのCMD命令にはコンテナで実行する メインプロセスをフォアグラウンドで動作するように指定す る。 コンテナ起動！ tomcatも起動！
47. メインプロセスはコンテナ起動時に実行する コンテナも死亡！ tomcat死亡！ メインプロセスの停止＝コンテナの停止となるので、 アプリ自体の死活監視が楽になる。
48. 良いDockerfileの書き方 ビルド高速化編
49. ビルドコンテキストを減らす ここでビルドコンテキストを指定している。 ここで指定したディレクトリ以下のファイルがビル ド時に読み込まれる。 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles
50. 不要なファイルをビルドコンテキストに含めない ビルドコンテキストを狭めて ビルド時に読み込むファイルを減らす ビルドコンテキスト 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles
51. 不要なファイルをビルドコンテキストに含めない（だ めなパターン） ビルドコンテキストを狭めて ビルド時に読み込むファイルを減らす ビルドコンテキスト 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles
52. ビルドコンテキストを減らすと 不要なファイルをビルドコンテキストに含めなければ ビルドは早くなる。 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles
53. ビルドキャッシュを使いこなす Docker buildで一度ビルドした内容はキャッシュされる。 このキャッシュをうまく使うことでビルドの高速化を図る。 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles
54. COPY命令の位置に気をつける キャッシュが効きにくい処理は下に持っていく 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles キャッシュ有効 キャッシュ無効 COPY命令はコピー元ディレクトリ以下に変更があると、 以降の命令のキャッシュを破棄する
55. COPY命令の位置に気をつける（だめな例） 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles キャッシュ有効 キャッシュ無効 コピー元ディレクトリ以下に変更があった場合
56. 良いDockerfileの書き方 イメージ軽量化編
57. 不要なファイルをイメージに残さない 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles • パッケージマネージャのダウンロードキャッシュ • 必須でない依存関係にあるパッケージ • ビルドのときだけ必要なツール
58. パッケージマネージャのキャッシュを削除 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles とりあえずキャッシュクリア
59. 必要な依存関係にあるパッケージのみインストール 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles debian系はapt-get installでこのオプションをつけ る。 redhat系は不要。
60. マルチステージングビルドを使う 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles docker buildを複数の段階に分けることができるヤツ。 最後にビルドされたステージがイメージとして吐き出される。
61. マルチステージングビルドでできること 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles Dockerfile ビルドステージ 完成ステージ ビルド ビルド成 果物
62. マルチステージングビルドでできること 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles Dockerfile ビルドステージ 完成ステージ ビルド ビルド成 果物 COPY 命令 --from=ビルドステージ ビルド成 果物
63. マルチステージングビルドでできること 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles Dockerfile ビルドステージ 完成ステージ ビルド ビルド成 果物 ビルド成 果物 イメージとして吐き 出される
64. FROM命令で軽量イメージを読み込む 203MB 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles
65. FROM命令で軽量イメージを読み込む 5MB alpine-linux 組み込みで使われるLinux。 かな～～～～～～～～り軽い。 参考：https://www.slideshare.net/zembutsu/explaining-best-practices-for-writing-dockerfiles
66. 軽いイメージには裏がある • alpine-linuxはglibc（GNU標準Cライブラリ）が入ってない • glibcをコールするアプリは落ちる可能性あり • ビルド時に静的リンクを指定するといい
67. 最後に
68. 複数コンテナの運用について • コンテナ間通信 • 複数コンテナの並列起動・停止 • コンテナ間の依存関係に基づいた設定 docker単体でやるのは面倒くさい
69. 面倒くさい理由 • コンテナ間通信 • 複数コンテナの並列起動・停止 • コンテナ間の依存関係に基づいた設定 docker network設定しないと、 ホスト名でほかコンテナに アクセスできない 参考：https://docs.docker.com/network/bridge/
70. 面倒くさい理由 • コンテナ間通信 • 複数コンテナの並列起動・停止・更新 • コンテナ間の依存関係に基づいた設定 イメージの更新があったらコンテナ作り直したり ・・・ スクリプト書くの地味に大変
71. 面倒くさい理由 • コンテナ間通信 • 複数コンテナの並列起動・停止・更新 • コンテナ間の依存関係に基づいた設定 Redisコンテナ起動 appコンテナ起動 管理辛い
72. そこでdocker-composeを使う docker-composeは複数コンテナの運用を楽にするアプリ。 docker-compose.ymlという定義ファイルに複数コンテナ運用に 必要な設定が書ける。
73. ご清聴ありがとうございました。 よろしければ感想を下記に入力してください。