本を読む

読書やコンピュータなどに関するメモ

「クラウドマネジメントツール勉強会 第2回」に行ってきた

 オープンクラウドキャンパス/クラウド運用管理研究会が主催する「クラウドマネジメントツール勉強会 第2回」に行ってきました。

 今回は、ChefやAnsibleのような構成管理ツールから、ScalrやSerf、Juju + MAASのようなクラウドマネジメントツールまでの発表がありました。特にOpenStackとからめながら、それらの入門的な話が中心で、どれがどの領域をカバーしているのかなどについて私のような素人が知るのにちょうどよかったと思います。

 以下、メモほぼそのまま。

挨拶、CUPA&クラウド運用管理研究会紹介(CUPA 荒井さん)

  • 一般社団法人クラウド利用促進機構の紹介
    • ユーザ会いろいろ
  • クラウドマネジメントツール
  • 構成管理ツール

Juju + MaaS + Landscape(Canonical 松本さん)

  • CanonicalでUbuntuのプリセールス
  • Canonical
    • コンサル、ソリューションのサポート
    • まだ東京オフィスない
    • メンバー募集中
  • DevOps
    • 反復作業
    • dev・test・run
      • 間でhandoverが発生
      • プラットフォームが違う
  • Juju
    • 触ったことある人 →いないw(emasaka注:実は試した程度ならある)
    • パブリッククラウドでやってみるのが簡単
    • 構成が決まればコマンド一発で
    • サービスオーケストレーションツール
  • エコシステムがけっこう充実
    • OpenStack SummitでMark Shuttleworthがプレゼン
      • OpenStackには選択肢があって組みあわせになる
      • 検証ラボを立ちあげ
  • Charm
    • サービスをデプロイする
    • どんな言語でも
  • Web GUIでドラッグ&ドロップ
  • Juju側でインテグレーション
  • コマンドラインも
  • MAAS
    • 物理マシンのプロビジョニング
    • 物理サーバーのひとつ上にAPI
  • Juju & MAASでできること
    • MAASでOSのレイヤーをプロビジョニング
    • その上でJujuでOpenStackをデプロイ
  • juju bundle:必要な組み合わせや設定をまとめて一度にデプロイするもの
  • 複数のマシンからなるOpenStack環境を一発で
    • 14台の物理マシンの例
  • OpenStack以外のjuju bundleも
    • WordPressなど
  • Q: Jujuの対象
    • A: OpenStackをデプロイする人
  • Q: 限られるのでは。クラウドサービスプロバイダーのユーザーに使わせるとか
    • A: それはサービスプロバイダーの関係で。もともとはEC2上のデプロイ用に始まった
  • landscape
    • 管理ツール
      • 監視
      • パッケージ管理

自動構築フレームワークChefについて話そう!(日立ソリューションズ 喜納さん)

  • システム構築における課題
    • 大規模クラウド基盤の構築
    • 単調な作業の暮り返し、待ち時間
      • 人手ではミスの元
    • 自動化
  • Chef
    • システム自動構築のフレームワーク
    • コードで表現して管理する
      • 手順書ではない
    • 処理ではなく状態を書く
      • 複数サーバーの構成を集約できる
  • 導入効果
    • 自動構築によるコスト削減
    • 設定変更の自動化による運用コスト削減
    • オペレーションの可視化(セキュリティ、コンプライアンス)
  • ユーザー
    • クラウドサービスが多い
  • アーキテクチャ
    • レシピとプログラムを各マシンに配置して構築
    • クライアントサーバー:Chefサーバーでレシピを一括管理
    • スタンドアロン(CHef Solo)
  • レシピ
    • RubyのDSL
    • 環境の状態と比較して、状態が違うものだけ実行
  • プラットフォーム
    • Linux系
    • 最近はWindowsも
  • OSのインストールなどは対象外
    • そのへんはネットブート + Kicksartなど
      • Chefのインストールも
  • Chefのインストール
    • Omnibusインストーラ
      • コマンド3つ
      • /opt下
  • 今年のChefをふり返る
  • 2月
    • Chef 11
      • 内部も大幅に変更
    • Facebookが採用
    • AWSがOpsWorks
  • 3月
    • 書籍「入門Chef Solo」で、Chefという言葉がよく聞かれるように
  • 8月
    • Enterprise Chef ←Private ChefとHosted Chef
  • メールの流量:コンスタントに
    • できごとの少し後に盛り上がる?
  • Ohloh(OSSプロジェクトの活動状況統計)
    • Chefはvery active
    • コード量:増加。Chef 11でリファクタリングされていちど減る?

Scalr (IDCフロンティア 梶川さん)

  • Scalr
    • マルチクラウド管理ツール
    • デザイン、プロビジョニング、運用
    • RightScale、Enstratius(enStratus)あたり
    • パブリッククラウド、プライベートクラウド
  • 詳しいことは第1回の資料で
  • ホステット版は30日フリー
  • OSS版のインストール
    • ちょっと前は公式サイトにも説明があまりなかった
      • 今はWikiに
    • CentOS 6.4 + EPEL + REMI
      • PHP 5.4以降が推奨されるためREMI
    • ほぼPHP、cronでキックされるものがPython
    • Apahe httpd
      • HTTPSで
    • rrdtool
      • rrdacheを使うので新しめのものを(ここではソースから)
    • セットアップ用pythonスクリプトを実行するとrpmが
    • IDCFクラウドのエンドポイント設定が間違っているので修正
    • YAMLで設定(4.4ぐらいから)
      • PHPによる設定ファイルにも書くところがあるので注意
    • DNSの管理:bindで
    • Webの設定→MySQL→cronから呼ばれるツールが実際の処理
    • Shared Role:テンプレート
      • 4.4からはホワイトリストの登録が必要
    • adminでログインしてユーザー作成
    • あとはいつものScalr
      • ホステット版のほうがインプリ先
    • Connection Endpointは無理
    • IDCFクラウドでは同じアカウントで同じDCの管理はできない
  • Q: ホワイトリスト詳しく
    • A: IDを登録
  • Q: テンプレートとは
    • A: 各サービスのテンプレート

Serf (at+link 前佛さん)

  • スライド96枚を10分でw
  • Serf
    • 汎用オーケストレーションツール
    • 簡単
  • やった
    • serf-wall:wallコマンドで通知
    • serf-raspi-notice
    • serf-munin
  • 農業の自動化?
  • 背景
    • Immutable Infrastracture
  • イベントハンドラ
    • 4種類だけ。楽
  • バイナリ1個。軽量
  • membership
    • ノード間で通信するとき
    • joinして認識
    • ノードのダウンも認識
  • serf-wall
    • wallコマンドを発行
    • ニセshutdown
  • serf-raspi-notice
    • ネットワークにつないだときに通知
  • serf-munin
    • Serfでmunin設定を生成
    • サーバーがぽこぽこ増えたとき

Ansible QuickStart (IIJ 斎藤さん)

  • Ansible
    • Python製
    • まとまった作業を自動化(Chef、Puppet…といっしょ)
    • push型でエージェントレス
      • 操作対象にエージェントを入れなくてはならいことはほぼない
      • ここがいちばん重要
    • 歴史が浅いぶん、小さい
      • 自分で手を入れやすい
    • 日本語のまとまった資料はない
      • まとまった資料は英語でもあまりない
  • 手順ベースの自動化ツールのひとつ
  • Capistranoぐらいの手軽さ
  • パラレルsshに羃等性がついたぐらいのところから
  • module
    • 言語は問わない
  • playbook
    • moduleを集めて仕事をさせる
    • Chefでいうcookbook
    • YAML形式
  • plugin
    • moduleが成功したときのnotifyなど
  • inventory
    • hosts
  • Ubuntu 12.04 ltsで
    • パッケージだとAnsible 1.1
      • OpenStackのモジュールが入っていない
    • pipで(virtualenv環境に)
  • インベントリファイルを作成
  • pingモジュールで動作確認
  • setupモジュールでサーバー環境を取得
    • 環境変数に
    • yumとaptの違いを分ける、などのとき
  • APIも
    • PythonコードでAnsibleを使うことも
    • serverspecみたいなのを誰か作らないかな
  • 仕組み
    • Pythonコードを生成してscpで送り込んで実行
      • 最後に削除
    • SELinuxの操作など、設定先にライブラリが必要な場合も
    • スイッチの設定などPython処理系を持たない場合
      • ローカルでPythonスクリプトを実行してリモートを操作
  • Ansible 1.3のOpenStackモジュールはだいぶ中をいじらないと使えなかった
  • Packagingモジュールではpipやvirtualenvにも対応
  • Q: 実行順序は?
  • A: 書いた順
  • Q: クライアントの負荷は?
  • A: それほど。モジュールしだい
  • Q: 台数が増えるとクライアントの負荷が増える?
  • A: はい

Chefが社内で浸透するまで+今後の目標(サイバーエージェント 長谷部さん)

  • Chefはお腹いっぱいですよね?
  • プライベートクラウド開発の話に
  • 背景
    • 複数DC点在
    • 物理サーバーでサービス→提供リードタイム
  • 1つのDCに統一してプライベートクラウドに
  • 2013年2月リリース
  • 設計からOpenStack前提で考えた
  • 自作ツールも並行して開発、そちらに切りかえ
    • プライベート管理システム「Clover」
  • Cloverの特徴
    • シンプル
      • libvirtが動いていればエージェントレス
      • 自社要件の機能のみ実装
    • デフォルトIPv6
      • 1VLAN内のIPアドレス数制限
      • RAでアドレスを配布
    • 毎回OSインストール
      • 統合イメージ置き場を必要としない
      • kickstartで管理
    • 物理サーバーと仮想サーバー
      • kickstartで
      • PXEブート
  • アーキテクチャ
    • Python
    • Django
    • libivirt、PostgreSQL、bind、dhcpd…
    • KVM限定
    • WebとRESTのインターフェイス
  • PXEブートしたインストールイメージからohaiを実行して情報を取得しCloverに登録
  • ラックのスイッチ接続ルールでサーバーを対応
  • 課題
    • すべてサーバー1台、蜜結合
    • UI
  • AWS、OpenStack、CloudStackなど、開発速すぎ
    • Cloverを開発した当時はOpenStackはまだ
  • 今後
    • 最終的にはPaaS/SaaS機能の開発にシフト
    • キーワード:
      • OpsWorks、RDS、統合管理…
      • Docker
  • オープンソースで公開する予定

コメント

コメントの投稿

管理者にだけ表示を許可する

トラックバック

http://emasaka.blog65.fc2.com/tb.php/1187-4844c2fd

 | HOME | 

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly


FC2Ad