Vagrant and Microservices Dev Environment

 

I have a running project that is comprised of 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'm starting it 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?

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

    • I agree in most of the answer of @Brian

    I have been reading through Vagrant for a while and it looks interesting. I'm starting it 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 would not do that, there's some cost (CPU, RAM) to setup the whole VM (as vagrant does, even when using the docker provider) so the best would be to have a single Vagrantfile with your services deployed on, so if you deploy a new service you can deploy on this VM.

    You can see (what I find) a good examples of seeing microservice architecture with Vagrant https://github.com/ewolff/microservice/tree/master/docker-vagrant

    链接地址: http://www.djcxy.com/p/30150.html

    上一篇: Angular2：在MyComponent上找不到指令注释

    下一篇: Vagrant和微服务开发环境