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 <or>
• 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) <or>
• 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
Exploring Containment in TOSCA: Modeling WebServer with Compute
• Effectively…
• Compute is a Container (Node Type)
• WebServer (i.e. a child of SoftwareComponent) is both a Container and Containee (Node Type)
Software Component
Artifacts
• Apache.TAR
• scripts
(Container + Containee)
WebServer
Capabilities
Container
Requirements
Container
capabilities:
host:
type: tosca.capabilities.Container
valid_source_types: [ tosca.nodes.WebApplication ]
HostedOn
Compute
(Container)
Capabilities
Container
Properties
•
•
•
num_cpus
mem_size
disk_size
requirements:
- host:
capability: tosca.capabilities.Container
node: tosca.nodes.Compute
relationship: tosca.relationships.HostedOn
Scalable
OpSys
capabilities:
host:
type: tosca.capabilities.Container
valid_source_types: [tosca.nodes.SoftwareComponent]
Modeling Container-Containee like Compute-Software Component
Expressing “Docker” as a Capability Type
PaaS
Modeling
IaaS
Modeling
-
•
Compute is explicit or implicit
Agnostic
Container is explicit or implicit
• Cloud Foundry
• Azure
Containee
Software
Component
(Container +
Containee)
(Docker Runtime
Requirement)
Requiremenb
ts
WebServer
Docker
Capabilities
Container
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.HostedOn
Software Component
Hosted
On
(Docker Runtime
Capability)
Hosted
On
Scalable
OpSys
Requirement
s
Container
Capabilities
Docker
Container
directive: substitutable
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.HostedOn
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 DataType)
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 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)
• Compose should recommend a technique for zero-downtime deploys.