Twelve-factor app for server
Published by riywo,
12-factor appは今の時代のサーバエンジニア(開発運用問わず)に必須の考え方の一つだと思うけど、今回PackerとTerraform使っててサーバ・インフラ作りも全く同じだなぁと思った。
つまり、buildとruntimeを明確に意識する必要がある。今までのサーバ構築とかconfiguration managerとかはこの辺が曖昧で混然一体としてしまっているが故に、なにか息苦しさを感じていた。12-factor app風のものを初めてちゃんと設計して作って感じたのは、アプリを作る過程に今までになかった道標というかマイルストーンを置いてくれるおかげで、迷わずに作れてかつ運用しやすいなぁというものだったけど、サーバ作りも全く一緒だった。
build時にやることは、runtimeで変えないファイル資源の確保。特に外部リソースからのinstallの類はbuild時にしかやってはいけない(12-factor appならbundle installとか)。ここで使うソフトウェアやライブラリのバージョンを固定してしまってAMIなりのイメージとして固めたら、runtimeではそれを変更してはいけない。逆にbuild時にやってはいけないのは、runtimeに関わる様な情報をファイル資源に入れてしまうこと。IPアドレス等はruntimeにしか分からないのでそういう情報がruntimeで与えられたらちゃんと取り込めるようにしておくことが必要(12-factor appでいう環境変数でruntimeの情報を受け取るイメージ)。
runtimeでやることは、先の情報を与えて必要な環境でbuildしたものを動かすこと。外部リソースをファイル資源に取り込むことは原則不可。こうすることで、実はChefやPuppetの様なcontinuous configurationは不要になるし、差分適応がなくなり原則immutable/disposableになるので、扱いがとても楽になる。楽になるとはいえ、ちょっとライブラリのバージョン上げるだけ(たとえばshellshock対応とか)でも、サーバをbuildイメージから作り直す必要があるし、もしクラスタを組んでいるならそこに再参加させたりしないといけないので、それはそれで大変。しかし、本来頭を悩ませるべきはこちらの方であり、差分更新によって不明瞭な状態になったサーバに頭を悩ませるのは旧世紀の笑い話にしてしまいたい。
ちなみに、Dockerみたいなcontainerもそういう発想が必須。ただ、Dockerを動かすためにはその下のOS設定が必要であり、実はそのレイヤも全く同じなんだよね、ということに今回改めて気づいた次第。
別にどういうframeworkやinfrastructureを使おうとも、こうした考え方をもって明確な意思の元に設計・実装できる人が増えていくといいなぁ。