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

Tue Aug 23 18:41:10 UTC 2016

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 <zach at wecreate.com> 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 <http://www.wecreate.com>
> 814.580.6636
>
> On Aug 23, 2016, at 1:26 PM, Umberto Nicoletti <
> umberto.nicoletti at gmail.com> wrote:
>
> Why not use https://cloudinit.readthedocs.io/en/latest/ ?
>
> On Tuesday, August 23, 2016, Zach Lanich <zach at zachlanich.com> 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 <http://www.wecreate.com/>*
>>
>> On Aug 23, 2016, at 1:05 PM, P. Lowe <plowe at zitovault.com> 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 <zach at zachlanich.com>:
>>
>> 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 <http://www.wecreate.com/>
>>
>> On Aug 17, 2016, at 4:48 PM, P. Lowe <plowe at zitovault.com> 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 at lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>>
>>
>>
>>
>>
>> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160823/1ddd416d/attachment.html>