Multi-Maching Provisioning: Post Vagrant Up Configs?

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

Multi-Maching Provisioning: Post Vagrant Up Configs?

Joaquin Menchaca

Looking for current ideas to have provisioning that is dependent of state of another system being up.  

Problem: Because systems come up sequentially (one at a time), need way to delay a config until after the another system is up.  If the systems were brought in parallel (like containers in docker-compose), I could then wait until the other systems come up. 

Use Cases:  For simple web development, web app may need to seed or db:migrate on an external database server, and for more advance scenarios, may need to populate data on other persistence (mem, nosql) or queuing systems, etc.  Other advanced cases (maybe sys engr testing) are popular ldap with user accounts for SSO on other LDAP client systems, load balancer w/ web backends, static monitoring depending on client systems to be monitored.

Solutions: Any solutions / patterns / best practices on this?  I would use vagrant ssh -c cmd outside of vagrant, but defeats the point of using a shell provisioner.  If I use Ansible, as Ansible is a remote-execution oriented, I would use it outside of vagrant.  But as vagrant is handling the provisioning and orchestration, would like to do it from within itself.

--
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/f8cbdebc-633e-4106-8700-248c2d55dde7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Multi-Maching Provisioning: Post Vagrant Up Configs?

Alvaro Miranda Aguilera
Hello

a common pattern is have a global config that setup a common key between all the machines.

Then on the last node you can run whatever you like to provision on the whole cluster.

I personally do multi machine setups and set the counter from high to low so when the last node is done, say node1, i allow that node to provision to all the others.

Alvaro


On Mon, Feb 20, 2017 at 8:51 PM, Joaquin Menchaca <[hidden email]> wrote:

Looking for current ideas to have provisioning that is dependent of state of another system being up.  

Problem: Because systems come up sequentially (one at a time), need way to delay a config until after the another system is up.  If the systems were brought in parallel (like containers in docker-compose), I could then wait until the other systems come up. 

Use Cases:  For simple web development, web app may need to seed or db:migrate on an external database server, and for more advance scenarios, may need to populate data on other persistence (mem, nosql) or queuing systems, etc.  Other advanced cases (maybe sys engr testing) are popular ldap with user accounts for SSO on other LDAP client systems, load balancer w/ web backends, static monitoring depending on client systems to be monitored.

Solutions: Any solutions / patterns / best practices on this?  I would use vagrant ssh -c cmd outside of vagrant, but defeats the point of using a shell provisioner.  If I use Ansible, as Ansible is a remote-execution oriented, I would use it outside of vagrant.  But as vagrant is handling the provisioning and orchestration, would like to do it from within itself.

--
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/f8cbdebc-633e-4106-8700-248c2d55dde7%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/CAHqq0ez%2B8820_8hjCqhQJ%2B75ZWBPivjpn6C7Mj8Z83ExHzae7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.