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
cpu_frequency: # per cpu
type: scalar-unit.frequency
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
• 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
Opaque Containee Implementation: Providing Docker “image” as an artifact
Use Case 1: Docker Image (with WebServer inside) as a TOSCA Artifact in CSAR file
TOSCA CSAR File
PaaS
Modeling
•
Containee
(Docker Runtime
Requirement)
Container is explicit or implicit
Software
Component
Container
(Docker Runtime
Capability)
Requirements
Hosted
On
tosca.artifacts.Container.Docker.Image:
derived_from: tosca.artifacts.Root
description: Docker Image TAR
mime_type: TBD
file_ext: [ TBD ]
Docker
Rocket
Container
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 ]
artifact_types:
# NEW Tosca non-normative type
Container
Capabilities
…
Artifacts
• Docker Image
• (Apache.TAR)
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:
Opaque Containee Implementation: Providing Docker “image” as an artifact
Use Case 3: Docker Image (with WebServer inside) in a “Docker” Repo.
Containee
PaaS
Modeling
•
(Docker Runtime
Requirement)
Container is explicit or implicit
• URI of DockerImage
• Relative to Repo.
Requirements
Software
Component
Container
Container
(Docker Runtime
Capability)
Artifacts
•
•
artifact_types:
tosca.artifacts.impl.Docker.Image:
derived_from: tosca.artifacts.Root
description: Docker Image TAR
mime_type: TBD
file_ext: [ tar ]
Hosted
On
Capabilities
Docker
Rocket
…
Container
Docker Image
.TAR)
# 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: < URI of Docker Image in Repo. >
type: tosca.artifacts.impl.Docker.Image:
repository: docker_repo
Docker Hub
(Repo.)
Opaque Containee Implementation: Providing Docker “image” as an artifact
Use Case 3: Dynamically “build” Docker Image using multiple repositories, single Node Template
(IN-PROGRESS)
Artifacts
Containee
PaaS
Modeling
•
•
Guest OS (TAR)
(Docker Runtime
Requirement)
Container is explicit or implicit
• URIs of components
• Relative to Repos.
Artifacts
•
Software
Component
Container
Apache Repo
Requirements
(Docker Runtime
Capability)
Docker Hub
(Repo.)
Apache
(Repo.)
Container
Hosted
On
Capabilities
Artifacts
Docker
•
Rocket
…
Container
# 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: ...
Pizza App
Pizza Store App
(Repo.)
Opaque Containee Implementation: Providing Docker “image” as an artifact
Use Case 4: Dynamically “build” Docker Image using multiple repositories, Multiple Node templates
(IN-PROGRESS)
Containee
PaaS
Modeling
•
•
•
Container is explicit or implicit
Docker Hub
(Repo.)
Artifacts
(Docker Runtime
Requirement)
•
Guest OS
URIs of components
Relative to Repos.
Capabilities
Artifacts
OS
•
WebServer
Software
Component
Container
Apache Repo
Apache
(Repo.)
Requirements
Container
(Docker Runtime
Capability)
WebApp
Hosted
On
Capabilities
Docker
Artifacts
•
Rocket
Pizza App
…
Container
# 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: ...
# NOT YET IN TOSCA SPEC. TO BE INVENTED…
repositories:
apache_repo: ...
Pizza Store
App
(Repo.)
node_templates:
TBD
# NOT YET IN TOSCA SPEC. TO BE INVENTED…
repositories:
paypal_repo: ...
node_templates:
TBD
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.
Opaque Containee Implementation: Providing Docker “image” as an artifact
Use Case 5: Docker Image (with persistent storage) using Cinder
BlockStorage
(implied if
Attachment is
“on” in Compute
Node)
Capabilities
Container.App
tosca.nodes.Containee
Software Component
tosca.nodes.Container.
Runtime
Attachment
-
-
AttachesTo
Choice of Impl.
Nova Docker
Magnum
perhaps with
Kubernetes
perhaps with
something else?
Requirements
Container
Compute
(Container)
Capabilities
Docker
Requirements
Requirements
(Turn on if
Attachment
Capability is
used by
Container)
Attachment
(0..N)
Container
Capabilities
Container
OpSys
Attachment
AttachesTo
Requirements
Docker
(subset of Dockerfile)
Container
Attachment
Scalable
“Container”
tosca.nodes.Docker.Container