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.frequency 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 Virtualizing “ports” and IP addresses is done within the Container.Docker Capability Type (as it is specific to Docker) Rocket does not consider port mapping, is relying on a Container network “overlay” via an IETF “GLU” proposal “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

Hosted On Software Component Container (Docker Runtime Capability) Container (Docker Runtime Capability) Containee (Docker Runtime Requirement) Containee (Docker Runtime Requirement) Requirements Capabilities node_templates: docker_webserver: type: tosca.nodes.Containee capabilities: # TBD requirements: - host: capability: tosca.capabilities.Container relationship: tosca.relationships.HostedOn target_filter: capabilities: - tosca.capabilities.Container.Docker properties:... artifacts: # Docker image is in CSAR file - my_image: files/docker_webserver_content.tar type: tosca.artifacts.impl.Docker.Image: Container Opaque Containee Implementation: Providing Docker “image” as an artifact Docker Rocket … PaaS Modeling Container is explicit or implicit Use Case 1: Docker Image (with WebServer inside) as a TOSCA Artifact in CSAR file artifact_types: # NEW Tosca non-normative type tosca.artifacts.impl.Docker.Image: derived_from: tosca.artifacts.Roottosca.artifacts.Root description: Docker Image TAR mime_type: TBD file_ext: [ tar ] Artifacts Docker Image (Apache.TAR) TOSCA CSAR File node_templates: # Note: this node represents just the Docker # client in a PaaS, BUT also the engine # (daemon) for single client / demo purposes docker_client: type: tosca.nodes.Container capabilities: tosca.capabilities.Container.Docker # Optionally… make this an abstract # node_template, allowing subsystem # replacement: directive: [ selectable ]

Hosted On Software Component Container (Docker Runtime Capability) Container (Docker Runtime Capability) Containee (Docker Runtime Requirement) Containee (Docker Runtime Requirement) Requirements Capabilities # NOT YET IN TOSCA SPEC. TO BE INVENTED… repositories: docker_hub: url: xxx credentials: yyy node_templates: docker_webserver: type: tosca.nodes.Containee requirements: - host: # omitted for brevity artifacts: - my_image: type: tosca.artifacts.impl.Docker.Image: repository: docker_repo Container Opaque Containee Implementation: Providing Docker “image” as an artifact Docker Rocket … PaaS Modeling Container is explicit or implicit Use Case 3: Docker Image (with WebServer inside) in a “Docker” Repo. artifact_types: tosca.artifacts.impl.Docker.Image: derived_from: tosca.artifacts.Roottosca.artifacts.Root description: Docker Image TAR mime_type: TBD file_ext: [ tar ] Docker Hub (Repo.) URI of DockerImage Relative to Repo. Artifacts Docker Image.TAR)

Hosted On Software Component Container (Docker Runtime Capability) Container (Docker Runtime Capability) Containee (Docker Runtime Requirement) Containee (Docker Runtime Requirement) Requirements Capabilities Container Opaque Containee Implementation: Providing Docker “image” as an artifact Docker Rocket … PaaS Modeling Container is explicit or implicit Use Case 3: Dynamically “build” Docker Image using multiple repositories, single Node Template (IN-PROGRESS) Docker Hub (Repo.) URIs of components Relative to Repos. Artifacts Guest OS (TAR) # NOT YET IN TOSCA SPEC. TO BE INVENTED… repositories: docker_hub:... apache_repo:... paypal_repo:... node_templates: docker_os_webserver_app: type: tosca.nodes.Containee requirements: - host: # omitted for brevity artifacts: - my_guest_os_image:... - my_apache_server:... - my_pizza_app:... Apache (Repo.) Artifacts Apache Repo Pizza Store App (Repo.) Artifacts Pizza App

Hosted On Software Component Container (Docker Runtime Capability) Container (Docker Runtime Capability) Containee (Docker Runtime Requirement) Containee (Docker Runtime Requirement) Requirements Capabilities Container Opaque Containee Implementation: Providing Docker “image” as an artifact Docker Rocket … PaaS Modeling Container is explicit or implicit Use Case 4: Dynamically “build” Docker Image using multiple repositories, Multiple Node templates (IN-PROGRESS) Docker Hub (Repo.) URIs of components Relative to Repos. Artifacts Guest OS # NOT YET IN TOSCA SPEC. TO BE INVENTED… repositories: docker_hub:... node_templates: docker_webserver: type: tosca.nodes.Containee requirements: - host: # omitted for brevity artifacts: - my_guest_os_image:... Apache (Repo.) Artifacts Apache Repo Pizza Store App (Repo.) Artifacts Pizza App WebServer WebApp # NOT YET IN TOSCA SPEC. TO BE INVENTED… repositories: apache_repo:... node_templates: TBD # NOT YET IN TOSCA SPEC. TO BE INVENTED… repositories: paypal_repo:... node_templates: TBD Capabilities OS

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.