Vagrant for deployment to production

[Brian Candler]

I am trying to understand how Vagrant is intended to be used at the point of production deployment of an application.

In the section on networking at https://www.vagrantup.com/docs/networking/public_network.html it says

Warning! Vagrant boxes are insecure by default and by design [my emphasis], featuring public passwords, insecure keypairs for SSH access, and potentially allow root access over SSH.

And yet, the Atlas managed service says it manages application deployment all the way to production:

https://www.hashicorp.com/atlas.html

I am interested in how these conflicting points of view are reconciled for a typical Vagrant deployment.

Is the user expected to prepare a separate, secure Box for production use? Are the steps required to lock down the standard boxes documented anywhere, other than the text highlighted above?

Or is production deployment outside of the scope of Vagrant entirely? Obviously the user could replicate the steps in the Vagrantfile on a production server by hand or using tools like Ansible, but then ISTM there's a risk that the production environment diverges from the test one.

Thanks,

Brian Candler.

[Torben Knerr]

Hi Brian,

the "config.ssh.insert_key" option mitigates that somehow by inserting a new keypair into the box when it's first started up:

https://www.vagrantup.com/docs/vagrantfile/ssh_settings.html

Also, your production environment may not run on a virtualbox or vmware basebox. Consider it runs in any kind of IaaS cloud provider infrastructure (e.g. via vagrant-aws), you would simply point to a dummy basebox (basically an empty .box which only defines the provider to be "aws") and define your keypair out of band (i.e. in AWS console, not in the basebox)

Finally, from my experience Vagrant works well for defining your production infrastructure as long as it is "static" (i.e. a fixed set of known servers). Once you want to have something more elastic that autoscales your instances depending on load you probably want to use something like terraform instead. 

HTH,

Torben

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/edeaeb5f-6a7b-43a3-99ba-70384431d674%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Candler]

Thank you, that's very helpful.  Regards, Brian.

[Alvaro Miranda Aguilera]

hello

on top of what Torben said, at somepoint you would create your own vagrant boxes, mainly for 2 reasons, a. create a base box that include all that is required, and b. moving to immutable infrastructure.

when you decide to get into that, have a look into packer.io that is also a hashicorp solution.

you will be able to have providers+provisioners and create several combinations of boxes

so you would end with a vagrant box (virtualbox) and a DigitalOcean or AWS AMI that have the same configuration.

As you did create the boxes, your level of trust will be higuer.

packer boxes can be vagrant, but is not a requirement, so you can create  boxes to be consumed by terraform or other tools

alvaro

This email has been sent from a virus-free computer protected by Avast. www.avast.com