mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 08:58:59 +00:00
Add more info to LXC tutorial
This commit is contained in:
Erik Johnson
parent
f98fe0b312
commit
2dad71adc9
@ -11,19 +11,243 @@ LXC Management with Salt
|
||||
|
||||
.. warning::
|
||||
|
||||
Some of the features described here are only currently available in the
|
||||
``2014.7`` and ``develop`` branches, and will not be available in an
|
||||
official Salt release until version 2014.7.1. These features will be
|
||||
clearly labeled as such below.
|
||||
|
||||
Put an opening paragraph here. Level headings are: = - ~ in that order.
|
||||
|
||||
Some features are only currently available in the ``develop`` branch, and
|
||||
will not be available in an official Salt release until the next feature
|
||||
release (codenamed "Lithium"). These new features will be clearly labeled.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
Manipulation of LXC containers in Salt requires the minion to have an LXC
|
||||
version of at least 1.0 (an alpha or beta release of LXC 1.0 is acceptable).
|
||||
The following distributions are known to have new enough versions of LXC
|
||||
packaged:
|
||||
|
||||
- RHEL/CentOS 6 and later (via EPEL_)
|
||||
- Fedora (All non-EOL releases)
|
||||
- Debian 8.0 (Jessie) (not yet released)
|
||||
- Ubuntu 14.04 LTS and later
|
||||
- LXC templates packaged separately (as **lxc-templates**), it is recommended
|
||||
to also install this package.
|
||||
- openSUSE 13.2 and later
|
||||
|
||||
.. _EPEL: https://fedoraproject.org/wiki/EPEL
|
||||
|
||||
|
||||
.. _tutorial-lxc-profiles:
|
||||
|
||||
Profiles
|
||||
========
|
||||
|
||||
Profiles allow for a sort of shorthand for commonly-used
|
||||
configurations to be defined in the minion config file, :ref:`grains
|
||||
<targeting-grains>`, :ref:`pillar <pillar>`, or the master config file. The
|
||||
profile is retrieved by Salt using the :mod:`config.get
|
||||
<salt.modules.config.get>` function, which looks in those locations, in that
|
||||
order. This allows for profiles to be defined centrally in the master config
|
||||
file, with several options for overriding them (if necessary) on groups of
|
||||
minions or individual minions.
|
||||
|
||||
There are two types of profiles, one for defining the parameters used in
|
||||
container creation, and one for defining the container's network interface(s).
|
||||
|
||||
.. _tutorial-lxc-profiles-container:
|
||||
|
||||
Container Profiles
|
||||
------------------
|
||||
|
||||
In the 2014.7 release cycle and earlier, LXC container profiles were all
|
||||
defined underneath the ``lxc.profile`` config option:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
lxc.profile:
|
||||
centos:
|
||||
template: centos
|
||||
backing: lvm
|
||||
vgname: vg1
|
||||
lvname: lxclv
|
||||
size: 10G
|
||||
centos_big:
|
||||
template: centos
|
||||
backing: lvm
|
||||
vgname: vg1
|
||||
lvname: lxclv
|
||||
size: 20G
|
||||
|
||||
However, due to the way that :mod:`config.get <salt.modules.config.get>` works,
|
||||
this means that if a ``lxc.profile`` key is defined in both the master config
|
||||
file and in a specific minion's config file, that will cause all profiles to be
|
||||
overwritten for that minion. For greater flexibility, in the next feature
|
||||
release each container profile should be configured in its own key, in the
|
||||
format ``lxc.container_profile.profile_name``. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
lxc.container_profile.centos:
|
||||
template: centos
|
||||
backing: lvm
|
||||
vgname: vg1
|
||||
lvname: lxclv
|
||||
size: 10G
|
||||
lxc.container_profile.centos_big:
|
||||
template: centos
|
||||
backing: lvm
|
||||
vgname: vg1
|
||||
lvname: lxclv
|
||||
size: 20G
|
||||
|
||||
This way, the ``centos_big`` profile can be redefined for a single minion
|
||||
without also removing the ``centos`` profile. The legacy usage will still be
|
||||
supported for a couple release cycles, to allow for some time to update
|
||||
configurations.
|
||||
|
||||
Additionally, in the next feature release, container profiles have been
|
||||
expanded to support passing template-specific CLI options. Below is a table
|
||||
describing the parameters which can be configured in container profiles:
|
||||
|
||||
================== ===================================== ====================
|
||||
Parameter Develop Branch (Next Feature Release) 2014.7.x and Earlier
|
||||
================== ===================================== ====================
|
||||
*template*:sup:`1` Yes Yes
|
||||
*options*:sup:`1` Yes No
|
||||
*image*:sup:`1` Yes Yes
|
||||
*backing* Yes Yes
|
||||
*snapshot*:sup:`2` Yes Yes
|
||||
*lvname*:sup:`1` Yes Yes
|
||||
*fstype*:sup:`1` Yes Yes
|
||||
*size* Yes Yes
|
||||
================== ===================================== ====================
|
||||
|
||||
1. Parameter is only supported for container creation, and will be ignored if
|
||||
the profile is used when cloning a container.
|
||||
2. Parameter is only supported for container cloning, and will be ignored if
|
||||
the profile is used when not cloning a container.
|
||||
|
||||
.. _tutorial-lxc-profiles-network:
|
||||
|
||||
Network Profiles
|
||||
----------------
|
||||
|
||||
In the 2014.7 release cycle and earlier, LXC network profiles were all
|
||||
defined underneath the ``lxc.nic`` config option:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
lxc.nic:
|
||||
centos:
|
||||
eth0:
|
||||
link: br0
|
||||
type: veth
|
||||
flags: up
|
||||
ubuntu:
|
||||
eth0:
|
||||
link: lxcbr0
|
||||
type: veth
|
||||
flags: up
|
||||
|
||||
However, due to the way that :mod:`config.get <salt.modules.config.get>` works,
|
||||
this means that if a ``lxc.nic`` key is defined in both the master config file
|
||||
and in a specific minion's config file, that will cause all network profiles to
|
||||
be overwritten for that minion. For greater flexibility, in the next feature
|
||||
release each container profile should be configured in its own key, in the
|
||||
format ``lxc.network_profile.profile_name``. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
lxc.network_profile.centos:
|
||||
eth0:
|
||||
link: br0
|
||||
type: veth
|
||||
flags: up
|
||||
lxc.network_profile.ubuntu:
|
||||
eth0:
|
||||
link: lxcbr0
|
||||
type: veth
|
||||
flags: up
|
||||
|
||||
This way, the ``ubuntu`` profile can be redefined for a single minion
|
||||
without also removing the ``centos`` profile. The legacy usage will still be
|
||||
supported for a couple release cycles, to allow for some time to update
|
||||
configurations.
|
||||
|
||||
The following are parameters which can be configured in network profiles. These
|
||||
will directly correspond to a parameter in an LXC configuration file (see ``man
|
||||
5 lxc.container.conf``).
|
||||
|
||||
- **type** - Corresponds to **lxc.network.type**
|
||||
- **link** - Corresponds to **lxc.network.link**
|
||||
- **flags** - Corresponds to **lxc.network.flags**
|
||||
|
||||
Interface-specific options (MAC address, IPv4/IPv6, etc.) can be passed on a
|
||||
container-by-container basis.
|
||||
|
||||
|
||||
Creating a Container on the CLI
|
||||
===============================
|
||||
|
||||
From a Template
|
||||
---------------
|
||||
|
||||
LXC is commonly distributed with several template scripts in
|
||||
/usr/share/lxc/templates. Some distros may package these separately in an
|
||||
**lxc-templates** package, so make sure to check if this is the case.
|
||||
|
||||
There are LXC template scripts for several different operating systems, but
|
||||
some of them are designed to use tools specific to a given distribution. For
|
||||
instance, the ``ubuntu`` template uses deb_bootstrap, the ``centos`` template
|
||||
uses yum, etc., making these templates impractical when a container from a
|
||||
different OS is desired.
|
||||
|
||||
To create a CentOS container named ``container1`` on a CentOS minion named
|
||||
``mycentosminion``, using the ``centos`` LXC template, one can simply run the
|
||||
following command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt mycentosminion lxc.create container1 template=centos
|
||||
|
||||
|
||||
For these instances, there is a ``download`` template which retrieves minimal
|
||||
container images for several different operating systems. To use this template,
|
||||
it is necessary to provide an ``options`` parameter when creating the
|
||||
container, with three values:
|
||||
|
||||
1. **dist** - the Linux distribution (i.e. ``ubuntu`` or ``centos``)
|
||||
2. **release** - the release name/version (i.e. ``trusty`` or ``6``)
|
||||
3. **arch** - CPU architecture (i.e. ``amd64`` or ``i386``)
|
||||
|
||||
The :mod:`lxc.images <salt.modules.lxc.images>` function (new in the next
|
||||
feature release) can be used to list the available images. Alternatively, the
|
||||
releases can be viewed on http://images.linuxcontainers.org/images/. The images
|
||||
are organized in such a way that the dist, release, and arch can be determined
|
||||
using the following URL format:
|
||||
``http://images.linuxcontainers.org/images/dist/release/arch``. For example,
|
||||
``http://images.linuxcontainers.org/images/centos/6/amd64`` would correspond to
|
||||
a **dist** of ``centos``, a **release** of ``6``, and an **arch** of ``amd64``.
|
||||
|
||||
Therefore, to use the ``download`` template to create a new 64-bit CentOS 6
|
||||
container, the following command can be used:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
salt myminion lxc.create container1 template=download options='{dist: centos, release: 6, arch: amd64}'
|
||||
|
||||
.. note::
|
||||
|
||||
These command-line options can be placed into a :ref:`container profile
|
||||
<tutorial-lxc-profiles-container>`, like so:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
lxc.container_profile.centos:
|
||||
template: download
|
||||
options:
|
||||
dist: centos
|
||||
release: 6
|
||||
arch: amd64
|
||||
|
||||
The ``options`` parameter is not supported in profiles for the 2014.7.x
|
||||
release cycle and earlier, so it would still need to be provided on the
|
||||
command-line.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user