Devsumi 2014: 「サーバプロビジョニングのこれまでとこれから」の感想とメモ

devsumi2014 infra chef

サーバプロビジョニングのこれまでとこれから

感想

Developers Summit 2014 に参加してきました！
まずは、一番最初に出た「13-B-1」の感想から。

今はの業務はインフラ専門では無いけれども、興味があったのでセッションに参加してみました。

個人的に（仕事でも少し）Chefのrecipeとか書いたり、serverspecを使ってみたりして「面白い」と思っていたので、他にどんな技術があるのかワクワクしながら聞いてました。

インフラのコード（chefのrecipeなど）を、徹底的にGitHubで管理したり、 テスト駆動インフラをすると安定して環境が整えられていいと思います。
開発環境はChefで作ってますが、ちょっとrecipeを直したりすることが億劫でした。
今は、recipe書き換えて、動作確認して、レビューして、マージしてみたいなことを全部手動でやっていて、正直面倒臭いなぁと思うことが多々あります。
結果、自分のローカル環境だけ変更をとどめたり（あとで纏めて出せばいいやとか）してしまって、非常に良くない。
テスト駆動インフラにすることで、こまめに書き換える習慣がつきそうです。

あと最近、よく耳に入ってくるDockerとかについても少し知ることができたのでよかったです。

うちのチームの開発環境でも、ChefのレシピをCIしたり、Dockerとか使ってやってみたいなぁと思います。

いやー、このセッション楽しかった。

以下は、セッション中に書いたメモです。
間違いとか、何かあったら教えていただけると助かります。

サーバプロビジョニング

サーバプロビジョニングを3つのレイヤで整理すると、

  • Bootstrapping: OS install など
  • Configuration: サーバの設定など
    • 最近はサーバプロビジョニングはここらへんのことを指すことが多い
    • middle ware の install
    • 手動, シェルスクリプト, chef, puppet など
  • Orchestration: Fabric, capistrano など
    • わかりにくい概念
    • インフラの新しい概念とともに意味も変わってきている

のようにまとめられる。

Infrastructure as Code

歴史

  • 2005年に Puppet が登場
    • 2005年に論文が出ている
    • 源流はCFEngine(1993)
      • 宣言的: 何をしたいか（どうするかを記述しない）
      • 抽象化: 詳細の面倒を見てくれる
      • 冪等性: 必要なときだけ実行する
      • 収束化: 放っておけばどうにかなる
  • 「Infrastructure as Code」という言葉は2008年くらいに言われ始めた

Infrastructure as Code とは

  • 以下の項目からビジネスをゼロから再構築できるようにすること
    • ソースコード
    • アプリケーションのデータのバックアップ
    • サーバリソース

「コードでインフラの情報を記述する」ということを推し進めていったのがChef。 「ソフトウェアと同じ概念が使えないか？」という発想を元に、 「Infrastructure as Code」から「Test-Driven Infrastructure（テスト駆動インフラ）」へ。

テスト駆動インフラ

この、発想は Chef 周辺で盛り上がってきて、「Test Kitchen CI」というツールが登場している。 でも、「Chefしか対応してない！」ということで、作ったのが serverspec。 テスト駆動インフラの「駆動」は、インフラを記述したコードを書くことを駆動するという意味。 serverspecはインフラの状態をテストするためのツールではない（使ってもいいけど）、 インフラの状態を記述した「コード」をテストするツール。

インフラCI

ツール的には、もう使い慣れているもので、

  • Jenkins
  • Wercker
  • Travis
  • Drone

などでまわす。

GtiHub Flowによるインフラワークフロー

GitHubに連携させて、

  1. Test OK
  2. Review OK
  3. Merge　OK

となる。 ここまでがひとつの流れ。

Immutable Infrastructure (Disposable Components)

Immutable ~（不変）より、Disposable ~ （使い捨て）のほうが重要。

  • 動いているサーバには変更を加えない
  • 新しいサーバを構築してロードバランサーで切り替える
    • 成功したら元のサーバは破棄（ここが disposable）
    • ダメだったら切り戻す
    • 昔は（当時？）Blue-Green Deploymentと呼ばれていた（Immutable Infrastructure という言葉が出てきたのは2013くらい）
    • EC2のようなIaaSが出てきたから容易になった

Immutable/Disposable の制約で得られるメリット

Immutableにできないところはどうするのか？

  • 永続化や可変なデータをどうするか？

そこは、やはりケースバイケースになる。

Container Base Deployment

  • コンテナとは、単機能で、軽量なVM っていうイメージ。厳密には違うけど。
  • コンテナをまるごと差し替えてデプロイする
    1. . サーバにコンテナが乗っていて、その上で Middle ware が動いている
    2. . コンテナを載せる
    3. . コンテナの接続先（？）をかえる
  • Docker のポータビリティによって普及
    • ローカル環境のコンテナを本番環境でつかえる
    • ローカルで十分テストすることが出来る
    • テスト駆動して、CIでまわして、コンテナデプロイ
  • 単機能なVMのイメージで、1コンテナ1機能と単純化し、これらを組み合わせてサービスを構築する
    • サーバ部品のコンポーネント化
    • 差しかえもし易い
    • テスタビリティも向上
    • IaaS上じゃなくても Bule-Green Deployment ができる
  • Mesos/YARN などと組み合わせて自動的なリソース配置

Orchestration

イメージ的には、

  • Configuration: 単一サーバで完結
  • Orchestration: 複数のサーバが関連するもの
    • LBへのノード追加
    • MuninやNagiosへのノード追加
    • アプリケーションデプロイ

とするとつかみやすい。

旧来と新しい Orchestration

  • 旧来
    • Immutable Infrastructure 前提ではない
    • サーバの増減が頻繁でないので Config. の領域でも可能
    • Command & Control 型
  • 新しい
    • Immutable Infra. Disposable component が前提
    • サーバの増減が頻繁で、Config. 領域での対応がキツイ
    • LBへの自動追加
    • Serf というツールの登場
      • ノードのクラスタリング
      • ゴシップロトコルべース
      • イベントプロパゲーション
      • Serfで、できることを Orchestration と捉えると、 Configuration との区別が明確になるのでいいのではないか

参考

Tools