今日は、July Tech Festa 2014に足を運んできました。ITインフラに関するソフトウェアや運用技術の話ばかりではなく、知見として獲得しておきたい他の分野に置ける開発のベストプラクティス等も聴く事が出来ました。
基調講演の「Serverspecに見る技術トレンドを生み出すヒント」では、Serverspec開発にあたってどのような事を考えていらっしゃっていたのか伺えた、貴重な機会となりました。
「インフラエンジニアのための次世代プロトコル入門」では、次世代プロトコルの導入はもう迫ってる現実であり、必ず来る未来である趣旨の話であることを確認させられる、ちょっとヒヤッとするセッションでした。
「Contrailを用いたSDI/NFVの実現」では、Interopよりもここ最近のネットワーク関連のキーワードを掘り下げるよい機会となりました。同時に、ネットワーク関連の話は本当に難しくなってしまって、OS・ミドルウェアレイヤーと同時に追いかけるには難しいのかなと思い始めています。
「フロントエンドで普及が進むビルドツールたち ? Grunt、gulp ほか」では、gulpを使ったWebページ・フロントエンド制作の最新のベストプラクティスを学ぶ事ができ、かつ自分の知識が化石化し始めている危機意識をもつ機会となりました。
それでは、今回もノートをアップしておきます。
概要
- 2014–06–22 (日)
- 産業技術大学院大学 (AIIT) (品川)
★今年もやります!JTF2014!!★ 皆様,今年もインフラエンジニアのための祭典,July Tech Festaを開催する運びとなりました。今年は6/22(日)開催です。昨年は300名超のご参加をいただき,技術セミナーをはじめ,数々のセッションが大盛り上がりとなりました。今年のJTF 2014は,セッションなど更にパワーアップし,昨年以上に熱く開催されます!テーマは「インフラ・テクノロジーマップ2014 〜明日を楽するために今日自動化を頑張るエンジニアの集い〜」とし,まさに今年の全貌が見える,旬のインフラ技術が結集します。ぜひご参加ください! ★イベントの詳細★ イベントの詳細は次のURLでご確認下さい。 http://2014.techfesta.jp/
- 弁当
- A会場にて頒布
- 13:00まで頒布
- 食べるのはA会場 or 食堂にて
- 指定のゴミ箱へ
Serverspecに見る技術トレンドを生み出すヒント
宮下 剛輔 さん
-
技術トレンドのキャッチアップ
-
Deckset でプレゼンしてる
-
今はほとんどCookpadで仕事をしているらしい
-
本セッションのインフラの定義: OSからミドルウェアといったソフトウェアレイヤーを指す言葉
- 最近のトレンド
- Chef
- 4, 5月に立て続けに本が出た
- USでは2014にPuppetのシェアを超えたらしい
- Ansible
- Chefへのカウンター (複雑さ、大規模さへのカウンター)
- 仮想化関連
- Vagrant
- Docker (2013–03くらい Serverspecと同じくらい 仮想化以上の意味があるものではあるがとりあえず SEE Also:WEB+DB Press Vol.81)
- テスト駆動インフラ/インフラCI
- Test Kitchen
- Serverspec
- WEB+DB Press Vol.80 に特集記事があるので読んでね
- Immutable Infrastructure
- Chef
- テスト駆動インフラ/インフラCI
- 概念自体はあった
- アプリケーション開発の手法をインフラ構築に応用する。
- 2012年に @riywo さん、 2007くらいに自身でも考えていた。
- GitHubを利用したワークフローにまで広げられる
- 概念自体はあった
- Serverspecとは
- 2013–03末にリリース
- 名称は正しく! Serverspec, serverspec, SERVERSPEC のどれか。1つめは現状、2つめは旧です。気をつけてね!人の名前間違えないのと同じように、
- Serverspec背景
- なぜ生まれたの?
- Puppetで構築は自動化できた→でもExcelベースのチェックシートでの目視をやめたい・自動化したい
- Assurerの誕生
- 2007年に作ったPerl製テストフレームワーク
- プラグイン拡張可能
- Plaggerの影響
- Filter, Format, Notify, Publish, Test
- make test でテスト実行, TAP形式で結果を出力
- CPAN AuthorなのでPerlでのテストのやり方を踏襲した
- 敗因
- 振る舞いをテストした
- 状態テストよりも要件が複雑化する
- 詰め込みすぎて更に複雑になった
- フェイズ分け, プラガブル, 分散処理, シェル
- Serverspecほどコンセプトが明確ではなかった
- 自分すら使わなくなった…
- 振る舞いをテストした
- Assurer以後
- 思い返しても積極的に何かしようともしなかった
- マネジャをやっていた事もあり若干現場から距離を置くようになりあまり触らなくなった
- またPuppetを触り始めた
- 以前書いたものがレガシーコードになっていた…(あの時はベストプラクティスがなく、今の状況に合っていない。)
- リファクタリングしたい→当然テストも必要
- CI環境を整える
- LXCコンテナでテスト。コンテナをさくっと作れるPuppetマニフェストを書いた。 (でもDockerが出てきて無用になってもた)
- テストツール探し
- Puppetはrspec-puppetくらししかない。しかしモジュール化されていない。使えない状況。
- Chef周辺の方が充実。
- 上記は実際のサーバの状態をテストする訳ではない。
- Serverspecの登場
- 同僚(@hibomaさん)のLXCコンテナをテストするコードをRSpecで書いていた。パクって汎用的にした。
- 1日でプロトタイプを作り、次の日にgemを公開。
- 初期
- 複数OS, バックエンド切り替え対応など、色々入ってきた。
- いろんな人を巻き込んだ。
- ちょっとした隙を作る。
- 今後
- v2.0
- 作業中
- 拡張しやすくするためのリファクタリングが中心
- 表面上はあまり変わりません
- v2.0
- なぜ生まれたの?
- Serverspec認知度
- Black Duck Open Source Rookies of the Tear 2013 にて、Docker, InfluexDB, Appium と並んで受賞。
- Thought Works Technology Rader 2014にて、Provisioning Testingの項目で出てくる。
- Rubygems.orgにて30万DL (参考:Chefは400万)。
- 雑誌 WEB+DB PRESS Vol.75,76,80,81
- @naoya_ito さんの推しあってのこと
- 書籍
- 5冊ほど
- 海外の反応
- Adam Jacob さんなど
- ドイツ
- ChefConf で発表した資料
- Puppet のカンファレンスではRejectされてしまった
- ChefConf で話せるのは認知されてきたんだなと思った
- Sensu+Serverspec って話もあるらしい
- Serverspec成功要因
- ワールドワイドで認知された経緯
- 能動的な要因
- 別領域で成功しているプラクティスを持ち込む (今回は特にソフトウェア)
- テスト駆動
- CI
- 同じ用語を用いるとイメージしやすい
- テスト駆動インフラ
- インフラCI
- 名前
- Server + RSpec と直球
- 類推しやすい
- 覚えやすい
- 英文ドキュメント
- 日本国外で広く認知してもらうためには重要
- README, serverspec.org などは最初から英語で書いた
- 既にメジャーになっているものに乗っかる
- Puppet, Chef と言ったキーワードをちりばめる
- Puppet ,Chef の中の人に拾われて広まったかと思う
- ドキュメントのわかりやすさ
- リーチャビリティあげるだけではダメ。
- 見てすぐにわかる、斜め読みしただけでわかるように。
- ツール自体のシンプルさ
- そのものがわかりやすいことが重要。
- テストに特化
- 構成管理・VMの操作をは省いた
- 他ツールとの組み合わせ
- busser-serverspec
- vagrant-serverspec
- Agent less
- テスト実行する環境でRubyで動けば良い
- テスト対象はSSHだけあればいい
- とりあえず動かせるような環境で
- サーバに色々入れるの嫌ですよね (わかります)
- RHELでサポートできるバージョンで使えるようにしておいた
- 別領域で成功しているプラクティスを持ち込む (今回は特にソフトウェア)
- 技術トレンド要因
- chef界隈テストの盛り上がり
- JenkinsやCI as a Serviceの普及
- GitHubの普及
- まとめ
- 欲しいもの、面白いものを自分のために作ろう!!!そして公開しよう。
- (人類の技術発展のための無償開発、というスタンスではいいものはできないよね。)
- 技術トレンド生み出す近道はない
- 少なくとも自分は知らない
- その積み重ねが素晴らしいものを生み出す事につながる
- 自分が作って公開したものは、小さなものを含めて100ほどある。
- 欲しいもの、面白いものを自分のために作ろう!!!そして公開しよう。
インフラエンジニアのための次世代プロトコル入門
中島 博敬 さん
-
スライドは後で公開します
- インフラエンジニアの仕事
- 上も下も知る
- 未来を見据える
- 現状
- HTTP, TCP, IP
- ずいぶん変わってない
- 動いているものを変更するな。変えるのは大変だ。
- Web
- 非同期通信の台頭
- HTTP, TCP, IP
- なぜ次世代プロトコルなのか?
- 接続環境の変化・ページのリソース数・Webアプリケーションのインタラクティブ化
- 遅延がWebサービスの収益にリンクする
- HTTP/1.1
- 接続の度のヘッダ、無駄だよね!
- コンテンツ圧縮はできるけど、ヘッダはできない。
- こまい通信が増えると最悪だね。
- 「黒魔術」による解決。
- それも限度がある。
- 接続の度のヘッダ、無駄だよね!
- HTTP/2
- SPDYからの提案をベースに議論を開始
- CRIME攻撃の問題を解決
- とにかくオーバーヘッドを減らす
- 全二重通信 (Push)
- SPDYからの提案をベースに議論を開始
- TCP Alternative
- QUIC
- SPDY – Head Line Blocking の問題
- だからUDPベース
- 1RTTで接続
- Forward Error Correction – パリティ技術
- Packet Pacing – Conguision Control (UDPの弱点を補強)
- Multi Path – ハンドオーバーを0RTTで
- QUIC
-
TCPを既存のネットワークに影響が出ないように変えて行く取組み
- TLS
- OpenSSL 悲しい出来事 2つ…
- IPv6
- 対応は 日本で3.49, 米国でも7.97% 泣ける
- Azure 米国リージョンの IPv4 のアドレスが枯渇 (65万個 使い果たした)
- IPv4 のアドレスの枯渇の問題は既に発生している
- fail2ban は v6 対応してなくて泣いたとか
- 新サービスから対応しよう
-
ハイパフォーマンスブラウザネットワーキングもあわせて読みましょう
-
興味があるプロトコル、一つはじっくり掘り下げてみよう。
-
次世代プロトコルの導入、もう迫ってる現実だ!必ず来る未来である。
Contrailを用いたSDI/NFVの実現
有村 淳矢 さん
-
ShowNet構築の気分的な疲れが残ってる…(汗)
- Contrailとは?
- SDNプラットフォーム ソフトウェア
- Open vSwitchを使って…という議論があるけど、それそのものだよ。
- コントリビュートできます
- プレーンの分離
- OLD WAY
- Managerment, Control, Service, Forwarding Plane が内在し、各機器が自立分散して動いていた。
- NEW WAY
- コントローラを用いてこれらを集中管理。
- OLD WAY
- Contrail
- 5つのコンポーネント
- Configuration Manager
- Collector
- Web UI
- Control Plane Node
- BGPベースのコントロールプレーンを管理
- Compute Node
- オケストレータ
- SDNコントローラ
- XMPPでメッセージをやりとりしている
- 大規模にスケールするクラウドサービスを実現可能
- MPLS VLAN のように
- 5つのコンポーネント
- OpenFlowとの違い
- 集中管理している所は同じ。
- 既存IPネットワークにも情報をフローベース(IP, Port)で注入 コントローラが膨大な情報をもっている
- 機器に負荷をかけずにトラフィックを切り替えられる
- オーバーレイモデル(Contrail)だと細かいものを太くして自律分散している
- 細かい制御が難しくなる
- NFVとSDN
- NFVとSDNは完全にイコールでは結ばれない
- NFVとSDNを絡めて使う事でより良くなる
- OSの部分だけ抜き出して仮想化するのがNFV
- Contrailを用いたSDNサービス
- オーバーレイ クラウドデータセンター
- IaaS & VPC, Seamless MPLS Datacenter
- サービスエッジ, NaaS VPN GW
- 末端のセキュリティ対策をデータセンター側で移譲させてしまう
- (CATVインターネットとかだといい感じっぽそう)
- Spine-Leaf のメリット
- 遅延・ジッターのレベルが一定 (輻輳しなければ)
- Webアプリケーションのネットワークパフォーマンスが安定する (Hadoopとか)
- 論文もあるよ
- 遅延・ジッターのレベルが一定 (輻輳しなければ)
- VXLAN GW (ToR)スイッチ
- VXLANトンネルを経由してデータセンター間でやりとりできる、が…
- VLANタグはつけない
- サーバ側で先にVTEPを通してしまう
- 仮想の世界で問題があると、単にミラーポートからDumpするデバッグは難しくなった。
- Contrail等を使えば楽、らしい。
- くわしくは
- http://opencontrail.org/jp/
- ハンズオンもやっています
- イベントもどうぞ!
-
久々に技術的に追いつけない内容だった…
フロントエンドで普及が進むビルドツールたち ? Grunt、gulp ほか
河村 奨 さん
-
下北沢オープンソースカフェとリブライズの人
-
カフェは東京で二軒目のコワーキングスペースだったそうだ
-
Grunt (ぐらんと)
- gulp (がるぷ)
- こちら中心でいきます
- フロントエンド制作の今
- デモンストレーション「アンネ・フランク・ライブラリー」
- 単にHTMLを書くだけでは作れなくなった
- gulpfile.coffee (coffeescript)
- 画像ファイルの自動変換
- いろいろ
- デザイナが手作業でやっていたものを自動化する (現場にいると本当に大変そうだった)
- クロスブラウザチェック
- 同時に複数のブラウザをチェックできる スクロールもsync (めっちゃいいですねこれ)
- ほぼリアルタイムにブラウザをチェックしながら制作可能
- HTMLの即時反映
- 画像のリアルタイム反映もできる (サイズも含めて!!!)
- それなりに高速に動くらしい
- 非同期でタスクが走る
- デモだと 300msec くらいでいける
- 比較
- Grant
- フロントエンド制作の自動化の立役者
- npmで入れられる デザイナも使うくらいなので簡単である
- 1年くらい、お世話になったそうです。
- gulp
- タスク設定ファイル、Grantと比較すると、1/3くらいの分量。おうふ。
- コマンド間連携もできます。
- Googleも乗った。
- Web Fundamentals – マルチデバイス対応スターターキット タスクランナーにgulp採用
- 新しめのサイトの制作はgulp採用が増えている
- Grant
- gulp
- package.json, gulpfile.coffee
- 「ブラウザ直近2バージョンまでサポート」なんてことも
- インクリメンタルビルド可能
- 何を自動化するの?
- LESS, Sass, Styles
- CSS最適化
- 「uncss」(使っていないCSSを削れる) – 秘伝のCSSをスリムに
- CoffeeScript 等のコンパイル
- Browserify, Require.js, Uglify
- ライブラリ依存、難読化、圧縮。
- Style Guide
- 画像最適化
- フォント自動生成
- 何のための自動化?
- 楽をする。2回同じ事しない。
- デザイナには鉄則ではなかった。美徳とさえ言われていた事もあった。
- コンパイル・自動生成
- テスト・ソースコードの検証
- リアルタイム化 (LiveReload, BrowserSync)
- 楽をする。2回同じ事しない。
- ビルドツールの変遷
- 石器時代
- ShellScript, AppleScript, Adobe JavaScript
- 中世
- Make – Watchman(Facebook謹製のファイル監視ツール)の影響
- Rake, Jake, Fabric, Ant
- 近代
- Guard, Watcher (ディスコン)
- Middleman
- 現代
- gulp, Grunt, Brunch, Broccoli
- 平行世界
- ワークフローが限定的になるので悩ましい
- CodeKit, Prepros, Atom, …
- 石器時代
- サーバ・クライアント・そして第三極?
- デザインの現場からの要請
- ウォータフォール方法論の崩壊
- レスポンシブ
- インブラウザ
- デザインもテストファースト(CI)の時代に
- 改めて、自動化。
- 共通プラットフォームとしてnode.jsがデファクト。
- フロントエンド開発にプログラマが参入した結果が、今。
- デザインの現場からの要請
総務部技術課!? エンジニアのための業務完全自動化へのアプローチ
服部 健太 さん
-
Kompira 開発している所 (2013年のプロシンに来てた所かな?)
-
フォースクーナーはデータホテルに売却
-
自社プロダクトの紹介。
-
プロシンの発表の後から、どの辺が変わったのだろう。