@Tom: yes, that's the association which people typically have with vagrant from the time when it was virtualbox only.
I think the problem that Vladimir faces is that lxc is a local "virtualization" technology like virtualbox and vmware are. There is no remote API which acts as an interface for managing lxc containers, like there are APIs for managing aws, rackspace or vsphere instances.
Does docker solve that problem?
Cheers, Torben
I would avoid (or at least be incredibly careful when) using Vagrant in production. Vagrant was designed to be an iterative testing tool for your local workstation, not a utility to manage your production infrastructure. I would look into an alternative like Docker (as Sterling mentioned)Tom Duffield — Automation Consulting Engineer
651.769.7497 – " style="color:rgb(105,117,130)" target="_blank"> – my: Linkedin Twitter
OPSCODE
CODE CAN
opscode.com Blog Facebook Twitter YouTube On Thu, Oct 31, 2013 at 7:21 AM, Sterling Windmill < " target="_blank"> > wrote:You may want to look into http://www.docker.io which uses LXC under the covers.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:
1. I has a application cookbook with true Vagrantfile for using with lxc-provider
2. I will create a cookbook to run on host server to install vagrant.
3. I will clone needed application repos to srvadm home's
4. 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
Archive powered by MHonArc 2.6.16.