Vagrant and Microservices Dev Environment

I have a running project comprising a set of microservices. We are planning to introduce Vagrant so that any new developer that joins the team is easily able to set the environment up and running on his/her machine.

I have been reading through Vagrant for a while, and it looks interesting. I started out simple: I initialized one of the microservices using Vagrant, which then created a VagrantFile.

Is this a good approach? One VagrantFile per microservice?

I then attempted to create a Box for this microservice.

What name should this box have? Should I stick to any naming conventions?
How and where should this box be persisted? Should this be part of the source code of my microservice component?

Solution

I see you've asked a similar and possibly duplicate question about this stuff as well.

I'm also not sure why you're capitalizing Microservice, as I'm not aware of any software specifically named that.

Vagrant, and virtualization/VMs in general, let you choose the system architecture - usually people try to choose something close to what production is or will be. If you have a small site and everything will be run off a shared box or VPS, then having everything installed in one vagrant box and provisioned as such (either with Docker or just simple shell provisioning scripts) is fine.

If you have multiple servers in production (www, app, db, whatever), then you have a choice. You can still provision all of those roles into one vagrant box, or you can launch multiple boxes with each trying to replicate those roles (see multi-machine vagrant) - this is a situation where you might prefer Docker over shell provisioning scripts. Presumably you could use the same or a very similar Docker configuration across all environments (dev, qa, production, etc).

The questions in your last paragraph,

What name should this box have? Should I stick to any naming conventions? How and where should this box be persisted? Should this be part of the source code of my Microservice component?

are generally up to you and your development and deployment workflow. In a multiple developer environment, I will usually store the Vagrantfile along with the source code in version control, so all developers can work from the same development environment, and it is quick and easy to onboard new developers or nuke your box and start again if you are working on deployment and provisioning.

naming the box, and naming conventions are not required and up to you
persistence of the box is generally not a high priority - the idea is you can quickly and easily (every few hours, days, once a week, etc) recreate your box
I can't say for certain if you should store the Vagrantfile with your source code, that will depend on your team composition, development workflow, etc