PaaS勉強会番外編に行ってきた〜 Cloud Foundry / Lattice Deep Talks #paasjp

PaaS 勉強会番外編に行ってきました。

PaaS とそれほど近い立ち位置にいるわけではないのですが、最近ときどき話題に上る Cloud Foundry / Lattice についての深い話題が聞けるということで、興味があって参加しました。
Cloud Foundry は国内で使っている事例をほぼ聞いたことがなかったので、どこか謎に包まれているイメージがありました。

Lattice という、Cloud Foundry が提供する次世代のコンテナベースの PaaS の発表が記憶に新しいのですが、自分の中では下のツイートで注目度が高まりました。

The 'war' on PaaS is almost over, CloudFoundry won, just quite a number of people are denial.
— Simon Wardley (@swardley) 2014年10月30日

PaaS 市場の勝者については諸説あると思いますが、Cloud Foundry Foundationの創立*1もあり、Cloud Foundry が最も大きな成功に近い位置にあるような気がしないでもないです。

以下、発表内容のメモになります。
まだ上がっていない資料もあるようですが、捕捉したら追加します。

Lattice の深掘り話

@jacopen さん

Lattice深掘り話 from Kazuto Kusama

Lattice とは http://lattice.cf/
- コンテナ管理システム
  - スケジューリング
  - 動的ルーティング
  - 死活監視, ログ収集
- Docker image 互換
- 次期 Cloud Foundry のサブセット
CF と Lattice の関係
- Lattice
  - cell
    - コンテナ動かす仕組み
  - brain
    - スケジューリングの仕組み
- CF
  - Lattice + PaaS に必要な機能:
    - API の提供
    - マルチテナント機能(ユーザ管理・認証)
    - アプリケーションのライフサイクル管理
    - その他 PaaS に必要な機能
DEMO
- GCE 上に Lattice 構築済み
- ltc ... Lattice の CLI
  - ltc create/remove ... コンテナ作成・削除
    - ltc create lattice-app cloudfoundry/lattice-app
  - ltc scale lattice-app 3 ... コンテナが3つに増える
    - ルータの配下に増やしたコンテナを置いて、rr してくれる
    - ltc scale lattice-app 1 で減る(元に戻る)
  - ltc create nginx library/nginx -p 80 -r
    - Nginx のコンテナ起動
  - ltc ビジュアライズ ... コンテナの配置状況を視覚化する CLI
  - xip.io ドメイン
    - 同じ IP アドレスの同じポートだけど、Host 名ベースでリクエストを適切なコンテナに振り分けてくれる
- インスタンスの突然死
  - => コンテナを自動再起動してくれる
DEMO 解説
- 動的ルーティング
  - URLベースでリクエストを適切なコンテナに振り分けてくれる
- 死活監視 => 復活
Kubernetes との比較
- Kubernetes の特徴
  - Docker コンテナをマルチポストで管理
  - Pod, Service, Replication Controller
- Lattice の特徴
  - Webアプリを動かすコンテナをマルチポストで管理
  - Docker image にも対応
    - garden というのを使ってる。
    - Linux の namespace 機能 ... Lattice コンテナは名前空間が別
      - ls -al /proc/$pid/ns/
  - コンテナのアクセスは HTTP のみ
garden とは
- Pluggable なコンテナのバックエンドを実現する仕組み
- Cell の中身
  - rep ... コンテナを動かすためのオークションに参加
  - exector ... rep からのコンテナ起動・削除指示を受け取る
  - garden ... 実際にコンテナ動かすバックエンド
- exector-garden 間はインタフェースが定められている
  - インタフェースを満たしていればバックエンドはさまざまな実装が可能
    - garden-backend
  - 標準の garden-linux は Docker image 対応
  - Windows や rkt にも将来的に対応するかも
なぜ Docker を直接バックエンドにせず、Pluggalbe な仕組みにしたのか？
- 歴史的経緯
- 元々 CF は Warden という独自のコンテナでアプリを動かしていた
- garden は warden 互換の Golang 実装
Dynamic Routing
- gorouter がアプリの情報を持ってないといけない
  - Cell から etcd に集約されてる
    - Route Emitter
      - NATS に情報を投げる
  - NATS から情報を取得
なぜ etcd から直 gorouter ではないのか？
- 歴史的経緯
- gorouter は元々 CF 向け
- CF が NATS 経由で疎結合に結びつくアーキテクチャ
Lattice の基本構造
- brain
  - gorouter
  - route-emitter
- Cell
- 大事なのは etcd
  - Cell のプロセスが etcd から情報を読み取る
    - rep
    - auctioneer ... 動かす必要のある...
    - converger ... 動作中のコンテナが正しい数存在するか
- Consul も活用している
  - 複数同時に動いては困る
    - コンポーネントのロック
    - converger が同時に2つ動くと2つコンテナが立ち上がる
- 結構複雑
- 歴史的経緯がある。。
Q&A

質疑では、「ユーザが使うのは簡単そうだが、Lattice を運用するのは大変じゃないのか？」と率直に聞いてみました。
答えは「Yes」で、実際に Cloud Foundry を運用していて難しいところがあると伺いました。
Lattice も同様の難点が出そうとのこと。

BOSHでCFとDiegoを一体デプロイした件について

@kenojiri さん

http://gistdeck.github.io/ozzozz/1d5567246995c3ac422e

スライドが gistdeck ... gist をスライド化してるっぽい
自己紹介 @kenojiri さん
- 日本 Cloud Foundry グループ4代目会長
はじめに
- BOSH
  - とっつきにくいと評判のご存知 Cloud Foundry の標準的デプロイツール
- CF ... 最近は Cloud Foundry Elastic Runtime と呼ばれてるとか
- Diego
  - Cloud Foundry の次期アーキテクチャの総称 "CFv3"
- 一体デプロイ
  - できるはず・・・！
できた
- bosh vms => 14個 VM デプロイ
使った IaaS 環境とバージョン
- AWS VPC
  - Tokyo Region
  - VPC x 1, subnet x 1, Security Group x 2, Elastic IP x 2
- cf-release - v207
- diego-release - v0.1099.0
- bosh - v162(1.2962.0)
- bosh-aws-cpi-release - v7
- stemcell - bosh-aws-xen-hvm-ubuntu-trusty-go_agent v2968
DEMO
- 普通にサンプルアプリを push
  - cf api => endpoint 表示
  - cf target
  - cf push dora => デプロイ
- Diego にデプロイ(diedora という名前のアプリとする)
  - プラグインインストールが必要
  - cf enable-diego diedora
  - cf start diedora
    - Downloading ...buildpack ...
- Diego に Docker イメージをデプロイ
  - cf docker-push ...
  - インスタンス増やすこともできる
どうやってデプロイするの？
- AWSにVPC,subnet,SG,EIPを確保(by GUI)
- bosh-init を使って AWS に MicroBOSH VM をデプロイ
- bosh_cli を使って stemcell と release 2個をアップロード
- CF+Diego 一体デプロイ用の deployment manifest ファイルを準備
  - これが一番重要
- bosh_cli でデプロイ
全体構成
- CF + Diego の全体図
- コンテナは dea OR garden で動く
特にハマったところ
- cf-release, diego-release のバージョン整合性を取らないといけない
- consul を使わないといけない
- etcd を CF / Diego 用で分けないといけない
結局、何がうれしいのか？
- CFv2 => CFv3 へのスムーズな移行が可能
  - ccの設定を変えればアプリのデフォルト配置先が DEA から Diego Cell に変わる
- ユーザが CLI plugin 入れるだけで Docker イメージも push 可能に

CF CLI pluginについて

@morika-t さん

※ https://www.slideshare.net/morika_t/cloud-foundry-cli-plugin の退避先↑

自己紹介
- Cloud Foundry 関連の業務
Agenda
- CLI Plugin とは
  - 特長
    - cf コマンドのさぶこまんどのように使える
  - go版の cf コマンド v6.7 から使用可能
  - CLI 同様、Golang で実装
- Plugin の入手と削除
Install plugin
- cf install-plugin hoge
- go get github.com/
Uninstall plugin
- cf uninstall-plugin hoge
community plugin を使う
- URL を CF コマンドに登録
  - cf add-plugin-repo community http://plugins.cfapps.io/
- リストから探す
- cf install-plugin Console -r community
community plugin ざっくり紹介
- CLI-Recorder v1.0.1
- Live Stats
  - localhost:8080 で HTTPserver を立ち上げ内部的には stats 相当を叩く
- Console
  - cloudfoundry-tmate-buildpack, cf-ssh と同じように tmate 経由でコンテナにアクセスするプラグイン
- Diego-Beta
- Open ... アプリのURLをブラウザで開く
- autopilot
  - app の旧バージョン manifest と新バージョン manifest を指定し、ダウンタイムゼロで app を新バージョンに移行する plugin
- Brooklyn
- cf-plugin-kibana-me-logs
  - Docker/Logstash Service Broker を使って log を kibana 経由で確認するためのプラグイン
- Buildpack Usage
- CF App Stack Changer
- Targets
  - CF_HOME を利用して複数環境のtarget情報を管理するplugin
- cf-download
cf tree 作ってみた
- cf files 相当を内部的に再帰的に呼び出し、ツリー表示
CLI Plugin を作るための知識
- 最初に参考になるのは plugin_examples/call_cli_cmd
- GetMetadata() を定義
- Run() 部分で実際に処理を行う
Plugin化のメリット・デメリット
- メリット: 独立して開発できる
- デメリット: バージョンの紐付けが必要になりそう

今後CFに追加されそうな機能について

@nota-ja さん

http://gistdeck.github.io/nota-ja/13a553a79a814583cff0

Agenda
- Cloud Foundry Design Document
  - これを見ると提案されてる機能がわかる
- Features Being Proposed (提案されている機能)
  - Context Path Routing
    - URL パスを使ってルーティングする
  - Event Notification
    - あるイベントが来たら通知する
    - NOT CF Notification Service
  - Route Service
  - CF Route API
  - ALM and CI Integration
    - Application Lifecycle Management
  - High Availability Policies
    - アプリを複数 AZ に効率よく配置しよう
    - シンプル
    - 無視されてる => 後述
  - Cloud Foundry Placement Pools
    - HA Policies と同じようなことを実現する
    - 複雑
  - Mapping Buildpack dependencies
    - buildpack の依存関係を機械的にわかるように