| 1 | The Basics: |
| 2 | |
| 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. |
| 4 | |
| 5 | Execution Flow: |
| 6 | |
| 7 | The execution flow of is as follows. The initialization uses the existing containers system as a bootstrap. |
| 8 | |
| 9 | 1. Create a containerized experiment with an NS file and the {{{/share/containers/containerize.py}}} script. |
| 10 | 2. Modify the generated NS file. |
| 11 | a. Change the OS type of the pnodes to {{{PNODE-BASE}}}. e.g. make the line in the NS file: |
| 12 | {{{ |
| 13 | tb-set-node-os ${pnode(0000)} PNODE-BASE |
| 14 | }}} |
| 15 | b. Add a new control node. Traditionally it's been called "config", but there is no restriction on the name. Add this to the NS file: |
| 16 | {{{ |
| 17 | set config [$ns node] |
| 18 | tb-set-node-os ${config} Ubuntu1404-64-STD |
| 19 | tb-set-hardware ${config} MicroCloud |
| 20 | tb-set-node-failure-action ${config} "nonfatal" |
| 21 | }}} |
| 22 | 3. Swap in the experiment. |
| 23 | 4. Run the bootstrap script. |
| 24 | |
| 25 | The bootstrap script: |
| 26 | 1. Uses the NFS mounted dir /share/chef/chef-packages to install Chef server and Chef client on the {{{config}}} node. |
| 27 | a. The {{{config}}} node is both a Chef server (talks to all machines in the experiment) and a Chef client/workstation (holds the Chef git repo which contains all configuration scripts). |
| 28 | 2. Configures Chef Server on the {{{config}}} node. |
| 29 | a. Simply runs the chef self-configure scripts. |
| 30 | 3. Configures Chef client/workstation on the {{{config}}} node. |
| 31 | a. creates a chef-deter identity (keys and names) for the Chef Server. |
| 32 | b. installs {{{git}}} on the {{{config}}} node. |
| 33 | c. git clones the canonical Chef repository from the NFS mounted dir {{{/share/chef/chef-repo}}}. Thie repo contains all configuration scripts and data for the system. |
| 34 | d. upload all Chef recipes, data bags, and roles (configuration scripts, data, and roles) to the Chef server on {{{config}}} (localhost). |
| 35 | 4. Create an experiment-specific "data bag" and upload it to the Chef Server. The data contains experiment name, project, group, name and address of the {{{config}}} machine, and the name and address of the RESTful configuration server. |
| 36 | 5. Register the {{{config}}} node (localhost) as a Chef client to the server, download and execute all local configuration recipes. Details of these are in the next section. |
| 37 | |
| 38 | {{{config}}} recipes. |