べにやまぶろぐ

技術寄りの話を書くつもり

JTF2014「Serverspecに見る技術トレンドを生み出すヒント」の聴講メモ #techfesta

JTF2014 最初のセッションは Serverspec Operations 宮下 剛輔 (id:MIZZY) 氏 の「Serverspecに見る技術トレンドを生み出すヒント」。宮下さんの講演は今年のデブサミ以来 (デブサミ2014 「サーバプロビジョニングのこれまでとこれから」 のメモ #devsumi - べにやまぶろぐ) でしたが、その間にペパボを退職され、肩書きがフリーランスエンジニア (Serverspec Operations が屋号)になられていました。

テスト駆動インフラや Immutable Infrastructure といった話を体系的にお話しされたデブサミとはまた違った内容で、Serverspec 誕生の歴史・裏話?など興味深く聞かせていただきました。

個人的に響いたこと
  • "ServerSpec" や "Server Spec" という表記は誤りで、"Serverspec", "serverspec", "SERVERSPEC" が正しいスペル(表記がまちまちなのでもやっとしてました)
  • Serverspec を使ったセキュリティチェック : ミドルの設定など新しく立てたサーバー・サービスが自社のガイドラインに準拠できているか確認する用途にも使えるかも
  • 人類の技術発展のための無償開発という考え方では良いものは作れない(自分が使いたいものを作るという理解で正しいでしょうか)
  • Shut the fuck up and write some code (今のプロジェクトにはこれも欠けている)
講演メモ
  • インフラ(OS からミドルまで)系技術のトレンド
    • Chef 人気、US では 2014 年になってようやく Puppet のシェアを超えたらしい
    • 大企業向けで複雑な Chef/Puppet のカウンターとしてライトに使いやすい Ansible も普及
    • テスト駆動インフラとインフラ CI (Test Kitchen, Serverspec など)
    • Immutable Infrastructure => WEB DB PRESS Vol.81 (先行発売中)
      • Vol.80 ではテスト駆動インフラ特集
  • テスト駆動インフラとインフラ CI
  • Serverspec
    • RSpec でサーバの状態をテスト、本質的には『サーバの状態を記述したコードをテスト』するもの
    • ServerSpec や Server Spec は誤りで Serverspec, serverspec, SERVERSPEC が正しいスペル (RSpec と Server の組み合わせであるため)
  • テストツール開発のきっかけ
    • Excel チェックシートでの目視確認はやめたいと思い、 Assurer というサーバテストフレームワークを Perl で 2007 年に作っていたが広まらなかった
      • Serverspec と違って振る舞いをテストするため、状態をテストするより複雑になった
      • フェーズ分け・プラガブル・分散処理・シェルと複雑になりすぎた
      • コンセプトが曖昧になり、自分でも使わなくなった
    • しばらくたって自分で書いた Puppet マニュフェストがレガシーになってしまっためリファクタリングしたくなった => テストが必要になった
      • LXC コンテナでテストするためにコンテナをさくっとつくれる Puppet マニュフェストを書いたが、Docker がちょうど同じタイミングで出てきたので無用な長物になった
      • テスト用ツールは rspec-puppet くらいしか Puppet で使えるものはなさそうで Chef の方が充実していた
        • rspec-puppet はモジュール化されているマニフェストしかテストできなくて自分ものには使えなかった
        • また実際のサーバをテストするわけではなくプロビジョニングの処理過程をテストするためツール依存になってしまい嫌だった
    • 同僚だった @hiboma さんが LXC のコンテナをテストするコードを RSpec で書いていたのでそれを拡張した
    • さらに拡張性を高くするため Serverspec は現在 2.0 に向けて鋭意リファクタリング・拡張中
  • Serverspec の認知度
    • Black Duck Open Source Rookies of the Year 2013 (Docker/InfluxDB/Appium などと並んで受賞)
    • rubygems.org で30万DL、Chef は400万DL
    • WEB+DB PRESS 75/76/80/81 やその他いろいろな書籍で言及されている
  • なぜ Serverspec は成功したのか?
    • 別領域で成功しているプラクティスを持ち込んだ
      • TDD/CI といったソフトウェア開発の世界のプラクティスを踏襲してテスト駆動インフラ/インフラCI というようにコンセプトを表現
    • わかりやすい名前 : Server + RSpec という直球のネーミング
    • 英語のドキュメントは世界的に認知してもらうのには必須、README や serverspec.org などは最初から英語で書いた
    • メジャーなキーワードやプロダクトに乗っかる (Puppet/Chef といったワードをちりばめることで Puppet/Chef 界隈の人に拾ってもらえた)
    • 斜め読みしてもすぐにわかるドキュメント
    • ツールそのものもシンプルでわかりやすいものにする
      • 構成管理ツールとの連携や VM 操作などは省いた
      • とはいえいろいろなユースシーンに対応する必要はあるので、拡張しやすいように作る
      • KISS の原則 : Keep it simple, stupid
    • インフラに余計なものを入れるのはすごく嫌なのでエージェントレスであることにこだわっている
      • テスト実行するマシンには Ruby さえあればよい
      • テスト対象マシンには SSH で入れればそれでよい
    • 使うまでの敷居を下げるため、Ruby 1.8.7 以降をサポートしている => Redhat 向け
    • 自分一人でやり過ぎない
      • 自分で使う機能しか基本的に実装しない
      • (OSS なので) 欲しい機能は個々の開発者に実装してもらう
    • 技術トレンドに乗った
      • Puppet から9年、Chef から5年たったのでみんなが次のことを考え始めた (元々テストに対して意識の高かった Chef 界隈の人に拾ってもらえた)
      • Vagrant が普及したので手元でテストを回すことができ始めた
      • Jenkins/CI/GitHub Flow といったツールや仕組みが普及してきた
      • 仮想化・構成管理・CI についての定番がなかったところにうまくはまった
  • とはいえ技術トレンドを生むとか考えないで自分が欲しいもの、おもしろいと思うものを自分のために作る
    • 人類の技術発展のための無償開発という考え方では良いものは作れない
    • 自分がほしいもの、おもしろいと思うものを作って公開、その積み重ねがすばらしいものを生むことにつながるはず
  • 好きな言葉
    • Shut the fuck up and write some code
    • Openness is our driver for excellence
    • 楽しんだものが強い(孔子の言葉)
WEB+DB PRESS Vol.81
WEB+DB PRESS Vol.81
posted with amazlet at 14.06.22
長嶋 享 藤 吾郎 八木 俊広 日高 一明 滝口 健太郎 田中 慎司 泉水 翔吾 海野 弘成 佐藤 太一 吉村 総一郎 伊藤 直也 川上 大喜 こしば としあき 舘野 祐一 中島 聡 橋本 翔 渡邊 恵太 はまちや2 竹原 川添 貴生 沢渡 真雪
技術評論社
売り上げランキング: 984

JTF2014「Swift code in Swift」の聴講メモ #techfesta

インフラの話が大多数を占めていた JTF2014 の中にあって若干異彩を放っていたのがこちらの swift セッションでした。個人的には swift 名前しかワカンネ状態だったのでこれはとばかりに飛び込んでみたら今回の会場だった産業技術大学院大学の教授の講演で驚きました。終始ノリの良い楽しいセッションでした。

個人的に響いたこと
  • Hack での PHP 拡張と Swift の機能強化で似ている点が結構ある
    • nil を許すかどうか ? などで明示する optional value や Generics など
  • Unity に慣れているとどうも cocos2d-x や swift でのゲーム作りに敷居を感じてしまう
    • 自分で境界領域を計算して collider はらないといけないとか
  • とりあえず swift 触るときは FlappySwift) 使ってみる
講演メモ
  • Swift : Fast/Modern/Safe/Interactive
  • Objective-C は 25年前の言語
    • Brad J.Cox et al 『オブジェクト指向のプログラミング』
    • 一方 C++ といえば
      • C++ の旧名 C with Classes (オブジェクト指向なんて言ってない)
      • C++ の別名 better C -> C89
    • C の中で smalltalk をインラインでかけるが若干浮いている
    • ある意味、これまでは古典言語も使って iOS 開発をしなくてはならなかったと言える
  • それまでのスクリプト言語では足りなかった機能を全部備えて現れたのが Perl
    • C はバイトを扱える、文字の配列と文字列はちょっと違う
      • 終端文字を意識しなくてはいけない、書式付き文字列変換など
    • Perl は正規表現を始めとして文字列操作に強い
  • Swift は 2010 年に Chris Lattner らが開発を始めた
    • 『Objective-C without the C』 : Objective-C の良いところを残して C からの脱却を実現
    • インタープリタ型の処理系、文字列操作を拡張し、main() などを排除
  • Fast
    • C よりは遅いが Objective-C よりは速いらしい
    • ちなみに Python よりも Objective-C が速く、Swift はそれよりさらに速い
  • Modern
    • Closures, Generics, Type inference, Multiple return types, Namespaces... などをサポート
    • Switch
      • break を書く必要がない
      • where で細かい条件を制御できる
      • perl/python にはそもそも switch はない
    • Safe
      • バグの原因になりやすい C の仕様が削除された
        • goto, ポインタ, バッファーオーバーフロー, 初期化忘れ変数, 書式付き文字列など
      • ! ? で nil の許可不許可を指定(optional value)
  • Playground

    • インタラクティブにデバッグしながら開発できる
  • 後半は株式会社あくしゅの山崎氏が二日でゲームを作ってみたというお話

    • 初学には FlappyBird もどきのサンプル (FlappySwift) が良かった
      • SpriteKit というゲームエンジンを使っている
        • シーングラフとイベントベースの制御エンジン
        • OpenGL を現在動かない
        • update でコマ落ちなどすると変位が大きくなってしまう (Unity で言うところの fixedUpdate はない?)
    • Ruby に近い気がする
    • オプションがあることでコンパイルとランタイムでのコードチェックの役割がとても良い感じ
    • 自分で衝突境界・領域を定義しなければならない

JTF2014「Dockerのエンタープライズ開発での活用モデル」の聴講メモ #techfesta

Docker 1.0 が出て誰もがユースケースや活用事例を欲している中、自分も大きな関心を持ってこちらのセッションに参加してきました。本番での運用はまだということでしたが、開発フェーズでの活用事例ということでいろいろと参考になることが多かったです。また、Docker って何だっけっていうところも丁寧に説明してくださって、初見の人にもためになる講演だったのではないかと思います。

個人的に響いたこと
  • AUFS の仕組み面白い
  • Docker を支える技術は namespace と cgroup
  • Private Docker Registry 立ててイメージの共有で 開発と CI 回すモデル試したい
  • 開発だけでなくデモ環境としても有用
    • ブランチごとにコンテナ立てて IP ふれば環境間の干渉を気にせずに動作確認できる
    • 従来型のデモ環境も考え直すべき
  • IDE も丸っと開発環境としてイメージ化して渡すというのも一考の価値あり
    • 使い慣れた設定もありつつ、コーディング規約のこととか考えると設定までパッケージ化して渡すのも良さそう。ただしライセンスフリーでないものはだめかも。
  • まだ本番まで適用できてはいない
講演メモ
  • Works Applications Advanced Technology and Engineering
    • 共通基盤開発などをしている
    • クラウド技術の調査検証など
  • Docker とは
    • 軽い: ハードウェア仮想化 vs コンテナ仮想化
    • 仮想化されたハードウェアを経由しないので処理が速い
    • コンテナ仮想化は OS を仮想化し、異なるディストリビューションのみ共存できる。起動したものはプロセスとして確認できる。
    • sysbench による性能評価をとったところ物理ママとほぼ遜色のない性能
  • ポータブル性
    • Docker registry
      • Docker Hub
      • Private Docker registry
    • どのクラウドにも物理マシンにも運べる
  • Docker を支える技術
    • AUFS
      • 複数のファイルシステムをあたかも一つのファイルシステムのように見せる技術
      • N-1 代目までのファイルは read-only として保存され、変更が入る際に改めて copy on write でコピーされて使われる
    • コンテナ仮想化
      • namespace
        • ユーザプロセスが動作する空間を分離する
          • Docker では PID/Net/UTS/IPC/Mount/User namespace を使っている
        • eth0 -> veth0(172.17.0.1) -> docker0 (仮想ブリッジ 172.17.0.0/16)
      • cgroup
        • プロセスが利用可能なリソースについて記述する
  • 事例紹介 (CI/開発/評価/DB)
    • CI 環境での活用
      • 上海・シンガポールなど複数拠点で同じ製品開発しているので開発環境を揃えたい
      • 製品の数が多く環境の入れ替えがよくある
      • 古いバージョンの補修が定期的に必要
      • アプリとテスト環境が違う、仮想化かけると重い
    • アプリの評価用環境へのデプロイ先に Docker でたてた
      • 誰かのアプリが問題を起こしても影響が限定的
      • 軽量なので確認時のパフォーマンスも問題にならない
    • Eclipse やライブラリなど IDE までまとめてイメージ化した
    • 複数拠点で使用する DB を Docker でパッケージ化
      • 国を超えた開発で DB へのアクセスがボトルネックになっていた
      • Master private registry から Slave private registry へ同期(単なるコピー)され、それを使う
      • いろいろな環境で運用するケースでは Docker は最適
  • 本番ではまだ使っていない
    • 開発・評価で試して上手くいけば production に持っていくというのはクラウドと同じ
  • Docker x AWS でコスト的なメリットは出そうか?
    • 社内リソースの有効活用には使えそう(古いPCなど)