In our workflow we using lxc containers to run service that setuped by
chef-client
How I can automate deploys without vagrant?
Bash scripting, ruby scripting or manual?
Manual: lxc-create, lxc-start, ssh, some preparations, install chef,
bootstrap, run chef-client, enable auto run container
I already has a some simple script to automate this. But I think this is
a wrong way, because Vagrant exists.
Vagrant has lxc plugin, but then vagrant must be installed and run on
that host server. (Is I’m right?)
Is this a good work flow (vagrant installed in home of serveradmin user) ?
I suppose this use case:
- I has a application cookbook with true Vagrantfile for using with
lxc-provider - I will create a cookbook to run on host server to install vagrant.
- I will clone needed application repos to srvadm home’s
- cd to application repo root and run vagrant up
What’s next?
Where information will be stored on this machine?
How I can understand vagrant will creating container and then star it.
Where vagrant is store information about running machines and how it
corresponds to my work flow ?
If I want to remove it, I’ll command ‘vagrant destroy’ and container
will be deleted.
Suppose I has a different one application coobook named application2 (I
suppose that I will use only container for one application cookbook)
I must cd to another application repo root dir and command vagrant up ?
And what will happen to the last virtual machine? It’s continue to work ?
Anybody uses vagrant for production in this use case ?
What additional settings in Vagrantfile you are using when setting up a
production servers (Not necessarily lxc, of course). Maybe setup ssh
keys, which is storing in the same git application repo?
Which additional setting can be stored in application cookbook repository ?
Additional I have a small question about lxc vagrant plugin:
How I can override bridge name, if I want to use plugin installed with
command *vagrant plugin install lxc* instead of cloning source
version and fix this manually ?
Thank you very much.
–
Best regards,
CVision Lab System Administrator
Vladmir Skubriev