- http://kokucheese.com/event/index/128799/
- 2013-12-04 19:00-21:35
- IDCフロンティア本社セミナールーム
- 申込者数 130/160
- Togetter http://togetter.com/li/599044
TODO スライドなどへのリンク追加
CUPA 荒井さん
- 一般社団法人クラウド利用促進機構の紹介
Canonical 松本さん
- 課題
- 開発もテストも本番も反復作業
- 工程の間にハンドアウトがあるために遅くなる
- 開発はラップトップでテストはクラウドで本番は実マシンだったりして環境が異なりうる
- Juju
- 会場では名前を知っているのは3割、使ったことがある人は0
- サービスオーケストレーションツール
- Charm
- サービスをデプロイするもの
- レシピに相当
- MAAS
- 物理サーバのプロビジョニングツール
- デモ
- MAAS で物理サーバに Ubuntu をプロビジョニングし Juju で OpenStack をインストール
- チャームを寄せ集めたバンドルを使うと複数ノードのシステムが一発で出来上がる
- 質疑: Juju を使っているお客さんは
- まだあまりいないがエコシステムは広がりつつある
- Landscape
- サーバのモニタリングやスクリプト実行ができる
- 質疑: MAAS がどうやってハードを選ぶのか、デモではどのハードかを選んでいないように見えた
- コマンドラインではメモリサイズの要求などを指定できる
日立ソリューションズ 喜納さん
- 課題
- 大規模環境構築では単調な繰り返し作業や待ち時間が発生する
- Chef の概要
- システム自動構築のためのフレームワーク
- システムの状態をコードで管理する仕組みを提供
- レシピ
- Ruby の内部DSLにより順序立てて記載
- 適用先環境と記述内容の差分を見て適用してくれる
- 今年の Chef を振り返る
- 0204 Chef 11 リリース
- 0219 AWS が OpsWorks を発表
- 0424 Chef Conf 2013 で IBM や Microsoft と協業と発表
-
IDCフロンティア 梶川さん
-
Scalr
- マルチクラウド管理ツール
- 類似のものは RightScale や enstratus
- Scalrの紹介は第一回でやったので SlideShare 参照
-
OSS版 Scalr のインストール手順を紹介
-
使ってみよう
- OSS 版と Hosted 版では Hosted 版のほうが機能が多い
- 次期の OSS 版では追加されるはず
-
質疑: ホワイトリストとは何か
- インストールしたときのIDをホワイトリストに登録すると Scalr 社が管理しているテンプレートが利用できる
-
リンク at+link事業部 前佛さん
-
10分のことを忘れてスライド94枚
-
Serf
- 汎用オーケストレーションツール
- Immutable Infrastructure
-
イベントハンドラ
- member-join, member-leave, member-failed, user の4つのみ
-
メンバシップ
- ゴシッププロトコル
-
IIJ 斉藤さん
-
Ansible
- OS、ミドルウェア、アプリケーションのインストール・設定を Playbook としてまとめてワンアクションで実行
- プッシュ型でエージェントレス
- SSH でログインできればよい
- Puppet, Chef, Capistrano と同じレイヤー
-
構成要素
- Module: サービスの起動停止などの作業をつかさどる
- Playbook: module の一連の流れをまとめたもの
- Plugin: module の実行失敗時の callback など
- Inventory: 操作対象ノードリスト
-
インストール
- Ubuntu にも入っているが古いので GitHub から取ってくるほうがいい
-
モジュール実行の仕組み
- ホストでコード生成
- ターゲットに sftp
- ターゲットに ssh で実行
- ターゲットからファイル削除
-
ターゲットに python 実行系を持たない場合、ルータなど
- ホストでコード生成
- ホストで実行
- その実行の中でターゲットを操作
- ホストからファイル削除
-
Playbook
- Chef でいう cookbook
- YAML でモジュールとパラメータを列挙する
- Chef でいう notification の仕組みもある
-
質疑: クライアントの負荷
- ターゲットでSSHで実行するだけなので、モジュールしだい
- ターゲットが増えるとホストの負荷が増えるので Chef Server のほうがエレガント
-
サイバーエージェント 長谷部さん
-
方向転換
- 旧題: Chef が社内で浸透するまで
- 普通に Chef を使っているだけで面白いことをしていなかった
-
プライベートクラウド開発の背景
- データセンターが点在
- 物理サーバの提供リードタイム
-
構築
- DRを考慮せずにDCを統一しプライベートクラウドを構築することにした
- 当初 OpenStack ベースで設計していたが自作ツールがシンプルでよかったので変更
- 5000VM くらいが稼働
-
Clover の特徴
- シンプル
- libvirt で管理し libvirtd を除いてエージェントレス
- デフォルト IPv6
- VLAN 内のIPアドレス数の制限がない
- Router Advertisement でIPアドレス自動配布
- 毎回 kickstart でOSインストール
- 統合イメージ置き場が必要ない
- 物理サーバと仮想サーバも共通の手順で構築できる
- シンプル
-
アーキテクチャ
- Python, Django, KVM
-
実装済み機能
- DNS管理: サーバ構築と同時にレコード登録
- 物理サーバ管理: ラッキング、配線、電源ON、pxeでSystemRescurCd、ohai実行でCloverに通知、OSインストール
- 仮想サーバ: サーバ情報入力、作成、起動、OSインストール
- スイッチ管理: 配線にルールを設けている
-
課題
- 機能が少ない
- セキュリティグループ、仮想サーバリソース制限
- Clover が1台のサーバで動いていてコンポーネントわけができていない
- 機能が少ない
-
こぼれ話
- AWS, OpenStack, CloudStack の開発スピードが速すぎる
- 今でも OpenStack にしたほうがよかったかも
-
今後
- まだ IaaS の基本機能のみ
- サービス品質の向上や PaaS, SaaS へのシフト
- インフラエンジニアがいなくなるようなシステム
- AWS の機能をまねていこうとしている
- 速度のためにコンテナベースにしたい
- オープンソースで公開する予定