How is deployment to Production done from local VirtualBox / Vagrant development environment?

vagrant virtualbox chef-infra puppet continuous-deployment
skanatek picture skanatek · Jun 12, 2014 · Viewed 11k times · Source

Recently I started to read about building development environments with virtualization software (I am a beginner) and it seems that 'infrastructure as a code' is a really powerful concept.

I really like the workflow structure described here:

  1. The same base VirtualBox image is used around the team
  2. Vagrant is used to quickly 'build up' and 'provision' such an image to a needed configuration with the help of
  3. Chef (or Puppet) recipes which is the only piece of code needed to be put under version control.

However, I still do not quite understand how the code is transferred and deployed on Production servers.

As I understand, the common way of keeping DEV and PROD environments identical is to manage the Production server instance as just another virtual image to be provisioned with Chef. I can have exactly the same OS installed on the Production server as I (and the team) use daily with VirtualBox-Vagrant-Chef.

But the Production server can have hardware which differs from that in the virtual guest OS and this might lead to inconsistencies again.

So, here is the question:

What is the known and common best practice to transfer and deploy code to a Production server from a development environment which is managed with the VirtualBox-Vagrant-Chef toolchain? Does this practice allow any continuous deployment?

[Edit]: Note: Is there any practice of running the same VM instance provisioned with Chef/Vagrant on the Production server, like it is depicted on this diagram?

Answer

csanchez picture csanchez · Jun 16, 2014

I'm the author of the article you linked, so my 0.02

If I understood correctly your question, you don't move the vms from dev to production, you create a repeatable process that allows you to create the same end state (OS + config + app) over and over again, no matter where the destination is.

By using vagrant you guarantee that your devs use the same OS that your production servers use no matter what OS they use for development.

Using Puppet/Chef you guarantee that the OS is configured the same whether it is running in a vm with Vagrant, a vm in production, a cloud vm, or bare metal hardware. It doesn't need to be virtual.

Related questions

Vagrant stuck connection timeout retrying

My vagrant was working perfectly fine last night. I've just turned the PC on, hit vagrant up, and this is what I get: ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: …

Read More
Failed to open/create the internal network Vagrant on Windows10

I upgraded my Windows 10 to the last update yesterday and now, when I launch vagrant up command, I get this error : ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... The guest …

Read More
Vagrant ssh authentication failure

The problem with ssh authentication: ==> default: Clearing any previously set forwarded ports... ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat default: Adapter 2: bridged ==> default: Forwarding ports... default: 22 =&…

Read More