Sha256: 39aa8235c289e067a5ecb8f32a288befb0d23ebed522fde1e573005d1ea28c01

Contents?: true

Size: 1.47 KB

Versions: 2

Compression:

Stored size: 1.47 KB

Contents

-------
Context
-------

To understand how Kameleon work you have to get the *context* notion. A context
is an execution environnement with his variables (like $PATH, $TERM,...), his
tools (debootstrap, yum, ...) and all his specifics (filesystem, local/remote,
...). When you build an appliance you deal with 3 contexts:

- The *local* context which is the Kameleon execution environnement
- The *out* context where you will bootstrap the appliance
- The *in* context which is inside the newly created appliance

These context are setup using the two globals variables: ``out_context``
and ``in_context``. They both takes 3 arguments:

cmd
    The command to initialize the context
workdir (optional)
    The working directory to tell to Kameleon where to execute the command
exec_prefix (optional)
    The command to execute before every Kameleon command in this context

For example, you are building an appliance on your laptop and you run Kameleon
in a bash shell with this configuration:

.. code-block:: yaml

    out_context:
        cmd: bash
        workdir: $$kameleon_cwd

    in_context:
        cmd: chroot $$rootfs bash
        workdir: /


Your *local* context is this shell where you launch Kameleon on your laptop,
the *out* is a child bash of this context, and the *in* is inside the new
environnement accessed by the chroot. As you can see the local and the out
context are often very similar but sometimes it could be useful for the out
context to be elsewhere (in a VM for example).

Version data entries

2 entries across 2 versions & 1 rubygems

Version Path
kameleon-builder-2.0.0 docs/source/context.rst
kameleon-builder-2.0.0.dev docs/source/context.rst