Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Eric]

On Thu, Sep 8, 2016, 01:05 Zach Lanich  wrote:
Umberto, I’m not 100% sure of what SaltStack uses under the hood lib wise,
but it’s written in Python an already does everything that Lib does. We’re
talking more of how the creation of the LXD containers themselves,
including setting Mounts, Static IP, etc. SaltStack & Chef handle
everything else from there once the provisioned container is connected to
the master. CloudInit would certainly be an option as the 2nd part of the
equation if we weren’t already using a configuration management tool

@zach, what configuration management tool are you guys using?
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Zach Lanich]

Umberto, I’m not 100% sure of what SaltStack uses under the hood lib wise, but 
it’s written in Python an already does everything that Lib does. We’re talking 
more of how the creation of the LXD containers themselves, including setting 
Mounts, Static IP, etc. SaltStack & Chef handle everything else from there once 
the provisioned container is connected to the master. CloudInit would certainly 
be an option as the 2nd part of the equation if we weren’t already using a 
configuration management tool. 

Does that make sense, or am I’m misinterpreting your point?

Best Regards,

Zach Lanich
Owner/CTO
weCreate LLC
www.WeCreate.com
814.580.6636

> On Aug 23, 2016, at 1:26 PM, Umberto Nicoletti  
> wrote:
> 
> Why not use https://cloudinit.readthedocs.io/en/latest/ 
>  ?
> 
> On Tuesday, August 23, 2016, Zach Lanich  > wrote:
> I’m not sure of the best way to pass LXD/Container specific parameters is yet 
> (so anyone, please chime in if you have advice), but I’m using SaltStack at 
> the moment and doing something similar. I’m currently running w/e necessary 
> commands to provision the container itself, setting the container’s IP via a 
> custom dnsmasq conf file, then using lxc exec to download the latest salt 
> bootstrap and run it, then I just trigger a key-accept on the master for the 
> container so the container acts just like any other minion and I can run 
> State/Scripts, etc on it from there on.
> 
> Hopefully that helps in some way lol. Still awaiting best practice advice for 
> passing container params for provision!
> 
> Best Regards,
> 
> Zach Lanich
> Business Owner, Entrepreneur, Creative
> Owner/CTO
> weCreate LLC
> www.WeCreate.com 
>> On Aug 23, 2016, at 1:05 PM, P. Lowe > > wrote:
>> 
>> Hi Zach,
>> 
>> No, I still haven't received an answer on this.
>> 
>> I'm still trying to determine if there is a best practice for passing 
>> provisioning parameters to an lxd container (hostname, block device mounts, 
>> secrets, monitoring server name for pub/sub, etc.)
>> 
>> I'm currently using a technique where I launch a new image, start it, and 
>> then do a:
>> 
>> "lxd file push ./provision.sh /container1/etc/rc.local"
>> 
>> Then I restart the container and it runs the provisioning in /etc/rc.local 
>> (pull and execute chef cookbook from git), and then reset rc.local to empty, 
>> so that future restarts won't re-run the provisioning.
>> 
>> Still trying to determine best way to pass provisioning parameters to the 
>> container...
>> 
>> -P. Lowe
>> 
>> 
>> Quoting Zach Lanich > >:
>> 
>>> P.Lowe, did you ever get an answer on this. I’m doing something very 
>>> similar with SaltStack.
>>> 
>>> Best Regards,
>>> 
>>> Zach Lanich
>>> Business Owner, Entrepreneur, Creative
>>> Owner/CTO
>>> weCreate LLC
>>> www.WeCreate.com 
>>> 
 On Aug 17, 2016, at 4:48 PM, P. Lowe > wrote:
 
 
 Hi,
 
 I am investigating the use of lxd to dynamically spin up server instances.
 
 I'm thinking about using a code-as-infrastructure approach using a 
 chef-solo cookbook that is pulled out of git upon the container's initial 
 boot and does all the provisioning upon initial boot.
 
 Would people recommend creating a new container from a base image, 
 modifying rc.local to pull the cookbook from git and launch it upon 
 initial bootup, after which rc.local is reset to be empty and the server 
 is restarted?
 
 After rc.local is modified, the new container would be published to the 
 local image store, so that whenever a new container is launched, it will 
 boot up, run rc.local, pull the cookbook from git, run the cookbook and 
 apply all the local provisioning operations, empty out rc.local, and then 
 reboot the machine, after which it will boot with the customized 
 provisioning parameters for normal operation.
 
 What is the recommended way to send provisioning parameters (e.g. ip 
 address, gateway, hostname, block device mounts, secrets (certs / keys)) 
 to the container? Would people just drop a config file into the container 
 using the lxc push command, or any other better techniques?
 
 Thanks,
 
 P.Lowe
 
 
 ___
 lxc-users mailing list
 lxc-users@lists.linuxcontainers.org 
 
 http://lists.linuxcontainers.org/listinfo/lxc-users 
 
>> 
>> 
>> 
>> 
> 
> 

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Zach Lanich]

That makes sense to me.

Best Regards,

Zach Lanich
Owner/CTO
weCreate LLC
www.WeCreate.com
814.580.6636

> On Aug 23, 2016, at 2:41 PM, Umberto Nicoletti  
> wrote:
> 
> P. Lowe asked:
> 
> Would people recommend creating a new container from a base image, modifying 
> rc.local to pull the cookbook from git and launch it upon initial bootup, 
> after which rc.local is reset to be empty and the server is restarted?
> 
> this is exactly a cloud-init use case: cloud-init with a bootstrap script in 
> user-data (like EC2 does).
> 
> You could of course swap cloud-init out for a custom salt-bootstrap, clone, 
> state.highstate flow and still get the job done.
> 
> But as far as I am concerned I find the additional abstraction layer and 
> flexibility provided by cloud-init to be convenient enough.
> 
> So my suggestion for P. Lowe is:
> 
> use cloud-init to drive the bootstrap process: early init, cloning cookbook, 
> installing chef and whatnot
> 
> then let chef take over and complete the configuration phase.
> 
> On Tue, Aug 23, 2016 at 7:44 PM, Zach Lanich  > wrote:
> Umberto, I’m not 100% sure of what SaltStack uses under the hood lib wise, 
> but it’s written in Python an already does everything that Lib does. We’re 
> talking more of how the creation of the LXD
> 
> I think the provisioning phase or how you manage containers (creation, move, 
> destroy, etc) is beyond (actually it is before :-)) P. Lowe's question scope 
> but you could certainly do that with SaltStack or through the container mgmt 
> API directly.
>  
> containers themselves, including setting Mounts, Static IP, etc. SaltStack & 
> Chef handle everything else from there once the provisioned container is 
> connected to the master. CloudInit would certainly be an option as the 2nd 
> part of the equation if we weren’t already using a configuration management 
> tool. 
> 
> Does that make sense, or am I’m misinterpreting your point?
> 
> Hope this clarify by previously hurried email :-)
>  
> BR,
> Umberto
> 
> 
> Best Regards,
> 
> Zach Lanich
> Owner/CTO
> weCreate LLC
> www.WeCreate.com 
> 814.580.6636 
> 
>> On Aug 23, 2016, at 1:26 PM, Umberto Nicoletti > > wrote:
>> 
>> Why not use https://cloudinit.readthedocs.io/en/latest/ 
>>  ?
>> 
>> On Tuesday, August 23, 2016, Zach Lanich > > wrote:
>> I’m not sure of the best way to pass LXD/Container specific parameters is 
>> yet (so anyone, please chime in if you have advice), but I’m using SaltStack 
>> at the moment and doing something similar. I’m currently running w/e 
>> necessary commands to provision the container itself, setting the 
>> container’s IP via a custom dnsmasq conf file, then using lxc exec to 
>> download the latest salt bootstrap and run it, then I just trigger a 
>> key-accept on the master for the container so the container acts just like 
>> any other minion and I can run State/Scripts, etc on it from there on.
>> 
>> Hopefully that helps in some way lol. Still awaiting best practice advice 
>> for passing container params for provision!
>> 
>> Best Regards,
>> 
>> Zach Lanich
>> Business Owner, Entrepreneur, Creative
>> Owner/CTO
>> weCreate LLC
>> www.WeCreate.com 
>>> On Aug 23, 2016, at 1:05 PM, P. Lowe > wrote:
>>> 
>>> Hi Zach,
>>> 
>>> No, I still haven't received an answer on this.
>>> 
>>> I'm still trying to determine if there is a best practice for passing 
>>> provisioning parameters to an lxd container (hostname, block device mounts, 
>>> secrets, monitoring server name for pub/sub, etc.)
>>> 
>>> I'm currently using a technique where I launch a new image, start it, and 
>>> then do a:
>>> 
>>> "lxd file push ./provision.sh /container1/etc/rc.local"
>>> 
>>> Then I restart the container and it runs the provisioning in /etc/rc.local 
>>> (pull and execute chef cookbook from git), and then reset rc.local to 
>>> empty, so that future restarts won't re-run the provisioning.
>>> 
>>> Still trying to determine best way to pass provisioning parameters to the 
>>> container...
>>> 
>>> -P. Lowe
>>> 
>>> 
>>> Quoting Zach Lanich >:
>>> 
 P.Lowe, did you ever get an answer on this. I’m doing something very 
 similar with SaltStack.
 
 Best Regards,
 
 Zach Lanich
 Business Owner, Entrepreneur, Creative
 Owner/CTO
 weCreate LLC
 www.WeCreate.com 
 
> On Aug 17, 2016, at 4:48 PM, P. Lowe > wrote:
> 
> 
> Hi,
> 
> I am investigating the use of lxd to dynamically spin up server instances.
> 
> I'm thinking about using a code-as-infrastructure approach using a 
> chef-solo cookbook that is pulled out of 

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Zach Lanich]

That makes sense to me.

Best Regards,

Zach Lanich
Business Owner, Entrepreneur, Creative
Owner/CTO
weCreate LLC
www.WeCreate.com

> On Aug 23, 2016, at 2:41 PM, Umberto Nicoletti  
> wrote:
> 
> P. Lowe asked:
> 
> Would people recommend creating a new container from a base image, modifying 
> rc.local to pull the cookbook from git and launch it upon initial bootup, 
> after which rc.local is reset to be empty and the server is restarted?
> 
> this is exactly a cloud-init use case: cloud-init with a bootstrap script in 
> user-data (like EC2 does).
> 
> You could of course swap cloud-init out for a custom salt-bootstrap, clone, 
> state.highstate flow and still get the job done.
> 
> But as far as I am concerned I find the additional abstraction layer and 
> flexibility provided by cloud-init to be convenient enough.
> 
> So my suggestion for P. Lowe is:
> 
> use cloud-init to drive the bootstrap process: early init, cloning cookbook, 
> installing chef and whatnot
> 
> then let chef take over and complete the configuration phase.
> 
> On Tue, Aug 23, 2016 at 7:44 PM, Zach Lanich  > wrote:
> Umberto, I’m not 100% sure of what SaltStack uses under the hood lib wise, 
> but it’s written in Python an already does everything that Lib does. We’re 
> talking more of how the creation of the LXD 
> 
> I think the provisioning phase or how you manage containers (creation, move, 
> destroy, etc) is beyond (actually it is before :-)) P. Lowe's question scope 
> but you could certainly do that with SaltStack or through the container mgmt 
> API directly.
>  
> containers themselves, including setting Mounts, Static IP, etc. SaltStack & 
> Chef handle everything else from there once the provisioned container is 
> connected to the master. CloudInit would certainly be an option as the 2nd 
> part of the equation if we weren’t already using a configuration management 
> tool. 
> 
> Does that make sense, or am I’m misinterpreting your point?
> 
> Hope this clarify by previously hurried email :-)
>  
> BR,
> Umberto
> 
> 
> Best Regards,
> 
> Zach Lanich
> Owner/CTO
> weCreate LLC
> www.WeCreate.com 
> 814.580.6636 
> 
>> On Aug 23, 2016, at 1:26 PM, Umberto Nicoletti > > wrote:
>> 
>> Why not use https://cloudinit.readthedocs.io/en/latest/ 
>>  ?
>> 
>> On Tuesday, August 23, 2016, Zach Lanich > > wrote:
>> I’m not sure of the best way to pass LXD/Container specific parameters is 
>> yet (so anyone, please chime in if you have advice), but I’m using SaltStack 
>> at the moment and doing something similar. I’m currently running w/e 
>> necessary commands to provision the container itself, setting the 
>> container’s IP via a custom dnsmasq conf file, then using lxc exec to 
>> download the latest salt bootstrap and run it, then I just trigger a 
>> key-accept on the master for the container so the container acts just like 
>> any other minion and I can run State/Scripts, etc on it from there on.
>> 
>> Hopefully that helps in some way lol. Still awaiting best practice advice 
>> for passing container params for provision!
>> 
>> Best Regards,
>> 
>> Zach Lanich
>> Business Owner, Entrepreneur, Creative
>> Owner/CTO
>> weCreate LLC
>> www.WeCreate.com 
>>> On Aug 23, 2016, at 1:05 PM, P. Lowe > wrote:
>>> 
>>> Hi Zach,
>>> 
>>> No, I still haven't received an answer on this.
>>> 
>>> I'm still trying to determine if there is a best practice for passing 
>>> provisioning parameters to an lxd container (hostname, block device mounts, 
>>> secrets, monitoring server name for pub/sub, etc.)
>>> 
>>> I'm currently using a technique where I launch a new image, start it, and 
>>> then do a:
>>> 
>>> "lxd file push ./provision.sh /container1/etc/rc.local"
>>> 
>>> Then I restart the container and it runs the provisioning in /etc/rc.local 
>>> (pull and execute chef cookbook from git), and then reset rc.local to 
>>> empty, so that future restarts won't re-run the provisioning.
>>> 
>>> Still trying to determine best way to pass provisioning parameters to the 
>>> container...
>>> 
>>> -P. Lowe
>>> 
>>> 
>>> Quoting Zach Lanich >:
>>> 
 P.Lowe, did you ever get an answer on this. I’m doing something very 
 similar with SaltStack.
 
 Best Regards,
 
 Zach Lanich
 Business Owner, Entrepreneur, Creative
 Owner/CTO
 weCreate LLC
 www.WeCreate.com 
 
> On Aug 17, 2016, at 4:48 PM, P. Lowe > wrote:
> 
> 
> Hi,
> 
> I am investigating the use of lxd to dynamically spin up server instances.
> 
> I'm thinking about using a code-as-infrastructure approach using a 
> chef-solo 

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Umberto Nicoletti]

P. Lowe asked:

*Would people recommend creating a new container from a base image,
modifying rc.local to pull the cookbook from git and launch it upon initial
bootup, after which rc.local is reset to be empty and the server is
restarted?*

this is exactly a cloud-init use case: cloud-init with a bootstrap script
in user-data (like EC2 does).

You could of course swap cloud-init out for a custom salt-bootstrap, clone,
state.highstate flow and still get the job done.

But as far as I am concerned I find the additional abstraction layer and
flexibility provided by cloud-init to be convenient enough.

So my suggestion for P. Lowe is:

use cloud-init to drive the bootstrap process: early init, cloning
cookbook, installing chef and whatnot

then let chef take over and complete the configuration phase.

On Tue, Aug 23, 2016 at 7:44 PM, Zach Lanich  wrote:

> Umberto, I’m not 100% sure of what SaltStack uses under the hood lib wise,
> but it’s written in Python an already does everything that Lib does. We’re
> talking more of how the creation of the LXD
>

I think the provisioning phase or how you manage containers (creation,
move, destroy, etc) is beyond (actually it is before :-)) P. Lowe's
question scope but you could certainly do that with SaltStack or through
the container mgmt API directly.


> containers themselves, including setting Mounts, Static IP, etc. SaltStack
> & Chef handle everything else from there once the provisioned container is
> connected to the master. CloudInit would certainly be an option as the 2nd
> part of the equation if we weren’t already using a configuration management
> tool.
>
> Does that make sense, or am I’m misinterpreting your point?
>

Hope this clarify by previously hurried email :-)

BR,
Umberto


> Best Regards,
>
> Zach Lanich
> *Owner/CTO*
> weCreate LLC
> www.WeCreate.com 
> 814.580.6636
>
> On Aug 23, 2016, at 1:26 PM, Umberto Nicoletti <
> umberto.nicole...@gmail.com> wrote:
>
> Why not use https://cloudinit.readthedocs.io/en/latest/ ?
>
> On Tuesday, August 23, 2016, Zach Lanich  wrote:
>
>> I’m not sure of the best way to pass LXD/Container specific parameters is
>> yet (so anyone, please chime in if you have advice), but I’m using
>> SaltStack at the moment and doing something similar. I’m currently running
>> w/e necessary commands to provision the container itself, setting the
>> container’s IP via a custom dnsmasq conf file, then using lxc exec to
>> download the latest salt bootstrap and run it, then I just trigger a
>> key-accept on the master for the container so the container acts just like
>> any other minion and I can run State/Scripts, etc on it from there on.
>>
>> Hopefully that helps in some way lol. Still awaiting best practice advice
>> for passing container params for provision!
>>
>> Best Regards,
>>
>> Zach Lanich
>> *Business Owner, Entrepreneur, Creative*
>> *Owner/CTO*
>> weCreate LLC
>> *www.WeCreate.com *
>>
>> On Aug 23, 2016, at 1:05 PM, P. Lowe  wrote:
>>
>> Hi Zach,
>>
>> No, I still haven't received an answer on this.
>>
>> I'm still trying to determine if there is a best practice for passing
>> provisioning parameters to an lxd container (hostname, block device mounts,
>> secrets, monitoring server name for pub/sub, etc.)
>>
>> I'm currently using a technique where I launch a new image, start it, and
>> then do a:
>>
>> "lxd file push ./provision.sh /container1/etc/rc.local"
>>
>> Then I restart the container and it runs the provisioning in
>> /etc/rc.local (pull and execute chef cookbook from git), and then reset
>> rc.local to empty, so that future restarts won't re-run the provisioning.
>>
>> Still trying to determine best way to pass provisioning parameters to the
>> container...
>>
>> -P. Lowe
>>
>>
>> Quoting Zach Lanich :
>>
>> P.Lowe, did you ever get an answer on this. I’m doing something very
>> similar with SaltStack.
>>
>> Best Regards,
>>
>> Zach Lanich
>> Business Owner, Entrepreneur, Creative
>> Owner/CTO
>> weCreate LLC
>> www.WeCreate.com 
>>
>> On Aug 17, 2016, at 4:48 PM, P. Lowe  wrote:
>>
>>
>> Hi,
>>
>> I am investigating the use of lxd to dynamically spin up server instances.
>>
>> I'm thinking about using a code-as-infrastructure approach using a
>> chef-solo cookbook that is pulled out of git upon the container's initial
>> boot and does all the provisioning upon initial boot.
>>
>> Would people recommend creating a new container from a base image,
>> modifying rc.local to pull the cookbook from git and launch it upon initial
>> bootup, after which rc.local is reset to be empty and the server is
>> restarted?
>>
>> After rc.local is modified, the new container would be published to the
>> local image store, so that whenever a new container is launched, it will
>> boot up, run rc.local, pull the cookbook from git, run the cookbook 

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Umberto Nicoletti]

Why not use https://cloudinit.readthedocs.io/en/latest/ ?

On Tuesday, August 23, 2016, Zach Lanich  wrote:

> I’m not sure of the best way to pass LXD/Container specific parameters is
> yet (so anyone, please chime in if you have advice), but I’m using
> SaltStack at the moment and doing something similar. I’m currently running
> w/e necessary commands to provision the container itself, setting the
> container’s IP via a custom dnsmasq conf file, then using lxc exec to
> download the latest salt bootstrap and run it, then I just trigger a
> key-accept on the master for the container so the container acts just like
> any other minion and I can run State/Scripts, etc on it from there on.
>
> Hopefully that helps in some way lol. Still awaiting best practice advice
> for passing container params for provision!
>
> Best Regards,
>
> Zach Lanich
> *Business Owner, Entrepreneur, Creative*
> *Owner/CTO*
> weCreate LLC
> *www.WeCreate.com *
>
> On Aug 23, 2016, at 1:05 PM, P. Lowe  > wrote:
>
> Hi Zach,
>
> No, I still haven't received an answer on this.
>
> I'm still trying to determine if there is a best practice for passing
> provisioning parameters to an lxd container (hostname, block device mounts,
> secrets, monitoring server name for pub/sub, etc.)
>
> I'm currently using a technique where I launch a new image, start it, and
> then do a:
>
> "lxd file push ./provision.sh /container1/etc/rc.local"
>
> Then I restart the container and it runs the provisioning in /etc/rc.local
> (pull and execute chef cookbook from git), and then reset rc.local to
> empty, so that future restarts won't re-run the provisioning.
>
> Still trying to determine best way to pass provisioning parameters to the
> container...
>
> -P. Lowe
>
>
> Quoting Zach Lanich  >:
>
> P.Lowe, did you ever get an answer on this. I’m doing something very
> similar with SaltStack.
>
> Best Regards,
>
> Zach Lanich
> Business Owner, Entrepreneur, Creative
> Owner/CTO
> weCreate LLC
> www.WeCreate.com 
>
> On Aug 17, 2016, at 4:48 PM, P. Lowe  > wrote:
>
>
> Hi,
>
> I am investigating the use of lxd to dynamically spin up server instances.
>
> I'm thinking about using a code-as-infrastructure approach using a
> chef-solo cookbook that is pulled out of git upon the container's initial
> boot and does all the provisioning upon initial boot.
>
> Would people recommend creating a new container from a base image,
> modifying rc.local to pull the cookbook from git and launch it upon initial
> bootup, after which rc.local is reset to be empty and the server is
> restarted?
>
> After rc.local is modified, the new container would be published to the
> local image store, so that whenever a new container is launched, it will
> boot up, run rc.local, pull the cookbook from git, run the cookbook and
> apply all the local provisioning operations, empty out rc.local, and then
> reboot the machine, after which it will boot with the customized
> provisioning parameters for normal operation.
>
> What is the recommended way to send provisioning parameters (e.g. ip
> address, gateway, hostname, block device mounts, secrets (certs / keys)) to
> the container? Would people just drop a config file into the container
> using the lxc push command, or any other better techniques?
>
> Thanks,
>
> P.Lowe
>
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> 
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
>
>
>
>
>
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Zach Lanich]

I’m not sure of the best way to pass LXD/Container specific parameters is yet 
(so anyone, please chime in if you have advice), but I’m using SaltStack at the 
moment and doing something similar. I’m currently running w/e necessary 
commands to provision the container itself, setting the container’s IP via a 
custom dnsmasq conf file, then using lxc exec to download the latest salt 
bootstrap and run it, then I just trigger a key-accept on the master for the 
container so the container acts just like any other minion and I can run 
State/Scripts, etc on it from there on.

Hopefully that helps in some way lol. Still awaiting best practice advice for 
passing container params for provision!

Best Regards,

Zach Lanich
Business Owner, Entrepreneur, Creative
Owner/CTO
weCreate LLC
www.WeCreate.com

> On Aug 23, 2016, at 1:05 PM, P. Lowe  wrote:
> 
> Hi Zach,
> 
> No, I still haven't received an answer on this.
> 
> I'm still trying to determine if there is a best practice for passing 
> provisioning parameters to an lxd container (hostname, block device mounts, 
> secrets, monitoring server name for pub/sub, etc.)
> 
> I'm currently using a technique where I launch a new image, start it, and 
> then do a:
> 
> "lxd file push ./provision.sh /container1/etc/rc.local"
> 
> Then I restart the container and it runs the provisioning in /etc/rc.local 
> (pull and execute chef cookbook from git), and then reset rc.local to empty, 
> so that future restarts won't re-run the provisioning.
> 
> Still trying to determine best way to pass provisioning parameters to the 
> container...
> 
> -P. Lowe
> 
> 
> Quoting Zach Lanich :
> 
>> P.Lowe, did you ever get an answer on this. I’m doing something very similar 
>> with SaltStack.
>> 
>> Best Regards,
>> 
>> Zach Lanich
>> Business Owner, Entrepreneur, Creative
>> Owner/CTO
>> weCreate LLC
>> www.WeCreate.com
>> 
>>> On Aug 17, 2016, at 4:48 PM, P. Lowe  wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> I am investigating the use of lxd to dynamically spin up server instances.
>>> 
>>> I'm thinking about using a code-as-infrastructure approach using a 
>>> chef-solo cookbook that is pulled out of git upon the container's initial 
>>> boot and does all the provisioning upon initial boot.
>>> 
>>> Would people recommend creating a new container from a base image, 
>>> modifying rc.local to pull the cookbook from git and launch it upon initial 
>>> bootup, after which rc.local is reset to be empty and the server is 
>>> restarted?
>>> 
>>> After rc.local is modified, the new container would be published to the 
>>> local image store, so that whenever a new container is launched, it will 
>>> boot up, run rc.local, pull the cookbook from git, run the cookbook and 
>>> apply all the local provisioning operations, empty out rc.local, and then 
>>> reboot the machine, after which it will boot with the customized 
>>> provisioning parameters for normal operation.
>>> 
>>> What is the recommended way to send provisioning parameters (e.g. ip 
>>> address, gateway, hostname, block device mounts, secrets (certs / keys)) to 
>>> the container? Would people just drop a config file into the container 
>>> using the lxc push command, or any other better techniques?
>>> 
>>> Thanks,
>>> 
>>> P.Lowe
>>> 
>>> 
>>> ___
>>> lxc-users mailing list
>>> lxc-users@lists.linuxcontainers.org
>>> http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> 
> 
> 

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[P. Lowe]

Hi Zach,

No, I still haven't received an answer on this.

I'm still trying to determine if there is a best practice for passing  
provisioning parameters to an lxd container (hostname, block device  
mounts, secrets, monitoring server name for pub/sub, etc.)


I'm currently using a technique where I launch a new image, start it,  
and then do a:


"lxd file push ./provision.sh /container1/etc/rc.local"

Then I restart the container and it runs the provisioning in  
/etc/rc.local (pull and execute chef cookbook from git), and then  
reset rc.local to empty, so that future restarts won't re-run the  
provisioning.


Still trying to determine best way to pass provisioning parameters to  
the container...


-P. Lowe


Quoting Zach Lanich :

P.Lowe, did you ever get an answer on this. I’m doing something very  
similar with SaltStack.


Best Regards,

Zach Lanich
Business Owner, Entrepreneur, Creative
Owner/CTO
weCreate LLC
www.WeCreate.com


On Aug 17, 2016, at 4:48 PM, P. Lowe  wrote:


Hi,

I am investigating the use of lxd to dynamically spin up server instances.

I'm thinking about using a code-as-infrastructure approach using a  
chef-solo cookbook that is pulled out of git upon the container's  
initial boot and does all the provisioning upon initial boot.


Would people recommend creating a new container from a base image,  
modifying rc.local to pull the cookbook from git and launch it upon  
initial bootup, after which rc.local is reset to be empty and the  
server is restarted?


After rc.local is modified, the new container would be published to  
the local image store, so that whenever a new container is  
launched, it will boot up, run rc.local, pull the cookbook from  
git, run the cookbook and apply all the local provisioning  
operations, empty out rc.local, and then reboot the machine, after  
which it will boot with the customized provisioning parameters for  
normal operation.


What is the recommended way to send provisioning parameters (e.g.  
ip address, gateway, hostname, block device mounts, secrets (certs  
/ keys)) to the container? Would people just drop a config file  
into the container using the lxc push command, or any other better  
techniques?


Thanks,

P.Lowe


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users





___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Ingo Baab]

sorry list,
- this mail was accidentally send by me to the list..  sorry.
-Ingo


Am 23.08.2016 um 17:56 schrieb Ingo Baab:


https://www.youtube.com/watch?v=5PXxINlP_8Y

http://mysticlabs.com/consulting/



Am 23.08.2016 um 17:02 schrieb Zach Lanich:
P.Lowe, did you ever get an answer on this. I’m doing something very 
similar with SaltStack.


Best Regards,

Zach Lanich
/Business Owner, Entrepreneur, Creative/
*/Owner/CTO/*
weCreate LLC
/www.WeCreate.com /

On Aug 17, 2016, at 4:48 PM, P. Lowe > wrote:



Hi,

I am investigating the use of lxd to dynamically spin up server 
instances.


I'm thinking about using a code-as-infrastructure approach using a 
chef-solo cookbook that is pulled out of git upon the container's 
initial boot and does all the provisioning upon initial boot.


Would people recommend creating a new container from a base image, 
modifying rc.local to pull the cookbook from git and launch it upon 
initial bootup, after which rc.local is reset to be empty and the 
server is restarted?


After rc.local is modified, the new container would be published to 
the local image store, so that whenever a new container is launched, 
it will boot up, run rc.local, pull the cookbook from git, run the 
cookbook and apply all the local provisioning operations, empty out 
rc.local, and then reboot the machine, after which it will boot with 
the customized provisioning parameters for normal operation.


What is the recommended way to send provisioning parameters (e.g. ip 
address, gateway, hostname, block device mounts, secrets (certs / 
keys)) to the container? Would people just drop a config file into 
the container using the lxc push command, or any other better 
techniques?


Thanks,

P.Lowe


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org 


http://lists.linuxcontainers.org/listinfo/lxc-users




___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users




___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Ingo Baab]

https://www.youtube.com/watch?v=5PXxINlP_8Y

http://mysticlabs.com/consulting/



Am 23.08.2016 um 17:02 schrieb Zach Lanich:
P.Lowe, did you ever get an answer on this. I’m doing something very 
similar with SaltStack.


Best Regards,

Zach Lanich
/Business Owner, Entrepreneur, Creative/
*/Owner/CTO/*
weCreate LLC
/www.WeCreate.com /

On Aug 17, 2016, at 4:48 PM, P. Lowe > wrote:



Hi,

I am investigating the use of lxd to dynamically spin up server 
instances.


I'm thinking about using a code-as-infrastructure approach using a 
chef-solo cookbook that is pulled out of git upon the container's 
initial boot and does all the provisioning upon initial boot.


Would people recommend creating a new container from a base image, 
modifying rc.local to pull the cookbook from git and launch it upon 
initial bootup, after which rc.local is reset to be empty and the 
server is restarted?


After rc.local is modified, the new container would be published to 
the local image store, so that whenever a new container is launched, 
it will boot up, run rc.local, pull the cookbook from git, run the 
cookbook and apply all the local provisioning operations, empty out 
rc.local, and then reboot the machine, after which it will boot with 
the customized provisioning parameters for normal operation.


What is the recommended way to send provisioning parameters (e.g. ip 
address, gateway, hostname, block device mounts, secrets (certs / 
keys)) to the container? Would people just drop a config file into 
the container using the lxc push command, or any other better techniques?


Thanks,

P.Lowe


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org 


http://lists.linuxcontainers.org/listinfo/lxc-users




___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[Zach Lanich]

P.Lowe, did you ever get an answer on this. I’m doing something very similar 
with SaltStack.

Best Regards,

Zach Lanich
Business Owner, Entrepreneur, Creative
Owner/CTO
weCreate LLC
www.WeCreate.com

> On Aug 17, 2016, at 4:48 PM, P. Lowe  wrote:
> 
> 
> Hi,
> 
> I am investigating the use of lxd to dynamically spin up server instances.
> 
> I'm thinking about using a code-as-infrastructure approach using a chef-solo 
> cookbook that is pulled out of git upon the container's initial boot and does 
> all the provisioning upon initial boot.
> 
> Would people recommend creating a new container from a base image, modifying 
> rc.local to pull the cookbook from git and launch it upon initial bootup, 
> after which rc.local is reset to be empty and the server is restarted?
> 
> After rc.local is modified, the new container would be published to the local 
> image store, so that whenever a new container is launched, it will boot up, 
> run rc.local, pull the cookbook from git, run the cookbook and apply all the 
> local provisioning operations, empty out rc.local, and then reboot the 
> machine, after which it will boot with the customized provisioning parameters 
> for normal operation.
> 
> What is the recommended way to send provisioning parameters (e.g. ip address, 
> gateway, hostname, block device mounts, secrets (certs / keys)) to the 
> container? Would people just drop a config file into the container using the 
> lxc push command, or any other better techniques?
> 
> Thanks,
> 
> P.Lowe
> 
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Recommended techniques for dynamically provisioning containers using lxd

[P. Lowe]

 Hi,

I am investigating the use of lxd to dynamically spin up server instances.

I'm thinking about using a code-as-infrastructure approach using a  
chef-solo cookbook that is pulled out of git upon the container's  
initial boot and does all the provisioning upon initial boot.


Would people recommend creating a new container from a base image,  
modifying rc.local to pull the cookbook from git and launch it upon  
initial bootup, after which rc.local is reset to be empty and the  
server is restarted?


After rc.local is modified, the new container would be published to  
the local image store, so that whenever a new container is launched,  
it will boot up, run rc.local, pull the cookbook from git, run the  
cookbook and apply all the local provisioning operations, empty out  
rc.local, and then reboot the machine, after which it will boot with  
the customized provisioning parameters for normal operation.


What is the recommended way to send provisioning parameters (e.g. ip  
address, gateway, hostname, block device mounts, secrets (certs /  
keys)) to the container? Would people just drop a config file into the  
container using the lxc push command, or any other better techniques?


Thanks,

P.Lowe


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users