44

I've been reading about Vagrant, and I find it quite useful for my development. I am currently managing a series of services (mail, web, LDAP, file sharing, etc.), and often one of these falls and needs a quick backup. Is it possible (and recommended) to use Vagrant for these purposes?

So far I've virtual machines installed like real machines.

I would also like to know about an alternative to Vagrant which would allow me to setup a simple configuration file and put a virtual machine, for example, with Zimbra, and quickly have an alternate mail server, enable RabbitMQ, etc.

nbro
  • 15,395
  • 32
  • 113
  • 196
rkmax
  • 17,633
  • 23
  • 91
  • 176
  • 7
    20th February 2014: I still think a detailed answer to your question remains to be provided! If not in production, why? – AsTeR Feb 20 '14 at 09:03
  • 2
    23rd September 2014: I am also still searching for the answer on why Vagrant is not suitable for production. To me, it comes down to the performance of the virtual server. And of course, what kind of application are we putting into production. It can't just be a general statement. – Will Sep 23 '14 at 21:43
  • @Will I gave up with Vagrant for production long time. now i'm using Docker for things like databases for more complicate things like Zimbra i'm using XEN – rkmax Sep 23 '14 at 22:50
  • @rkmax can you tell us why you gave up? Is it performance? Unstable? what? – Will Sep 26 '14 at 02:50
  • Mainly for stability, vagrant (virtualbox) has by default not a way to control io in virtual machines when some machine has high IO can block anything (including the host). the current (xen, xcp-xapi) solution allows me to better control the resources of the machine and stability is flawless – rkmax Sep 26 '14 at 04:45

6 Answers6

20

Vagrant should be used more like a staging environment to test your infrastructure changes. It should be your test bed for automated infrastructure changes.

The way we use it at my company is like so:

  1. Create VMs for our managed servers in Vagrant.
  2. Create puppet definitions for each server.
  3. Create cucumber tests for each server.
  4. Make infrastructure changes via puppet and add cucumber tests.
  5. Launch our servers to test for failures.
  6. Fix bugs, release and/or back to step 4.

Basically when we're happy with our changes, we'll pull our puppet changes into production to make it happen.

I'd not recommend using vagrant to manage VMs for real production. I'd use something else like razor, virsh, OpenStack or one of the many other vm management systems out there.

Sekm
  • 1,658
  • 13
  • 22
  • 5
    Basically you're recommending not use virtualbox for production environments – rkmax Nov 29 '12 at 00:39
  • 18
    That Vagrant 'should' be for staging/development is just an opinion. If you can pull in evidence for this your answer would carry more weight. I sympathise with your workflow, in the sense that it looks practical, but one could also argue that you could have 2 sets of Vagrants, one for staging, others for production. To some this might seem practical, again, as before-mentioned, evidence might exist that would strongly recommend to NOT use Vagrant in production. – Mosselman Feb 26 '13 at 10:54
  • 3
    Seriously, the first thing you can read at the Vagrant website itself is "**Development** environments made easy". – Papipo Jan 05 '15 at 01:09
  • @Papipo Basically you are adding another layer of abstraction on-top of your production environment. – Ricky Boyce Jan 17 '18 at 23:54
3

This page suggests that the Vagrant push command is meant for deploying to production:

https://www.hashicorp.com/blog/vagrant-push-one-command-to-deploy-any-application/

"Additionally, multiple config.push.define declarations can be in a Vagrantfile to define multiple pushes, perhaps one to staging and one to production, for example."

skinneejoe
  • 3,921
  • 5
  • 30
  • 45
2
  • From my experience, Vagrant mainly used in a development environment.
  • Vagrant configuration and provisioning options are limited compared to Terraform for example.
  • If you are working on a cloud based environment, you can use Terraform for infrastructure provisioning.
  • If your environment is local or your VMs will be hosted on a datacenter, you can use Ansible, chef or puppet for you configuration management and automation.
Omar Khaled
  • 401
  • 6
  • 11
0

I had the same question and have been investigating the use of Vagrant push which as per their documentation, as of version 1.7, Vagrant is capable of deploying or "pushing" application code in the same directory as your Vagrantfile to a remote such as an FTP server.

I'm considering having vagrant spin up in a VM for developers, while also giving you the option to deploy your code to a live server for production environments.

aphexlog
  • 1,503
  • 3
  • 16
  • 43
-1

Hashicorp just published Otto, which is meant to be the Vagrant's successor. It is designed to support deployment environments.

From their Github page:

The key features of Otto are:

  • Automatic development environments: Otto detects your application type and builds a development environment tailored specifically for that application, with zero or minimal configuration. If your application depends on other services (such as a database), it'll automatically configure and start those services in your development environment for you.

  • Built for Microservices: Otto understands dependencies and versioning and can automatically deploy and configure an application and all of its dependencies for any environment. An application only needs to tell Otto its immediate dependencies; dependencies of dependencies are automatically detected and configured.

  • Deployment: Otto knows how to deploy applications as well develop them. Whether your application is a modern microservice, a legacy monolith, or something in between, Otto can deploy your application to any environment.

  • Docker: Otto can use Docker to download and start dependencies for development to simplify microservices. Applications can be containerized automatically to make deployments easier without changing the developer workflow.

  • Production-hardened tooling: Otto uses production-hardened tooling to build development environments (Vagrant), launch servers (Terraform), configure services (Consul), and more. Otto builds on tools that powers the world's largest websites. Otto automatically installs and manages all of this tooling, so you don't have to.

Community
  • 1
  • 1
Andre Pena
  • 56,650
  • 48
  • 196
  • 243
-5

As mentioned by @andrerpena, Otto is the successor of Vagrant.

From www.ottoproject.io :

Otto can deploy your application. Users of Vagrant for years have wanted a way to deploy their Vagrant environments to production. Unfortunately, the Vagrantfile doesn't contain enough information to build a proper production environment with industry best practices. An Appfile is made to encode this knowledge, and deployment is a single command away.

Tomasz Szawara
  • 77
  • 2
  • 9