14

vagrant (理想的には同じ vagrantfile から) を使用した dev/prod 環境の単純な自動化 (puppet を使用) をどのように処理していますか?

私が解決しようとしているユースケース

  • 本番マシンが作成されていない場合は、vagrant で起動したいと思います。
  • 開発環境の puppet ファイルで調整されている場合は、本番環境で nginx または apache conf を vagrant でリロードしたいと考えています。

問題

AWS や Digital Ocean などのプロバイダーで vagrant を呼び出すと、それがアクティブなプロバイダーになり、切り替えることができなくなります。次のエラーが表示されます。

アクティブなマシンが別のプロバイダーで見つかりました。Vagrant では現在、各マシンを一度に 1 つのプロバイダーのみで起動することができます。将来のバージョンでは、この制限が取り除かれます。それまでは、既存のマシンを破棄して、新しいプロバイダーを立ち上げてください。

破壊するのが答えのようですが、切り替える必要があります。破壊したくない。

言っていただけると幸いです

vagrant up prod

また

vagrant reload prod

そして、単純な vagrant up がデフォルトのマシンにフォールバックします。

この構文は、複数のマシンの動作に似ていますが、vagrant up (デフォルトの動作) を呼び出すだけで、開発環境と運用環境をスピンアップしたくありません。

ワークフローの一部としてパッカーを検討する必要がありますか? puppetconf 2013 での Mitchell の Multi-Provider に関する講演全体を見ましたhttp://puppetlabs.com/presentations/multi-provider-vagrant-aws-vmware-and-more

私はまだ私の問題の解決策を見ていません。

2013 年 9 月 27 日更新

他の誰かがこの考えに反対している場合に備えて、この記事は私が持っていた多くの疑問を解決しました. http://pretengineer.com/post/packer-vagrant-infra

4

4 に答える 4

1

理想的な解決策ではありませんが、git ブランチの使用はどうでしょうか? 私の考えでは、heroku を使用する場合と概念的に似ている可能性があり、マスター バージョン、ステージング バージョン、および製品バージョンが存在する可能性があります (通常、これらは異なるリモートであるため)。

この場合、Vagrantfile に小さな編集を加えて prod ブランチから開始し、VM に少し異なる名前を付けます。次に、dev からのすべての変更を、発生時に prod ブランチにマージできるはずです。したがって、ワークフローは次のようになります。

$ git checkout prod
$ vagrant up
$ git checkout master
...  make changes to puppet ...
$ git checkout prod
$ git merge master
$ vagrant reload
$ git checkout master

これらをスクリプト化してエイリアスすることができるので、最終的には

$ start_production
$ reload_production
于 2013-09-15T11:30:29.003 に答える
0

このシナリオで作業するために私が思いついたのは、2 つの異なる.vagrantフォルダーを管理することです。

注：他の回答のほとんどは、異なるプロバイダーでdevとprodを実行すると仮定して、マルチプロバイダーの設定を扱っています。ほとんどの場合、これは真実かもしれませんが、devとprodに同じプロバイダーがある場合は間違いありません。aws を使用していて、dev と prod を ec2 インスタンスとして使用するとします。これは同じプロバイダーになります。

devインスタンスを管理したいprod場合、異なるプロバイダーを使用する可能性があります (ただし、同じプロバイダー上にある可能性も非常に高い)。その場合は、次のようにします。

  • dev通常のインスタンスを設定しますvagrant up --provider <dev_provider>。これにより、管理できる開発 VM が作成されます

  • .vagrantプロジェクトディレクトリに作成されたフォルダーをバックアップし、次のように名前を変更します.vagrant.dev

  • prod選択したプロバイダーでインスタンスをセットアップしますvagrant up --provider <prod_provider>。これで、prod VM が作成されます

  • .vagrantプロジェクトディレクトリに作成された新しく作成されたフォルダーをバックアップし、次のように名前を変更します.vagrant.prod

ここで、dev または prod で作業するかどうかに応じて、.vagrant.devまたは.vagrant.prodディレクトリの名前を に変更する.vagrantと、vagrant が適切な VM を操作します。

ほとんどの場合、dev で作業し、他のプロバイダーに切り替える必要があることはほとんどないため、スクリプトを思いつきませんでした。しかし、CLI からパラメーターを読み取り、名前の変更をより動的にするのは難しいとは思いません。

于 2016-06-14T06:57:11.080 に答える
0

コマンドラインからの指定に応じて「デフォルト」のマシン名を動的に変更する簡単な方法を次に示します。これにより、異なるプロバイダー間で競合が発生しなくなります。--provider

require 'getoptlong'
opts = GetoptLong.new(
  [ '--provider', GetoptLong::OPTIONAL_ARGUMENT ],
  [ '--vm-name',  GetoptLong::OPTIONAL_ARGUMENT ]
)

provider=ENV['PROVIDER'] || 'virtualbox'
vm_name=ENV['VM_NAME'] || 'default'
opts.each do |opt, arg|
  case opt
    when '--provider'
      provider=arg
    when '--vm-name'
      vm_name=arg
  end
end

Vagrant.configure(2) do |config|

  # HERE you are dynamically changing the machine name to prevent conflict.
  config.vm.define "mt-#{provider}-#{vm_name}"

  # Below sections are just examples, not relevant.
  config.vm.provider "virtualbox" do |vm|
    vm.name = "test.local"
    vm.network "private_network", ip: "192.168.22.22"
    vm.customize ['modifyvm', :id, '--natdnshostresolver1', 'on']
    config.vm.box = "ubuntu/wily64"
  end

  config.vm.provider :aws do |aws, override|
    aws.aws_profile = "testing"
    aws.instance_type = "m3.medium"
    aws.ami = "ami-7747d01e"
    config.vm.box = "testing"
  end
end

使用例:

VM_NAME=dev PROVIDER=virtualbox vagrant up --provider=virtualbox
VM_NAME=uat PROVIDER=aws vagrant up --provider=aws
VM_NAME=test PROVIDER=aws vagrant up --provider=aws
VM_NAME=prod PROVIDER=aws vagrant up --provider=aws
VM_NAME=uat PROVIDER=aws vagrant destroy -f
VM_NAME=test PROVIDER=aws vagrant status

参照:単一の vagrant ファイルに複数のプロビジョナー?

于 2016-06-10T16:05:22.697 に答える