[chef] Re: Re: Re: Re: Deploy production servers with vagrant

[Sterling Windmill < >]

Docker's remote API looks to provide a possible solution in the surface (although I've not personally used it):

http://docs.docker.io/en/latest/api/docker_remote_api/

On Oct 31, 2013, at 1:17 PM, Torben Knerr < "> > wrote:

@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

On Oct 31, 2013 4:26 PM, "Tom Duffield" < "> > wrote:

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.

On Oct 31, 2013, at 8:19 AM, Vladimir Skubriev < " target="_blank"> > wrote:

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