はじめてのコンテナ / Container 101 in 3 days

とあるIT企業の新卒が新卒のために3日で行った「はじめてのコンテナ研修」

Transcript

1. 3日で学ぶはじめてのコンテナ
2. 1日目 コンテナとは
3. あじぇんだ 1. コンテナとは 2. いんすこ 3. コンテナを使う 4. コンテナを作る・保存する 3
4. コンテナ 4 * https://www.monotaro.com/g/02895278/
5. コンテナ 5 ??? ????
6. （IT分野）コンテナ 6 mobyくん docker compose ?? docker swarm ??? ??? ????
7. （IT分野）コンテナ 7 mobyくん docker compose ?? docker swarm ??? ??? ???? ？
8. コンテナ(化)とは 8 まじめにやります ▪ コンテナ Container • アプリケーションがある計算環境から別の計算環境で 素早く確実に実行できるように、 コードとそのすべての依存関係をパッケージ化する ソフトウェアの標準単位。 * * https://www.docker.com/resources/what-container/ パッケージ化された アプリケーション
9. コンテナ化とは > アプリケーションがある計算環境 から別の計算環境で ... ▪ 「ある計算環境」=「開発者のコンピュータ」のこと ▪ 「別の計算環境」=「実行者のコンピュータ」のこと たとえば... 9 ソフトウェアが全国の子供達の 元へ出荷される様子
10. コンテナ化とは たとえば ▪ あるPCゲームを遊びたい • Java 8のインストールが必要です • 30億のデバイス(ry • DirectX 11のインストールが必要です • インストール後、このファイルもここに置く • etc… なぜこうなるのか ▪ 開発者や他プレイヤーと自分のPC環境は違う！ • 入っているソフトウェア、modファイル、設定ファイル、... 10
11. コンテナ化とは あるPCゲームを遊びたい → ▪ Steam / Epicなら • 必要なソフトウェア、設定ファイルを丸ごとインストールしてくれる！ • 「Play」ボタンを押すだけ • （でも最近のゲームってみんなそうですよね... 体験が良い） ≒ コンテナ化 (Containerization) 11
12. コンテナ化とは ゲーム以外のソフトウェアも同じ ▪ 「このソフトウェアにはNode.js v20とあのライブラリとこのライブラリが必要」 • 1. 実行サーバー上に 直接インストール？ • 「npm install -g foo@1.2.3 を実行します」 • 「同サーバー上で動いている別ソフトウェアが応答停止しました！」 • 実はそのライブラリの1.2.3には破壊的変更が入っており、 上書きインストールしたことで他ソフトウェアに影響が！！ • みたいなことになりかねない • 2. コンテナ化 = 必要なファイルや依存を全てパッケージ化 • 環境が分離 されるため、サーバー上で動いている他のソフトウェアには 原理的に影響が及ばない ！ 12 色んなソフトが インストールされて爆発
13. コンテナ化とは > アプリケーションがある計算環境から別の計算環境で... → コンテナを使うと、可搬性（portability）が向上する。 要するに「いろんな環境にすぐにインストールできて便利」ってこと 13
14. 標準としてのコンテナ ▪ コンテナ Container • アプリケーションがある計算環境から別の計算環境で 素早く確実に実行できるように、 コードとそのすべての依存関係をパッケージ化する ソフトウェアの標準単位。 * > パッケージ化するソフトウェアの標準単位 コンテナ（Docker image）はOCIによって標準化されたソフトウェアのフォーマット → 結構いろんなところで動かせる ▪ 自分のPC上で • Docker Engine / Docker Desktop / Kubernetes • Podman, containerd, CRI-O, … ▪ クラウド上で • Managed-Kubernetes: EKS, GKE, AKS, OKE, … • ECS, App Runner, Cloud Run, Cloudflare Workers, … 14
15. 標準としてのコンテナ > パッケージ化するソフトウェアの標準単位 要するに ▪ 色んなところで（可搬性; portability） ▪ すぐに / 簡単に（設置性; installability） ▪ 競合を起こさず（共存性; co-existence） 自分のソフトウェアを動かせて、便利！ 15
16. 講義の目的
17. 講義の目的 目的 ▪ Dockerを始めとするコンテナ技術の根底を理解 することで • どのような時にコンテナが必要か を理解できる • コンテナを使いこなし、開発、運用（デプロイ） を効率的に行う • コンテナが役立つのはデプロイの時だけではありません！ cf. dev containers ここでは（あまり）やらないこと ▪ コンテナ関連の技術を網羅的に紹介 すること • CNCF Landscape* でも眺めておいてください ▪ 個々の技術の実装詳細、コマンド体系、実際の使い方を、 すぐに実務で使えるレベルで 解説すること • コンテナ関連の技術は流れが早く、 1年前とベストプラクティスが全く違う などが よくあります。 • 細かい使い方は覚えず、「その技術は何ができるか」という概要の理解に抑えましょう。 • コマンドオプション丸暗記は 2025年では一才意味がありません（強い主張）。 • ChatGPTに聞いてください。マジで。 17 * https://landscape.cncf.io/
18. Disclaimer: 講義の構成 この講義の構成は roadmap.sh* を参考にしました Docker, Kubernetes以外にも色々な技術分野があるので 確認してみてね 18 * https://roadmap.sh/docker
19. コンテナ vs VM（vs ベアメタル）
20. ソフトウェアを動かす ▪ 原始時代（ベアメタル） 20 * https://courses.devopsdirective.com/docker-beginner-to-pro/lessons/01-history-and-motivation/03-history-of-virtualization 👍 ▪ シンプル 👎 ▪ 依存のコンフリクト ▪ アプリが爆発したときの 影響範囲のデカさ ▪ 起動が遅くなる ▪ 確保・リースが大変 • 数ヶ月 ~ 数年単位でかかる
21. ソフトウェアを動かす ▪ 仮想マシン（Virtual Machine; VM）= ハードウェアレベル の仮想化 21 👍 ▪ 依存がコンフリクトしない ▪ アプリが爆発しても大丈夫 = セキュリティの向上 ▪ 確保が簡単 ▪ 起動が速い 👎 ▪ ハイパーバイザ・OSの オーバーヘッド
22. ソフトウェアを動かす ▪ コンテナ = OSレベルの仮想化 22 👍 ▪ 依存がコンフリクトしない ▪ アプリが爆発しても大丈夫 = セキュリティの向上 ▪ さらに確保が簡単 ▪ さらに起動が速い 👎 ▪ OSは共有
23. ソフトウェアを動かす 結局どれで動かしたら良い？ もちろん万能な解決策（one-size-fits-all）は無い、が... （うちで扱うような）だいたいのWebアプリケーションは OSレベルの仮想化で良い はず = docker とか もっと細かい仮想化の歴史はご自身で調べてみてください >< https://en.wikipedia.org/wiki/Timeline_of_virtualization_technologies 23
24. Dockerを実現する様々な技術
25. Dockerを取り巻く技術 ⭐注意点⭐ そんなのあるんだ程度に聞いておいてください メモ・丸暗記する必要はありません 今後必要になったときに適宜LLM + RAGしてください 25
26. Dockerを取り巻く技術 > OCI Open Container Initiative (OCI) * > The Open Container Initiative is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes. Docker（会社）を始めとする複数社が集まってできた標準化団体 主にOCI Image（docker imageのこと）や、OCI Runtime Spec.の 設計に取り組んでいる 26 * https://opencontainers.org/
27. Dockerを取り巻く技術 > OCI Dockerの技術スタック 27 Docker CLI Docker Backend (dockerd) containerd runc OCI Runtime Spec. 低レベルランタイムの 動作を定義 OCI Image Format ソフトウェアの パッケージ形式を定義 Container Registry OCI Distribution Spec. OS (Linux) Hardware HTTP UNIX domain socket gRPC exec syscall Image Push/Pull CRI RESTful API
28. Dockerを取り巻く技術 > namespace Namespaces（Linux Kernelの機能）* > A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes. One use of namespaces is to implement containers. リソース（プロセス空間、ネットワーク、ファイルシステム、 IPC空間、ユーザーID空間など）を分離するLinuxカーネルの機能 28 * https://man7.org/linux/man-pages/man7/namespaces.7.html
29. Dockerを取り巻く技術 > OverlayFS OverlayFS (Filesystem)* 複数のファイルシステムの“レイヤー”を積み重ね、 一つのファイルシステムのように見せかける技術 似た実装: overlayfs (in-kernel since 3.18), UnionFS, AUFS, Brtfs, zfs, … 29 * https://docs.docker.com/engine/storage/drivers/overlayfs-driver/ この“レイヤー構造”は使う上で結構出てきます！ ので頭に入れておいて
30. Dockerを取り巻く技術 > OverlayFS 30 * https://docs.docker.com/get-started/docker-concepts/building-images/understanding-image-layers/ Docker Imageの構成 ▪ 複数のreadonlyな“レイヤー”が重なっている Dockerコンテナの構成 ▪ Docker Imageの上に、一枚のwritableなレイヤーが重なる
31. 💡 実習: OverlayFS 31 * https://docs.docker.com/get-started/docker-concepts/building-images/understanding-image-layers/ ** https://github.com/wagoodman/dive ▪ Docker Hubから好きな イメージのレイヤーを 見てみよう • オススメCLI: dive** ▪ それができたら、 元のDockerfileも覗きにいっ てみよう
32. あじぇんだ 1. コンテナとは 2. いんすこ 3. コンテナを使う 4. コンテナを作る・保存する 32
33. Dockerのインストール 33 これまでの座学で学んだように... Dockerやコンテナ関連の技術は、 Linux (Kernel) の技術の上に成り立って います！ これはどういうことかを語弊を恐れずに言うと OSSのDocker (Engine)はmacOSやWindowsでは使えません
34. Dockerのインストール...？ 34 衝撃の事実なのでもう一度言います
35. Dockerのインストール...？ ＿人人人人人人人人人人人人人人＿ ＞　DockerはmacOSで使えません　＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣ 35
36. DockerはLinux以外では使えない 36 もう少しどういうことなのかを説明すると ▪ Dockerやコンテナ技術はLinux Kernelの機能の上に成り立っている • 当然ながら、macOSやWindowsは、Linuxではないので、互換性はない • Docker EngineはLinux向けであり、macOSやWindows向けではない ▪ でも開発用にmacOSやWindowsでもDockerを使いたい！！！ • → Linux VMを建てます
37. DockerをLinuxで使う場合（普通の場合） 37 * https://courses.devopsdirective.com/docker-beginner-to-pro/lessons/01-history-and-motivation/03-history-of-virtualization Linux Kernel Docker Engine
38. DockerをmacOSで “どうしても” 使いたい場合 38 Windowsの場合も基本は同様（ Linux VMが立つ） Hardware macOS Kernel アプリ1 アプリ2 Hypervisor.Framework Linux Kernel (VM) Docker Engine コンテナ1 コンテナ2 ハイパーバイザ わざわざVMを立てて Linux Kernelをエミュレート
39. DockerをmacOSで “どうしても” 使いたい場合 ＿人人人人人人＿ ＞　あほくさ　＜ ￣Y^Y^Y^Y^Y^Y￣ 39
40. DockerをmacOSで使いたい 40 ▪ 一番多いのは “Docker Desktop” というソフトウェアを用い、 Linux VMを通してdockerを使うこと • Docker Desktopのライセンス* では、一定規模以上の商用利用は有償プランに 加入することが義務付けられている • しかし人数単位で課金されるので、意外と高くつく ▪ 幸いに、Docker Desktop以外にも、 Linux VMを建ててdockerを動かす選択肢があります ** • Lima, (colima,) Podman, Rancher Desktop, Orbstack, … • 今回はLimaを使います * https://docs.docker.com/subscription/desktop-license/ ** https://zenn.dev/ttnt_1013/articles/f36e251a0cd24e
41. 💡 実習: DockerをmacOSにインストール 41 ▪ Limaをインストール • https://github.com/lima-vm/lima ▪ templates/docker-rootful.yaml を持ってくる • https://github.com/lima-vm/lima/blob/master/templates/docker-rootful.yaml ▪ limactl create lima.yaml ▪ limactl start lima ▪ limactl shell lima ▪ limactl stop lima
42. あじぇんだ 1. コンテナとは 2. いんすこ 3. コンテナを使う 4. コンテナを作る・保存する 42
43. 💡 実習: Dockerを使ってみよう Dockerと仲良くなってみよう ▪ docker run --rm hello-world ▪ docker ps ▪ docker image ls 43
44. 💡 実習: Docker Composeを使ってみよう ▪ docker compose • 今回はDocker Desktopじゃないので個別でプラグインのインストールが必要 • docker-compose（notice the “-”!）は古いv1なので注意 • execプラグイン形式のv2を使用しましょう ▪ 複数コンテナを扱うときに便利 • 一気に立ち上げる • ネットワーク: お互いにコンテナ（サービス）の名前でアクセスできる • ボリュームのライフサイクル管理 44
45. あじぇんだ 1. コンテナとは 2. いんすこ 3. コンテナを使う 4. コンテナを作る・保存する 45
46. 復習 > Docker Image / コンテナ 46 * https://docs.docker.com/get-started/docker-concepts/building-images/understanding-image-layers/ Docker Imageの構成 ▪ 複数のreadonlyな“レイヤー”が重なっている Dockerコンテナの構成 ▪ Docker Imageの上に、一枚のwritableなレイヤーが重なる
47. コンテナを作る Dockerfile ▪ Docker Imageを作るための定義書 • FROM: ベースイメージを定義（一番最初のレイヤーになるもの） • “FROM scratch”: ゼロから（ダジャレ） • COPY: ホストからファイルをコピー、レイヤーを 1つ追加 • RUN: コマンドを実行、レイヤーを 1つ追加 ▪ Multi-stage build • “FROM” が複数ある Dockerfileのこと • FROM foo AS stage-name で“ステージ”名を定義 • COPY --from=stage-name で前のステージからファイルをコピー してくる • 最終イメージにコンパイラのファイルなどを残したくない ときに便利 * https://docs.docker.com/reference/dockerfile/ 47
48. コンテナを作る Dockerfile ▪ レイヤーキャッシュ ・イメージサイズ問題 • 調べると色々プラクティスは出てくるが、 基本はDocker Imageが“レイヤーである ”ことを理解していれば簡単！ • 同じファイル & 同じコマンドの場合は、キャッシュされる • 純粋関数型みたいだね • RUN rm filename しても、「削除した」という情報を持つレイヤーが残るだけ • “whiteout” file: 削除したという情報を持つ特別なファイル • ファイル自体は下のレイヤーに残っている = イメージサイズは減らない！ • → イメージサイズ肥大化の回避方法: 一つのRUN命令内で必要なコンパイラなどのインストール & 実行 & 削除までやる • Multi-stage buildしているのなら、そこまで頑張らなくても良いけどね 48
49. 💡 実習: コンテナを作る ▪ 適当なDockerfileを見てみよう • 社内project or OSS? ▪ ビルドしてみよう • Buildxも触ってみよう • これって最近のDocker Desktopだと有効化されてるのかな ▪ CIも見てみよう • どうやってビルドしているの 49
50. コンテナレジストリ Docker Imageを保存する場所 ▪ SaaS型 • Docker Hub, GitHub Container Registry (ghcr) • Google Cloud Registry (gcr), Elastic Container Registry (ecr), … ▪ セルフホスト型 • Quay, Harbor, … 💡 やってみよう: Docker Hubを覗いてみよう 50
51. コンテナレジストリ ▪ タグの付け方 • あるアーティファクト（イメージ）には、1個以上のタグをつけることができます • タグはmutableなので、後から変更・削除もできます！ • Gitのタグみたいだね • docker/metadata-action 51
52. 💡 実習: Docker Imageを作ってみよう ▪ 適当なDockerfileを探す • Docker Hubなどからソースを探してきてもいいかも ▪ ビルドする • Buildx plugin? ▪ ビルドしたものからコンテナを作成する ▪ （どこかのレジストリにpushしてみる） • ghcrが楽かも ▪ 発展: 自分の好きなアプリをコンテナ化してみる ▪ 発展2: DBなどの依存を含めてdocker composeで動かしてみる 52
53. 2日目 コンテナのさらなるあれこれ
54. あじぇんだ 1. コンテナセキュリティ 2. ネットワーク 3. ストレージ 4. その他: watch, test, CI, … 5. デプロイ先 54
55. コンテナセキュリティって？
56. コンテナセキュリティ セキュリティとコンテナ（仮想化）は 切っても切り離せない 56
57. コンテナセキュリティ 57 ▪ おさらい
58. 仮想化 = 分離の利点 ▪ 可搬性・設置性の向上 だけでなく... ▪ セキュリティの向上 • アプリケーションが暴走した場合 = バグやDoS攻撃を含む → リソースの使用を制限 → 他の仮想化アプリまで影響が及ばない • アプリケーションに攻撃があった場合 e.g. RCE → 環境を分離 → ホストや他の仮想化アプリまで影響が及ばない 58
59. なぜセキュリティが向上するか ▪ もっと具体的に言うと 59
60. なぜセキュリティが向上するか 60 アプリケーションにRCEの脆弱性があったとする Namespaceで様々な空間が分離されていない と... ▪ プロセス空間 → 他アプリケーションのプロセスに干渉・監視 できる kill, strace, … ▪ ネットワーク → 他プロセスのネットワークを監視 、内部ネットワークから攻撃 ... ▪ ファイルシステム → 他アプリ設定ファイル の書き換えや機微情報 の流出 /etc/shadow ▪ IPC → 他アプリの共有メモリへのアクセス ▪ ユーザID / seccomp / privileges → 危険な操作が可能に 他プロセスの監視やホストのシャットダウンまで などなど
61. なぜセキュリティが向上するか 61 コンテナを使用して空間が分離されていれば... ▪ RCE → 攻撃者がシェルを入手しても、基本的に何もできない • そのコンテナの中の設定ファイルや環境変数を読むくらい まあそれだけでもヤバいのはそうなんですけど ▪ コンテナイメージに危ないバイナリを含めない • もしRCEがあってもシェルや色んなコマンドがそもそも無ければ できることは少ない 例え: 一つの建物に複数の部屋を分割し、ロックしておく 部屋の中から鍵は開けられない & 部屋の中には最低限のモノしかない 攻撃者が一つの部屋の中に入ったとしても、 他の部屋は無事
62. なぜセキュリティが向上するか 62 攻撃者視点だと ▪ cat /etc/shadow → そもそもそんなファイルはない ▪ ps aux / strace → このアプリ以外のプロセスは見えない ▪ shutdown -r now → seccomp / privilegesをdropしておけば叩けない ▪ そもそもシェルをイメージに含まないことでシェルを取らせない せっかくRCEしてやったのにそれ以上攻撃範囲を広げられない 何もできなくてマジでムカつく
63. コンテナセキュリティって必要？ 63 簡単に言えば... ▪ 多層のセキュリティ を設けるため • 一つの防御だけだと、それが破られたときに何もできない • 現実にはコンテナなどを使い、防御層を増やす アプリケーションの脆弱性の修正も大事だけど、 全ての修正にまでは実際手が回らないことも多い cf. ゼロデイ攻撃 → インフラ側で根本的な対策（分離、syscallの制限...）をしておけば、 　 万が一攻撃を受けても防げるコトも多い
64. コンテナセキュリティのプラクティスあれこれ
65. セキュリティのプラクティスあれこれ 65 ⭐注意点⭐ ▪ 雑に色々紹介しますが、今すぐ全部メモ・暗記しなくていいです （しないでください できたらすごいけど） ▪ そういう概念に気をつけなければいけないという さわりだけ頭にインプットしてください • 実際にどうやって対策すればいいの？は適宜必要になったらLLM + RAGなどで調べる • 2025年度現在言っていることが数年先正しいとも限らない
66. イメージの作成時 66 リスク: アプリケーションの脆弱性 ▪ あまりビルドを頻繁にしていないイメージだと ... めっちゃ古いバージョンで脆弱性いっぱいだったり 対策: 依存関係の定期的な更新 ▪ ベースイメージのバージョンを更新する • 言語のバージョンはもちろん ▪ アプリケーションの直接的・間接的な依存を更新する • OSに同梱しているライブラリのバージョンとか見逃しがち ▪ 定期的に再ビルドする
67. イメージの作成時 67 リスク: アプリケーションの脆弱性 対策: 脆弱性のスキャン ▪ スキャナーを用いる • Aqua security, trivy, tristlock, sysdig secure, anchore engine, openscap, … • OSSのもいっぱいあります • イメージ内のファイルをスキャン → 既知の脆弱性を報告してくれる • 全ての脆弱性が分かるわけではない 結構見落としも多い ▪ アップロード・デプロイ時などに自動スキャン + 通知を行う • ただし全てに手をつけていられない / オオカミ少年になってはいけない • 対応に優先度を付ける / 複層の防御を行う
68. イメージの作成時 68 リスク: サプライチェーン攻撃 ▪ レジストリのタグはmutable • ubuntu:24.04 とか使っているつもりだったけど、いつの間にか中身が変わっている 対策 ▪ タグを固定する + 自動更新をかける • 自動マージ・デプロイは気をつけて行う（cf. Renovate > minStabilityDays） ▪ ベースイメージや使用イメージの選定には注意を払う • 信頼できるアップロード元か？ • セキュリティスキャンが付いているレジストリもある
69. コンテナの実行時 69 リスク: 不適切な分離 ▪ コンテナは環境の分離・制限によりセキュリティを向上している • しかし、この分離が時には特定のアプリケーションで妨げとなることも → 分離・制限を無効化するオプション が存在します • 当然ながら、分離・制限を無効化すれば、コンテナを使うことによる セキュリティの向上効果は得られません = コンテナを使っている意味がない ！ 対策: 分離・制限オプションを理解する & 理解しないで無効化しない ▪ Dockerの場合 • --security-opt seccomp=unconfined → 危険なsyscallを許可 • --privileged → 雑に言えばhostのrootと同じくらい危険 • --net host → hostのinterfaceや通信が見える • -v /:/rootfs → ファイルシステムの分離が意味なくなる などなど
70. 💡 実習: 脆弱なコンテナ 70 ▪ 適当な脆弱なコンテナを持ってきて攻撃してみる ▪ Webshellからコンテナ内をみてみる ▪ コンテナの分離機能を有効にしているとき / しないときで比べる • ネットワークが分離していなかったら？ • ホストのファイルシステムをマウントしていたら？ • 実行ユーザーがrootだったら？ • ホストとuser IDのマッピングは同じものとする
71. 💡 実習: 脆弱なコンテナ 71 CVE-2022-22965 (CVSS 9.8) https://github.com/BobTheShoplifter/Spring4Shell-POC docker run -it --rm -p 8888:8080 bobtheshoplifter/spring4shell-vulnerable-tomcat docker run -it --rm --network host ghcr.io/bobtheshoplifter/spring4shell-poc:main --url http://localhost:8888/spring-form/greeting CVE-2017-12617 (CVSS 8.1) https://github.com/ygouzerh/CVE-2017-12617 https://github.com/cyberheartmi9/CVE-2017-12617 あんま試してない
72. あじぇんだ 1. コンテナセキュリティ 2. ネットワーク 3. ストレージ 4. その他: watch, test, CI, … 5. デプロイ先 72
73. （Dockerの）ネットワーク 73 ▪ あんまり詳しいことは説明しません • 僕も詳しく無いので説明するとボロが出る • 一言でいうと: bridgeというネットワークに 各コンテナがvethを通して繋がって外界と通信 ▪ 仕組みをざっくり知っておくと良い • ネットワークのトラブルはマジでよくある • トラブルシューティング時 に役立つ • 今時はLLMに聞きながらやればいいけど * https://knowledge.sakura.ad.jp/23899/
74. 💡 実習: Dockerのネットワーク 74 ▪ docker network ls/create • docker run --network でネットワークを指定してコンテナを作成 • コンテナ名で解決できるか • お互いのIPに通信できるか / ネットワーク外のコンテナには通信できないか ▪ docker compose • コンテナ群が互いに通信するときdockerのnetwork機能を使っている • サービス名で解決できるか • お互いのIPに通信できるか / ネットワーク外のコンテナには通信できないか ▪ --network=host でネットワークが分離されていないことを確認
75. あじぇんだ 1. コンテナセキュリティ 2. ネットワーク 3. ストレージ 4. その他: watch, test, CI, … 5. デプロイ先 75
76. コンテナにおけるストレージの扱い 76 前提: コンテナはscrap and buildするもの 1. イメージからコンテナを作成 • cf. クラスからインスタンスを作成 2. コンテナが削除されたら ファイルシステムに書いたデータは全部消える
77. Dockerにおけるストレージ 77 VolumeやBind mountを用いることで... ▪ コンテナのライフサイクルを超えて 永続化 ▪ コンテナ間、またはホスト⇔コンテナ間で データを共有 • 正確に言えばdocker用語ではbind mount ≠ volume Kubernetesではどっちもvolumeっていうからややこしい ストレージの種類 ▪ Volume • Named volume, anonymous volume ▪ Bind mount • ホストのファイルをコンテナ内にマウントできる • readonly, shared, slave, … 様々なモードがある* * https://docs.docker.com/engine/storage/bind-mounts/
78. 💡 実習: ストレージを使ってみよう 78 ▪ Named volumeを作る ▪ （Volumeをattachした）コンテナを作る • → マウントしたボリュームに書き込む • → コンテナを削除する ▪ （Volumeをattachした）コンテナを新しく作る • → ファイルが読めることを確認する ▪ ホストから設定ファイルをreadonlyでマウントしてみる ▪ -v /:/rootfs などでホストのファイルシステムにアクセスできることを確認して みる
79. あじぇんだ 1. コンテナセキュリティ 2. ネットワーク 3. ストレージ 4. その他: watch, test, CI, … 5. デプロイ先 79
80. 雑多な知識 80 知っておくと開発で役立つかもしれない雑多な知識です
81. 雑多な知識 > ホットリロード 81 ▪ ホットリロード = ソースコードが変更されたときに 自動で再ビルド・再読み込みすること • 開発時の修正→チェックのループを高速化 • 意外とこれがバカにならない ▪ やりかた • Bind mount + 各種hot reloadプログラム • docker compose watch
82. 雑多な知識 > Dockerを使ったテスト 82 テスト環境の構築 ▪ 同じ環境を用意するのにコンテナは適している ▪ DBコンテナ、アプリケーションコンテナなど • （重いので本当は避けたいが）テストケースごとにDBコンテナを立て直すなど
83. 雑多な知識 > CI / CD 83 Continuous Integration / Continuous Delivery (Deployment) ▪ GitHub Actions • docker/metadata-action • docker/build-and-push-action • docker/bake-action • 色々あるよ
84. 💡 実習: 時間が余ったら 84 ▪ ホットリロード docker compose watch ▪ CI / CDの設定例を知っているプロジェクトから探してみる
85. あじぇんだ 1. コンテナセキュリティ 2. ネットワーク 3. ストレージ 4. その他: watch, test, CI, … 5. デプロイ先 85
86. デプロイ先 86 イメージを作って、これをデプロイする先のお話 ▪ PaaS • Cloud Run, AWS ECS / App Runner, Cloudflare Workers, … ▪ Kubernetes • 明日やります ▪ Docker Swarm ▪ Nomad
87. 3日目 はじめてのKubernetes
88. あじぇんだ 1. Kubernetesとは 2. ワークロード + 実習 3. スケジューリング 4. セキュリティ 5. モニタリング 6. その他 88
89. Kubernetesとは 89 https://github.com/motoki317/mini-k8s-hands-on こっちの資料を参照します
90. ワークロードについて + 💡 実習 90 引き続き motoki317/mini-k8s-hands-on を参照します
91. あじぇんだ 1. Kubernetesとは 2. ワークロード + 実習 3. スケジューリング 4. セキュリティ 5. モニタリング 6. その他 91
92. スケジューリング 92 > In computing, scheduling is the action of assigning resources to perform tasks.* ▪ Kubernetesにおけるスケジューリング = ワークロード（= Pod）のスケジューリング • = PodをどのNodeで動かすかを決める ▪ やり方 • Podごとのresources.requests指定 → binpacking • topologySpreadConstraints → 耐障害性 • taints / tolerations → 特別なNodeを避ける • etc * https://en.wikipedia.org/wiki/Scheduling_(computing)
93. スケジューリング 93 ▪ オートスケール • Cluster Autoscaler • Karpenter ▪ Eviction • Node-pressure / API-initiated
94. あじぇんだ 1. Kubernetesとは 2. ワークロード + 実習 3. スケジューリング 4. セキュリティ 5. モニタリング 6. その他 94
95. Kubernetesセキュリティ 95 ▪ RBAC (role-based access control) ▪ NetworkPolicy ▪ securityContext
96. Kubernetesセキュリティ > RBAC 96 RBAC (role-based access control) ▪ Role: 権限を定義 (namespaced) ▪ ClusterRole: 権限を定義 (cluster-scoped) ▪ RoleBinding: SAにロールで定義された権限をnamespace内で付与 ▪ ClusterRoleBinding: SAにロールで定義された権限を全 namespaceで付与
97. Kubernetesセキュリティ > NetworkPolicy 97 ▪ 前提: デフォルトでPodはクラスター内ネットワークからの全ての通信を許可 する ▪ NetworkPolicy • L3 or L4で通信を制御 • cf. ファイアウォール, AWSのSecurityGroup, みたいな
98. NetworkPolicy 98 ▪ 対象となるpodを選択 ▪ Ingress: 受け入れるトラフィックを選択 • IP Rangeで選択 • Namespaceで選択 • Podで選択 ▪ Egress: 送出するトラフィックを選択 • IP Rangeで(ry * https://kubernetes.io/ja/docs/concepts/services-networking/network-policies/
99. Kubernetesセキュリティ > securityContext 99 securityContext* という設定がPodの定義にあり、色々セキュリティ関連の動作を制御できる ▪ プロセスのuid/gid: 0以外を指定しよう ▪ SELinux label / AppArmor profile ▪ 特権モード (privileged) • コンテナの分離機能をほぼ全て無効化するので基本的に危険 ▪ Capabilities**: rootを直接与えるのではなく部分的に権限を付与 ▪ Seccomp: syscallを制御 ▪ etc * https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ ** https://man7.org/linux/man-pages/man7/capabilities.7.html
100. Kubernetesセキュリティまとめ 100 ▪ セキュリティの基本 = 最小権限の原則 = 必要な権限以外与えない • コンテナでのやり方 → 必要な機能を与えない / 環境を分離する ▪ 何ができるかを確認して適切な分離を行おう • aquasecurity/kube-bench: マニフェストがベストプラクティスに沿っているかをチェック が、こういうlinterをいきなり全てクリアするのはキツイので... • Security Checklist*: チェックリストを公式がまとめてくれているよ * https://kubernetes.io/docs/concepts/security/security-checklist/
101. あじぇんだ 1. Kubernetesとは 2. ワークロード + 実習 3. スケジューリング 4. セキュリティ 5. モニタリング 6. その他 101
102. モニタリング / 可観測性 102 ▪ モニタリング vs 可観測性 • モニタリング: 故障などをメトリクスで監視して通知など • 可観測性: システムの内部状態を詳しく知ること ▪ 可観測性 = Observability（o11y）が大事 • Observabilityが無いと • どんなユーザーがどれだけアクセスしているのか分からない！ • システムがどれだけの処理をして、どれだけシステムに余裕があるのか （saturation）が分からない！ • 障害が起きたときに、なぜ障害が起きたか、どう調査・復旧すれば良いか、 原因が分からないので根本対策のしようが無い！ • 特にKubernetesにおいては、多くのコンテナが行ったり来たりする = 複雑なシステム なので、特にObservabilityが重要
103. Observability > 3つの柱 103 ▪ Metrics: Time-series data • アプリケーションやシステムで何が起きていたかを時系列で知る • cf. Four Golden Signals* • Latency, Traffic, Errors, Saturation ▪ Logs: アプリケーションが何をしていたか • cf. Structured logging ▪ Traces: リクエスト / トランザクションがどのように処理されたか • cf. Distributed tracing • cf. Continuous Profiling * https://sre.google/sre-book/monitoring-distributed-systems/
104. Observability > Kubernetes特有のポイント 104 ▪ Metrics: cAdvisor (api-server built-in) • コンテナのいろいろがデフォルトで取れる ▪ Logs • コンテナ: /var/run/logs 以下（にあるはず） • Control-plane log, Events: Kubernetes control-plane自体やオブジェクトのログ * https://sre.google/sre-book/monitoring-distributed-systems/
105. Observability > エコシステム 105 Disclaimer: 自分が知っているほんの一部を頭の中から書き出しました CNCF Landscape*でも見ておいた方が正確だと思います ▪ Metrics • プロトコル: prometheus, otel, … • ストレージ: prometheus, victoriametrics, thanos, mimir, openobserve, クラウド（Grafana Cloud, Cloud Metrics, …） ▪ Logs • プロトコル: loki, otel, fluentd, … • ストレージ: loki, victorialogs, クラウド（Cloud Logging, DataDog, New Relic, …） ▪ Traces • プロトコル: otel, Jaeger, Zipkin • ストレージ: tempo, uptrace, elasticsearch, sentry, クラウド（Cloud Trace, New Relic, …） * https://landscape.cncf.io/
106. Observability > エコシステムの有名なプレイヤー 106 Disclaimer: 自分が知っているほんの一部を頭の中から書き出しました CNCF Landscape*でも見ておいた方が正確だと思います ▪ Grafana Labs • LGTM (Loki, Grafana, Tempo, Mimir) Stack • Grafana Alloy (promtail / grafana agentはdeprecated) ▪ OpenTelemetry: CNCF Incubating Project • Logs / Metrics / Traces 送信プロトコルの標準化 • opentelemetry-collector(-contrib): Logs, Metrics, Tracesを受け取る・加工・送信までやる ▪ Elastic N.V. • ELK (Elasticsearch, Logstash, Kibana) Stack * https://landscape.cncf.io/
107. Observability 107 ▪ ここでGrafanaダッシュボードの一部を紹介したい • ダッシュボード、ログ、トレース • アラート、SLO
108. あじぇんだ 1. Kubernetesとは 2. ワークロード + 実習 3. スケジューリング 4. セキュリティ 5. モニタリング 6. その他 108
109. 管理パターン 109 ▪ CI/CD → デプロイ ▪ GitOps • ArgoCD, FluxCD ▪ Helm Chart ▪ Canary deployment / BlueGreen / Rolling Update • Argo Rollouts
110. カスタマイズ性 110 ▪ 自作コントローラー • Kubernetesの仕組み（controller-manager, reconciliation）を考えると拡張が自明 & シンプル ▪ Custom Resource Definition (CRD) • オブジェクトの種類を自分で定義 可能 = api-serverをカスタマイズできる • これと自作コントローラーを組み合わせると、楽しいことができる • cf. Argo Projects, Crossplane, … ▪ Schedulerも実はカスタマイズ可能 ▪ その他* * https://kubernetes.io/docs/concepts/extend-kubernetes/#extensions
111. クラスター管理 111 ▪ セットアップ • 生で: kubeadm • Distribution: k3s, k0s, RKE, EKS, GKE, AKS, OKE, … • マルチクラスター管理: Rancher, …
112. And Keep Learning…? 112 ▪ Kubernetes • Kubernetes blog: https://kubernetes.io/blog/ ▪ DevOps / SRE • とりあえず https://sre.google/ の本を読みましょう • DevOps vs SRE?: “class SRE implements DevOps” ▪ Backend • https://roadmap.sh/backend