先日開催されたJAWS FESTA Kansai 2013に、アンカンファンレンスのモデレータとして参加してきました。

※本エントリの写真はスタッフの山崎誠さん提供の共有資産を使わせていただきました、ありがとうございます。

イベント全体については参加者の方による各方面のエントリを参照いただければ様子がわかるかと思いますのでお任せして、モデレータを務めた『Chef Casual Talks ドーム公演 – クラウド時代の構成管理 -』についてレポートにまとめます。

Chef Casual Talks ドーム公演 – クラウド時代の構成管理 –

遅番アンカンファレンスの１区画として参加者４名、モデレータ１名の計５名で行いました。

結論は表計算ソフトに構成を転記するのは限界、ChefServer/Clientなどのツールで構成管理＆サーバ構築の自動化を図り、同時にCIツール・テストツールの活用で安全性や俊敏性を高めていこう。

と、システムのライフサイクル・運用監視を見据えたトータルな構成管理を効率よく行いましょうと、参加者全員が良い感じの方に向けたセッションになったかと思います。

率直な感想ですが、この調子ならInfrastructure as Codeの実践はすぐに広まるのではないでしょうか。

以降はモデレータとして進行中の感想とメモ程度の議事録です、内容等に共感する点などありましたら是非次回のChef Casual Talksにご参加お願いします。

概要(LT)

まずLTを行い、アンカンファレンスで話し合いたいテーマについて発表しました。

それぞれの詳細はこのような感じです。

コンピュータシステムにはライフサイクルがあります。それを円滑に管理するためにはシステムを効果的に構成管理しておく必要があります。

２，３台のサーバならまだしも、それが数多くなってくると何かしらのツールがなければやってられません。 もちろんそのためにハードベンダは古くから構成管理に注力しています、IBM Tivoli, HP OpenView, Hitachi JP1など。 そして表計算ツール！

ハードを買って、お金を出して、キッチリと構成管理をしていくというのはシステムの安定稼働に欠かせない要素でした。

しかし、クラウドではどうでしょうか。御存知の通りAWSではサーバというのはインスタンスです、ボタンひとつでポチッと起動して廃棄も一瞬です。 いまは コンピュータのリソースを確保するということは、自動販売機で水を買ってくるのと変わらない手間で行えます。

そしてInfrastructure as Codeという概念、これと高いツールがマッチするか。

じゃあ、構成管理どうするん？ということでこのようなテーマでディスカッションしたいです。

• 昔はこうだった
• 今はこう変えた、変わってない
• そもそもやらなくていい
• 今昔 良い点 悪い点
• 理想の未来

アンカンファレンス(今/昔どうしています？)

前フリでエンタープライズ色満々のプロダクトを例に出しましたが、さすがにこういったもの(※使いこなすの大変！)を有効に利用されている所がAWSのユーザーイベント、ひいてはOpscode Chefやはあまり興味ないだろうなと。
ただ管理厨の私としては外せないところでしたのであえて出してみました。MicrosoftのADやSMSもキッチリできてますよね。

まずはざっくりと、『最近どうやってます？』をいろいろな角度から参加者にアンケートしてみました、票数は複数投票を含み、分類なども結構いい加減な集計ですのでご参考まで。

* 自前で管理しているサーバの構成管理はどうしてますか *

• Microsoft Excel 4.5票

他にも構成図にCacooなどが上げられました。

Microsoft Excel、貫禄の1強です。サーバの構成情報を結構細かいところまでExcelの表に記載して更新しているという方も。

* サーバはよくどこに作っていますか *

• AWS 3票
• 自社iDC 2票
• 自社iDC VMware(VCenter)のプライベートクラウド環境 1票

パブリッククラウドはAWS、他は自社管理環境のiDCにサーバ。

* 環境の規模はどのくらいですか *

• 10-50台 2票
• 50-100台 2票
• 数百台 2票

システムによって違うため、本当に参考ですが。ちなみに台数が多い場合もExcel強し。

* サーバの構築は主にどうしていますか *

• ほぼ手動 3票
• 自作スクリプト 2.5票
• AMIにしている 1票
• ChefSolo 1票

スクリプトで自動化

* サーバの構築の手順書はどうしていますか *

• 構成管理のMicrosoft Excelにて一緒に記載 3票？

Excelからコピーペーストで、多数でした。Wordも使われているのは聞きますが、それよりは文字化けしづらい分マシなのかも。

* サーバの更新まわりの管理はどうしていますか *

• AMIにしている 1票
• 手作業 1票
• Chef-Solo(Why-Run併用) 1票

ご意見集

• Excelしんどい
• 私もです
• Excelなどでは最新に保つのが大変、棚卸しも
• AMIは構築が楽になるが、更新時がややヘビー
• Chefの質問ができると聞いて来ました
• 私もです

この辺りでアンカンファンレンスの方向性が固まった感じです。

ChefServerってなんでしょうか

さてChefの話題を振られる格好になったのですがその前にChefに関するアンケートを取ってみました。

* Opscode Chefを使ったことがありますか *

• VagrantでChefSoloしてみた 2票
• 最近ChefSoloを導入した 1票

* 入門Chef Solo 持ってますか *

• 持っている (参加者全員)
• むしろ読みながらVagrantでChefSoloしてみた

入門Chef Solo – Infrastructure as Code

さすが。ですがChefServerについてはみなさん未知数だということでしたのでさらっと説明。

Ohai知ってますか？

• サーバ情報を収集します
• ChefSoloではClient実行時のみ利用されて、使い捨てです
• OSのかなり細かいところまでJSON形式で一定の構造にします
  • 収集する情報はインフラ系エンジニア垂涎もの

   

• 自分で収集する情報を拡張しやすい

ChefServerの構成管理

• Ohaiで収集した情報をNode(管理対象のサーバ)が全部送ってくれる
• クエリ可能、エクスポート可能
• 管理下ノード達は互いの情報を利用できる
• Clientはレシピでサーバ状態を収束させる

と、実際のChefServerにログインしたり、管理中システムでの使い方を交えながら説明。Ohaiの収集する情報については『まさにExcelでそれを記述して管理している』という声も上がりました。

Opscode Chef感想質問疑問集

以降しばらくChefの話でした。質問した人、回答した人は参加者のいずれかなので箇条書きで覚えている範囲を。微妙に補足も入っているかも。

• Q. ソースからインストールするなど、Chefで用意されていない手順を書くレシピが大変
  • 特にソースを使う理由がなくパッケージでも十分な場合はそのほうが楽。
  • コツを掴めば大丈夫、冪等性。バージョンをOhaiで収集できるようにするときれいなレシピに。

   

• Q. Ruby詳しい方がよさそうな印象
  • レシピを書くのに慣れてきたら、いつのまにかそこそこ身につきます

   

• Q. OSS版のChefServerはインストールが入れるのが大変そう
  • 11くらいから簡単に、ワンライナーでパッケージが導入できるようになっています
  • 実はパッケージではCookbookがインストールされて、ラッパーコマンドでChefServerがChefSoloによってセットアップされます

   

• Q. ChefServerってGUIあるんですね
  • ありますよ、結構見やすいです

   

• Q. ChefServerポート沢山あいてませんか？
  • 色々ミドルウェアが上がってますが、HTTP(S) APIのポートが空いていればOK

   

• Q. ChefClient側はどうですか
  • Cron等で実行されて取りに行くので特に空いてなくて良い
  • sshが最低空いていればknifeから操作できる

   

参加者さんの間では、『だいたい触ったし、便利そうと思うけどまだ本格的に導入には至ってない、でもやったほうがいいとなんとなく思う。』という感じがありました。
今回の参加者数は多いとは言えないですが、その分じっくりと意見を伺うことができました、業界でも全体的にこんな感じなのかなと。

アプリケーションのデプロイはどうやっていますか

ここらで情報の集約の話は十分になってきたので、話題をInfrastructure as Code方面に徐々に持って行くことにしました。

• スクリプト
• Capistrano
• 手

自社サービスで開発しているアプリケーションのデプロイとバージョン更新も構成管理の重要要素です、このあとのCIの話にも関わってきますね。

実はChefでもDeployリソースで可能なのですが、結構熟練の技がいるのであまり流行らない感じです。デフォルトではRails向けで、Engine YardやOpsWorksなどのアプリケーションのデプロイはこの機能を使っているようですが。

テストしてますか

• テストらしいものはしていない
• ChefSoloでやる時は事前にWhy-Runを掛ける程度

テストの話は結構皆さん意外そうでした。『serverspecとか？』といいとこ付いてくる方も。

私からはserverspecで受け入れテスト、test-kitchenによる仮想サーバでChefの実行を行うテスト紹介しました。

• serverspec
• test-kitchen
  • 各種Driver(gem)で仮想サーバ実行環境をVagrant,kvm,Openstackなど手元の環境やawsほか各種クラウドでCookbookのテスト
  • 起動・収束・テスト・廃棄

   

更新のレビューはどうですか

• 特に決まってレビューというほど大層なかんじではない
• お客さんによってコード見たい、という場合は実行するコマンドをリストにして提出

インフラがコードであれば、差分レビューもしやすくなります。Chefで構成管理しているサービスでの例を紹介しました。

• Github プルリクエスト上でのコメントレビュー
• test-kitchen等による、テスト環境の更に前での単体テスト

各自で単体テストできれば、インフラといえど検証環境に載せる前に色々なテストをしておくことが出来ますね。
影響範囲もレシピなら把握しやすいというメリットがあります。

CI(Jenkins)使ってますか

これは結構皆さん活用されている感じでした。Jekninsはインフラ系ともかなり相性よいと思います。

• Gitlabと連携して色々やっている
• コードのテストにつかっている
• デプロイに使っている(本番)
• デプロイに使っている(開発)
• 高機能Cronとしてジョブを定期的に実行
• ドキュメントのコンバートなど
• 使っていない
• 基本はスクリプトでジョブ作成

Jenkinsの話で、面白い運用の話がありましたので紹介します。

• AWSにJekninsサーバを置く
• 夜が来たらAMIにジョブを保存して止める
• 朝が来たら起動
• 土日は止まっている
• それによりコスト55%カット！

APIでサーバをインスタンスとして扱えるクラウドならではの操作と節約術だと思います。

あとGitlabが人気でした、Gitも十分に浸透しているようですね。

監視はどうですか

モニタリング・死活監視などによる環境の維持管理も重要なので、アンケートを取ってみました。

• CloudWatch
• 自作スクリプト
• muninでモニタリング + プラグインで閾値監視
• cactiで同上

サーバmunin, スイッチ/ルータcactiはどちらも使いやすくてパフォーマンスモニタリングツールの定番ですね。

AWSにサーバをおいている場合は、CloudWatchのカスタムメトリクスを活用するのがよいようです。監視にサーバを使うのも色々とコストが掛かりますしね。

一応私が死活監視で好んで使うのはこの2つです。

• 外部：nagios
• 内部: monit , m/monitと併用で外部監視も。

特にmonitは完成度と使いやすさの割になんだか知名度が低い気がしています。AWS OpsWorksでも使われていましたし、M/Monitとの組み合わせでクラウドでも管理しやすいし、内部監視系で最もバランスがよいプロダクトだと思っているのですが。
ということで使っていないならmonitもお奨めですよ、としておきました。

最後に

全体的な結論・感想ははじめに書きましたので省略するとして、アンカンファレンスは無事成功したと(個人的に)思いました。とても楽しいイベントでしたJAWS FESTA Kansai 2013。

次回Chef Casuak Talks Kansai をお楽しみに。ちなみに『うちでも開催して欲しい』『HangOutsで参加したい』などのご意見ご要望も随時受け付けていますのでよろしくお願いします。