36

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?

skanatek
  • 4,793
  • 3
  • 41
  • 69
  • In my case, I chose to have the same Linux distribution in dev and prod and I also manage the production servers with Chef. That way I can be sure that the same versions of apache, db, etc will be available in both environments. And for that reason, I'm using Ubuntu in AWS instead of Amazon Linux. – Daniel Jun 13 '14 at 00:59
  • Daniel, is your dev a physical machine or a VM? Also, could you please elaborate on Ubuntu-AWS vs Amazon Linux? – skanatek Jun 13 '14 at 12:54
  • 2
    Dev is in a VM that I run with Vagrant (on top of VirtualBox) and provision with Chef Solo, but it could be a physical server. It doesn't make much difference. If I recommend Ubuntu is because that way you can have exactly the same OS in your Vagrant and in AWS; that way, you will not have to adapt your Cookbooks to two different OS. It's just a matter of optimizing your time. Linux AMI is Red Had family, but the packages are different than those in Centos. By the way, if you want to learn Chef, prepare yourself for some days of hard work. It's not easy to find good documentation. – Daniel Jun 16 '14 at 00:57
  • [packer.io](https://packer.io) might be relevant here. – Erik Kaplun Nov 28 '15 at 04:00

2 Answers2

24

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.

csanchez
  • 1,446
  • 9
  • 16
  • Sorry for writting on a so old post but i want to understand something. If i understand your statement right, you don't deploy your VM with the code, you just replicate the same box everywhere using vagrant. When you want to update your application, you technically don't need to refresh your box, just update your code using GIT or wathever VCS. Code uses the boxes to ensure same environment but boxes don't get deployed except once and then you just update your code base using GIT. Is that right? – Mathieu Dumoulin Mar 05 '15 at 18:59
1

In the case of Puppet (Chef can most likely do this also), you can build the manifest (recipe) in such a way that they behave differently in your vagrant environment, e.g.

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

The question about continuous delivery is a little too broad in this context. I think the answer would be "yes", for what it's worth.

Felix Frank
  • 7,912
  • 1
  • 20
  • 30
  • 2
    Felix, I'm more interested in using all that Chef/Puppet+Vagrant goodness in a 'proper' way, i.e. avoiding different platforms from the start. – skanatek Jun 13 '14 at 12:53
  • Meaning you will move your production into Vagrant? Thats..."interesting" to be sure ;-) – Felix Frank Jun 13 '14 at 17:10