最近、仮想化ソフトウェアを使用した開発環境の構築について読み始めました (私は初心者です)。そして、「コードとしてのインフラストラクチャ」は本当に強力な概念であるように思えます。
説明されているワークフロー構造がとても気に入りましたここ:
- チーム全体で同じ基本VirtualBoxイメージが使用される
- Vagrantは、次のような助けを借りて、必要な構成でこのようなイメージを素早く「構築」し「プロビジョニング」するために使用されます。
- バージョン管理下に置く必要がある唯一のコードである Chef (または Puppet) レシピ。
しかし、コードがどのように転送され、本番サーバーにデプロイされるのか、まだよくわかりません。
私の理解では、DEV 環境と PROD 環境を同一に保つ一般的な方法は、プロダクション サーバー インスタンスを、Chef でプロビジョニングされる別の仮想イメージとして管理することです。VirtualBox-Vagrant-Chef を使用すると、私 (およびチーム) が毎日使用するのとまったく同じ OS をプロダクション サーバーにインストールできます。
ただし、実稼働サーバーのハードウェアは仮想ゲスト OS のハードウェアと異なる場合があり、これによって再び不整合が発生する可能性があります。
それで、質問です:
VirtualBox-Vagrant-Chef ツールチェーンで管理されている開発環境から本番サーバーにコードを転送してデプロイするための、既知の一般的なベスト プラクティスは何ですか? このプラクティスにより、継続的なデプロイが可能になりますか?
[編集]: 注: この図のように、Chef/Vagrantでプロビジョニングされた同じVMインスタンスをプロダクションサーバーで実行するという方法はありますか?図?
ベストアンサー1
私はあなたがリンクした記事の著者なので、私の0.02
質問を正しく理解していれば、VM を開発環境から本番環境に移動するわけではなく、宛先がどこであっても、同じ最終状態 (OS + 構成 + アプリ) を何度も作成できる繰り返し可能なプロセスを作成するということです。
Vagrant を使用すると、開発にどの OS を使用するかに関係なく、開発者が実稼働サーバーと同じ OS を使用することが保証されます。
Puppet/Chef を使用すると、Vagrant を使用した VM、実稼働 VM、クラウド VM、またはベアメタル ハードウェアのいずれで実行されていても、OS が同じように構成されることが保証されます。仮想である必要はありません。