Is it possible to load a Vagrantfile config from within another Vagrantfile?

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

Is it possible to load a Vagrantfile config from within another Vagrantfile?

James Conant
In other words, to merge two Vagrant files?

Vagrant Multi-Machine functionality seems pretty cool, however one thing that bothers me (or is isn't immediately apparent) is that there doesn't seem to be a good way to share configuration options between a "parent" Vagrantfile and "children" Vagrantfiles. Is there a way to effectively and maintainably share configuration options between the parent and it's children? An example might make this more clear.

Let's assume I've got a platform which is comprised of 3 apps/services: API, Web, and Worker.

Let's presume a directory structure of the following:


   
/some_platform
     
/api
       
# app code...
       
Vagrantfile
     
/web
       
# app code...
       
Vagrantfile
     
/worker
       
# app code...
       
Vagrantfile
     
Vagrantfile


Let's say `/some_platform/api/Vagrantfile` looks like:


   
Vagrant.configure("2") do |config|
      config
.vm.box = "debian/jessie64"
   
end


Presumably the web and worker Vagrantfiles look similar.

Now, using the wonders of Multi-Machine I rely on Vagrant coordinate these VMs, and `/some_platform/Vagrantfile` looks like:


   
Vagrant.configure("2") do |config|
      config
.vm.define "web" do |api|
        api
.vm.box = "debian/jessie64"
     
end

      config
.vm.define "web" do |web|
        web
.vm.box = "debian/jessie64"
     
end

      config
.vm.define "web" do |worker|
        worker
.vm.box = "debian/jessie64"
     
end
   
end


I realize this example is contrived, but it's easy to see how once you get more and more complex config declarations, it's annoying and hazardous to have that config duplicated in two places.

You might be wondering "Why does each project have it's own Vagrantfile?" Doing so provides a single source of truth for how the server that app runs on should be setup. I realize there are provisioners you can use (and I will use them), but you still have to declare a few other things outside of that and I want to keep that DRY so that I can either bring up a cluster of apps via Multi-Machine, or I can work on a single app and change it's VM/server setup.

What I'd really love is a way to merge other Vagrantfiles into a "parent" file.

Is that possible? Or am I crazy for trying? Any clever ideas on how to achieve this? I've mucked about with some yaml files and POROs to skate around this issue, but none of the hacks feel very satisfying.

Best,
James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/7aa4d471-8784-4eab-9c77-f65af954f2f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Is it possible to load a Vagrantfile config from within another Vagrantfile?

Alvaro Miranda Aguilera
Hello

so Vagrantfiles are read outside to inside.

so you can setup some global settings at config. level and you can override inside the do |lele| level


  Vagrant.configure("2") do |config|

      confi.vm.box = "debian/jessie64"

      config
.vm.define "api" do |api|
        # something
      
end

      config
.vm.define "web" do |web|
        
# something
      
end

      config
.vm.define "web" do |worker|
        worker
.vm.box = "centos/7"
      
end
    
end


I usually have a global provision for shared code and then on each box some local box/role specific setup

Example:

Does that help?


Alvaro

On Thu, Sep 28, 2017 at 5:18 AM, James Conant <[hidden email]> wrote:
In other words, to merge two Vagrant files?

Vagrant Multi-Machine functionality seems pretty cool, however one thing that bothers me (or is isn't immediately apparent) is that there doesn't seem to be a good way to share configuration options between a "parent" Vagrantfile and "children" Vagrantfiles. Is there a way to effectively and maintainably share configuration options between the parent and it's children? An example might make this more clear.

Let's assume I've got a platform which is comprised of 3 apps/services: API, Web, and Worker.

Let's presume a directory structure of the following:


   
/some_platform
     
/api
       
# app code...
       
Vagrantfile
     
/web
       
# app code...
       
Vagrantfile
     
/worker
       
# app code...
       
Vagrantfile
     
Vagrantfile


Let's say `/some_platform/api/Vagrantfile` looks like:


   
Vagrant.configure("2") do |config|
      config
.vm.box = "debian/jessie64"
   
end


Presumably the web and worker Vagrantfiles look similar.

Now, using the wonders of Multi-Machine I rely on Vagrant coordinate these VMs, and `/some_platform/Vagrantfile` looks like:


   
Vagrant.configure("2") do |config|
      config
.vm.define "web" do |api|
        api
.vm.box = "debian/jessie64"
     
end

      config
.vm.define "web" do |web|
        web
.vm.box = "debian/jessie64"
     
end

      config
.vm.define "web" do |worker|
        worker
.vm.box = "debian/jessie64"
     
end
   
end


I realize this example is contrived, but it's easy to see how once you get more and more complex config declarations, it's annoying and hazardous to have that config duplicated in two places.

You might be wondering "Why does each project have it's own Vagrantfile?" Doing so provides a single source of truth for how the server that app runs on should be setup. I realize there are provisioners you can use (and I will use them), but you still have to declare a few other things outside of that and I want to keep that DRY so that I can either bring up a cluster of apps via Multi-Machine, or I can work on a single app and change it's VM/server setup.

What I'd really love is a way to merge other Vagrantfiles into a "parent" file.

Is that possible? Or am I crazy for trying? Any clever ideas on how to achieve this? I've mucked about with some yaml files and POROs to skate around this issue, but none of the hacks feel very satisfying.

Best,
James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/7aa4d471-8784-4eab-9c77-f65af954f2f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Alvaro

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/CAHqq0eyt6Oha3S7S85p%3DEBkjQOGhmjpE%2BHXgweY2Tp6DMGSO1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Is it possible to load a Vagrantfile config from within another Vagrantfile?

James Conant
Hi Alvaro,

Thanks for you quick response. My concern isn't so much sharing one set of global configs with each VM, as it is to have one canonical config for each defined app. For instance, let's say I've got the API, Web, and Worker apps. They each have their own Vagrantfile in their own directory. Additionally there is the parent directory that has it's own Vagrantfile which coordinates running all of them at the same time. This is so that you can either work with the meta-repo which contains all repos, or you can pull down a single repo and work with that. What I'm looking for is a way to share the content of the Vagrantfile configurations between all of the Vagrantfiles so that I don't have the same code living in two different places. For instance, let's say someone changes  `config.vm.box = "debian/jessie64"` to `config.vm.box = "centos/7"` in the "parent" Vagrantfile (in the main directory), but does not change that same option in the particular apps subdirectory "child" Vagrantfile. Now the configuration code has drifted and the box being used depends on where you are initializing the VMs from.

The best solution I've come up with so far is something along the lines of this: https://gist.github.com/jamesconant/491ca8198433c92e4925dec3e79da30e

Again, this example is contrived and there aren't as many options, but obviously those can increase quite a bit. Additionally, once you point to a provisioning script or framework, you have to make sure to keep those pointed at the same files in two places as well. Does that help explain what I'm getting at?

Best,
James


On Thursday, September 28, 2017 at 3:47:24 AM UTC-4, Alvaro Miranda Aguilera wrote:
Hello

so Vagrantfiles are read outside to inside.

so you can setup some global settings at config. level and you can override inside the do |lele| level


  Vagrant.configure("2") do |config|

      confi.vm.box = "debian/jessie64"

      config
.vm.define "api" do |api|
        # something
      
end

      config
.vm.define "web" do |web|
        
# something
      
end

      config
.vm.define "web" do |worker|
        worker
.vm.box = "centos/7"
      
end
    
end


I usually have a global provision for shared code and then on each box some local box/role specific setup

Example:
<a href="https://github.com/nabels-coolblue/redis-sampleapp-dotnet/blob/master/Vagrantfile" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fnabels-coolblue%2Fredis-sampleapp-dotnet%2Fblob%2Fmaster%2FVagrantfile\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH1BTd4DcgrJDONOz1Wn6x9zXNROQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fnabels-coolblue%2Fredis-sampleapp-dotnet%2Fblob%2Fmaster%2FVagrantfile\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH1BTd4DcgrJDONOz1Wn6x9zXNROQ&#39;;return true;">https://github.com/nabels-coolblue/redis-sampleapp-dotnet/blob/master/Vagrantfile

Does that help?


Alvaro

On Thu, Sep 28, 2017 at 5:18 AM, James Conant <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="2rcVgQBJBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jfac...@...> wrote:
In other words, to merge two Vagrant files?

Vagrant Multi-Machine functionality seems pretty cool, however one thing that bothers me (or is isn't immediately apparent) is that there doesn't seem to be a good way to share configuration options between a "parent" Vagrantfile and "children" Vagrantfiles. Is there a way to effectively and maintainably share configuration options between the parent and it's children? An example might make this more clear.

Let's assume I've got a platform which is comprised of 3 apps/services: API, Web, and Worker.

Let's presume a directory structure of the following:


   
/some_platform
     
/api
       
# app code...
       
Vagrantfile
     
/web
       
# app code...
       
Vagrantfile
     
/worker
       
# app code...
       
Vagrantfile
     
Vagrantfile


Let's say `/some_platform/api/Vagrantfile` looks like:


   
Vagrant.configure("2") do |config|
      config
.vm.box = "debian/jessie64"
   
end


Presumably the web and worker Vagrantfiles look similar.

Now, using the wonders of Multi-Machine I rely on Vagrant coordinate these VMs, and `/some_platform/Vagrantfile` looks like:


   
Vagrant.configure("2") do |config|
      config
.vm.define "web" do |api|
        api
.vm.box = "debian/jessie64"
     
end

      config
.vm.define "web" do |web|
        web
.vm.box = "debian/jessie64"
     
end

      config
.vm.define "web" do |worker|
        worker
.vm.box = "debian/jessie64"
     
end
   
end


I realize this example is contrived, but it's easy to see how once you get more and more complex config declarations, it's annoying and hazardous to have that config duplicated in two places.

You might be wondering "Why does each project have it's own Vagrantfile?" Doing so provides a single source of truth for how the server that app runs on should be setup. I realize there are provisioners you can use (and I will use them), but you still have to declare a few other things outside of that and I want to keep that DRY so that I can either bring up a cluster of apps via Multi-Machine, or I can work on a single app and change it's VM/server setup.

What I'd really love is a way to merge other Vagrantfiles into a "parent" file.

Is that possible? Or am I crazy for trying? Any clever ideas on how to achieve this? I've mucked about with some yaml files and POROs to skate around this issue, but none of the hacks feel very satisfying.

Best,
James

--
This mailing list is governed under the HashiCorp Community Guidelines - <a href="https://www.hashicorp.com/community-guidelines.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.hashicorp.com%2Fcommunity-guidelines.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGHa_CaKfZaJiwbkUndUQbVGlQCDw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.hashicorp.com%2Fcommunity-guidelines.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGHa_CaKfZaJiwbkUndUQbVGlQCDw&#39;;return true;">https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: <a href="https://github.com/mitchellh/vagrant/issues" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fmitchellh%2Fvagrant%2Fissues\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHxcA5DuHlQlPInMi_k1Pz4pMNqNw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fmitchellh%2Fvagrant%2Fissues\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHxcA5DuHlQlPInMi_k1Pz4pMNqNw&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="2rcVgQBJBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vagrant-up+...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/vagrant-up/7aa4d471-8784-4eab-9c77-f65af954f2f8%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/vagrant-up/7aa4d471-8784-4eab-9c77-f65af954f2f8%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/vagrant-up/7aa4d471-8784-4eab-9c77-f65af954f2f8%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/vagrant-up/7aa4d471-8784-4eab-9c77-f65af954f2f8%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.



--
Alvaro

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/f5e077b8-477e-43d6-a906-fd8b2030be69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.