4

This will likely be the most convoluted question I've asked on stackoverflow but I think one that all Continuous Integration newbs might really benefit from. To start, I've read thru a ton of documentation and many "Get Started" tuts to understand this all, but I'm missing the bigger picture that ties it all together.

I'm interested in a bit of a higher level explanation that can help direct someone around setting up a full stack CI workflow around AWS, Packer, Vagrant and Chef. Added bonus would be to have it all tie in with a NodeJS, Express server.

Here are a few pitfalls I'm finding hard to suss out from all the the documentation across all topics.

  1. Packer/Vagrant - When user Packer's Vagrant post-processor of a AWS build to generate a Vagrant Box.... is that box stand alone? Can I delete the instance on AWS and the box will still work locally?
  2. Is there a way to setup a Vagrant Box mentioned above that you can test against locally using chef and then use those same packer/chef scripts to generate that same AMI on AWS? My thinking is that you then can be pretty sure the result will be the same.

Any useful tutorials would be super helpful too.

iDVB
  • 388
  • 2
  • 12

2 Answers2

2

Check out this Codeship guest post from the creator of Vagrant/Packer. This might help you get started easier.

http://blog.codeship.io/2013/11/07/building-vagrant-machines-with-packer.html

The premise of your second question says it all. The idea is you build images, AMI, virtualbox, etc.. with identical setup scripts (chef, puppet, ansible, bash, whatever) and deploy to different target VM environments.

m0rganic
  • 61
  • 3
1

I'm more or less in the same boat as you and just started to dabble in the devops world but I'll try to answer as best as I can.

  1. You should be able to delete your AWS instance and the Vagrant box you created will still work; you don't even have to provision an AWS instance and only create a Vagrant box.

  2. You can setup a dev box with Packer and use the same config to deploy with Packer; from my understanding this is the problem Packer is trying to solve.

To add a bit more to those answers, Packer will create "golden images" which are speedy in the sense that everything you need is already downloaded and configured. The other side of that coin is even a small change to a config file could mean creating and uploading a brand new Box, which might be 700+ MB.

A good middle ground might be to use Packer to create a Vagrant Box with the basics (such as things that will most likely remain constant like Nginx and gcc) and use Vagrant alongside Chef configs to configure that Box, including setting up Node and installing requirements.

Then when you are ready to deploy you can use Packer and the same Chef configs to spin up an AWS instance. Of course this will create a new instance and not reconfigure an existing one; I'm not sure if Packer can do that, but Chef fits the role of configuration management quite well.

A little extra, if you haven't already, you should consider version controlling your Vagrant configs. Also it never hurts to start small and work your way up.

Crimson
  • 156
  • 1
  • 1
  • 3
  • Do you have any tutorials, or samples that you can share? I've been looking hi and low and can't seem to find one showing Packer using Chef-solo as a provisioner. The half-pager in packer's docs is really not enough. – iDVB Nov 03 '13 at 19:09
  • The tutorials I followed when learning were just official documentation and I haven't looked too much into Packer, so unfortunately I don't have anything to offer in terms of tutorials or examples. – Crimson Nov 04 '13 at 04:39
  • checkout this [presentation](https://speakerdeck.com/ndemoor/phoenix-servers-with-packer) – mestachs Jan 16 '14 at 15:48