ChefConf 2015 レポート (part 1)
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
2015年3月31日から4月2日まで実施されたChefConf 2015の現地レポートです。
全7回のレポートとなります。今回ChefConf 2015にできなかった方、英語がちょっと・・という方、ChefConf 2016に参加するために社内稟議の資料作成が大変な方、、是非ご活用ください^^
登録者の受付カウンター:Chefのロゴをあしらったポスターやディスプレイがいたるところに配置
合計、2000人程度の参加者を募っており、ほとんどがプログラマ/開発者、という構成
スーツを着ている人はほぼ皆無、という状況
総勢2000人くらいの参加者で、ほぼ100%がプログラマー、という雰囲気。
Santa Clara Convention Centerは昔からIT系のイベントを行う会場として有名だが、今回のイベントはその中でもかなり金をかけている事が会場の雰囲気でよくわかる。
ステージ左にはDJが音楽を流しており、イベントの間中、ずっと操作をしていた。
Keynote Speech: Nathen Harvey: ChefConf Program Chair
イベントのMC役として、Community Directorという役職を持つ、Nathan Harvey氏がイベントを通して、講演者の紹介、等を実施。
Chefはコミュニティの強い支援を受けて育った典型的なオープンソースであるが、コミュニティを構成する開発者/プログラマのフィードバックを製品の時期リリース機能、ひいては企業の戦略に反映する活動を推進するのが役割。
Nathan Harvey氏は、Chef Conf 2015向けに作成したビデオに出演しており、その時のコスチューム(寝間着)で登壇。
遊び感覚あふれたムードがイベント全体に流れていて、Chefコミュニティの自由な気風が流れている様子がよくわかる。
Chefが単なる技術ではなく、ソフトウェア開発に対する一つの「流儀」を提唱している事がよくわかる。
コミュニティを支える様々なツールやサービスを提供している組織やオープンソースの紹介
Foodcritic: OpscodeのChef Cookbookの間違いを検知し、問題を未然に防ぐためのlintツール
Berkshelf: Cookbookの依存度を管理するツール。Chef-DKの一部になっている。
ChefSpec: リソースやレシピのテストを行うツール
Chefだけでコミュニティを運営しているだけではなく、広い範囲の組織がChef文化を作り上げている点が特徴
ユーザでもコミュニティが形成されている事も紹介
Target: F5 BIG-IP CookbookをChefコミュニティに提供
CenturyLink Cloud: Windowsの自動化を自社クラウド+Chefで実現
Rally Software: Chef関連のツールを開発、提供
Nordstrom: 衣料リテール大手。Chefを本格的に採用、ツールも開発、提供
最年少のGitHub Contributorを紹介
8歳の少女が父親と一緒にChefのプロビジョニングツールを開発
Chefサーバがオープンソースである、という事と、グローバルに広がっている今日でも、分化せずに統一されたコードで、大企業からスタートアップでも利用されている、という点がChefの大きな特徴である、と説明。
Chef Ambassador(Chef大使)の制度:
会場を歩くと、オレンジのステッカーをつけている人が数人見かけられるが、Chef Ambassadorの印。
コミュニティについての説明や、どのような形でコミュニティに寄与できるかどうかを気軽に相談できる人として是非声をかけてほしい、と招待される。
CEO Keynote: Barry Christ: CEO Chef
キーノードスピーチの第一弾は、CEOである、Barry Christ氏
今回で、3回目のChef Confへの参加。毎年、規模が大きくなっていることと、コミュニティの活動が活発になっている、ということを強調
また、エンタプライズやレガシー企業からの参加が増えてきている、という点も強調
古い、レガシー系の企業を訪問した経験の話
IT部門は古いビルの中が拠点
IT予算は、コスト削減とアウトソースが要求として経営側から来ていた
IT部門はそれに基づいて戦略を立案したが、当初は企業のビジョンとかけ離れていたものになっていた
ただ、そのIT改善のプロセスを通して、スピード感をもったDevOpsのコンセプトが植え付けられるようになっていった
道のりは難しかったが、Chefの導入による成果は単なるコスト削減だけではなく、企業内でのIT部門の重要性の認識と、企業内での調和が実現された事が成果として大きかった。
これは、どんな企業でも起こりうる成果であり、業界に関わらず、すべての企業がソフトウェアビジネスにいる事を認識する様になる。
ChefはFord, Target, GE, Starbucks等の大企業を、ソフトウェア企業に変革することに寄与している。
これらの企業のソフトウェア開発の課題は、早く世に新しいサービスを出さなければいけない、というSPEEDへの要求があるのと同時に、そのサービスを提供するソフトウェアの品質:QUALITYを維持することの難しさ。あまりにも早く出荷/リリースをしてしまうと、ソフトウェア、ひいてはサービスの低下につながる。
Chefが提唱する品質を高めるための3つの価値は:
クラウドでの実装
ITプロセスの自動化
DevOps
DevOpsは、3つのコンポーネントがあって、お互い密に連携しながら企業内で運用する必要が有る。
Culture: 企業文化
Workflow: ソフトウェア開発/運用の手順の確率
Tooling: DevOpsを実現するツールの整備
特に、Velocity(スピード)は、DevOpsを導入することによって最も重要で大きな効果をもたらしている、という事をアピール。
例えば、GEでの事例:
Chefの導入により、ソフトウェアの開発プロセスの速度に大幅に向上:開発スピードが8千倍!
これに伴い、新規ソフトウェアのサービスの収益が195%成長
Seattle Police Department
元AmazonのCIOを雇い、ITの促進を図った
今日の企業のIT環境の2分化が大きな課題になっている。
NewIT:時世代のIT技術/開発/運用手法
ウェブ/モバイルのプロジェクト主体で、業務改革(イノベーション)をもたらすアプリ
Traditional IT
eメール、ERP、POS、データベース、等、従来から存在するアプリケーション
この2つの環境は全く異なる文化、技術を保有する。
レガシーアプリケーションは、Traditional ITの方に存在する。
2つを分ける最も大きな違いは、「スピード」の違い
Chefの戦略は、この2つの異なる、Traditional ITとNew ITとを結びつける事。
GEはこの2つの文化を保有する企業の典型的な例で、数年かけて、率先してChefを使ったITの統合を実現している。
Customer Keynote: Matt Merchant: Global Managing Director, Infrastructure Operator, GE Capital
GEでは、ArchOpsというコンセプトを推進している。次の4つのコンポーネントを持つ。
MVP: 新製品、サービスを市場に投入する際のマーケティングテスト手法
Continuous Delivery: ボタン一つでシステムへの変更やエンハンスが簡単にできる仕組み
DevOps: 開発者(Dev)と運用者(Ops)との間のコミュニケーション、協業力を強化する動き
Cloud: セルフ型のサービスを迅速に、柔軟に実装することができるホスティング環境
3年前にソフトウェアの強豪力を強化するために大きな変化が必要がある、と認識
新しい技術を導入するだけではいけない
組織も新しい技術に合わせた変化が必要
GEは特に規制の厳しい業界にいる。
セキュリティ規制
コンプライアンス要求
規制要求に対する対応
コンプライアンス:Compliance, Governance teams get together to discuss
セキュリティは参照アーキテクチャに作り込む
4ヶ月かかったソフトウェア開発が4日でできるようになった
企業文化を大きく変えることが重要
変えていくのに3〜5年かかる
6シグマプログラムをモデルにした(指導ができるプロを育成するプログラム)
企業のDNAがだんだんと改善されてきた
Product Demo:
James Casey: VP Engineering, Chef
Seth Falcon: Engineering GM, Chef Delivery
Chef Deliveryの発表:
IT業界のノウハウを集約したワークフローをシステム化:
今までの実績でうまくソフトウェアの開発/デリバリーを調査し、そのパターンをChef Deliveryに実装した
Create new changes: 新規の変更の作成
Test change locally: ローカルに変更の適用/テスト
Submit changes: 変更を提出
Review change: 変更のレビュー
Approve changes: 変更の承認
Ship changes: 変更をシステム全体に適用
Chef Deliveryの機能:ソフトウェア開発のワークフローを定義し、そのワークフローの各ステージに対してポリシーを設定できるシステム
Visualize: ソフトウェア開発のワークフローを常に監視し、変更がどのように付与されているかを常に確認
Apply Policy to Change: 開発フローに対してポリシーを提供し、一貫して変更を管理することができる
実際にChef Deliveryのデモを会場で実施
数週間前から、Chef.ioのウェブサイトはすでにChef Deliveryを使っている。
今回は、Chef Deliveryのランディングページを実際に変更を加えてリアルタイムで更新するデモを実施する。
画面左が古い画面、右が新しい画面
次がその手順:
Verify: コードの変更を要求するプロセスで、まずは変更要求を出し、その内容のレビューがよければ、承認責任者は承認を行う。
Build: 承認が完了すれば、サイトのアーティファクトをビルドする。
Acceptance: そのアーティファクトを承認ステージにデプロイする。その環境内で実際にサイトが完成しているかどうかをチェックする。
続いて、Union、Rehearsal, Deliveryという3つのステージを経て、サイトがライブになる。
実際のデモ
承認をまだ受けていない、変更要求の内容をリストアップする。
ランディングページに関わるモジュールのリストを表示。
その中である特定のモジュールを選択し、コード内容を表示する。
承認後は、ビルドを作成し、実際のプロダクションのサイトにデプロイする。
成功したことが表示される。
Chef Server 12の発表
今回のリリースも、すべての機能がオープンソースとして提供される。
Chefコミュニティは非常に成長しており、Chef自体における変更もかなりの部分がコミュニティの要求によるもの
Chef Supermarket:コミュニティのCookbookサイトのデザインもかなりコミュニティからの意見を取り入れて設計
Policy File機能:
システム全体のワークフローにフォーカスを置くことができるように配慮。Cookbookバージョンの指定、Run Listに適用すべきRecipeの指定、等を規定するのがPolicy File。
そのPolicy Fileもアップロードすると、プロダクションサイトに於いても全く同じPolicy Fileを適用保証することが可能
Audit Mode:
Chefクライアント内で、モジュールをテスト運用することができる機能。きめ細かい品質保証を開発段階で徹底したいときに使える。
Test Kitchen:
ChefDKと直接統合されている。
様々なクラウド環境で動く:AWS EC2, Docker, Azure, Vagrant, etc...
テスト環境の自動化ツール
Windows上でも実装されている。
Powershell DSC:
DSC = Desired State Configuration
MS社はかなりの開発を行っていて、Windows環境上でもChefをかなり使える環境が出来上がっている
Chef Provisioning:
昨年リリースされたが、今回のリリースでHW, Network, Softwareを含めた、システム全体の設定情報管理と自動化を行えるようになった
Build Cookbook:
プロジェクトのビルド/テスト/デプロイの手順の詳細を規定するツール。
Chef リソースを使って記述する。
Chef自身が提供するCookbookのライブラリもあり、オープンソースとして提供されている。
DeliveryのCLIとDelivery-Truckはすでに提供開始
Early Access Programも提供されている。
Chefのプラットホームについての整理
4つのコンポーネントが提供されている。
Chef DK: ローカルでアプリを開発する環境を提供
Chef Delivery: ローカルの開発からシステム全体のプロダクション運用へのフローを管理
Chef Server: 開発したアプリケーションのプロダクション運用を支援
Chef Analytics: コードの分析を行うツール
Chef Analytics:
コンプライアンスも含めた、分析機能を提供するツールとして、DevOps全体のワークフローをカバーする。
コードに対する変更履歴を管理し、全体的な管理ができる。
Chef Splunk App:
Chef Analyticsは他の既存の3rdパーティとの統合も行っている。
今回発表されるのは、Splunkとの統合:Chefの収集したデータをSplunkに引き渡し、Splunkを通して分析を行う事ができる。