ローファイ日記

出てくるコード片、ぼくが書いたものは断りがない場合 MIT License としています http://udzura.mit-license.org/

OCI Runtime Specification を読む

某Docker CTOの記事を見てから、ちゃんと見とかないとねという気持ちになり、まずはざっくり読んだ。

なにせ不勉強は承知、メモ程度ということで間違い等のご指摘をお待ちしています。

github.com

ソースは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

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
    • terminal(whether you want a terminal attached to that process) cwd env args(executable to launch and any flags as an array)
    • capabilities, rlimits, apparmorやselinuxの設定、noNewPrivileges
    • User - uid, gid, additionalGids(groups)
  • Hostname
    • hostnameです
  • Platform
    • イメージがターゲットとするプラットフォーム。linuxのamd64です、など
  • 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)を指定できる
  • User namespace mappings
  • Devices
    • コンテナで利用できるデバイスファイルたち
    • mknod的な表現でのtype(cとか), path, メジャーマイナー番号, fielMode, オウナーのuid/gid
    • /dev/null, /dev/zero, /dev/random など幾つかのデバイスファイルについては必ずランタイムが提供しないといけない
  • 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 を読む。

Haconiwa のrpm/debパッケージを配布開始しました

packagecloud を使っております。

便利です。一応 CentOS >= 7 / Ubuntu Trusty / Ubuntu Xenial / Debian jessie で利用できると思います。

パッケージをインストールすると3つのバイナリが入ってきます。

haconiwa

haconiwa コマンド本体です。READMEにあるようなhacoファイルを解釈してコンテナを立ち上げたりできます。まあ 例 の通りです。debootstrapなどでルートファイルシステムを作っておためしください。

hacorb

haconiwa コマンドと大体同じmgemが入った、mrubyのバイナリそのものです。個々のmgemの機能を直接組み合わせて、Rubyでプログラムを書いたりできます。

$ hacorb -e 'p Process::Sys.getuid'
1000

これはこれで少し面白いと思うので、興味があって何かしたい場合は、個別のmgemのREADMEをご参照ください。ちなみに haconiwa revisions でコア以外の依存mgem(ついでに組み込まれたmrubyのリビジョンも)がわかったりします。

$ haconiwa revisions
mgem and mruby revisions:
--------
MRUBY_CORE_REVISION     97283faa16d2e69a27de891e5a6695bf370cb4c3
mruby-argtable          6c281979b82941a17936347abcbb5c76d368257f
mruby-capability        fa1e553258362547a6393830ae55d2310700a6f3
mruby-cgroup            5d5573bae88f8f742b90f9464b7534be55ad8a3e
mruby-dir               0c3c538855dd15208d34fee96b13675e564bb4b6
mruby-exec              16451d728533584b55233f4ef3fab0da892e31e2
mruby-io                93d481d4b49829e37b1f501c7307663c6327dfab
mruby-mount             dabaa7c487e09a878893d06573500e851cb20364
mruby-namespace         f5dbc47b3174a117e26d5ff6e21c1322a650e45f
mruby-process           e532ff8837ebed35bdc03f26aed6a9105bbd7c44
mruby-process-sys       925f227d36edebc5accde2ff9a2497a91cc7d954
mruby-procutil          14b3a7bc66bc290af1f2fec339e73eb5cd5ace0c
mruby-resource          ed74671bd4c653434367ec8fb05e094d2b2cff20
mruby-signal            2aff41b5dffb1ab233141472fa8a0a456b703ef0

hacoirb

上で紹介した hacorb の対話環境です。rubyに対するirbですね。入っているmgemは同じなので、コンテナ要素を気軽に（？）試せるかと。

以下はUTSの隔離のサンプルです。

p = Process.fork { Namespace.unshare(Namespace::CLONE_NEWUTS); Procutil.sethostname 'udzura.example.com'; system 'hostname' }; Process.waitpid p
# udzura.example.com
# => 13903
system 'hostname'
# localhost
# => true

実用というか、勉強に便利かもしれない。

ということで、パッケージになってアンインストールも気軽にできるようになって、haconiwaをより気軽に試せますね！！知人は仕事で使っているベアメタルのDebian(sid)にhaconiwaを早速突っ込んでいました。

何卒ご贔屓ください。

Enjoy jailing~

Emacsでmrubyをそこそこ快適に書く

こんにちは、これはEmacs記事です。みなさんはEmacs記事...ではないですよね...。

Haconiwaのおかげですっかりmruby人間になって久しい id:udzura です。

で、宣伝はこんなくらいにしておきまして、なんとなく流れでセットアップしたEmacsによるmruby環境をこの辺で整理しとこうと思ったので、書きます。というか、ほとんどC言語を書くための環境...。平成が終わるとか終わらないとか言っている2016年にEmacsでC言語を書く環境の記事を書きます。

なお僕は　C言語をまともに書いて2ヶ月ぐらいだったり、あと普通にカーソルキー使う人間だったりするので、その辺りは優しく突っ込んでいただければと...思います...。

何はともあれggtags、その他インストール

続きを読む

HaconiwaでDockerのsshdコンテナを利用してみる

こんにちは。これは技術記事です。みなさんは、技術記事ですか？

まず、 Haconiwa の近況報告なんですが、この度 mruby で書き直し、ひとまず MRI 版と同じ程度の機能までは実装できました。

github.com

これに伴い、Linux用のバイナリを配布する形にインストール方法を変更しました。また、今後MRI版の開発（haconiwa-mri とプロジェクトをリネーム済みです）は積極的には行わない予定です。何か機能追加したい際は mruby 版の方へPRを！

（一応、MRI版のリリース記事は以下です）

udzura.hatenablog.jp

ということで、今日はこのmruby版のHaconiwaを用いて、Dockerのsshdコンテナを再利用してsshdを立ち上げてみる手順を紹介します。

続きを読む