第27回 PaaS勉強会

  • OpenShift v3 リリース記念
  • PaaSを勉強する会です
    • herku, MS Azure, GCP...
    • PaaSと組み合わせるHashicorp product, CoreOS, Mesos...
  • あるべきPaaSの姿を求めてみんなで調べてみんなでつくってみんなで学ぼう、が主旨です

OpenShiftとScheduler

  • Kenjiro Nakayama
    • RedHat OpenShiftサポートエンジニア
    • Fedor Project パッケージメンテナ
    • Emacsコミッタ

なぜScheduler

  • OpenShiftV3のスケジューラ←k8sのスケジューラと全く同じものが使われています
  • 勉強すると役に立ちます
    • k8sの構造が難しくなっている、結構勉強になります
    • プラガブル
    • 入り口としては良い
  • 個人的にはHOTです
    • Mesosフレームワークとしてk8s on Mesosができるようになります
    • スケジューリング周りが最強になる風潮
    • k8sだけのスケジューラがどんなもんか、まず把握しておくのが重要

OpenShiftとSchedulerの仕組み

  • 今回はJob Schedulerの話ではありません
    • バッチ処理のやつではない
    • 今RHからk8sへJobSchedulerのプロポーザルPRを投げている
  • どのNodeにPodを配置するか
    • CPU/Memoryリソースやポートなどで、ベストフィットするノードを選択

  • OSv3はk8sのSchedulerをそのまま使用

  • oc get node

  • oc create -f hello-pod.json
  • oc get pod --watch
    • Pending状態で１時間待ってしまうことがあります
      • 待ってはいけない
    • oc get event | less
      • Error scheduling: failed to pod
      • 名前は一緒だけど、ポートが被ってる
  • oc delete pod hello-openshift
    • バッティングしてるポートの１つ目を消すと後のがREADYになる

Scheduling Steps

  1. ノードのフィルタ
  2. predicates
    • ≒フィルタ
    • Portが競合するNodeをふるい落とす、要求したリソースの上限を超えるNodeをふるい落とす
  3. ふるい落とされなかったノードにPriorityをつける
  4. 0~10までのスコアを計算、各Priorityの計算で重み付けして、スコアと掛け算させることも可能
  5. 最もフィットしたノードの選択
  6. 同じスコアはランダムに選択

意外と単純な振る舞いに鳴ってますが、Priorityの計算だけ少し複雑

Predicates

  • PodFitsPorts
    • 既存のPodとportが競合しないノードに絞る
  • NoDiskConflick
    • GCEとEBSを使っている場合に、Diskがconflictしないのーどに絞る
    • OSv3は↑２つではまだTechPreview
  • PodFitsResources
    • リクエストしたPodのCPUとMemoryがノードのCapacityを超えていないノードに絞る
  • MatchNodeSelector
    • 指定したSelectorがマッチするノードに絞る
  • HostName
    • Host名の指定が既存のノードのホスト名にマッチしているものに絞る
  • LabelsPresence
    • k8sの機能、ノードのラベルで絞る
  • ServiceAffinity
    • Labelのvalueに関係なく、ラベルの付いているNodeにpodをデプロイ
    • チューニングの腕の見せどころでもある

Priority

  • LeastRequestedPriority
    • 要求されているリソースが最も少ないリソースのノードにデプロイ
  • BalancedResourceAllocation
    • CPUとメモリで偏りがないPodにデプロイ
    • ↑とセットで使うのが吉
  • ServiceSpreadingPriority
    • 同一ノード上に同じサービスが稼働しないように分散させる
  • EqualPriority
    • 基本使わない
    • 指定のないノードを1に
  • LabelPreference
    • ラベルのあるノードにweight分だけscoreを足す
  • ServiceAntiAffinity
    • ServiceAffinity同様、チューニングの腕の見せどころ

Affinty(Zone), Anti-Afinity(Region, Rack)

  • 同じゾーンにしたいけど、リージョンとラックは分けたい場合

Default Schedule Policy

  • ポート害競合しない、リソースがNode上限を超えない、など
  • Affinity周辺は自前でチューニングする必要がありますが、ほっといてもだいたい上手くいきます

Debug in Error

  • SchedulingエラーはPending状態になるので、eventを見て下さい

Resource

  • Nodeを走らせたタイミングでetcdにリソース情報が送られる
    • 完全同期ではない
  • k8sで管理していないリソースは見ていない

Schedulerの苦労

  • なぜ不完全か
  • 計算されるリソースはCPUとMemoryのみ
    • トラフィックやストレージは考慮されていない
    • ↑２つをWeightに加味するのはなかなか大変なので、先送りしてます
    • upstreamで動きはあるので、入ってくるんじゃないかな、というのが個人の見解です
  • OSv3(k8s)で管理しているリソースのみを計算
    • Mesosは他のホストプロセスも考慮するけど、OpenShiftが動いているホストで直接バッチなんかを回すとpodが影響を受けることがある
    • とはいえ、OpenShiftを動かすホストで直接なんかやるのはなにか設計が間違ってるのでは、と思っています

割と新し目のOpenShift Originで作る自宅PaaS作成記

  • 原嘉彦
    • @GORO_Neko
    • 某ITベンダに勤めています
    • 日本OSS推進フォーラム(JOPF)
    • OpenShiftの中の人でも、プロでもありません
  • 一回も組んだことのない人が構築してみる、動かしてみる、というレイヤーです

OpenShift Originの構造

  • Docker + k8s + 何か、でできているPaaSです
  • 4台構成の場合
    • マシン１にOpetShift-master
      • ログインなど
    • マシン２にOpenShift-node
      • インフラ的な役割
      • docker-registryなど
    • マシン３、４にユーザーの使う

構築してみる

  • 構築方法
    1. 1つのDockerコンテナにマスターもノードも構築する
    2. 1つのVM(Vagrant)にマスターもノードも構築する
    3. 別々のマシンにマスターとノードを構築する

  • 今回の環境

  • ソースコードの準備

    • openshift/origin
    • リリース版のバイナリもopetshift/origin/releasesに、現在は1.0.3
  • 起動・ログイン
    • 素のVagrantfileはmemoryが1024
    • RHのガイドラインは最低4GB、8GB以上推奨
    • 開発版は動きが定まってないみたいなので、リリース版が吉です
    • openshift startすると設定ファイル群はカレントディレクトリ以下にできてしまう
      • 環境変数周りはサービス起動のものに準拠、sudo systemctl start openshiftだとトップノード以下に配備される
  • Private Docker Registryのログイン
    • oadm registroyはsu権限で

気になったこと

  • jsonの書き方がよくわからない
    • 何はともあれ公式ドキュメントかー
    • (中の人)ちゃんと使うと実はあんまり書かなくてよいです
      • 古いドキュメントを引きずって書かないといけない雰囲気になってますが、シェルとかでも書けます
  • VagrantでSELinux, firewalldが止まってる
    • 利用する形だった気がするが、まだ未実装の様子
    • (中の人)SELinuxはVagrantのみです、実機はEnforcing、firewalldは未実装でiptablesゴリゴリです
  • 開発が進むほどコマンドが変わる
    • もう少しソフトランディングしてもらえないものだろうか
    • (中の人)他のコマンドとかぶっていた事実がありました、1.0.0以降で変わってたら殴って下さい

OpenShift v3のCIとCD

  • 去年の7月Flynnをベースに開発開始、おそらくDockerベースPaaSでは最速でエンタープライズベースに持っていった

    • 皆さん上から「Docker使え」ってなんか降りてくるようで、今エンタープライズで日本語サポートが有るのはOSだけ、ということらしい

  • Takayoshi Kimura

    • @nekop

  • OPENSHIFTの特徴

    • k8sがスケーリングや障害復旧、B-G Deploymentなど基本的な機能をカバー
    • ドキュメントが古いのを引きずっていて難しく見える
    • OSのデプロイは慣れれば簡単
      • Dockerを知らなくても動かせる
      • プラットフォーム非依存

  • oc

    • oc login
    • oc new-project
    • oc new-app <git clone url>
      • DBなどを使うアプリはテンプレート(長いjson)利用、実は無くてもnew-appを何度か叩けば無くても建てれます
    • oc expose service <service name>
    • http://..

  • 基本的な開発フロー

    • git pushやoc start-buildでビルド指示
    • OpenShiftソースからDocker imageをビルド
    • OpenShiftが自動でデプロイ

  • この流れでどうやってCIを？

    • Jenkinsを使う

      • Docker imageのテストにJenkinsは基本大変
      • Jenkins slaveを混ぜてDocker imageビルド
      • コンテナ内でsshdを建ててslaveをプロビジョニング
      • Jenkinsを使う場合Docker、コンテナの恩恵は受けられないけどOpenShift関係なく普通にOpenShiftの外でJenkinsを使うのが無難
        • CloudBees社が先月、今月にDocker対応/k8s対応を発表しました

    • STIビルドにテストを混ぜる

      • フックスクリプト自体を置き換える必要があります
        • 前処理/後処理フック追加をfeatureでissueがあります
    • fabric8
      • DevOps促進統合プラットフォーム
      • まだあんまり見慣れてないですが、見た目キレイなので統合できたらよさげ

  • OPENSHIFTでCD

    • IMAGESTREAM
      • OSの中で一番わかりづらい概念だと思う
      • Docker imageへの参照、を管理するオブジェクトです
      • IMAGESTREAMのタグ、実際はgitにおけるブランチのようなもので管理

Docker PaaSとしての OpenShift. DEIS, Flynn比較

  • Kazuto Kusama

    • @jacopen

  • Open PaaS

    • 今回話すのはDEISとFlynn
    • OpenShift勉強会でOpenShift以外の話をします

  • OpenShiftのいいところ

    • 進化著しい
      • そもそもk8sの進化が早い
    • github連携、webhookなど、便利な機能が最初から備わっている
      • きれいなGUIがあるのが良い
        • CloudFoundryはありません
    • RH, Google, ...のベンダや開発者が作っている安心感
  • OpenShiftのここがちょっとなー
    • 色濃くk8s、簡単に使えるPaaS、とはちょっと毛色が違いそう
      • デプロイのためにjsonを書かされる
        • 実はYAMLでもシェルでも書けますが
    • CloudFoundryほどエコシステムが広がっていない

DEIS

  • Docker, CoreOSベースのPaaS
  • '13~、OpDemand→EngineYard
  • PaaS、CLIはすごい地味
    • deis create
      • 作られました！超地味！
    • git remoteするとdeisリモートができている
    • git push deis masterでgit経由でデプロイ
      • buildpackでデプロイされています
    • deis openで表示
  • 簡単にアプリがデプロイできるよ
    • 要はherokuインスパイア
    • PaaSなのでスケールアウトも簡単
      • deis scale web=3
      • スケジューラのせいか、20秒くらいかかるけど簡単にインスタンスを増やせます
  • メリット
    • Herokuライクな使い勝手
    • Buildpack, Docker image, Dockerfileなど様々な仕組みが利用できる
  • デメリット
    • スケジューリングが遅い
    • Production投入にはもう少し
      • EYがDeis Proってのもあるようです

Flynn

  • '13 クラウドファンディングスタイルでスタート

    • 現在はPrime Directiveが主導
    • dokku開発者が在籍

  • flynn create

  • git remoteするとflynnリモートができている
    • デジャヴ
  • git push flynn master
    • FlynnもBuildpackを使っています
    • コッチのほうが早い
  • flynn routeでエントリポイントが表示

  • flynn scale web=3

    • すぐ終わる

  • シンプル、モジュラー、カスタマイズしやすいアーキテクチャ

  • PaaSに必要な要素がFlynn内で完結している
    • OpenShiftはk8s、DEISはCoreOSのFleetあたりをバリバリ使っているがFlynnはワンストップ
  • 開発の継続力に一抹の不安
    • 会社の規模が違いすぎる

  • Ubuntu前提

  • All-in-OneはどれもVagrantが提供されてます

  • 開発言語は全部goです

Open PaaS tsuru

  • たかはしなおと
    • @tnaoto
    • Cloud Foundry理事

tsuru

  • ブラジル開発、golang製
    • '12 3.14~
    • どこかでコードがらっと変わっている可能性はある

  • インストール: all-in-one or Vagarnt

    • http_proxyがあるとどうやってもインストール出来ないので諦めましょう

  • Webインターフェースもtsuruアプリとして動いている

  • tsuru app-create hoge ruby
    • Rubyを別途ビルド、Buildpackを事前にビルドしてるような形
    • repositoryが吐かれる
      • git push hoge masterでデプロイ
      • nokogiriがビルドできないらしく、必ず死ぬので...

  • デモではダッシュボードをもう１個デプロイします

    • tsuru app-create dashbord2 python
    • git push dashbord2 master

  • アプリはplatformと呼ばれるランタイムで動く

    • 実態はdocker build
    • baseimageを作って、そこにアプリをデプロイしている
    • 実行時のアプリはcircus

  • 運用管理も考えている

    • 物理ホスト管理
    • dockerプール管理
    • platform管理

  • service

  • contributeするなら今のうち
    • 1.0.0が25%くらいです

  • どれもVagrantで試せます

    • どっかのPaaSと違って2GBもあれば動きます

  • 次回

    • PaaS x IoT Node-RED勉強会
    • 8/26
      • 110/50人でめっちゃ好評なので、今後頻繁に開催します
    • 第２９回は多分9月上旬〜中旬、多分品川あたり