LXC provision

As always, the configuration is done via a registry module: mc_cloud_lxc / lxc registry for compute nodes. To provision a new lxc provider, you need to:

  • Select a profile type (combination of backing mode (lvm/dir) and install mode (clone/create)
  • Select a size profile if you are using block level backing stores (LVM)
  • Select a mode: mastersalt (localmaster+minion and a minion linked to mastersalt) or salt (only a minion linked to master)
  • add an entry to your lxc container in pillar reflecting those choices plus the other vm parameters.
  • We create a default container in mastersalt node named makina-states-precise. In cloning mode, this is the default origin container.
  • You can of course either start an lxc from scratch or begin with a template like a barebone ubuntu which will be cloned at a start.
  • By default, we use the 10.5/16* network on tje **lxcbr1 bridge using the default gateway: 10.5.0.1.
  • We use LVM as the default backing store in production, and the lxc volume group.
  • We use overlayfs with snapshot in development mode.

To create new VMS, just configure your pillar and add some entries as follow

makina-states.services.cloud.lxc.targets.devhost10.local:
  # -> autogenerated ip + mac + password stored in grains, name is id (mysupertest3.foo.co,
  #   will use default configured profile & settings
  mysupertest3.foo.com: {}
  # explicit configuration and not using mastersalt mode
  gfoobar.test.com:
    profile: small
    profile_type: lvm
    password: foobar
    ip: 10.5.10.16
  # -> autogenerated ip + mac
  gfoobar4.test.com:
    ip: 10.5.10.15
    profile: small
    mode: mastersalt
    profile_type: lvm
    password: foobar
  # -> autogenerated ip + mac + password stored in grains
  gfoobar3.test.com:
    ip: 10.5.10.17
    # from_container: makina-states-precise -> default
    profile_type: dir
    mode: mastersalt
    password: foobar
    bootsalt_branch: stable
  gfoobar2.test.coma:
    ip: 10.5.10.17
    # image: ubuntu -> default
    profile_type: dir-scratch
    mode: mastersalt
    password: foobar
  • The first line ends (after containers.) with your targeted minion id, where the lxc containers will be installed.
  • You have to assign the ip yourself to something that will be in the 10.5/16 network or the targeted minion
  • MAC is autogenerated if not providen, so you dont need to give one
  • IP is autogenerated if not providen, so you dont need to give one
  • PASSWORD autogenerated if not providen, so you dont need to give one
  • And the inner mappings define the container themselves.
  • Please note that the name in makina-corpus way must be the NickName FQDN.
  • Please do not use snapshot in production.

Misc notes

  • Salt cloud profiles are just collections of default for your next provision.

  • The naming scheme of raw salt-cloud is ms-{encoded minion id}**[-**{size profile}]-{profile type}, eg profiles:

    ms-devhost-10-local-dir-scratch
ms-devhost-10-local-dir
ms-devhost-10-local-small-lvm-scratch
ms-devhost-10-local-medium-lvm

  • Those are the availables modes:

    salt:cf saltity modes
    mastersalt:cf saltity modes

  • You can specify the makina-states branch to use with:

    bootsalt_branch:
     branch name

  • Those are the sizes available in profiles

    xxxtrem:2000g
    xxtrem:1000g
    xtrem:500g
    xxxlarge:100g
    large:20g
    medium:10g
    small:5g
    xsmall:3g
    xxsmall:1g
    xxxsmall:500m

  • Those are the types available in salt-cloud profiles

    lvm-sratch:starting a lxc container from scratch (lvm backing)
    lvm:cloning from existing container (lvm backing)
    dir-scratch:starting a lxc container from scratch (directory backing)
    dir:cloning from existing container (directory backing)
    overlayfs-scratch:
     starting a lxc container from scratch (overlayfs backing)
    overlayfs:cloning from existing container (overlayfs backing)

  • Attention, we need also that root from controller can connect both as saltmaster and via ssh to either the computenode and the lxc node as root without password (sshkey). Please not that the states normally do that setup for you but that may be a start of investigation in case of problems.

Remove a vm

To destroy at once boxes and minion keys on master:

salt-cloud -d <name>

Get infos for a VM

To know specific settings for a vm, like the generated ip and password, you can inspect the per vm settings. Those settings are mainly used at creation time but not reapplied after further setup, so they may be obsoletes. The only “live” settings are the gateway, the ip and ssh_reverse_proxy_port.

Please note that we also give here the ssh_reverse_proxy_port to access the vm from the host:

mastersalt-call mc_cloud_lxc.get_settings_for_vm <compute_node <vm_name>

For exemple, you can have something like that:

autostart:
    True
backing:
    overlayfs
bootsalt_branch:
    master
bridge:
    lxcbr1
dnsservers:
    - 8.8.8.8
    - 4.4.4.4
domains:
    - nmdcarto51.test.com
from_container:
    makina-states-precise
gateway:
    10.5.0.1
image:
    ubuntu
ip:
    10.5.0.12
lxc_conf:
lxc_conf_unset:
mac:
    00:16:3e:00:f1:81
master:
    10.5.0.1
master_port:
    4606
mode:
    mastersalt
name:
    nmdcarto51.test.com
netmask:
    16
network:
    10.5.0.0
password:
    balh
profile:
    ms-devhost10-local-overlayfs
script_args:
    -C --from-salt-cloud --mastersalt-minion -b master
snapshot:
    True
ssh_gateway:
    devhost10.local
ssh_gateway_key:
    /root/.ssh/id_dsa
ssh_gateway_password:
    None
ssh_gateway_port:
    22
ssh_gateway_user:
    root
ssh_reverse_proxy_port:
    40000
ssh_username:
    ubuntu
sudo:
    True
users:
    - root
    - sysadmin

Detailed documentation

Exemple of the makina-states.cloud.lxc and how will integrate itself in the previous sequence:
steps = [‘spawn’,
‘hostsfile’, ‘sshkeys’, ‘grains’, ‘initial_setup’, ‘initial_highstate’]

  • On the controller front:

    • At run pre configured drivers specific hooks stage:

      • install the salt cloud lxc providers
      • install a cron that sync all defined images templates from controller to compute nodes.

    • At compute node post hook

      • install lxc
      • ensure images templates are installed
      • install lxc host specific grains

  • On the vm pre hook:

    • spawn the vm

  • on the vm post hook

    • configure specific lxc grains
    • configure host file
    • initial setup

LXC specific usage

All of those are integrated directly withe mc_cloud_{controller,compute_node,vm} runners, you do not have to use them directly, this is purely for documentation purpose.

Controller

Re run configuration of cloudcontroller:

mastersalt-run -lall mc_cloud_lxc.post_deploy_controller

compute node

Install lxc:

mastersalt-run -lall mc_cloud_lxc.install_vt <computenode_id>

This will call in turn those runners:

  • mc_cloud_lxc.configure_grains <computenode_id>
  • mc_cloud_lxc.configure_install_lxc <computenode_id>
  • mc_cloud_lxc.configure_images <computenode_id>

This will also run the LXC images (templates) syncrhonnisation runner on that specific node.

VM