my new lxc puppet template is growing

I am using puppet to manage my containers. This might have some disadvantages in form of speed but the advantage is that it is
only the puppet service that needs to be secured, not an lxd or some other service. So what…

lets see how that works, the following hiera stencil defines me a virtual machine, this time without an
ip addess, but it can come with one at all:

- ethSand
lxc::vm::sandbox::network::ethSand: brsandbox

lxc::vm::sandbox::puppet: True
lxc::vm::sandbox::autostart: True

lxc::vm::sandbox::rawconfig: |
# this is the tun tap device
lxc.cgroup.devices.allow = c 10:200 rwm
lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file 0 0

as soon as I enable

- lxc
. sandbox

the machinery starts its work: it checks for any lxc maintainace scripts and a logindefs class to set subuids, as soon as all prereqs are there it

  • creates a user
  • creates subuid and subgid ranges in lxc configuration
  • creates network permissions
  • installs a local debian os template with puppet node
  • configures puppet and hostname
  • modifies permissions so that no one exept root and the vm user can access vm data
  • configures container backup via duplicity
  • starts the container

It may not that easy to actualy move containers, but creation really is that easy… it also has a mode where it can automatically migrate a priviledged container into an unpriviledged one…

by the way, one short notice, if one sees manuals pointing that you should write: your-username veth lxcbr0 10 I am not really happy with that example, because I cant think of any user who needs more than 1 simultaniously connected ethernet devices for his unpriviledged containers. so you may want to write 1 here. because if you really want to seperate your containers you might consider having one user that holds exactly one container, running with one specific range of subuids.

so far….

Posted on May 25, 2016, 11:46 am By
Comments Categories: misc