某Docker CTOの記事を見てから、ちゃんと見とかないとねという気持ちになり、まずはざっくり読んだ。
なにせ不勉強は承知、メモ程度ということで間違い等のご指摘をお待ちしています。
ソースは2016/08/02 14:30 時点のHEAD(95a6ecffd04732bdf7db0518fdfd59bcabdad442
) です。
Introduction
Code of Conduct はまあ省略で。
Container Principles
- Standard operations
- ツールにより create, start, stop ができる
- filesystemについて copy, snapshotができる
- ネットワークツールで upload, downloadができる
- Content-agnostic
- PostgreSQL DB, PHP, Java, その他コンテナの中身に関係なく同じ操作ができる
- Infrastructure-agnostic
- OCI supported infrastructure ならどこでも動く
- Virginiaのfiber hotel(っち何?)で作ったコンテナがプラクラで試されてパブクラで動く的な
- Designed for automation
- スタンダードがないと人力筋力コンテナ作成になってしまう的な
- Industrial-grade delivery
- エンプラから小規模なシステムまで、等しくINDUSTRIAL-GRADEなデリバリをする
Style and Conventions
- これは本当にコーディング規約というか、
"classID": 1048577 instead of "classID": "0x100001"
とか、redundant prefixesをキープしてね(KILLじゃなくてCAP_KILLなど)という話が書かれていて、読むだけ - Goのコーディング規約っぽい内容も入ってるけどなんだろ
Roadmap
- 1.0 でここまでやるぞーの話
Implementations
- 関連プロジェクト、というか実装例のご紹介
- Hypervisor-based runtime もあるそうな https://github.com/hyperhq/runv
Project
- プロジェクトの進め方?
Filesystem Bundle
a set of files organized in a certain way, and containing all the necessary data and metadata
- OS X application bundles 的なファイルツリーの規約
config.json
を含むこと。see below (Container Configuration file)A directory representing the root filesystem of the container
。rootfs/
みたいな規約があるといい。config.json
で参照されていてほしい
- これらのartifactsをtar archiveで固める
Runtime and Lifecycle
General Runtime and Lifecycle
- こういうオペレーションができないといけないリスト。プラットフォームに関係ないもの
- State
- ociVersion, id, status(created/running/stopped), pid(as seen by the host), bundlePath, annotations(タグ)
- Lifecycle
- createがinvokeされる
- config.json に従ってコンテナが作られる
- additional actionsがあってもいい
- startされたらuser-specified codeが走る
- erroring out, exiting, crashing or the runtime's kill operationで止まる
- delete でcreate stepで行われたことのundoが行われ、削除される
- Errors
- エラーの表示方針。 “generating an error MUST leave the state of the environment as if the operation were never attempted”
- Operations
- 言ってみればサブコマンド。こういうのにしてね、というのが書かれる。エラーの条件なども。
- state, create, start, kill, delete
- ん〜書いてある通りだな
- Hooks
- 設定見てねとのこと
Linux-specific Runtime and Lifecycle
- File descriptors
- “only the stdin, stdout and stderr file descriptors are kept open”
- “additional file descriptors to the application to support features such as socket activation”だそうです。Socket Activationはsystemdのやつなど
- これらfdは /dev/null にリダイレクトされててもいい
- Dev symbolic links
/proc
をマウントしたら、例えば/proc/self/fd -> /dev/fd
のようなsymbolic linkを貼ってほしいとのこと
Configuration
General Configuration
- config.json をバインドしたGoのライブラリやJSON Schemaがすでにあるそう
- Specification version
ociVersion
the version of the OpenContainer specification
- Root Configuration
path(e.g. "rootfs")
,readonly
- Mounts
- マウントポイントたち。
destination,sourse,type,options
- マウントポイントたち。
- Process configuration
- Hostname
- hostnameです
- Platform
- Hooks
- Prestart/Poststart/Poststop が定義できる
- 「Runtime namespace」(コンテナを作った側のプロセスのネームスペース)で、hostのファイルシステムで実行される
- 例を見ると、せやなという感じ
- Annotations
- タグです
- で、全体の例として巨大なJSONが...
Linux-specific Configuration
- この章は面白い
- Default File Systems
/proc, /sys, /dev/pts, /dev/shm
がほしい
- Namespaces
- type(例の
pid, network, mount, ipc, uts, user, cgroup
)と、もしnamespaceファイルを指定したければpath(/proc/1234/ns/pid
だの、あるいは/var/run/netns/netfoo
)を指定できる
- type(例の
- User namespace mappings
- ユーザ名前空間関連の設定。どういうことかは tenforwardさんの記事 などで
- Devices
- Control groups
- そのままcgroup周り。コントローラーごとに記法が違って大変...
- まあここも書いてある通り
- Sysctl
- あのsysctlだけど、“modified at runtime for the container”とのことでコンテナごとに変えられるもんでしたっけ...
- seccomp
- Rootfs Mount Propagation
- こんなのも指定できるのね...
- Shared Subtreeのやつ、
mount --make-private /
とか
- Masked Paths
- コンテナから見えなくするパス。例のやつはマウント名前空間が共有でも
/proc/kcore
は見せない、ということ?
- コンテナから見えなくするパス。例のやつはマウント名前空間が共有でも
- Readonly Paths
- コンテナからリードオンリーにするパス
- Mount Label
- “mountLabel will set the Selinux context for the mounts in the container”
Solaris-specific Configuration
(省略...)
最後に用語集
次は image-spec を読む。