Docker Container Modeling Goals
Goals(not requirements)Not proliferate Node Types for “Docker”Consider modeling “Docker” as an (explicit) runtime Capability TypeConsider using a Property eitherwithin existing Container Capability Type <or>within a new Containee Node TypeNote: this is essentially how Azure PaaS does itConsider using Artifact Type (i.e., Docker image) to imply RuntimeNote: this is howCloudFoundryPaaS works (introspects app’s code)Allow model to allow Docker container so that it can be run ona PaaS (implicit container) <or>an IaaS platform (explicit container)Note: this implies Compute Node and Container Node have interchangeablecapabilities.If the Docker image has a WebServer (e.g., Apache) inside it, we want to reflect thisin the TOSCA modelConsider using existing WebServer Node TypeConsider using a new WebServer Capability Type
Exploring Containment in TOSCA: Modeling WebServer with Compute
Propertiesnum_cpusmem_sizedisk_size
Container
OpSys
Scalable
Container
ArtifactsApache.TARscripts
requirements:- host:capability:tosca.capabilities.Containernode:tosca.nodes.Computerelationship: tosca.relationships.HostedOn
capabilities:host:type: tosca.capabilities.Containervalid_source_types: [tosca.nodes.SoftwareComponent]
capabilities:host:type: tosca.capabilities.Containervalid_source_types: [tosca.nodes.WebApplication]
Container
Effectively…Computeis a Container (Node Type)WebServer(i.e. a childofSoftwareComponent)is both a Container and Containee (Node Type)
Modeling Container-Containee like Compute-Software ComponentExpressing “Docker” as a Capability Type
Container
Docker
Docker
artifacts:-image:mime_type: Dockerrepo: xxxURI: xxx
Container
OpSys
Scalable
Container
Container
ArtifactsDocker 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 *]
Container
IaaSModelingCompute isexplicit or implicit
PaaSModelingContainer isexplicit orimplicit
AgnosticCloud FoundryAzure
directive:substitutable
Container
* “Effectively NULL”, not actually a NULL value.meaning, we do not need to bind to a Node Type
ArtifactsDocker Image(Apache.TAR)
requirements:-host:# Primary Capability for relationshipcapability:tosca.capabilities.Containerrelationship:tosca.relationships.HostedOntarget_filter:# 1-N secondary Capabilities…capabilities:-tosca.capabilities.runtime.Dockerproperties:- foo: bar
capabilities:host:type:tosca.capabilities.Container# Shows we need to loosen type dependency, not actually NULLvalid_source_types: [NULL]docker:type:tosca.capabilities.runtime.Docker
Container
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 TypeBut also then:Provides a “target_filter” that lists 1..nSecondary 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
…
Note: We would still want to move Compute properties into Containercapabilityi.e., because every container “virtualizes” basic memory/storage/compute powerand allows application to provide “desired” or “optimal” VM environmentbut without any new Runtime property (orDataType)
Final Proposal:Docker provided as a Capabilityin addition to “Container” CapabilityType
Still need to address virtualizing “ports” and IP addresseswhich 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 beexpressed 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 2015-02-25:http://blog.docker.com/2015/02/announcing-docker-compose/Show how we address their “roadmap” items already…“Morethan just developmentenvironments”Over time we will extendCompose'sremit to cover test, staging and production environments. This is not a simple task, and will take many incremental improvements such as:Compose’sbrute-force “delete and recreate everything” approach is great fordevand 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.
0
Embed
Upload