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

Umberto Nicoletti umberto.nicoletti at gmail.com
Tue Aug 23 17:26:13 UTC 2016


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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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/62027c33/attachment.html>


More information about the lxc-users mailing list