CA 1Day Youth Boot Camp コンテナ技術入門編 / CA 1Day Youth Boot Camp - Introduction to Container technology

こちらのイベント冒頭のコンテナ技術に関する資料です。

1. コンテナ技術入門
 Urushida Mizuki
 CA 1Day Youth Boot Camp
 Nov 24, 2021 CyberAgent, Inc. CIU 

2. 2 コンテナ技術入門 (2~30min)
 Docker 入門
 Kubernetes 入門

3. 3 コンテナ技術入門 (2~30min)
 Docker 入門
 Kubernetes 入門

4. CA 1Day Youth Boot Camp - Introduction of Container 4 漆田 瑞樹 (Urushida Mizuki)
 • CyberAgent, Inc.
 ◦ 2018 年度 新卒入社
 • インフラ & ソフトウェアエンジニア
 ◦ 機械学習・推論基盤の開発
 ◦ Kubernetes 基盤の開発 (AKE)
 • 趣味
 ◦ タイピング
 ◦ 筋トレ (と書きたい)

5. CA 1Day Youth Boot Camp - Introduction of Container 5 「コンテナ」という一般的概念について
 説明していきます

6. What is a “Container”? 6 • ソフトウェア（≒アプリケーション）の標準単位
 ◦ コードとその依存関係が 1 つにまとまっている（移行しやすい）
 ◦ これらを組み合わせて大きなサービスを構築する
 • 様々なところで使われている
 ◦ サービスの各コンポーネント
 ◦ CI/CDにおける各ジョブ
 ◦ 個人の PC 上での開発・テスト環境
 A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.
 https://www.docker.com/resources/what-container 

7. Why use a Container? 7 • 仮想マシン (VM) 時代 (~2012-14くらい)
 ◦ 環境の分離
 ◦ マシンの集約率の向上（リソースの効率利用）
 ▪ 1 台の物理マシン上に複数のマシンを集約
 ◦ Portability の向上
 ▪ 構成ファイル + ディスク、マイグレーション
 • ただ...
 ◦ リソースコストが高い
 ◦ 起動が遅いことが多い
 ◦ ハイパーバイザーが異なると Portability はそこまで高くない
 ▪ 例えば AWS から GCP に移したい時に VM だと移行が大変
 Hardware
 Host OS
 Process
 Process
 HW Virtualization 
 Guest OS
 Guest OS
 HW Virtualization 

8. Container is here 8 • HW ではなく OS を仮想的に見せることで改善
 ◦ Guest OS を動かさなくて済む 
 ▪ Bootstrap 処理の省略やリソース節約のメリット
 ◦ OS or コンテナ管理ソフトウェアに依存することで移行しやすくなる
 • 著名なコンテナの仕組みは 2007 年に大体揃う
 ◦ cgroups (2007), namespace (2002)
 ◦ 分離に関しては UnixV7 の chroot から (1979)
 ◦ コンテナらしいものは FreeBSD Jail から (2000)
 • VM を使ったコンテナ表現もあるので
 OS Virtualization = コンテナではない
 Hardware
 Host OS
 Process
 Process
 OS Virtualization 
 Process

9. Container cons 9 • 良いことばかりではない
 ◦ ホスト OS を共有するので制約などがある
 • Cons
 ◦ VM と比べて分離が弱い
 ▪ 層が薄いので各箇所の脆弱性によるリスクが高い
 ◦ デバッグが大変になる
 ▪ ネットワークが複雑なことが多い
 ▪ イメージが軽量すぎるとツールがない
 ◦ ABI がホストOSと揃っていないといけない
 ▪ Linux 上で Windows コンテナは動かない
 ◦ この界隈の技術は進化が早いので人材の確保が大変

10. What is Application Binary Interface (ABI)? 10 • バイナリの構成に対する制約
 ◦ ③システムコール呼び出し
 ◦ ⑦ユーザー命令
 • 逆に ABI が同じなら動く
 ◦ RHEL, Ubuntu など Linux 系は
 ABI が統一されている
 • VM だと ISA レベルの制約
 ◦ Emulator (QEMU など) が
 挟まるとその限りではない
 (Appendix) Virtual Machines: Versatile Platforms for Systems and Processes 

11. VM defeated? 11 • VM とコンテナは共存している
 ◦ コンテナが流行っているからといって VM を使わないわけではない
 • VM の強み
 ◦ 隔離性に優れている
 ◦ ライブマイグレーション技術が枯れている
 ▪ コンテナにも Checkpoint/Restore
 技術 (CRIU) はあるがそれを運用
 しているところは少ない
 ▪ 多くのコンテナ管理ミドルウェアでは
 ステートレスが良しとされているので
 そこまで使われない (メリットが薄い)
 Host OS
 HW Virtualization 
 HW Virtualization 
 Hardware
 Guest OS
 OS Virt.
 Guest OS
 OS Virt.
 Process
 Process
 Process

12. Overhead of virtual machine 12 • オーバーヘッドは結構小さい
 ◦ そもそもユーザーランドで実行できる命令はそのまま実行される
 • 完全仮想化 (Full Virtualization)
 ◦ Binary Translation
 ▪ センシティブ命令の動的変換より低パフォーマンスだった
 ◦ ハードウェアサポート (Intel VT/AMD-V)
 ▪ x86 のセンシティブ命令をトラップできるような
 VMX Mode の追加 + Mode 切り替え処理の最適化により高速化
 • 準仮想化 (Para Virtualization)
 ◦ センシティブ命令 (Ring-0 で実行されるべき) を VMM 用に置き換え
 ◦ ハードウェアサポートが出てきてからあまり使われなくなった
 (Appendix)
13. How are containers implemented? 13 • Linux におけるコンテナでは主に次の機能が使われている
 ◦ cgroups
 ▪ リソース制限
 ◦ namespaces
 ▪ リソース分離
 ◦ capabilities
 ▪ 権限制約
 ◦ Linux の機能として提供されているものをうまく組み合わせて
 「コンテナ」というものを実現している
 • Docker, Podman, LXC などではこれらを使用している
 ◦ ユーザーが Linux の機能を直接操作するのは苦ですよね

14. Cgroups 14 • 各プロセスへの制限は木構造で表現される
 ◦ 親の制限は子へ引き継がれる
 • 制限可能なリソース (一部)
 ◦ Unified (v2) だと単一ツリーで
 すべてのリソースを管理する
 cpu
 CPU 時間
 cpuset
 実行 CPU 番号
 memory
 メモリ使用量
 blkio
 ブロックデバイス IO 
 pids
 プロセス数

15. Cgroups operation 15 • sysfs でインターフェースが提供されている
 ◦ カーネル内情報を操作するためのファイルベースのインターフェース
 ▪ cgroup-tools という CLI 用パッケージもある
 ◦ 各ファイルが Read/Write のハンドラを持っており、
 echo や cat などで読み書きが発生すると対応した処理が行われる
 $ ls -la /sys/fs/cgroup dr-xr-xr-x 3 root root 0 Jul 12 2020 blkio/ dr-xr-xr-x 2 root root 0 Jul 12 2020 cpu,cpuacct/ dr-xr-xr-x 3 root root 0 Jul 12 2020 cpuset/ dr-xr-xr-x 5 root root 0 Jul 12 2020 devices/ dr-xr-xr-x 3 root root 0 Jul 12 2020 freezer/ dr-xr-xr-x 3 root root 0 Jul 12 2020 hugetlb/ dr-xr-xr-x 5 root root 0 Jul 12 2020 memory/ dr-xr-xr-x 3 root root 0 Jul 12 2020 net_cls,net_prio/ dr-xr-xr-x 3 root root 0 Jul 12 2020 perf_event/ dr-xr-xr-x 5 root root 0 Jul 12 2020 pids/ dr-xr-xr-x 5 root root 0 Jul 12 2020 systemd/ dr-xr-xr-x 5 root root 0 Jul 12 2020 unified/ $ ls -la /sys/fs/cgroup/cpu,cpuacct -rw-r--r-- 1 root root 0 May 9 15:22 cgroup.clone_children -rw-r--r-- 1 root root 0 Nov 11 15:25 cgroup.procs -r--r--r-- 1 root root 0 May 9 15:22 cgroup.sane_behavior -rw-r--r-- 1 root root 0 May 9 15:22 cpu.cfs_period_us -rw-r--r-- 1 root root 0 May 9 15:22 cpu.cfs_quota_us -rw-r--r-- 1 root root 0 May 9 15:22 cpu.shares -r--r--r-- 1 root root 0 May 9 15:22 cpu.stat -rw-r--r-- 1 root root 0 May 9 15:22 notify_on_release -rw-r--r-- 1 root root 0 May 9 15:22 release_agent -rw-r--r-- 1 root root 0 May 9 15:22 tasks
16. Namespaces 16 • グローバルなリソースに対して名前空間を提供する
 ◦ 例えば PID Namespace ならその名前空間内の PID と
 グローバル名前空間内の PID のマッピングが行われる
 
 • システムコールと CLI が提供されている
 ◦ setns, unshare
 • 分離可能なリソース (一部)
 Network ネットワークデバイスなど 
 Mount マウントポイント
 PID プロセス ID
 User UserID, GroupID
 $ cat /proc/2958976/status | grep pid NSpid: 2958976 1 #Outer NS #Inner NS
17. Namespaces as security 17 • 内から外を認知できなくすることによりセキュリティが向上
 • 例: Docker での User Namespace 対応
 ◦ デフォルトではホスト上・コンテナ上 UID が同じ
 ▪ 他リソースの Namespacing により隔離されているが、
 コンテナランタイムの脆弱性によっては問題になることがある
 ◦ --userns-remap により UID/GID を別の空間へマッピング
 ▪ root で動いているようでもホストから見れば一般ユーザー
 • 余談: これとは別に Rootless という仕組みもある
 ◦ コンテナのデーモンとコンテナ自体を root 以外で実行する

18. Capabilities 18 • 特権プロセスの持つ一部権限を非特権プロセスに与える仕組み
 ◦ 特権プロセス = 実効ユーザーが root (UID 0) のプロセス
 • Linux の Capability 一覧
 • 強い権限はできるかぎり避けましょう
 ◦ --cap-add=SYS_ADMIN や
 --privileged は過剰であることが多い
 ▪ 例えばブロックデバイスの操作権限
 やマウント権限など
 ◦ Container Escape とか Breakout など
 調べると色々ヒットします
 $ docker run --rm -d nginx $ getpcaps $(pgrep nginx) Capabilities for `2958976': = cap_chown,cap_dac_override,cap_fowner,cap_ fsetid,cap_kill,cap_setgid,cap_setuid,cap_ setpcap,cap_net_bind_service,cap_net_raw,c ap_sys_chroot,cap_mknod,cap_audit_write,ca p_setfcap+eip $ cat /proc/2958976/status | grep Cap CapInh: 00000000a80425fb CapPrm: 00000000a80425fb CapEff: 00000000a80425fb CapBnd: 00000000a80425fb CapAmb: 0000000000000000
19. CA 1Day Youth Boot Camp - Introduction of Container 19 最後にコンテナに関係する
 ミドルウェアやサービスを軽く紹介

20. Software to support container management 20 • Docker
 ◦ コンテナの作成・管理、ネットワークへの接続、
 コンテナイメージの定義・管理を行う
 ◦ オーケストレーションの仕組みとして Docker Swarm がある
 • Kubernetes
 ◦ コンテナの分散オーケストレーションツール
 ▪ クラスタ上でのコンテナ管理
 ▪ ネットワークの管理
 ▪ コンテナで使われるデータ表現の管理
 ◦ Docker は Kubernetes のコンテナランタイムとして
 使われることがある (1.20 から deprecated にはなった)

21. Container services of AWS 21 • AWS Elastic Container Service (ECS)
 ◦ コンテナ管理を行うサービス (コントロールプレーン)
 ◦ AWS 製のオーケストレーションサービスという感じ
 • AWS Elastic Kubernetes Service (EKS)
 ◦ Kubernetes クラスタ管理を行うサービス (コントロールプレーン)
 • AWS Fargate
 ◦ ECS や EKS のバックエンド (データプレーン) として
 選択できるサーバーレスコンピュートエンジン
 ◦ EC2 とは違ってノードを意識しなくて良い
 ECS EC2 Fargate EKS Control Data
22. Container services of GCP 22 • Google Kubernetes Engine (GKE)
 ◦ Kubernetes クラスタ管理を行うサービス
 • GKE Autopilot
 ◦ 最適な k8s ノードを自動プロビジョンする機能（Pod 課金になる）
 ◦ Fargate と同様にノードを意識せずに使用することができる
 • Google Cloud Run
 ◦ サーバーレスでコンテナをデプロイできるサービス
 ◦ k8s 上でサーバーレスを実現する Knative が使われている
 ▪ ECS + Fargate に少し似ている
 ▪ 自身の GKE クラスタをバックエンドとして使うこともできる

23. CA 1Day Youth Boot Camp - Introduction of Container 23 Thank you for listening! Any questions?