Immutable Infrastructureに対する自分なりの考えメモ

この辺りを読んだ。自分の中ではImmutable Infrastructureについてはここ一週間で調べただけであり、解説などは出来ないが、とりあえず自分用のメモとして自分の思ったことなどを書いていく。

コンテナベースのデプロイ

　Dockerなどが出てきたことにより、Dockerのイメージをそのままアップロードし、それを本番でも動かすということが出来そうというのが面白かった*1。こういう風なフローになるとすると、これまでのデプロイ手順とは全く違うようになりそう。

これまでのデプロイと、コンテナベースのデプロイ

これまでのデプロイは

masterにmergeされたら、コードの反映を今動いているサーバに行う
反映が終わったらweb serverのrestartなど

もしくはサーバを新しく立てる形式だと(例: AWS, chef, Cinnamon等を使った無停止デプロイ(PrePAN carton 1.0化の裏側) - $shibayu36->blog; )

masterにmergeされたら、新サーバを新しく作ってそこに反映
load balancerで新しく立ち上がったサーバに向ける

のように

テストなどが通りデプロイ準備が完了する
コードの反映などを起動中サーバに行う
再起動やload balancerの切り替えにより、新しいコードを使う

という流れだった。

しかし、コンテナベースの場合

masterにmergeされたら、最新のコードをdockerのimageに反映
dockerのimageを起動中サーバに配布
docker runなどでweb server起動

のような流れになりそう。

この時、これまではコードの反映などを起動中サーバに行わなければならなかったものが、コンテナのimageに対して行えるようになるというのは手順として大きく違うように思う。このような手順になると、本番と完全に同じ状態のimageに対し、jenkinsでアプリケーションのテストを走らせ、それが通ったらそのimageをそのままアップロードするという事もできそう。

必ず一から作り直すのか

　Immutable Infrastructureでは、必ず一から作りなおすのかというのはそうではないという話のようだった。作ったものにはもう触らない、いつでも捨てられるという考え方にすることで管理を容易にしようという話のように聞こえた。実際にデプロイごとに毎回まっさらな状態からchefを走らせて、アプリケーションの配置を行ってってやってるとすごい時間かかりそうだし、デメリットも多そう。

　具体的にどうするのがいいのかなと想像してた。
　まずインフラの構成管理という部分と、アプリケーションの反映という部分は分けられるんじゃないかなーと思う。

インフラの構成全ての冪等性は難しい
- chefとかの難しさを見てるとそういう感じ
アプリケーションコード反映のみの冪等性は結構簡単
- コード自体は最新の状態で配置すればよいだけ
- 依存モジュール管理もbundlerやcartonに任せられる?

　こう考えると、冪等性が難しい部分の変更があった時は最初から作り直す、簡単なところは差分で作るというふうにしてもいいのかなと思った。

　例えばDockerによる管理だと

Dockerfileにはchefのインストール部分と、chefを実行するというコマンドのみが書いてある
chefの変更があった場合はdocker buildをして、一から作り直す
アプリケーションコードのみの変更であれば、元にあるimageに対し反映して、docker commitするだけ
- コードの反映、アプリケーションの依存モジュールインストールなど

　このくらいだと、毎デプロイの段階で作りなおすことはしないけど、一から作り直すのも簡単なのかなと思った。

Orchestration?

　Orchestrationという部分が結構難しかった。
　僕の中ではmizzyさんのエントリを見た時、Orchestrationにcapistranoやfabricが入っているというのは非常に違和感があった。そのあとstanakaさんのエントリのOrchestrationの説明がしっくり来た。

　思ったこととしてはImmutable Infrastructure的なことをしようとすると、これまでのようにサーバの管理表を作って管理するということが出来なくなる(?)ので、いろんな場所に作られたサーバから自分はここにいるという通知をしたり、そのイベントを使ってアクションする必要が出てくるのかなと思った。

　例えばある構成の一部分だけ入れ替えたいときに便利だったりしそう。あるアプリケーション構成のmemcachedだけ置き換えたい時に、置き換えた後アプリケーションの該当部分の設定を書き換えてデプロイするというのではなく、置き換えた通知を受けたアプリケーションサーバが自動で設定を書き換えて再起動するみたいに。

　とはいえまだまだ良く分かってない。

(12/9 追記)
別のエントリでもう少し書きました。
http://shibayu36.hatenablog.com/entry/2013/12/09/193856

まとめ

　特にまとまってないけど、とりあえず最近の流れを調べたいと思って、Immutable Infrastructureについて調べたので、その時に感じたものを自分の備忘録として記録してみた。

Rebuild ep.25を聞きながら考えてたことメモ

Immutableなインフラストラクチャは便利だけど、従来ホスト管理は出来ない
- このへんはserfでいい感じにしたい
serfはかなり原始的な感じだからラップしたツールがどんどん出来そうだなあと思った
- と思ってたらなんかそういうこと言ってた pluginで提供されるかもという話しらしい
もしかしたらhostの管理状態をserfでやり、その状態をどこかに置いておいて(これはサーバ管理ツールの分野かも知れない)、アプリのconfigでhost名を取るところはその場所から起動時に取ってくるとかしたい
まだハマりどころは結構ありそう、今のところこのへんのツールは始まったばかりのツールっぽい
- まずはjenkinsのアプリケーションテストを本番相当環境で、デプロイのCI、インフラCIあたりで使っていくという感じかな
Dockerは一つの役割を一つのコンテナに担わせるということになってる
- あるコンテナの中で複数のデーモンを動かす時は、一つの起動スクリプトを実行するということにしておくのがいいのかな?
- 少なくともweb server, fluentd agent, serfくらいは立ちそう(たぶんもっといろいろ)
Dockerfileの中ではConfigurationレイヤーのツールのセットアップ + 起動のみをやるといいのではと思った
- chefの設定を変えたらdocker buildすれば新しくコンテナが作れるとか

*1:もちろん今の状況でいきなりそれをやるとリスクも多そうだけど