人事 to IT カイギ #01 に参加してきた

参加してきた

jinji-to-it.connpass.com

3行 (僕の中の

めでたい

@meso 出産おめでとう!

登壇者

  • 藤本 真樹 (@masaki_fujimoto) @gree
  • 庄司 嘉織 (@yoshiori) @cookpad
  • 清水 俊博 (@meso) @dwango

ふじもとさん

  • ソフトウェアがからまないことはないよね
  • 38歳 なんで人事か?
  • HR の作業はいろいろあるし、3回おなじことやるんだったらシステム化できる
  • 人事はハードコスト高い

やったこと/めざしていること

  • 人事機能のサービス化
  • まずはデータ集約から
    • 「ある人が、同じチームに何日いるかをすぐ出せるヒト?」 会場シーン
    • ジョブローテを自動化する仕組みとかあるといいよね。
    • 人事が「より人間しかできない仕事ができるようにする」
  • ACL 問題については悩みが尽きない
  • ハードスキル(人事の)も欠かせない
    • 法律も変わるし・・・

おもしろい

  • エンジニアリングの観点で HR はとても楽しい

よしおりさん

  • 最初は断った
  • 当事者になれるチャンスを逃すのはもったいない (任天堂 岩田社長)

http://www.1101.com/president/iwata-index.htmlwww.1101.com

  • 人事の IT 化?
    • そうじゃない
    • IBM Kenexa
      • Watson を使ってる

やったこと

  • 現地にいって海外チームとの連携
  • インドとかでの新卒通年採用
    • カースト制度ができたときに、 IT 系はなかったので、誰でもなれる!インドでのし上がるためには IT 系しかない
  • コアタイム廃止
    • 昔は裁量労働制だった (エンジニア、デザイナ、企画職) けど、バックオフィスはできなかった
    • じゃあ、フルフレックスに全員した
    • エンジニアを神聖化しない
  • エンジニア採用
    • 「手伝って下さい」はあくまで「手伝い」
    • 当事者にならないと、手伝いになっちゃう
    • 2018年度の新卒採用選考エントリ
      • gist で yaml を書いて、それを html にするコードを書いて提出しろ
      • 内容もわかるし、コードもわかる!github のアカウントも収集できる!
  • システム入れ替え (勤怠システム辛み)
    • いろいろ口出せるのはよい

学んだこと

  • ミスは絶対許されない
  • 正常に遂行して当たり前
  • (SREなどの)インフラに近い感覚
  • DevOps や Infrastructure as a Code の思想的に近いかも

meso

  • kwappa さんとよしおりさんが説明している
  • 「@meso はコミュニケーションをしている」

パネルディスカッション

  • 人事マスタの難解さと他システムからの参照回数の多さにより、んごごご
  • HR テック、1) IT 化と 2) ヒトができなかったこと(うまくできてない最適化など)の2つに分けて前者をやるだけでも楽しいよ(少しやったりしているのでよく分かる
  • エンジニアが人事部長になったから非エンジニアが冷遇されると思ってる人たちの中にあるのはいいようのない劣等感なんじゃないかと思ってる(僕は)
    • 紐解くと、「全業種が ICT 化に向かっている中でできないこと」が広がっていることに対する焦りが全職種であるんだろうなと邪推したりしなかったり

  • Dwango や一休は別だと思うけど、 kaizen や GREECookpad はそもそも「エンジニアが強い(営業/企画と少なくとも同等)の企業なのでその中で「エンジニアを厚遇したらハレーション起こるだろ」というのが感想。そもそもそういう意見が出る会社のエンジニアは恵まれてる。
  • Google はいろんな人事制度を変えたりできる背景にあるのは「生産性を可視化」できているから。これは冷静に考えたらすごくすごい

うちは冷遇されてません

  • 冷遇されないようにしている途中です!
  • 厚遇されているわけではないです!
  • エンジニアだけ、とか、企画だけ、とか、営業だけ、とかクッソくだらないセクショナリズム発揮してる暇があったら全社が1つの組織として With Us, You Can すればいいと思ってます

KPT をチェックリストに昇華させると無駄なく知識が蓄積される

KPT やってますか? KPT やっても割りと無駄なこと多いですよね? KPT はチェックリストに昇華させると、捗るぞ!という話です。

KPT ?

KPT については以下の各社の取り組みを見てください

kuranuki.sonicgarden.jp

http://engineer.wantedly.com/2015/04/01/sync-kpt.htmlengineer.wantedly.com

端的にいうと振り返りを行い、取り組みを改善するためのフレームワークです。 下記のように3つの項目を皆で出し合い、

  • KEEP: 取り組みの中で良かったこと
  • PROBLEM: 悪かったこと
  • TRY: 次に活かしたいこと

KJ 法 などによってまとめ、チーム間の意識をあわせつつ、取り組みを継続的に改善していきます。

私のチームやワークグループ、技術戦略委員会でも継続的に実施しています。

KPT あるある (課題)

  • TRY が抽象的
  • TRY の主担当が決まらず、結果、 TRY されない
  • PROBLEM が「まあ、しかたがないよね」と放置される

(本論) KPT をチェックリストに昇華させる

上記のような課題があり、スクラムマスターなどの誰かの属人による「運用でカバー」を避けるために最近は「チェックリストへの昇華」を促進しています。

具体的には、

  1. KPT を実施する
  2. PROBLEM を TRY に昇華させる
  3. KEEP / TRY をチェックリストにする

とし、ドキュメントとして管理する。

こうしておくことでなにか必要になったときにチェックリストとして残っているのでそれにチェックを付けながら実施することで、漏れや懸念点を意識しながら進めることができます。

効用

  • チェックリストにしようとすると、どうしても「実現できること」に落とし込まなければならないため、抽象的な TRY を作りづらく成ります
  • 担当はそれのチェックリストの利用者なのでそもそも考えなくてよくなります
  • PROBLEM をチェックリストの項目にするので、「まあ、しかたがないようね」がなくなります

余談

弊社では #nobolycloud のおまけパートでも話しましたが、gitlab を利用し、かつ、私のチームは「ラベル」を重視し、wiki や git 管理の対象のファイルではなく、 issue でいろいろなドキュメントを管理しています(これが正解とはいっていない)

f:id:muddydixon:20170113085022p:plain

issue board でみるとこんな感じで「チェックリスト」を一覧で見ることができるので、なにか必要になったときにはこれを利用する事ができます。

また、うちのチームは自作の gitlab issue を使った KPT ツールがあるので、

  1. KPT issue を立てる
  2. コメント欄に各自が KPT を書く
  3. ツールを使って issue の本文にアグリゲート
  4. 読み上げ/説明しつつ、 issue の本文に KJ 法などでグルーピングしつつ、 PROBLEM を TRY に昇華

が気楽にできるようになっています。

後は公平にジャンケンや練習を兼ねて若手にチェックリスト化してもらえばナレッジを再利用可能な形で蓄積することができます! yummy!

With Us, You Can というコーポレート・メッセージについて思うこと

弊社はコーポレート・メッセージとして「With Us, You Can」を掲げています。

www.nifty.co.jp

結論は「僕はこのコーポレート・メッセージが大好き」だ。です。

ニフティグループは、お客様、株主、社員、パートナー企業、地域社会等の夢をかなえるため、常にお客様起点で行動し、チャレンジャーとしてサービスを開拓し、社会に役立つ企業として、新しい価値の創造に取り組み続けます。」と堅苦しく書かれていますが、つまるところ

  • 自社単独でやるよりも、多くのステークホルダーと一緒に仕事をする方が大きなことができるし、その結果としてより広い社会的な貢献ができるから
  • ぶっちゃけリスク減るし、メリットあるし ( muddydixon 解釈

プラスアルファとして後付で「パソ通時代はパソ通の個人・法人ユーザの足回りとして」「ISPでは個人・法人の足回りとして」「クラウドではICTビジネスを立ち上げたい/成長させたいお客様の足回りとして」の役割を担ってきたからより強いメッセージになった、というのがあるかと思っています。

コーポレート・メッセージとは

コーポレートアイデンティティ - Wikipedia

Wikipedia を確認すると、

コーポレート・アイデンティティ (以下 CI ) は、企業が掲げてきた理念や事業内容、また企業の社会的責任 (CSR) 等に基づいて自らの存在価値を体系的に整理し、改めて定めた理念やそれに基づく行動指針を企業内外で共有することでより良い企業活動を行っていこうとするもの。またそれを実施するための計画である。 主に社会における企業イメージの構築を行うために計画・実行されるが、企業内部においても価値の共有による意識の向上、また品質や生産性、就職希望者の増加などの効果が期待できる。

役割はいくつかあるとは思いますが、大別すると

  1. 企業理念/存在価値の体系的な整理
  2. 上記や上記に基づく行動指針の内外への共有
  3. 企業イメージの構築(ブランディング)
  4. 企業内部への価値の共有による意識の向上、品質や生産性向上の効果を期待する

Wikipedia ではこれらをまとめてCIの3つの構成要素としてまとめてあります。

理念、それに基づいた企業活動という行動、(情報の伝達経路で大きな割合を占める視覚的な)イメージ・デザインを統一する事が大事だとあります

内部ガバナンスにおけるコーポレート・メッセージ

チームマネジメントの観点で、非常に重要かつガバナンスのためのツールとして重要視しているのは特に「企業内部への価値の共有による意識の向上、品質や生産性向上の効果を期待する」です。

知識創造企業の中でも(意訳が含まれていた場合には申し訳ありません)、トップがビジョンを示し、ミドルマネジメント層はそれを具体的にブレークダウン/解釈し、最前線の価値観を説明・共有するとありましたが、重要なことは

  1. ドルマネジメント層に自事業における「解釈」「具体化」の幅を持たせる
  2. 共有化(体験としてイメージしやすく)しやすい
  3. 様々な知識の中でどれを「価値」として判断するかの、正当化基準として機能する

だと考えています。

知識創造企業

知識創造企業

これらを整理すると

  1. 価値の基準点としての機能
  2. 解釈の多様性
  3. 共有しやすさ

こういった観点で他社のコーポレート・メッセージ/コーポレート・アイデンティティを眺めてみると

コーポレートスローガン一覧 - NAVER まとめ

(こういうまとめは最近話題の記事の盗作でなくて手間を掛けての本当の価値だと思っています)

キッコーマンの「おいしい記憶をつくりたい。」、バンダイナムコエンターテイメントの「アソビきれない毎日を。」などは、価値のグラウンディング(正当化・基準点)、イメージがし易い、そして何より「解釈に幅がある」という点で、非常に優れたコーポレート・メッセージだと思います。

さて、上記観点で弊社のコーポレート・メッセージを振り返ってみます

価値の基準点としての機能

「With Us, You Can」は、お客様とともに私達があり、お客様へ価値を提供することでその価値への正当な対価として見返りをいただくという解釈を私はしています。 この観点に立つと、私達の利益を増やすためには、お客様がまず利益を得ていただかなければならない、つまり、お客さまのビジネスが自分たちの土俵であるという ATI (圧倒的当事者意識) の高まりが不可欠になります。

悪い言い方をすると他人の褌で相撲を取る、という表現にもなるかと思いますが、少なくとも私が現在自部署での活動においてはこの ATI をかなり強く意識しています。

解釈の多様性

PRESS RELEASE FROM NOSIGNER 2016

ギンザ・グラフィック・ギャラリーでの展示「ノザイナー かたちと理由」の「De(construct)sign」で「木は葉・実・枝・根の4種類で非常に多様性があるが、扇風機は100を超える多くの部品で構成されている」との展示がありました。 この中の説明文の中に

優れたデザインは、要素が少なく、かつ多くの理由を備えているものだ。自然は我々よりも遥かに優れたデザイナーであり、我々は自然から多くのことを学べるだろう

翻ってみると、「With Us, You Can」は 「Us」とは?、「You」とは?、という明示的なプレースホルダーに加え、ここに「How」「What」などの非明示的なプレースホルダーを想像することは容易です。解釈の幅を許しているだけではなく、明示的・非明示的なプレースホルダーを備えている、ある意味陳腐と捉えられるかもしれませんが、 解釈を促す コーポレート・メッセージは他社を探してもそれほど多くは見つかりません。

これはコーポレート・メッセージの多様性=タフさとも考えています。各事業・各社員の中で様々な解釈・具体化をされたとしてもそこから「With Us, You Can」の要素が見て取れることはコーポレート・メッセージとしてとても強いのではないでしょうか。

共有のしやすさ

「With Us, You Can」は Us を含むことにより、「自分たちはなにができるだろう」という想像を喚起します。 また、(多くの)ヒトはヒトの役に立つ、認められることを望む生き物である(承認欲求)ことを踏まえると、自分が役に立つ、というイメージは共有がし易いものでもあります。 また、各事業においてはメッセージはプレースホルダーを埋めることで具体性を持たされ、その際により一層、役に立つ姿、 ATI は高まります。

その他

最近ベンチャーの方々のお話を伺い恥ずかしながらアドバイスをしていたりしています。 その中で感じているのが、創業メンバはビジョンなどなくとも共有している時間・想いがあるとは思います。 ですが、人数が増えた際の企業文化うんぬんが起きた時に、ビジョンがコーポレート・メッセージとして表現されていると、「これに合わない」という話ができると思います。 在籍期間によるマウンティングをするわけではないですが、意地を張る/張らねばならないタイミングはあると思っており、この際の拠り所とになるのではないかと考えています。

まとめ

ニフティのコーポレート・メッセージは 1) 価値の基準点としても、2) 解釈多様性の幅の面でも、 3) 共有のしやすさ、の面でも最強だと思ってる

これからコーポレート・メッセージを作成される方々の一助になればと思います。

おまけ

経験者採用 | 募集情報 | 採用情報:ニフティ株式会社

こんな感じでやっていますので、興味を持たれた方はぜひ仲間になってください。

私の所属する IoT デザインセンターでは電気回路の設計、基盤の設計・実装(ハンダゴテ含む)、API サーバ・フロントエンドの設計・実装・運用、 データ解析・レポート作成、お客様への技術企画の提案を含むコンサルティングまで幅広くやっています。興味がある方は 特にぜひ 助けてくださるとうれしいです。(2回目

第1回 エンジニアリングマネージャ勉強会を開催し、因数分解でメンタリングをすることを発表してきました

f:id:muddydixon:20161214111008p:plain

id:takesako煽られて背中を押されて

connpass.com

開催しました。

エンジニアリングマネージャ

資料内にもありますが、現在僕は2つの組織の改善を推進していて

  • IoTデザインセンタ 開発チーム リーダ
  • 全社 技術戦略委員会 (どこかで別に書きます)

ミクロなチームのマネジメントをしつつ、マクロなエンジニアリングのルールやガイドラインの提供、環境の改善などをおこなっています。

全社でやろうと考えていることのトライアルをチームで試し成功事例として全社に展開したり、チームの課題を汎用的に他のチームのメリットが出るように全社の課題として取り組んだりと、両方を睨むことで、うまく回っていきつつあります。

エンジニアリングマネージャの課題

id:antipop も話していましたし、懇親会でも話題になっていたのですが、エンジニアリングに限らず「再現性が無い(難しい)」があります。その背景として

  • メンティー自身の問題ではなく、メンターとメンティーの組み合わせなので自由度が一つ高い
  • メンティーのメンタルの状況が、人生のフェイズ、取り組んでいるミッション、その日の体調と乱数要素が大きい

というのがあるのかと思います。

取り組んでいること

私自身が「コミュニケーションが下手」というのもあるため、更に難易度が上がっています。 まるっと「メンター」「メンティー」「成長」という組み合わせでやるから「空気嫁」とか「人間力」みたいなモヤモヤすると考え、メンターの (指向・姿勢, 状況) とメンティーの (指向・姿勢, 能力) とその間の (動機づけの方法, アサインする仕事) という形で因数として分解してみることにしました。

  1. 指向・姿勢: キャリア・アンカー改
  2. 動機: 動機づけ要因、衛生要因
  3. 仕事: ロール/事業関与

分解した上でモデル化、実践と進めて行きたいと思います。

speakerdeck.com

全体を通して

私が「具体的な取り組みと分解の話」、 id:antipop が広い知識からの整理とペパボの「いいじゃん、いい感じに、バーンと」、 @kenchan が1 on 1の取り組みなどについて(途中、社内対応してたので、資料公開お待ちしております)、 id:takesako (こちらは ATI の高いピザ対応をしていたため見れなかったので公開をお待ちしております)と多岐に渡っているようで、下記のような共通点が見えて、自分が外れたことをかんがえているわけではない、と安心ができました。

新しい懇親会のスタイル

id:takoratta が司会をしてくださったこともあり、今回の勉強会では懇親会が非常に面白い形が「立ち現れました」。 懇親会で LT をし、飛び入りを募集する予定だったのですが、飛び入りが現れず、代わりに「会場みなへの質問」が投げかけられました。 そこから後は、話せるヒトが皆、代わる代わるにマイクをもち、個別に雑談もなく、会場全体が議論の渦になっていきました。

この背景として、おそらく、

  1. 参加資格を設けたこと
  2. 数回のイテレーションを回し、成否にかかわらず知見があったこと(反省・課題がある
  3. スクラム同様、教科書はあるが、正解がないため、現状が不安なこと(より正解に向かいたい
  4. マネージャという立場上、議論を回すことが好き・能力がある

だったのではないかと思いました。

これは非常にエキサイティングで、そこかしこから良し悪し問わず、知見が披露され、ためになるものでした。

今後、条件を統制することでこの形式を意図的に引き起こせるのであれば検討してみたいと思います。

最後に

id:takoratta id:takesako id:antipop @kenchan @yuku_t @tatsushim ここ数年、いろいろと考え、闇雲にトライしていたものを棚卸しする機会をいただきありがとうございました。

!?

f:id:muddydixon:20161214114604p:plain

「いいちこ棒」という謎の仕組みで GUGEN に展示します

gugen.jp

GUGEN というハードウェアコンテストに今年も応募しています。 無事、第1次審査は通過し(する自信はありましたが!)、本戦に進めました。

詳細は、プレスリリース をご覧いただければと思います(RBBTodayさんにも記事にしていただきました)。

GUGEN は昨年も2件だし、2件とも!予選を通過したので本戦で展示して、他の方々の展示も見ましたが 世の中は広いもので、どうでもよいものから、役に立ちそうなもの、ビジネスになりそうなものまで広くモノを作られているのが見えて面白かったです。

昨年の展示で私が一番印象深かったのが「恋のビビビを電気のビビビに!『ビビビコントローラー』」でした。

大きなディスプレイに映る女の子に向き合い、女の子が可愛らしくハートに来るセリフを行ったときに心拍の変化を検知(ほんとうかなぁ?)し、 割りとガチで「イラッ」とするほどの電気でしびれる、本当にどうでもよい(褒めてる)デバイスです

で、この記事で言いたいことは、秋葉原で12/17(土)に本戦があるので、ぜひ、見学に来て、いいちこ棒を応援してください、ということです。 よろしくお願いいたします

いいちこ

いいちこ棒は、イベンター・イベントに参加のお客様に対して「With Us, You Can」を実現すべく 弊社のエンジニアのデバイス班、アプリ班と広報部隊が協力して開発しました。

電子回路の一部は某所にお願いして設計しましたが、その回路のデバッグや検証などは完全に内部で行いました。 余談ですが、デバッグ用回路がバグっていたり、端子が間違っているなどもコツコツとテスタで確認して、発見・修正案の提案までしています。 (割りと漏れが合ったので、オフショアむずいなぁと思ったりゲフンゲフン)

ダッシュボードのフロントエンドも企画サイドの * サーバ費用持ちたくない * 運用もしたくない というニーズにお答えして、拙作の MQTTPress を導入して実現しました(もちろん、とはいえ、 MQTT はどこかでかりるのですが、誰かがマネージしてくれている)

speakerdeck.com

フロントエンドのUIも実際のイベンター様の声を聞きつつ、修正を重ね(これからも可能な範囲で手を入れていく予定)て作ったもので、「なるべくわかりやすく」「良く使う機能(3択とかYes/Noなど)」はすぐ作れる」などの改善が加えられています。

現時点では投票に特化していますが、回路/デバイス的にはもっともっと豪華な機能を詰め込めるようには作ってあるので、今後、よりエンターテイメントに向けたりもできるかと妄想しています。

おまけ

手が汚いので撮り直し・動画作り直しさせられたんですが、GUGEN の方もお忙しいのか、変更がないので、社内 Slack で「写真変わらないままだ」とか dis られてますが、僕は元気です

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 ...

デフォルトで、コンテナはこれらのデバイスに対して readwriteおよび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 の設定を閲覧できて、その場で実行ができる。

  • トップ f:id:muddydixon:20160308004640p:plain

  • 実行 f:id:muddydixon:20160308004704p:plain

  • playbook タスクリスト f:id:muddydixon:20160308004720p:plain

あと、当然これは API を持っている。

% curl -X POST "http://localhost:2401/api/playbook/sample2.yml"

こんな感じで叩くことができる。

としておけば op サーバあたりで git clone して、 ansibrest を上げておけば、 hubot から簡単に実行できる。

カジュアルにチーム皆の(slackの)前で

@repo_hubot play sample2.yml development

とか実行することができる(はず

残項目

  • playbook は通常、結構時間がかかるので、ウェブから実行する場合には stream / websocket にしたいところ(hubotの場合はなんか進捗的なやつを定期的に処理できるようにするか)
  • sshの鍵とかそういうのの管理ができない
    • これはしないほうがいい気もする
  • ansible ini フォーマットと yaml が混ざってるし、 playbook 作る人によって書き方違うのでアレなのどうしたらいいのか