Vagrant work flow - vagrant

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..

Related

is Vagrant suitable for beginners that are not tech savvy?

I'm planning to teach a group a people how to setup a website using WordPress. Those people have some basic computer usage knowledge : they can surf the web, write emails, install software on their computer, ... But they are absolutely not developers. And the training does not aim to teach them development.
But I want them to be able to setup a fully working local web environment or their computer that runs on Windows. I was planning to use XAMPP, but I'm wondering if Vagrant is not more suitable. I could prepare a box with a lot of tools already included, and they will just have to install it. Interaction with the server would take place only via http and FTP (no ssh needed).
Is it possible to create a batch file that they can click on to launch the Vagrant ? If properly configured, is that as easy to use as that for absolute beginners ?
from what you describe there is almost no vagrant thing, you would be responsible to make the vagrant box and the vagrantfile, and you will not expose your students to vagrant. only thing is that they would need to have this bat file on their desktop (the only command that it will need to run is vagrant up, make sure to expose the vagrant cwd variable) and the server will be up and running.
The main advantage I see then is that you will completely make your students in the same situation they will be with their production system. they will face the same tool (FTP, wordpress admin ...) on an environment (more or less) identical to a production environment.

Vagrant workflow: Share the box or share the setup code

Using Vagrant to have a number of developers share the same environment I see two approaches that people are using.
Create a box file with entire basic environment installed, and share it on Vagrant cloud?
Create a setup script that will "apt-get install" and "git clone" everything that is needed?
With 1st approach I don't like the fact that you have to host large files, also changes to environment would be harder to do (uploading the subsequent version of the entire box?).
Its difficult to make an answer for this, I can only share my experience, I started with #1 and provided a full box to my team, the box was 13 GB but it worked fine (although was not too easy to share), then when we had to upgrade any 3rd party software its was more difficult (it was also before the time vagrant update was available) but still I like option #2 much more flexible now. The provisioning takes 2-3 hours but we can run it at night, repeat the process anytime and at the end, its much easier to provision a new instance for a new member.

Custom developer setup with Vagrant

I currently have a Vagrant vm with a typical web setup (apache, php, etc). The actual web repo is checked out onto the my local machine, and accessed through synced folders and forwarded apache ports (like http://127.0.0.1:4567/web). The question is, how do I make this work for a team, as opposed to just me? Since you have to sync folders, how is it possible for multiple devs to connect to one VM and sync folders?
I initially thought sharing the Vagrantfile would be all that is needed, but the Vagrantfile is agnostic to all apt-get commands and apache/php/node etc setup. I don't want devs to have to worry about running those.
This is what Vagrant provisioning is for.
Vagrant allows you to automatically alter configuration of a box or install additional software packages as a part of the first vagrant up process. Moreover, you can provision your system with various configuration management systems: Chef, Puppet, Ansible, CFEngine. Or you can simply use shell scripts.
Sitepoint offers a good tutorial on provisioning Ubuntu 14.04 box with bash scripts to install nginx, PHP-FPM and MySQL. Read it. Later you might want to move to configuration management systems.
Take a look at Phansible project which generates Ansible provisionings for PHP-based projects. Puppet provisioning for PHP-projects can be generated via PuPHPet. They will give you an idea how to use configuration management with Vagrant and might be used as s template for your Vagrantfile.
I always try to craft my Vagrantfiles carefully (provisioning, synced folder, for example, maps host's ./src/public onto /var/www/html/ on guest machine, port forwards and so on) so I can put them into project's root under version control. Later when my teammate clones project's repo on his machine he can issue vagrant up right away and get a fully functional development environment.
The only problem I haven't solved yet is updating existing VMs when new dependencies are added to projects. Now we update provisioning scripts and if developers encounter errors they manually reprovision their VMs by using vagrant reload --provision.
P.S. I asked a question regarding this problem

Export customized vagrant

I mounted a vagrant machine several time ago.I have modified some configurations to the VM since the installation and now my co-workers need to use exactly the same VM.
How can I do it ? I would like keep the database i used for my co-workers too if it's possible.
Look into VagrantCloud: https://vagrantcloud.com/
I'm using that service to host a customized box for my team. Started from a vanilla box, customized it to match our environment, then used the "vagrant package" command to create a new *.box file. You just need to host that file somewhere online, register it with the VagrantCloud service, and you can manage box releases and deployments for your co-workers. It even notifies them if you update the box. Pretty nifty.
As far as the DB, if it is in the VM it will get packaged up too. Might wat to look into providing updated DB files for later since they will get out of date fast, I would imagine.

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