Slashdot Mirror

Now only if there wasn't a free way to do that before...

For basic workstation stuff it's fine.

It's also pretty heavily used for development and test of server deploys. A lot of DevOps types are trying to use VirtualBox to build disposable test clusters for their applications, and has been the default and one of the best supported engines for vagrant.

Unfortunately, a lot of app footprints are starting to rely on deploying other "appliance VMs" in your VM (yo dawg), and VirtualBox is still straggling behind the others on implementing some form of nested VM capability. https://www.virtualbox.org/tic... So it's kinda getting to a point of having a large and growing number of server apps that you won't be able to use VirtualBox to set up a local development and test environment for things that involve, say, using a Stackato PAAS, or a FEO appliance, or an Apigee API gateway appliance, etc. to pick a bunch of essential pieces from recent memory. At least not without a lot of work to host those VMs directly on VirtualBox and not looking or working at all like they would when they hit production.

Vagrant is a wrapper for Virtualbox and VMWare Workstation that accelerates the deployment of development environments.

http://www.vagrantup.com/

Please tell a bit more about when and in what situations you would want to use this instead of a plain Virtualbox VM.

Vagrant is a wrapper for Virtualbox and VMWare Workstation that accelerates the deployment of development environments.

http://www.vagrantup.com/

I've only used Ubuntu in it, but a colleague set up something with RedHat. I think he made the base box himself, rather than using something publicly available. That is, he made an extremely minimal install of RedHat, then followed the instructions on what's required -- adding a specific username with an SSH key and adding VirtualBox guest tools so it can mount a directory from the host. (Possibly removing certain temporary files -- I think Ubuntu caches the network card MAC address, so that file needs removing.) Vagrant can then package that up.

There's also a list of community-made ones here: http://www.vagrantbox.es/ (I've not used any of these.)

You might find Veewee useful if you want to generate a base .box yourself. The colleague got this working, I think quite easily, but we don't really need it so I didn't look myself.

I'll try and make the first useful comment of the discussion (so, it has nothing to do with the article).

I've been using Vagrant to manage development VMs. It automates using VirtualBox. There's an example on that homepage:
$ vagrant box add base http://files.vagrantup.com/lucid32.box

Can it handle anything other than Debian-based distros? The web site seems silent on that.

What .box choices are available?

I'll try and make the first useful comment of the discussion (so, it has nothing to do with the article).

I've been using Vagrant to manage development VMs. It automates using VirtualBox. There's an example on that homepage:
$ vagrant box add base http://files.vagrantup.com/lucid32.box

Can it handle anything other than Debian-based distros? The web site seems silent on that.

What .box choices are available?

I'll try and make the first useful comment of the discussion (so, it has nothing to do with the article).

I've been using Vagrant to manage development VMs. It automates using VirtualBox. There's an example on that homepage:
$ vagrant box add base http://files.vagrantup.com/lucid32.box
$ vagrant init
$ vagrant up
which leaves you will a running Ubuntu lucid install. Apart from the once-only download of the base image, it takes about 15 seconds to do this.

I've customised the vagrant configuration and added Puppet scripts, so it takes about 30 seconds to bring up my base box (which includes Apache, Tomcat, etc), download the software I've written from a Maven repository, and deploy it to Tomcat. My colleagues have a clone of the base box I produced

The operations team are in the process of producing a set of Puppet scripts for the production (UAT, etc) servers. Once they've done that, I'll make my Vagrant VM a reasonable derivation of the live environment.

Another tool, veewee, automates producing Vagrant boxes. I've not had time to look at this myself, but as far as I can see it automates setting up a VM (configuring discs, network, etc) and installing an OS, then exporting the resulting drive. I don't need many different host environments, but if you were testing some software against many different Linuxes or otherwise frequently installing Linux on VMs it could be useful.

I'll try and make the first useful comment of the discussion (so, it has nothing to do with the article).

I've been using Vagrant to manage development VMs. It automates using VirtualBox. There's an example on that homepage:
$ vagrant box add base http://files.vagrantup.com/lucid32.box
$ vagrant init
$ vagrant up
which leaves you will a running Ubuntu lucid install. Apart from the once-only download of the base image, it takes about 15 seconds to do this.

I've customised the vagrant configuration and added Puppet scripts, so it takes about 30 seconds to bring up my base box (which includes Apache, Tomcat, etc), download the software I've written from a Maven repository, and deploy it to Tomcat. My colleagues have a clone of the base box I produced

The operations team are in the process of producing a set of Puppet scripts for the production (UAT, etc) servers. Once they've done that, I'll make my Vagrant VM a reasonable derivation of the live environment.

Another tool, veewee, automates producing Vagrant boxes. I've not had time to look at this myself, but as far as I can see it automates setting up a VM (configuring discs, network, etc) and installing an OS, then exporting the resulting drive. I don't need many different host environments, but if you were testing some software against many different Linuxes or otherwise frequently installing Linux on VMs it could be useful.

Oh, by the way, you really should listen to those that tell you *need* some development environment.

Again, I've already been there, so I know you pain: even for the silliest development the developers will have their development environment but for us, systems people, it's expected that everything just fits in place at first try, no second chances. Of course, next heavy refurbish will be near to impossible because while being a good professional allows for more or less "clean" kaizen-style development, anything a bit dangerous is an almost impossibility because of lack of test environments (with luck, next "heavy test window" will be in three/four years when all the servers are decomissioned and new ones come in place) but that's the way it is, take it of leave it.

The good news is that, while not a panacea, virtualization, even at desktop level (you surely need to have a look at vagrant[1]) allows for a lot of testing, impossible in the age or "real-iron only".

[1] http://www.vagrantup.com/

Good luck running 64 separate VMs on your small server (not saying it's not impossible but I really wonder which one is faster to set up) and you won't be able to test any of the very different interconnects that easily.

Very easy indeed, and almost certainly quicker/easier to set up than the physical way, either using something like Vagrant or by rolling your own scripts to drive VirtualBox.

However, I think it's instructive for students to do it the physical way first. By analogy: first understand LANs, then learn about VLANs.

Ruby people make some cool tools that you can use even if your code isn't written in Ruby. Check out Chef and Vagrant. Both are configured with Ruby, which is amenable to making DSLs.