Docker Container Modeling Goals not requirements Not proliferate

Docker Container Modeling Goals (not requirements) • Not proliferate Node Types for “Docker” 1. Consider modeling “Docker” as an (explicit) runtime Capability Type 2. Consider using a Property either • within existing Container Capability Type <or> • within a new Containee Node Type • Note: this is essentially how Azure Paa. S does it 3. Consider using Artifact Type (i. e. , Docker image) to imply Runtime • Note: this is how Cloud. Foundry Paa. S works (introspects app’s code) • Allow model to allow Docker container so that it can be run on • a Paa. S (implicit container) <or> • an Iaa. S platform (explicit container) • Note: this implies Compute Node and Container Node have interchangeable capabilities. • If the Docker image has a Web. Server (e. g. , Apache) inside it, we want to reflect this in the TOSCA model • Consider using existing Web. Server Node Type • Consider using a new Web. Server Capability Type

Exploring Containment in TOSCA: Modeling Web. Server with Compute • Effectively… • Compute is a Container (Node Type) • Web. Server (i. e. a child of Software. Component) is both a Container and Containee (Node Type) Software Component Artifacts • Apache. TAR • scripts (Container + Containee) Web. Server Capabilities Container Requirements Container capabilities: host: type: tosca. capabilities. Container valid_source_types: [ tosca. nodes. Web. Application ] Hosted. On Compute (Container) Capabilities Container Properties • num_cpus • mem_size • disk_size requirements: - host: capability: tosca. capabilities. Container node: tosca. nodes. Compute relationship: tosca. relationships. Hosted. On Scalable Op. Sys capabilities: host: type: tosca. capabilities. Container valid_source_types: [tosca. nodes. Software. Component]

Modeling Container-Containee like Compute-Software Component Expressing “Docker” as a Capability Type Paa. S Modeling Iaa. S Modeling Agnostic • Container is explicit or implicit - Compute is explicit or implicit • Cloud Foundry • Azure Software Component (Container + Containee) Containee (Docker Runtime Requirement) Requiremenb ts Web. Server Docker Capabilities Container Artifacts • Docker Image • (Apache. TAR) artifacts: - image: mime_type: Docker repo: xxx URI: xxx Requirements Container Compute (Container) Container Capabilities Container requirements: - host: capability: tosca. capabilities. Container # node: NULL * relationship: tosca. relationships. Hosted. On Software Component Hosted On Scalable Op. Sys (Docker Runtime Capability) Requirement s Container Capabilities Docker Container directive: substitutable Hosted On capabilities: host: type: tosca. capabilities. Container # valid_source_types: [NULL *] * “Effectively NULL”, not actually a NULL value. meaning, we do not need to bind to a Node Type

Final Proposal: Docker provided as a Capability in addition to “Container” Capability Type (but separate) This approach: • First: formulates the primary requirement “host” to the Container Capability Type But also then: • Provides a “target_filter” that lists 1. . n Secondary Capability Types • [Secondary] Capabilities expressed in “target_filter” do not have relationships. This approach ALSO allows us to: • Treat some Capability Types more like a “decorators” • Still pass in properties on any Secondary Capability Type Containee (Docker Runtime Requirement) Artifacts • Docker Image • (Apache. TAR) Requirements Container Hosted On Software Component Container (Docker Runtime Capability) Capabilities Docker Rocket … requirements: - host: # Primary Capability for relationship capability: tosca. capabilities. Container relationship: tosca. relationships. Hosted. On target_filter: # 1 -N secondary Capabilities… capabilities: - tosca. capabilities. runtime. Docker properties: - foo: bar Container capabilities: host: type: tosca. capabilities. Container # Shows we need to loosen type dependency, not actually NULL valid_source_types: [NULL] docker: type: tosca. capabilities. runtime. Docker

Final Proposal: Docker provided as a Capability in addition to “Container” Capability Type • • Note: We would still want to move Compute properties into Container capability • i. e. , because every container “virtualizes” basic memory/storage/compute power • and allows application to provide “desired” or “optimal” VM environment but without any new Runtime property (or Data. Type) tosca. capabilities. Container: derived_from: tosca. capabilities. Root properties: # re-located the following properties # from Compute node to make them portable # for any node having a Container capability. num_cpus: type: integer constraints: - greater_or_equal: 1 processing_power: # per cpu type: scalar-unit. speed required: false disk_size: type: scalar-unit. size constraints: - greater_or_equal: 0 MB mem_size: type: scalar-unit. size constraints: - greater_or_equal: 0 MB • “Number of CPUs” is too abstract and subjective to implementation / provider (and their SLAs) • Provide a scalar-unit based type to allow compute power to be expressed in GHz, • which is meaningful to app developers and can be used to reasonably hold/map to actual provider capabilities/SLAs • Still need to address virtualizing “ports” and IP addresses • which may be shared within the same Compute host (guest VM)

TOSCA will want to be able to show modeling against Docker “Compose” (links and components) with a basic lifecycle (fig now deprecated) announced 2015 -02 -25: http: //blog. docker. com/2015/02/announcing-docker-compose/ Show we address their “roadmap” items already… “More than just development environments” • Over time we will extend Compose's remit to cover test, staging and production environments. This is not a simple task, and will take many incremental improvements such as: • Compose’s brute-force “delete and recreate everything” approach is great for dev and testing, but it not sufficient for production environments. You should be able to define a "desired" state that Compose will intelligently converge to. • It should be possible to partially modify the config file for different environments (dev/test/staging/prod), passing in e. g. custom ports or volume mount paths. (#426) • Compose should recommend a technique for zero-downtime deploys.