19 docker_instances_lifecycle_management

zet809 edited this page 2016-01-21 13:34:26 +08:00

Unescape Escape

Table of Contents

• Overview
• The interfaces
• The docker instance definition
• The docker instance management commands
• Create a docker instance
• Remove a docker instance
• List docker information
• Operate docker
• The commands internal interfaces
• For mkdocker
• For rmdocker
• For lsdocker
• For rpower
• rpower start:
• rpower stop:
• rpower restart:
• rpower pause:
• rpower unpause:
• rpower state:
• The implementation details
• The hash table
• The hash variable to store node related info
• The main loop
• Other Design Considerations

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Overview

The docker technology is very hot those days, xCAT as a system management tool have the natural advantage to support docker. Such as multiple OS, multiple archs and large scale clusters for docker hosts supported. So xCAT plan to support docker.

This doc provide more detailed info for basic docker container management with fixed docker host.

Note: This interfaces include in this design are based on docker version 1.9.1 and docker API version 1.21 on ubuntu/x86_64.

The interfaces

The docker instance definition

The docker instance will be treat as a normal node in xCAT, the definition can be like this:

#lsdef host1c1 -z
host1c1:
    objtype=node
    dockerflag=xx
    dockerhost=host1
    dockercpus=xx                                      
    dockermemory=xx
    groups=docker
    ip=10.0.0.1
    mac=xx:xx:xx:xx:xx:xx
    mgt=docker
    provmethod=<image:command>
    status=<create|running|stop|…>

Notes: The dockerflag is a JSON string which will be used as parameters to create a docker, it will map to vm.othersettings. The dockerhost is the host on which the docker run, it will map to vm.host. The dockercpus is the CPUs in which to allow a container execution, it will map to vm.cpus. The dockermemory means the size of memory available to a container, it will map to vm.memory.

The docker instance management commands

Create a docker instance

mkdocker <node> [image=<image_name>  [command=<command>] [dockerflag=<docker_flags>]]

This command can be used to create a docker instance with the image and command specified. If dockerflag is used, its parameter will also be included in the request to create docker instance. For more information about the parameters can be specified for “dockerflag”, please reference https://docs.docker.com/engine/reference/api/docker_remote_api_v1.21/.

Note: You can also use *def command to modify the image, command, addkcmdline attribute for a docker node.

For example, to have the docker node “host1c1” running “ubuntu” image and with “date” command:

chdef host1c1 provmethod=ubuntu:date

Remove a docker instance

rmdocker <node>

List docker information

lsdocker <node> [-l|—logs]

The command will list the docker info. If the node is a docker host, all the running containers will be returned.

If option -l or —logs specified, the docker logs will be returned.

Operate docker

rpower <node>  start/stop/restart/pause/unpause/state

For rpower start, it can be used to start a docker container.
For rpower stop, it can be used to stop a docker container.
For rpower restart, it can be used to restart a docker container.
For rpower pause, it can be used to pause all processes within a docker container.
For rpower unpause, it can be used to unpause all processes within a docker container.
For rpower state, it can be used to check the container status, running/stop/exited/created.…

The commands internal interfaces

Basically, the commands above are done through a series of RESTAPI operations. The interfaces are:

For mkdocker

POST  /containers/create

For rmdocker

DELETE /containers/(docker_name)

For lsdocker

If the destination node is a docker host:

GET /containers/json

If the destination node is a docker container:

GET /containers/(docker_name)/json

To get docker logs:

GET /containers/(docker_name)/logs?stderr=1&stdout=1

For rpower

rpower start:

POST /containers/(docker_name)/start

rpower stop:

POST /containers/(docker_name)/stop

rpower restart:

POST /containers/(docker_name)/restart

rpower pause:

POST /containers/(docker_name)/pause

rpower unpause:

POST /containers/(docker_name)/unpause

rpower state:

GET /containers/(docker_name)/json

Note: For rpower state, the State.Status attribute in the response needed to be returned.

The implementation details

The main code logic include 3 parts

• The hash table that store the mapping of command and its state_machine_engine.
• The hash variable that store the SSL connection and its corresponding node, state…
• The main loop to send and read packages to and from docker host

The hash table

The hash table will be like this:

%command_states = (
    rpower => {
        start => {
            state_machine_engine => \&single_state_engine,
            init_method => “POST”,
            init_url => “/container/#NODE#/start”,
        },
        stop => {
            state_machine_engine => \&single_state_engine,
            init_method => “POST”,
            init_url => “/container/#NODE#/stop”,
        },
        …
    },
);

The hash variable to store node related info

The hash variable structure will be like this:

%node_hash_variable = (
    $SSL_connection => {
        node => $node,
        state => $current_state,
        state_machine_engine => $state_machine_for_the_command,
    },
);

This hash variable is generated dynamically only after the SSL connection is created, so there will be no where that define this structure.

The main loop

The main loop need to deal with 2 things.

• controlling number of sessions can be running in the same time
• process the response and start state machine engine for all nodes.

The function deal_with_rsp()

for the sockets have data received
    read data and write (data, the corresponding node and state_machine_engine) into a data array.
    decrease the pending response counter that recording how many response were expected.

deal with the data array about the received the data
    the state_machine_engine will be triggered here        

return the pending response counter.

The function init_session($node)

create a SSL connection for the specified node
increase the $num_of_concurrent_sessions if SSL connection is created succeed.
add the SSL connection into select or epoll waiting fds
send out request based on init_method and init_url
increase the pending response counter 
change state for the node to WAIT_FOR_RES accordingly
return whether the SSL connection is created successful

The function single_state_engine for state machine engine

parse out the http response status codes
switch $curr_state
case WAIT_FOR_RES:
    if ($http_status_code OK) print "done"
    else print "failed"
default: 
    print "failed"

remove the SSL connection from the select or epoll waiting fds.
decrease the $num_of_concurrent_sessions.

The code logic for main_loop:

while (1) 

        if (the node array that stores nodes which hadn’t been dealt with is empty) and (pending response counter equal 0)   # It means all nodes have been dealt, and no more response is expected, the loop will end 
            break;

        if num_of_concurrent_sessions less than concurrent_sessions_allowed
                   (# concurrent_sessions_allowed is a variable which can be calculated before)

            init_session($node, …) # The node is shifted from the node_array that stores nodes which hadn’t been dealt with    

        endif (# if num_of_concurrent_sessions…)

        deal_with_rsp();   
        
end of while(1)

Other Design Considerations

Required reviewers: Cheng Long, Wang Jun Xia
Required approvers: Wang Xiao Peng
Database schema changes: N/A
Affect on other components: N/A
External interface changes, documentation, and usability issues: N/A
Packaging, installation, dependencies: N/A
Portability and platforms (HW/SW) supported: N/A
Performance and scaling considerations: N/A
Migration and coexistence: N/A
Serviceability: N/A
Security: N/A
NLS and accessibility: N/A
Invention protection: N/A

News

• Apr 22, 2016: xCAT 2.11.1 released.
• Mar 11, 2016: xCAT 2.9.3 (AIX only) released.
• Dec 11, 2015: xCAT 2.11 released.
• Nov 11, 2015: xCAT 2.9.2 (AIX only) released.
• Jul 30, 2015: xCAT 2.10 released.
• Jul 30, 2015: xCAT migrates from sourceforge to github
• Jun 26, 2015: xCAT 2.7.9 released.
• Mar 20, 2015: xCAT 2.9.1 released.
• Dec 12, 2014: xCAT 2.9 released.
• Sep 5, 2014: xCAT 2.8.5 released.
• May 23, 2014: xCAT 2.8.4 released.
• Jan 24, 2014: xCAT 2.7.8 released.
• Nov 15, 2013: xCAT 2.8.3 released.
• Jun 26, 2013: xCAT 2.8.2 released.
• May 17, 2013: xCAT 2.7.7 released.
• May 10, 2013: xCAT 2.8.1 released.
• Feb 28, 2013: xCAT 2.8 released.
• Nov 30, 2012: xCAT 2.7.6 released.
• Oct 29, 2012: xCAT 2.7.5 released.
• Aug 27, 2012: xCAT 2.7.4 released.
• Jun 22, 2012: xCAT 2.7.3 released.
• May 25, 2012: xCAT 2.7.2 released.
• Apr 20, 2012: xCAT 2.7.1 released.
• Mar 19, 2012: xCAT 2.7 released.
• Mar 15, 2012: xCAT 2.6.11 released.
• Jan 23, 2012: xCAT 2.6.10 released.
• Nov 15, 2011: xCAT 2.6.9 released.
• Sep 30, 2011: xCAT 2.6.8 released.
• Aug 26, 2011: xCAT 2.6.6 released.
• May 20, 2011: xCAT 2.6 released.
• Feb 14, 2011: Watson plays on Jeopardy and is managed by xCAT!
• xCAT Release Notes Summary
• xCAT OS And Hw Support Matrix
• xCAT Test Environment Summary

History

• Oct 22, 2010: xCAT 2.5 released.
• Apr 30, 2010: xCAT 2.4 is released.
• Oct 31, 2009: xCAT 2.3 released.
  xCAT's 10 year anniversary!
• Apr 16, 2009: xCAT 2.2 released.
• Oct 31, 2008: xCAT 2.1 released.
• Sep 12, 2008: Support for xCAT 2
  can now be purchased!
• June 9, 2008: xCAT breaths life into
  (at the time) the fastest
  supercomputer on the planet
• May 30, 2008: xCAT 2.0 for Linux
  officially released!
• Oct 31, 2007: IBM open sources
  xCAT 2.0 to allow collaboration
  among all of the xCAT users.
• Oct 31, 1999: xCAT 1.0 is born!
  xCAT started out as a project in
  IBM developed by Egan Ford. It
  was quickly adopted by customers
  and IBM manufacturing sites to
  rapidly deploy clusters.