Docker Privileged でできること
訳そう訳そうと思いつつ放置していたのを訳す
- docker 1.9.0 build 76d6bc9
Runtime privilege and Linux capabilities --cap-add: Add Linux capabilities --cap-drop: Drop Linux capabilities --privileged=false: Give extended privileges to this container --device=[]: Allows you to run devices inside the container without the --privileged flag.
Note: Docker 1.10 以上では、
--cap-add
がコンテナに渡されたかどうかにかかわらず、デフォルトの seccopm profile が syscall をブロックします。このような場合は、用意されているデフォルトのものをベースにご自身でカスタムした seccomp profile を作成することをオススメします。そうでなく default で起動したくないのであれば、--security-opt=seccomp=unconfined
を渡して起動してください。
デフォルトでは、 Docker コンテナは "unprivileged" であり、例えば、 Docker コンテナ内で Docker daemon の起動を行うことができません。これは、デフォルトではコンテナがあらゆるデバイスへのアクセスが許されていないためです。しかし、 "privileged" なコンテナはすべてのデバイスへのアクセスが許可されます (see the documentation on cgroups devices)。
docker run --privileged
を実行したすると、 AppArmor や SELinux で設定するのと同じように、コンテナ以外のホスト上のプロセスとほとんど同じレベルでホストへのアクセスを許可するように、そのホストのすべてのデバイスへのアクセスが可能になります。 --privileged
での起動についての付与的な情報は Docker Blog で確認してください。
もし、特定のデバイスへのアクセスを制限したければ、 --device
フラグを利用できます。コンテナ内からアクセス可能な1つ以上のデバイスを指定することができます。
$ docker run --device=/dev/snd:/dev/snd ...
デフォルトで、コンテナはこれらのデバイスに対して read
、write
およびmknod
が可能です。--device
フラグのそれぞれのオプションに対して 3つぐみの :rwm
を用いることで上書きすることができます。
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc Command (m for help): q $ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc You will not be able to write the partition table. Command (m for help): q $ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk /dev/xvdc crash.... $ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc fdisk: unable to open /dev/xvdc: Operation not permitted
--privileged
に追加して、--cap-add
および --cap-drop
を使うことで、capability をより適切な粒度で制御することができます。デフォルトでは、 Docker は 下記の利用可能性を保持しています。下記のテーブルに追加や削除が可能な Linux capability options を記載します。
Capability Key | Capability Description |
---|---|
SETPCAP | process capabilities の変更 |
SYS_MODULE | kernel modules のロードまたはアンロード |
SYS_RAWIO | I/O port の操作(iopl(2) and ioperm(2)). USB message とか |
SYS_PACCT | acct(2) を使って, process accounting on or off のスイッチが可能 |
SYS_ADMIN | System Admin の操作範囲の実行 |
SYS_NICE | プロセス nice 値 (nice(2), setpriority(2)) を上げる、および 任意のプロセスの nice 値の変更 |
SYS_RESOURCE | リソース制限の上書き. |
SYS_TIME | System clock (settimeofday(2), stime(2), adjtimex(2)) の設定; real-time (hardware) clock の設定 |
SYS_TTY_CONFIG | vhangup(2) の実行; employ various privileged ioctl(2) operations on virtual terminals. |
MKNOD | mknod(2) を利用して special files の作成 |
AUDIT_WRITE | kernel auditing log への records の記載 |
AUDIT_CONTROL | kernel auditing の有効化/無効化; auditing filter rules の変更; auditing status と filtering rules の取得 |
MAC_OVERRIDE | MAC configuration の許可または state の変更. Smack LSM で実装されている |
MAC_ADMIN | Mandatory Access Control (MAC) の上書き. Smack Linux Security Module (LSM) で実装されている. |
NET_ADMIN | various network-related operations の実行 |
SYSLOG | privileged syslog(2) operations の実行 |
CHOWN | file UIDs and GIDs (see chown(2)) の任意の変更 |
NET_RAW | RAW と PACKET sockets の利用 |
DAC_OVERRIDE | file read, write, and execute permission check のバイパス. |
FOWNER | Bypass permission checks on operations that normally require the file system UID of the process to match the UID of the file. |
DAC_READ_SEARCH | ファイル読み込みおよび直接読み込みと実行の権限チェックのバイパス |
FSETID | ファイルが修正された時に set-user-ID と set-group-ID の権限ビットをクリアしない |
KILL | シグナル送信の時に権限チェックをバイパスする |
SETGID | プロセス GID および 補助 GID の任意の操作 |
SETUID | プロセス UID の任意の操作 |
LINUX_IMMUTABLE | FS_APPEND_FL and FS_IMMUTABLE_FL i-node flags の付与 |
NET_BIND_SERVICE | 特権ポートでのインターネットへのソケットの利用 |
NET_BROADCAST | broadcast ソケットの作成とマルチキャストへの listen |
IPC_LOCK | Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)). |
IPC_OWNER | operations on System V IPC objects の権限チェックのバイパス |
SYS_CHROOT | chroot(2), change root directory の許可 |
SYS_PTRACE | ptrace(2) を利用した任意のプロセスの trace |
SYS_BOOT | reboot(2) and kexec_load(2) を利用して reboot と新しいカーネルのロード load |
LEASE | 任意のファイルのリース Establish (see fcntl(2)). |
SETFCAP | file capabilities のセット. |
WAKE_ALARM | システム起動に対してトリガーを送る |
BLOCK_SUSPEND | block system をサスペンドさせるような機能を適用する |
より詳細なリファレンスは capabilities(7) - Linux man page で御覧ください。
(--cap-add
/ --cap-drop
)両方のフラグの値として ALL
をサポートしているので、例えば、 MKNOD
以外のすべての権限を付けたい場合は、下記のようにすることが可能です。
$ docker run --cap-add=ALL --cap-drop=MKNOD ...
ネットワークスタックを操作するのであれば、 --privileged
ではなく、 --cap-add=NET_ADMIN
として、ネットワークインターフェイスを変更するべきでしょう。
$ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy RTNETLINK answers: Operation not permitted $ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy To mount a FUSE based filesystem, you need to combine both --cap-add and --device: $ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt fuse: failed to open /dev/fuse: Operation not permitted $ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt fusermount: mount failed: Operation not permitted $ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs # sshfs sven@10.10.10.20:/home/sven /mnt The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established. ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6. Are you sure you want to continue connecting (yes/no)? yes sven@10.10.10.20's password: root@30aa0cfaf1b5:/# ls -la /mnt/src/docker total 1516 drwxrwxr-x 1 1000 1000 4096 Dec 4 06:08 . drwxrwxr-x 1 1000 1000 4096 Dec 4 11:46 .. -rw-rw-r-- 1 1000 1000 16 Oct 8 00:09 .dockerignore -rwxrwxr-x 1 1000 1000 464 Oct 8 00:09 .drone.yml drwxrwxr-x 1 1000 1000 4096 Dec 4 06:11 .git -rw-rw-r-- 1 1000 1000 461 Dec 4 06:08 .gitignore ....
Ansibrest というツールを作りました
ものすごい久しぶりに記事を書く。理由は気がつかないままに bang されてたから (stanaka さん, daiksy さん, songmu さんありがとうございます)
掲題の通り Ansibrest というツールを作った
- github
- 最近のプロダクトでは ansible をほぼ全面的に使ってる
- チーム的にもうちのチームはほとんどが ansible に移行した(利用し始めた)
- 遅まきながらようやく chatops 環境が整いつつある(この辺りは情報解禁されたらどこかで書きたい)
Ansible はとてもよいツールなので積極的に使っていきたいけど、結局どこかの端末にログインしてコマンドを実行するか、 Jenkins おじさんの手をわずらわせるかしないといけない。 slack とかで利用するときも直接叩くなんてことはなく実際には jenkins おじさんに頼んで ansible を実行してもらう。
かといって jenkins おじさんを定常的に育てるのは手間でもっとカジュアルに ansible を叩きたいと思ったので ansibrest 作った。 やれることは単純でプロダクトのリポジトリ内に次みたいな構成で ansible playbook があるとする
% tree -L 2 ansible ansible ├── group_vars │ └── development.yml ├── inventories │ └── development ├── roles │ └── sample2 ├── sample1.yml └── sample2.yml
この状態で
% npm install ansibrest -g
としたのち
% ansibrest
とするとデフォルトでは2400番でWebサーバが立ち上がる。
キャプチャを見ればわかると思うけど、 playbook の一覧、それぞれの playbook のタスク一覧と inventories の設定を閲覧できて、その場で実行ができる。
トップ
実行
playbook タスクリスト
あと、当然これは API を持っている。
% curl -X POST "http://localhost:2401/api/playbook/sample2.yml"
こんな感じで叩くことができる。
としておけば op サーバあたりで git clone して、 ansibrest を上げておけば、 hubot から簡単に実行できる。
カジュアルにチーム皆の(slackの)前で
@repo_hubot play sample2.yml development
とか実行することができる(はず
残項目
エンジニアのためのデータ可視化実践入門 の訂正
今年のはじめに「エンジニアのためのデータ可視化実践入門」を出版しました。 私の不手際で多くの方にご迷惑をお掛けしました。
遅くなってしまいましたが、その中でもソースコードを確認する時間を十分に確保できなかったために 多くの間違いがございました。
共著者のあんちべ様はじめ、レビューしてくださった皆様とは無関係の私の責任です。 購入してくださった皆様、申し訳ありません。
下記サポートページで訂正しております。 サポートページ:エンジニアのための データ可視化[実践]入門 ―D3.jsによるWebの可視化:|技術評論社
下記のリポジトリに実際に動作するコードをすべて置きました。
muddydixon/WebVisualizationSample · GitHub
お世辞にも素晴らしいコードではありませんが、よろしければご参考ください。
また、CoffeeScriptで書かれていることにも言及されておられる方がおりましたが、 この目的は、共著者の方と相談し、なるべく安価な値段設定にできるようにとも 考え、どうしても増えると考えられたソースコードの記述量を減らすために用いたものです。
今後、このような機会をいただけた際には、自分自身で行うだけではなく、 お願いする方にはお手数おかけするかもしれませんが、コード自体のより十分な レビューをお願いし、対応したいと思います。
家庭を支える技術アドベントカレンダー 14日目(ごめんなさい
家庭を支える技術 Advent Calendar 2014 - Adventar
数日、夫婦の家庭が続いたので、子どもがいる家庭について多めに書いてみます。
スペック * 妻 * 子(年長) * 子(年少)
夫婦間のコミュニケーションツール
- Google Calendar
- 幼稚園の行事の共有は大事
- 習い事の予定の共有は大事
- Google Spread Sheet
- Line
- 帰るコールなどはこちらで
子どものデータ
- 外付けHDD/メモリースティック: データぶっ飛び2回
- 1回目8GBで10万近い金額
- 2回目250GBで見積もり怖くて出してない) 1人目の出産時動画・・・どうしよう
- flickrのプロ契約で対応(解像度下がっても見られないよりまし
- 依存度が高すぎて困る
- アップロード時間かかりすぎ
- 選択ダウンロードのUIへぼすぎ
子どもへのデータ
- ChromeCast
- 映画とかビデオを見せるのにとても良い
- motownのplaylistとか流しっぱなしでレゴやったりもしてます
- Kano
その他、非IT技術
うちがいっている幼稚園は、小規模幼稚園なので保護者の協力が不可欠で、大変ですが楽しいです。 また、マンションもマンモスマンションなので同年代がだいたい30人近くいるのでそこのコミュニケーションも多く、こちらもなかなか円満な関係を築いていて楽しいです。
餅つき
30臼とかを15人位のお父さんたちでつききるので体力まじ大事。あと、手返しができる(うまい)ヒトも希少価値があります。
行事もの
行事ごとに「あれ作れ」「これ作れ」と言われるのですが、子どもたちが喜ぶのであればと思ってシコシコ作っています
家事
- 料理: なんだかんだで平日一日中子どもたちの相手をしている妻に代わって、土日料理を作ったりすることが多いので、料理スキルは大事です。
- 小松菜をどう食べさせるか→ミキサーに掛けてパスタのソースに
- ほうれん草をどう食べさせるか→餃子の皮にねりこむ
- ごぼうをどう食べさせるか→ボロネーゼにしてパスタのソースに
- 魚をどう食べさせるか→子どもたちにはあえて与えず、僕が美味しそうに食べ始めてから味見させ、一人前食べさせる
- あいつら、ちゃんと出すと食べないくせに、ヒトが食べだすと取りに来る
レゴ
レゴを始めると子どもたちは1〜2時間遊んでくれるので、こちらも作りがいがあります。
地域とのコミュニケーション
- 幼稚園の連絡手段がメーリングリスト(広告入り)なので、なんとかしたい
- 地域の人とは、FBグループ/LINE/メールなのでなんとかしたい
- 幼稚園お父さんたちとも仲がいいととても楽
- 仕事関係ない友だちができて楽しい
- マンションのお父さんたちとも仲がいいとても楽
- 仕事関係ない友だちができて楽しい
欲しいガジェット
やってみたい
これが次世代の砂遊びか……! 本物の砂を使うセガのアーケードゲーム「え〜でる すなば」が面白そう - ねとらぼ
まだ早いですが子どもの小遣いはこうやりたい
mackerel meetup #2 に参加しました
mackerel meetup #2に参加しています
Mackerel Current Status @stanaka
- Overview & Update
- 正式化と今後の予定
Overview & Update
監視
- ホスト/ロール単位:来月そうそう
- サービスメトリクス:来月早々
アラート通知(チャンネル)
- メール
- Webhook
- sladk 来週くらい
正式化と今後の予定
- ベータリリース(5/8)
正式リリース(9/19)
2000円/ホスト/月(台数20+でディスカウントあり)
無料トライアルあり
- 5台, ログ24h, サービスメトリクス・監視数に制限
個人・小規模ユーザ向けプラン
- GitHubログイン
- Monitor対象の詳細化(ロール単位)
- サービスメトリクス監視
- カスタムメトリックプラグイン拡充
- Slack連携など通知先拡充
イベント機能
- アラート・デプロイなど
- グラフ改善
- アラート改善
- ダッシュボードカスタマイズ
ヌーラボがMackerelに移行した3つの理由 @tksmd
まとめ
id:stanaka さん, id:songmu さん、はじめhatenaの皆様、会場のフリークアウトの皆様ありがとうございました!
Travis CI Meetup Tokyoに参加しました
Hiro Asari さんの Travis CI の demo
Travis-CI のライフサイクル
Setup -> Services | v before_install | v install | v before_script | v script | v after_success after_failure | | v | before_deploy | | | v | after_deploy | | | v v after_script
.travis.yml
# build地にsudoを利用しない設定 sudo: false # アカウントに依存して、通常は動かない設定 language: ruby
bash の wait というオプションで標準出力がない場合に殺されないで済む
110+ vms 68+ servers heroku
openvz and docker
82000 jobs 125,435 jobs per day 7,000 repositories
|node.js | 2800| | python |1900| | ruby |1600| |php| 1500| |default (=ruby)|1000| ...
in COM, ruby is top usage.
team
- team teal: ui ux
- team blue: infrastructure
- BIWOMM but it works on my machine
points
- Case sensitive
- inode deference
- Package difference dev and travis CI
- Services which are slow to start or configured differently
- 'apt get update' system packages change and are removed overtime
- test ordering and isolation
- time zone dependent test and timing differences
- capabilities turned off in container based virtualization systems
tachikoma.io
- 依存関係とかのチェックを実現する
travis の selenium
YAPC::ASIA 2014に参加しました
YAPC::ASIA 2014に参加しました。
当然個人スポンサーチケットです! パーカーが欲しかったので。。。
また、29日のみでしたが、昨年に引き続き「YAPC::Asia 2014 スペシャルレポート」のレポーターとしても参加しました。
ですので内容のレポートは上記を見ていただければ。。。 個人的には
@toritori0318 さんのTV連携の運用改善の話と、 @deeeet さんのツールを作る話、 @aoneko さんの自動デプロイが本質的なところで面白かったです。 両者ともに共通していたのが、「いま現状の課題に全力で取り組む一方、(自分の身を守るという意味での)エゴからくる利他精神」だと思いました。 共通化する、ドキュメント化する、自動化する、頻繁に利用するものだからこそ準備をする(プロセスにする、README/USAGE/MANPAGEを書く)、これはまさに「楽をするために苦労を厭わない」というエンジニアスピリッツにあふれたものだなぁと思いました。
あ、あと、レポーターはどんなに混んでいても一番いい席に座れるので皆様本当にお勧めです。 また、毎年参加の id:hiratara さんやその他素晴らしい人と事前にお会いしてYAPCのワクワク感を高められることも嬉しい事です。 ぜひ、来年のYAPCやその他のイベントでもレポーター枠があれば参加することをおすすめします
切り戻しの話
懇親会で @koemu さんと @risou さん、あと id:papix さんと話していたのですが、アプリケーションレイヤのデプロイ/切り戻しは楽になっている(自動化やスクリプト化で)とは思うのですが、DBの切り戻しがどうにも楽になっていない気がします。
どうしてもここだけはデプロイプロセスに人手を介入させ、ターミナルのフォントサイズを上げ、「いいですか?」「ダイジョブです」みたいなやりとりを経て実施しているので、とても辛いです。
例えば、onreadyみたいなコマンドで、新しいDBホストが立ち上がってマスターへの書き込み時にクエリを新しいアプリ向けに書き換えて流し込んでいき、launchで旧DBから新DBへの切り替えがされ、そのタイミングで今度は新DBへの書き込みのクエリを旧DBのクエリに書き換えて流しこみを続けてくれて、いつでも切り戻しができるようになってて、ここぞというタイミングで切り離す、などができる様になってくれると嬉しいなと思っています。
YAPCの優しさ
某社CTOの惨状です #yapcasia pic.twitter.com/czfvvS76mh
— Muddy Dixon (@muddydixon) 2014, 8月 29
こうなって
今日のhokacchaハイライト
1. 懇親会では元気
2. Hubではもう会ったら焦点定まってなかった
3. イミュータブルの話の時点で寝る
4. 駅でmuddydixonに担がれる
5. 南北線に乗ってるけど帰れる?って聞いたら南北線はダメだよーしか言わなくなる
— Yosuke FURUKAWA (@yosuke_furukawa) 2014, 8月 29
6. 電車で寝そうなので近くにいるYAPC参加者に声をかけて目黒になったら起こしてあげてくれと頼む
7. YAPC参加者の心意気で目黒まで送ってもらう
8. 嫁にPromiseの話する
帰宅してて良かった。
— Yosuke FURUKAWA (@yosuke_furukawa) 2014, 8月 29
YAPC最高や!