web-dev-qa-db-ja.com

ローカルのVirtualBox / Vagrant開発環境から本番環境へのデプロイはどのように行われますか？

最近、仮想化ソフトウェア（私は初心者）を使用した開発環境の構築について読み始めましたが、「コードとしてのインフラストラクチャ」は本当に強力なコンセプトのようです。

私は説明されているワークフロー構造が本当に好きです ここ ：

  1. 同じベースVirtualBoxイメージがチームの周りで使用されています
  2. Vagrantは、このようなイメージを必要な構成にすばやく「構築」および「プロビジョニング」するために使用されます。
  3. Chef（またはPuppet）のレシピは、バージョン管理下に置く必要がある唯一のコードです。

ただし、コードがどのように転送され、運用サーバーに展開されるのかは、まだよくわかりません。

私が理解しているように、DEV環境とPROD環境を同一に保つ一般的な方法は、Chefでプロビジョニングされる別の仮想イメージとして本番サーバーインスタンスを管理することです。私（およびチーム）がVirtualBox-Vagrant-Chefで毎日使用するのとまったく同じOSを運用サーバーにインストールできます。

ただし、本番サーバーには、仮想ゲストOSとは異なるハードウェアを使用できるため、再び不整合が発生する可能性があります。

だから、ここに質問があります：

VirtualBox-Vagrant-Chefツールチェーンで管理されている開発環境から本番サーバーにコードを転送およびデプロイするための既知の一般的なベストプラクティスは何ですか？この方法では、継続的な展開が可能ですか？

[編集]：注：この diagram に示されているように、プロダクションサーバーでChef/Vagrantを使用してプロビジョニングされた同じVMインスタンスを実行する習慣はありますか？

vagrantvirtualboxchefpuppetcontinuous-deployment
36
skanatek

私はあなたがリンクした記事の著者なので、私の0.02

私があなたの質問を正しく理解した場合は、VMを開発から本番に移動せず、宛先がどこであっても同じ最終状態（OS +構成+アプリ）を何度も作成できる繰り返し可能なプロセスを作成しますです。

Vagrantを使用すると、開発に使用するOSに関係なく、開発者が本番サーバーが使用するものと同じOSを使用することが保証されます。

Puppet/Chefを使用すると、OSがVagrantを備えたvm、運用中のvm、クラウドvm、またはベアメタルハードウェアで実行されている場合でも、OSが同じように構成されていることが保証されます。仮想である必要はありません。

23
csanchez

Puppetの場合（Chefはほとんどの場合これも行うことができます）、マニフェスト（レシピ）を作成して、迷惑な環境での動作が異なるようにすることができます。

if $::virtual != "virtualbox" { # not in vagrant
    include sysctl_tuning
}

継続的なデリバリーに関する質問は、この文脈では少し広すぎます。答えは「はい」だと思います。

1
Felix Frank