Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Cc51eff3fb508929891d79dc8a382d80?s=128

Mizuki Urushida

November 26, 2021
Tweet

More Decks by Mizuki Urushida

Other Decks in Technology

Transcript

  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?