Changes between Version 15 and Version 16 of NeoContainers


Ignore:
Timestamp:
Oct 2, 2015 2:08:54 PM (5 years ago)
Author:
Geoff Lawler
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NeoContainers

    v15 v16  
    11=== The Basics ===
    22
    3 The neo-containers system uses cloud-container technology to abstract and generalize container creation and initialization.  There is a per-experiment control node that centralizes configuration details. At the DETER level, the experiments have the control node and a number of "pnodes" which serve as hosts for the virtualized containers. The control node configures the pnodes as well as the containerized nodes as well as itself.  The bootstrap script is run on the control node and: 1) installs configuration software on itself, 2) updates its own configuration, 3) updates the configuration of the other physical nodes (which includes virtual networking and starting virtual machines), 4) give configuration information to virtual nodes and allows them to configuration themselves.
     3The neo-containers system uses cloud-container technology to abstract and generalize container creation and initialization. At the DETER level, the experiments have a number of "pnodes" which serve as hosts for the virtualized containers and a DETER-wide Chef server at {{{chef.isideterlab.net}}}.
    44
    55=== HOWTO run neo-containers ===
    66
    7 1. The neo-containers are started via a single script run on an experiment node. The script is on the {{{configdb}}} branch of the (existing) containers source repository. The script is {{{./bin/container_bootstrap.sh}}}. Checkout the containers repository and switch to the correct branch:
     71. Checkout the containers repository and switch to the {{{configdb}}} branch:
    88{{{
    99users: > cd src
     
    1313}}}
    1414
    15 2. Create a containerized experiment with an NS file and the {{{/share/containers/containerize.py}}} script. The NS file should declare a {{{config}}} node as an embedded container that uses the {{{UB14-CHEF12}}} image. Use a snippet like:
    16 {{{
    17 set config [$ns node]
    18 tb-set-node-os $config UB14-CHEF12
    19 tb-set-hardware $config container0
    20 tb-add-node-attribute $config containers:node_type "embedded_pnode"
    21 }}}
    22 The {{{UB14-CHEF12}}} image is not required, but speeds things up a bit.
    23 For each container in the experiment, specify  {{{image_os}}}, {{{image_type}}}, {{{image_name}}}, and optionally an {{{image_url}}} via the {{{tb-add-node-attribute}}} syntax. Details on each attribute is given below.
     152. Create a containerized experiment with an NS file and the {{{/share/containers/containerize.py}}} script.
     16
     17In your NS file for each container in the experiment, specify  {{{image_os}}}, {{{image_type}}}, {{{image_name}}}, and {{{image_url}}} via the {{{tb-add-node-attribute}}} syntax. Details on each attribute is given below.
    2418
    2519* {{{image_os}}} - This is really just to distinguish Windows from non-Windows nodes. If the {{{image_os}}} starts with "{{{windows}}}", the image will be treated as a Windows node. Otherwise it'll be assumed to be some sort of Unix-y container.
    2620* {{{image_type}}} - This setting describes the containerization tech of the node. Currently this is *always* set to "{{{vagrant}}}" as Vagrant is the only package used to spin up the containers.
    27 * {{{image_name}}} - The name of the image. The name identifies an OS, virtualization platform, and version. This name is based on the Vagrant naming scheme. The standard, "baked in" image names (and types) are:
    28   * chef/centos-7.0      (virtualbox, 1.0.0)
    29   * chef/freebsd-10.0    (virtualbox, 1.0.0)
    30   * fgrehm/precise64-lxc (lxc, 1.2.0)
    31   * fgrehm/trusty64-lxc  (lxc, 1.2.0)
    32   * hashicorp/precise64  (virtualbox, 1.1.0)
    33   * liibvert/centos64     (libvirt, 0)
    34   * ubuntu/precise64     (virtualbox, 12.04.4)
    35   * ubuntu/trusty64      (virtualbox, 14.04)
    36 So to create an Ubuntu 14.04 64 bit container, the name would be "{{{ubuntu/trusty64}}}". The only fully tested image is "ubuntu/trusty64". We are working on the LXC nodes. Each container that has the same name, will use a copy of the same container image.
    37 * {{{image_url}}} - If the image name is not one of the baked in images above, a URL must be specified from which the neo-containers system can download the container image. This URL must be resolvable from the {{{config}}} experiment node. There is an existing tested Windows 7 image at {{{http://scratch/benito/deter_win7.box}}}. The image will only be downloaded once as long as the {{{image_name}}}s are the same for each container.
     21* {{{image_name}}} - The name of the image. Any containers that share a name will also share an image.
     22* {{{image_url}}} - A URL must be specified which the neo-containers system uses to download the container image. This URL must be resolvable from the experiment nodes. The image will only be downloaded once as long as the {{{image_name}}}s are the same for each container. Existing and supported images are Ubuntu 14.04 64 @ {{{http://scratch/containers/deter_ub1404_64_vb.box}}} and Windows 7 @ {{{http://scratch/containers/deter_win7.box}}}.
    3823
    39 Here is an example that creates a Windows and Ubuntu 14.04 containers:
     24Here is an example that creates Windows and Ubuntu 14.04 containers:
    4025{{{
    4126set r2d2 [$ns node]
     
    4328tb-add-node-attribute $r2d2 containers:image_type vagrant
    4429tb-add-node-attribute $r2d2 containers:image_name deter/win7
    45 tb-add-node-attribute $r2d2 containers:image_url http://scratch/benito/deter_win7.box
     30tb-add-node-attribute $r2d2 containers:image_url http://scratch/containers/deter_win7.box
    4631
    4732set c3po [$ns node]
     
    4934tb-add-node-attribute $c3po containers:image_type vagrant
    5035tb-add-node-attribute $c3po containers:image_name ubuntu/trusty64
     36tb-add-node-attribute $r2d2 containers:image_url http://scratch/containers/deter_ub1404_64_vb.box
    5137}}}
    5238
    53393. Use the NS file to create a containerized experiment using the existing containers scripts (on users): {{{/share/containers/containerize.py [group] [experiment] [ns file]}}}. Note that the experiment must currently be created in the {{{Deter}}} group as that's where the custom images are. This will change.
     40
    54414. Modify the NS file generated by {{{containerize.py}}} to have a new image for the pnode machines. Navigate to the new experiment page and click {{{Modify Experiment}}}. Change the OS type of the pnodes to {{{PNODE_BASE}}} and the hardware type to {{{MicroCloud}}}. I.e. for each pnode in the NS file, make the lines have the form:
    5542{{{
    56     tb-set-node-os ${pnode(0000)} PNODE-BASE
     43    tb-set-node-os ${pnode(0000)} PNODE-CONT
    5744    tb-set-hardware ${pnode(0000)} MicroCloud
    5845}}}
    5946Remove all existing {{{tb-set-node-startcmd}}} lines as these start the old containers system.
    60 Add the bootstrap script to the {{{config}}} node's start-cmd, so it executes after boot. Add the following to the {{{config}}} node stanza in the NS file:
    61 {{{
    62 tb-set-node-startcmd $config "~/src/containers/bin/container_bootstrap.sh"
    63 }}}
    64 (Of course have it match the path to your copy of the containers repository.) See the experiment Deter/swtest3 for a working example.
     47
    65485. Swap in the experiment and wait a long time. There is no great way to tell when the containers are up, unfortunately. Tail the start-cmd output on the {{{config}}} node and look for the "complete" message.
    6649{{{