July Tech Festa 2015に行ってきました

JTF2015 (July Tech Festa) に行ってきました。

自分はお昼から参加しました。参加費1000円(早割だと500円)でフリードリンク、お菓子食べ放題、お弁当支給（ハンバーグ弁当とかタコライスとかいろいろあった）。非常に素晴らしいサービスでした。

どのセッションもとても興味深かったです。もっといろいろ見たかった。

以下、セッションのメモ。

Modern DevOps with Mackerel

by はてなCTO 田中さん

DevOpsとは？

CommunicationやCollaboration

  • アプリケーションエンジニアとインフラエンジニアの協調作業

チームの仲が悪くなる

  • それぞれがそれぞれの目標に最適化されてしまっている
    • 同じ目標に向くことが大切

Integraton, Automation, Measurement

  • 脱職人技*脱属人性
  • 効率向上
  • 再現を容易に
  • 誰かがやったことをそのまま再現できると、脱属人性につながる

Modern DevOpsとは？

  • 高速なテスト、デプロイ
  • インフラの自動化と効率向上
  • Immutable Infrastructure
  • Infrastructure as Code
    • 各社様々な取組

インフラの自動化と効率向上

  • 構築（新規、変更）あれいれたい！減らしたい！
  • 観測、監視

ここ2，3年で流行してるのが、下の2つ。

Immutable Infrastructure

  • できるだけサーバに状態を持たせない。
    • 可能なものと不可能なものがある。不可能な例→DB
    • Immutableにできれば考えることが減る。
  • 簡単に作り直せるように
  • The Twelve-Factor App(Heroku)の考え方

Infrastructure as Code

  • インフラの設定をコードで管理
    • 長いスパンでサーバを管理するには必須になってくる。

インフラ構築の道具

  • プロビジョニング
    • ansible/chef/puppet
  • CI
    • serverspec
  • デプロイ

デプロイの高速化

  • CIの活用
    • Jenkins/CI環境でイメージを自動作成
  • Docker, AWSならamiを用意しておくことで容易にデプロイ
  • ChatOps
    • チャットツールを中心としたオペレーション
      • Slackなど
      • bot活用
    • 誰がどういう作業をしているかわかる
    • ただしチャットツールが落ちると仕事が出来なくなったりする。github落ちても…

Staging環境への自動デプロイ

  • 自動デプロイ
    • git pushトリガでproxy設定まで自動化
  • 自動停止
    • ゴミを残さない

インフラ状態の一元管理

Mackerelとは

インフラの状態をAPIで取得可能

  • ホストの状態の更新はPOSTで出来る

tmux-sshでまとめてssh

  • APIを組み合わせて、一発で複数サーバにログインできる

Capistrano連携

  • deploy.rbにIPアドレス等をハードコーディングしなくていい

Ansible Dynamic Inventory

Webhook+hubot

  • アクションの自動化
  • アラート→再起動、など

AutoScaling

  • mackerle-agentを組み込むと自動的に反映される

監視ルールAPI

開発ツールのクラウド化

実行環境もクラウドへ

  • AWS、GCEなど

運用ツールもクラウドに

  • infrastructure as codeの推進
  • インフラの一元管理DBとしてのMackerel

ひしめき合うオープンソースPaaSを徹底解剖! PaaSの今と未来

by PaaS勉強会 草間さん

OpenPaaS

Cloud Foundry

  • VMwareがOSSとして公開(2011年)

    • Public PaaS
      • IBM Bluemixなど
      • NTT-Com Cloundn PaaS
    • Private PaaS

  • DEMO

    • phpファイルをCloud Foundry上にデプロイ
    • $ cf push <app-name>

  • 別のPaaSサービスに向ける

    • $ cf api <APIサーバ>
    • 今回はcloudnからbluemixにAPIを変更した。

  • スケールも簡単

    • $ cf scale <app-name> -i <count of instance> -m <memory size>

CFのメリット

  • ベンダーロックインが防げる
  • たくさんのベンダーさんがサービスを提供している

CFのデメリット

  • オンプレにCFのデプロイが死ぬほど大変（1日かかったり）

  • Dockerは使えないの？

    • CFはDocker使ってない。次期バージョンでDocker imageサポート。

  • Dockerが使えるPaaSはないの？

    • OpenShift

OpenShift

  • RedHatが開発
  • OpenShift v3...Docker PaaSとして生まれ変わった。今までを捨てた。
  • KubernatesをコアにしたPaaS
    • Kubernatesの開発にRedHatが深くかかわっている。Kuberの概念を取り込み
  • JSONでいろいろ定義。長い。その分いろいろ設定できる。
  • Webhookにも対応。これはPaaSの中ではOpenShiftのみ。
  • 開発早い。
  • KubernatesをコアにしていてPaaSっぽさがない？

Deis

  • Docker + CoreOSをベースとしたPaaS

  • DEMO

    • $ deis create
      • git上にリモートrepoが設定される。
    • $ deis scale web=5
      • スケーリング
  • herokuライク。
  • スケジューリングが遅い。

Flynn

  • Docker PaaS
    • Heroku CloneのDokkuの開発者も関与
  • DEMO
    • $ flynn create
      • git上にリモートrepoが設定される。

  • Heroku互換のBuild Packを使ってる

  • メリット

    • シンプルかつモジュラーでカスタマイズしやすい
    • スケジューリングもDeisよりはやめ
    • スケール早い(3→5台で、2.2秒)
  • デメリット
    • 開発の継続力に不安
    • どこまでメンテし続けられるか
    • スケジューラが賢くない（デプロイ先をランダムで決める。ただその分早い）
  • 開発はほとんどGo。流行り。

4つ見てみて

  • どれも似たり寄ったり。
  • なんで？
    • "12 Factor App"というベストプラクティスがある。どのPaaSもこれを前提にしている。

PaaS使いたいなら

  • まずはPublic PaaS

  • Private PaaS構築は？

    • あまり実例ない。
    • 準備が死ぬほど大変。
    • 自由があまり効かない。

  • 優れた仕組みを積極的に取り入れていくのは大切。

    • Docker
    • 構成管理ツール
    • Fluentd
    • など
  • ただ規模が大きくなるにつれ複雑になり、メンテが出来なくなってくる。引継ぎコストも無視できなくなる。
  • 自前で似たような構成を作るならOpenPaaSを採用してダクトテープ（継ぎはぎのテープ）を捨てませんか。

OpenPaaSの未来

  • ネットワーキングの強化
    • あらゆるサービスの「ハブ」に