Docker Container Modeling Goals 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 within a new Containee Node Type Note: this is essentially how Azure PaaS does it 3.Consider using Artifact Type (i.e., Docker image) to imply Runtime Note: this is how CloudFoundry PaaS works (introspects app’s code) Allow model to allow Docker container so that it can be run on a PaaS (implicit container) an IaaS platform (explicit container) Note: this implies Compute Node and Container Node have interchangeable capabilities. If the Docker image has a WebServer (e.g., Apache) inside it, we want to reflect this in the TOSCA model Consider using existing WebServer Node Type Consider using a new WebServer Capability Type

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

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

Hosted On Software Component Container (Docker Runtime Capability) Container (Docker Runtime Capability) Containee (Docker Runtime Requirement) Containee (Docker Runtime Requirement) Requirements Capabilities Artifacts Docker Image (Apache.TAR) requirements: - host: # Primary Capability for relationship capability: tosca.capabilities.Container relationship: tosca.relationships.HostedOn target_filter: # 1-N secondary Capabilities… capabilities: - tosca.capabilities.runtime.Docker properties: - foo: bar 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 Container 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 Docker Rocket …

tosca.capabilities.Container: derived_from: tosca.capabilities.Roottosca.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 cpu_frequency: # per cpu type: scalar-unit.speed required: false disk_size: type: scalar-unit.sizescalar-unit.size constraints: - greater_or_equal: 0 MB mem_size: type: scalar-unit.sizescalar-unit.size constraints: - greater_or_equal: 0 MB 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 DataType) Final Proposal: Docker provided as a Capability in addition to “Container” Capability Type Still need to address virtualizing “ports” and IP addresses which may be shared within the same Compute host (guest VM) “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

TOSCA will want to be able to show modeling against Docker “Compose” (links and components) with a basic lifecycle (fig now deprecated) announced : Show how 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)#426 Compose should recommend a technique for zero-downtime deploys.