docker container modeling goals goals (not requirements) not proliferate node types for “docker”...

Docker Container Modeling Goals

Goals (not requirements)• Not proliferate Node Types for “Docker”

1. Consider modeling “Docker” as an (explicit) runtime Capability Type2. 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 it3. 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 interchangeablecapabilities.

• 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)

WebServerWebServer

HostedOn

Compute(Container)Compute

(Container)

Exploring Containment in TOSCA: Modeling WebServer with Compute

Properties• num_cpus• mem_size• disk_size

Capabilities

Requirements

ContainerContainer

OpSysOpSys

ScalableScalable

ContainerContainer

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

ContainerContainer

• Effectively…• Compute is a Container (Node Type)• WebServer (i.e. a child of SoftwareComponent) is both a Container and Containee (Node Type)

Hosted On

Hosted On

Software Component

Container(Docker Runtime

Capability)


Capability)

Modeling Container-Containee like Compute-Software ComponentExpressing “Docker” as a Capability Type

Containee(Docker Runtime

Requirement)b


Requirement)b

Capabilities

ContainerContainer

DockerDocker

Requirements

DockerDocker

artifacts: - image: mime_type: Docker repo: xxx URI: xxx

Software Component(Container + Containee)

Software Component(Container + Containee)

WebServerWebServer

Compute(Container)Compute

(Container)

Capabilities

Requirements

ContainerContainer

OpSysOpSys

ScalableScalable

ContainerContainer

Capabilities

ContainerContainer

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 *]

Requirements

ContainerContainer

IaaS Modeling- Compute is explicit or implicit

PaaSModeling• Container is explicit or implicit

Agnostic• Cloud Foundry• Azure

directive: substitutable

ContainerContainer

* “Effectively NULL”, not actually a NULL value. meaning, we do not need to bind to a Node Type

Hosted On

Software Component


Capability)


Capability)


Requirement)


Requirement)

Requirements

Capabilities


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

ContainerContainer

ContainerContainer

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..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

DockerDocker

RocketRocket

…

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

• 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 ComponentContainer

(Docker Runtime Capability)


Capability)


Requirement)


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:

ContainerContainer

ContainerContainer

Opaque Containee Implementation: Providing Docker “image” as an artifact

DockerDocker

RocketRocket…


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.Root description: Docker Image TAR mime_type: TBD file_ext: [ 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




Capability)


Requirement)


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: < URI of Docker Image in Repo. > type: tosca.artifacts.impl.Docker.Image: repository: docker_repo

ContainerContainer

ContainerContainer


DockerDocker

RocketRocket…


Use Case 3: Docker Image (with WebServer inside) in a “Docker” Repo.

artifact_types: tosca.artifacts.impl.Docker.Image: derived_from: tosca.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




Capability)


Requirement)


Requirement)

Requirements

Capabilities

ContainerContainer

ContainerContainer


DockerDocker

RocketRocket…


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




Capability)


Requirement)


Requirement)

Requirements

Capabilities

ContainerContainer

ContainerContainer


DockerDocker

RocketRocket…


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

WebServerWebServer

WebAppWebApp

# 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

OSOS

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.

http://blog.docker.com/2015/02/announcing-docker-compose/



https://github.com/docker/fig/issues/426

docker container modeling goals goals (not requirements) not proliferate node types for “docker”...

Documents