ご存知のように、開発では常に 工数削減 と 品質工場 という 相反する要求 があり、プロジェクトの要請により、いずれをより優先するか が決まります。
しかし、これら要求は根底では 互いに深く関連 しており、いずれを軽視しても結局は 開発コスト という形で跳ね返って来ます。
つまり、いずれを優先させる場合でも、結局は バランス が重要であり、全体の底上げが求めてられている訳です。
そこで、まず、そもそもなぜ Ansible
のような構成管理ツールや Packer
のようなイメージ生成ツールが開発され広く利用されるに至ったのか、つまり どんな必要があったのか を考えてみると理解しやすいと思います。
開発システム全体の品質を担保するには、システム自体 の品質を担保することはもとより、実行環境 の構成も正確に管理する必要があります。
つまり、どんなに頑張ってテストを実施しても テスト環境 と 本番環境 の 構成が一致 していないと品質を担保することはできません。
普通に手動で
vagrant -> 既存の vagrant box を使用
aws -> マーケットプレイスのAMIを使用
とした方が開発コストが少ない様な気がします。
確かに、そのようなプロジェクトもあると思います。特に、必要とされる実行環境が
- 初回構築後はほとんど変更がない
- ロードバランサー、Webサーバー、DBサーバーなど、一般的かつ簡易な構成である
の場合には、わざわざマシンイメージを作成するまでもないと思います。
一方、次のような場合には、開発環境の構築時に本番環境用のマシンイメージを一緒に作成して管理し、アプリ本体と共に環境自体も合わせてリリースすることで、品質向上およびリリース時間短縮に役立つケースもたくさんあります。
- 開発が進むに連れて、基盤構成にしばしば変更が発生する
- 開発環境・本番環境を大量に作成する必要がある
- テスト環境自体もAWS上に構築した方が都合が良い
- 既成のマーケットプレイスのAMIとして提供されていない特殊な環境である
- 既成のイメージは利用できるが多くのカスタマイズが必要となる
- 構成要素が多く、毎回ゼロからインストールしているととても時間が掛る
- クリティカルなシステムで障害発生時に環境自体も素早く切り戻しをする必要がある
#細かい話をすれば「既存の vagrant box」と「マーケットプレイスのAMI」が細部に至るまで本当に同じ構成かどうかを検証するにもそれなりの手間が掛かります
もちろん、品質担保のために有用とはいえ 工数の大幅な増大 や 手順の複雑化 は許容できないですけれども、幸いなことに、最近では面倒で時間の掛る マシンイメージ 作業は 高速かつ自動的 に実施できる開発基盤も開発が進んでおり、工数の問題はさほど問題ではなくなっています。
具体的な事例については、下記をご参照ください。
Jenkins + Ansible + PackerでAMI作成を自動化する
以上、ご参考になれば幸いです。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。