Purpose of using provisioning sofware in virtual machine like Vagrant - vagrant

I am a very new in web application development.My question is whats the purpose of using provisioning software like Puppet or Chef while using Vagrant as a Virtual machine.

Largely it is about consistency. Vagrant simply gives you a virtual machine. Chef/Puppet, allows you to configure that machine in EXACTLY the same way, every time. So you can do some development, spin up a VM, deploy your code to it, and test. Once you're done, you can destroy the VM, do some more development, and start again from scratch. This ensures that things like debugging don't give you a false sense of security. Since each test session starts with a totally clean environment, you know what you're getting. Finally, once you finish all that testing, you have a consistent method for deplying to your production environment. Again, knowing that everything will remain consistent as Chef will do the same thing in production as it did in vagrant.

Related

How can I setup an IDE in Vagrant? Is this a good idea?

I'm totally new to vagrant and wanted to ask if it is possible to setup my development enviroment (Java; Netbeans; Ant; maybe link to Subversion) in Vagrant.
The idea would be to have a 'clean'/same configuration IDE with all the same versions for each development project.
Or am I missing the point of Vagrant? And it should work like a build-server?
Is there any point besides simulating a component for testing (like a server or production enviroment?)
Of course you can install your whole development environment within a vagrant VM. It does not matter if you use it as reproducible and independent development or test environment.
For more information see the 'Why Vagrant Section' on the developer home page
http://docs.vagrantup.com/v2/why-vagrant/index.html

Vagrant. VM after provisioning

I tried to adopt Vagrant in our team. I created a Vagrantfile and make provisioning in some way. Everything works as charm, but ...
It's unclear for me how I can automate some routine tasks like:
running django(I use django, but it's framework agnostic problem) dev server on 0.0.0.0
running grunt watcher
providing a separate console for django-specific commands
It is looks like vagrant not intended to help with this kind of automation and I look for some community adopted way to do that. I goggled and found nothing.
I see a few way to that:
bootstrap.sh script but messy and hard to mantain
something like tmuxinator -- requires tmux on host machine and now it's impossible to put tmuxconfig in project repo
etc
What is the 'canonical' way to resolve this problem?
P.S.: Please, think about designers, manual testers and other guys which like to use tools as is
In general you are best off using a provisioner. To be honest, a bootstrap.sh file is a good place to start unless you want to learn the ins and outs of something like chef / ansible / salt / puppet. If you do you might want to start at salt (SaltStack) because it is written in python which I'm guessing you use given the django angle.
For your specific questions:
Part of the point of vagrant is it lets you develop against real stacks and real web servers so you can avoid the "oh, that don't quite work the same on apache" moment that often comes in projects. So for your first question I would look at how to provision the app behind apache / nginx or whatever you are using for the production web servers.
Because of the shared file systems users can just run grunt locally on the host machine. This also lets grunt do things like hook into OSX notifications.
I'm not familiar with tmuxinator so I'm not sure how to start here. But if it is a service that the server really runs then you should figure out a way to package the install and deploy it to the provisioned VM. As for configuration, is it possible to get a dev config in the repo?
Same as #Wyatt, I recommend use Vagrant with provision tools, such as puppet, saltstack, chef, anisble, etc. These tools are created for the requirements you ask for, and most are open source. Choice is no wrong, you can start learning from any one, they are similar.
With that, you can quickly and easily run several VM servers with all applications installed automatically. With the customised Puppet codes or chef cookbooks, you can update them any time and provision to VM easily, you can re-use them for your PROD environment as well.
Take some times to learn one of these automation tools first, you will get benefit to save a lot of time.
I use Puppet, and recommend the best puppet book PRO PUPPET to you. It has all you need.

Vagrant work flow

I read about vagrant today, I have observed few points in it.
Vagrant creates a identical development environment for everyone in the team.
A modern, complex application probably uses a number of external dependencies, like various database servers, message queue etc. Installing these on every developer's machine individually for a local development environment can be quite a difficult. Using a virtual machine image, we can distribute a per-configured environment easily.
Have a 5 minute setup for any new developer who joins our team to get up and running. This should be as easy as running a single command: "vagrant up". No installation, no troubleshooting. It should “just work” ™
I have some queries on above statements,
How can we setup an environment for new member who joins our team?
In case new developer makes some changes in his virtual setup, how will it be reflected or deployed to your virtual setup?
Will you have to do the setup again? Or will it work as similar to SVN, namely, if one developer will change it will automatically affect the other machine also?
Vagrant is a good tool for manage teamwork and create a good startup flow..
You can create a git repository with your Vagrantfile and your provisioning script.. a new developer clone your repo and start it with "vagrant up" command.. And he is ready for work with complete env.
My configuration of Vagrant is a git repository.. I use it with normale VCS.
VCS :) git commit, pull, push ecc how a normal project..

Whats the best fit for continious delivery, Vagrant or Puppet,

At present I have to deploy the latest version of my application to a QA environment which is a painful and completely manual task. Im looking at possibly using Puppet or Vagrant as a way to manage my infrastructure and spin up some virtual machines with all the components I need so I can run acceptance tests against the latest version of my software. Im looking for something that integrates with my Bamboo and will teardown these machines when im finished with them.
Theres alot of talk about Vagrant, but it seems to me that you need to first prepare a VM before using Vagrant. Is one better than the other or is anyone using both as part of there CI environment?.
Why or when you can use "and":
Puppet is a configuration management tool - forcing consistency and predictability across your cluster. Usually used in Staging/Production set ups where autoscaling of machines is used.
Vagrant is a simple framework for setting up virtual machines from a list of pre-configured "clean" installations. The first use case is a "playground" on your development machine.
Once Vagrant sets up the virtual machine it can provision it using Puppet to install all the prerequisites (e.g. your app) (just like it does in the production machines) and then you can test it.

Creating a virtual machine image as a continuous integration artifact?

I'm currently working on a server-side product which is a bit complex to deploy on a new server, which makes it an ideal candidate for testing out in a VM. We are already using Hudson as our CI system, and I would really like to be able to deploy a virtual machine image with the latest and greatest software as a build artifact.
So, how does one go about doing this exactly? What VM software is recommended for this purpose? How much scripting needs to be done to accomplish this? Are there any issues in particular when using Windows 2003 Server as the OS here?
Sorry to deny anyone an accepted answer here, but based on further research (thanks to your answers!), I've found a better solution and wanted to summarize what I've found.
First, both VirtualBox and VMWare Server are great products, and since both are free, each is worth evaluating. We've decided to go with VMWare Server, since it is a more established product and we can get support for it should we need. This is especially important since we are also considering distributing our software to clients as a VM instead of a special server installation, assuming that the overhead from the VMWare Player is not too high. Also, there is a VMWare scripting interface called VIX which one can use to directly install files to the VM without needing to install SSH or SFTP, which is a big advantage.
So our solution is basically as follows... first we create a "vanilla" VM image with OS, nothing else, and check it into the repository. Then, we write a script which acts as our installer, putting the artifacts created by Hudson on the VM. This script should have interfaces to copy files directly, over SFTP, and through VIX. This will allow us to continue distributing software directly on the target machine, or through a VM of our choice. This resulting image is then compressed and distributed as an artifact of the CI server.
Regardless of the VM software (I can recommend VirtualBox, too) I think you are looking at the following scenario:
Build is done
CI launches virtual machine (or it is always running)
CI uses scp/sftp to upload build into VM over the network
CI uses the ssh (if available on target OS running in VM) or other remote command execution facility to trigger installation in the VM environment
VMWare Server is free and a very stable product. It also gives you the ability to create snapshots of the VM slice and rollback to previous version of your virtual machine when needed. It will run fine on Win 2003.
In terms of provisioning new VM slices for your builds, you can simply copy and past the folder that contains the VMWare files, change the SID and IP of the new VM and you have a new machine. Takes 15 minutes depending on the size of your VM slice. No scripting required.
If you use VirtualBox, you'll want to look into running it headless, since it'll be on your server. Normally, VirtualBox runs as a desktop app, but it's possible to start VMs from the commandline and access the virtual machine over RDP.
VBoxManage startvm "Windows 2003 Server" -type vrdp
We are using Jenkins + Vagrant + Chef for this scenario.
So you can do the following process:
Version control your VM environment using vagrant provisioning scripts (Chef or Puppet)
Build your system using Jenkins/Hudson
Run your Vagrant script to fetch the last stable release from CI output
Save the VM state to reuse in future.
Reference:
vagrantup.com
I'd recommend VirtualBox. It is free and has a well-defined programming interface, although I haven't personally used it in automated build situations.
Choosing VMWare is currently NOT a bad choice.
However,
Just like VMWare gives support for VMWare server, SUN gives support for VirtualBOX.
You can also accomplish this task using VMWare Studio, which is also free.
The basic workflow is this:
1. Create an XML file that describes your virtual machine
2. Use studio to create the shell.
3. Use VMWare server to provision the virtual machine.

Resources