Managing all application environments with Vagrant

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Managing all application environments with Vagrant

Shawn Dahlen
Hi All --

When Vagrant 1.1 was launched a month ago, I became excited about the possibility of using
Vagrant as my single DevOps interface -- creating and configuring reproducible
development, test, and production environments (potentially across multiple cloud providers).

I wanted to share my work to achieve this vision over the past few weeks:

http://shawn.dahlen.me/blog/2013/04/12/manage-all-application-environments-with-vagrant/

I would love to hear your thoughts on what other plugins would be helpful to fulfill this goal.

Thanks.

Shawn

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Managing all application environments with Vagrant

Jimmy Cuadra
Great article, Shawn. Thanks for sharing. There are a couple things that seem less than ideal to me. The first is having to separate server creation and provisioning into two commands. The second is this all assumes that you are only ever controlling your cloud machines with Vagrant from a single machine. Once you've set up these servers for the first time, how do you transfer your local Vagrant set up to another computer, either yours or a coworkers? There's been a small amount of discussion on this second topic over on the vagrant-aws issue tracker: https://github.com/mitchellh/vagrant-aws/issues/35 Thanks again for sharing your work. It's a great start.

J

On Friday, April 12, 2013 3:05:59 PM UTC-7, Shawn Dahlen wrote:
Hi All --

When Vagrant 1.1 was launched a month ago, I became excited about the possibility of using
Vagrant as my single DevOps interface -- creating and configuring reproducible
development, test, and production environments (potentially across multiple cloud providers).

I wanted to share my work to achieve this vision over the past few weeks:


I would love to hear your thoughts on what other plugins would be helpful to fulfill this goal.

Thanks.

Shawn

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Managing all application environments with Vagrant

Shawn Dahlen
For the moment I haven't come up with an ideal solution for bringing back the server creation and provisioning into a single command -- I agree, that would be ideal.

With regards to your second point, I implemented basic support for this in the vagrant-digitalocean provider (along with submitting a patch to Vagrant).

When creating a new machine, the provider first checks if it is already active (e.g. an ID exists in the local Vagrant data path). If it doesn't exist, the provider
queries the Digital Ocean API for all droplets looking for a machine (droplet) with a matching host name. If there is a match, it assumes that the machine is
already created and saves the droplet ID locally. This approach helps 'synchronize' Vagrant machine data across servers.

In addition, the provider allows the user to change the config.ssh.username between runs (assuming the user account and authorized keys have
been provisioned). The initial stumbling block here was the shell and Chef provisioners (I haven't tested the others). The upload and provisioning paths
required their permissions to be recursively changed to the current ssh user. The current 0.1.0 version does this with right before
provisioning is called. I recently submitted a patch directly to Vagrant to handle this instead -- it is part of the upcoming 1.2 baseline.

While I haven't done extensive testing yet, the approach appears to work. Moving forward, my Vagrantfile will set both config.ssh.username and
config.ssh.private_key_path through environment variables. My continuous integration server will populate those variables and run the two
Vagrant commands. If the environment was already created elsewhere, the vagrant up operation will simply sync the machine IDs locally and
provision them using the continuous integration account.

I'm sure there will be other issues as I continue to explore this -- but all and all, I think it is heading in the right direction. 

On Friday, April 12, 2013 7:27:53 PM UTC-4, Jimmy Cuadra wrote:
Great article, Shawn. Thanks for sharing. There are a couple things that seem less than ideal to me. The first is having to separate server creation and provisioning into two commands. The second is this all assumes that you are only ever controlling your cloud machines with Vagrant from a single machine. Once you've set up these servers for the first time, how do you transfer your local Vagrant set up to another computer, either yours or a coworkers? There's been a small amount of discussion on this second topic over on the vagrant-aws issue tracker: https://github.com/mitchellh/vagrant-aws/issues/35 Thanks again for sharing your work. It's a great start.

J

On Friday, April 12, 2013 3:05:59 PM UTC-7, Shawn Dahlen wrote:
Hi All --

When Vagrant 1.1 was launched a month ago, I became excited about the possibility of using
Vagrant as my single DevOps interface -- creating and configuring reproducible
development, test, and production environments (potentially across multiple cloud providers).

I wanted to share my work to achieve this vision over the past few weeks:


I would love to hear your thoughts on what other plugins would be helpful to fulfill this goal.

Thanks.

Shawn

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.