Upload
august-thomas
View
212
Download
0
Embed Size (px)
Citation preview
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)
Container(Docker Runtime
Capability)
Modeling Container-Containee like Compute-Software ComponentExpressing “Docker” as a Capability Type
Containee(Docker Runtime
Requirement)b
Containee(Docker Runtime
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
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
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)
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:
ContainerContainer
ContainerContainer
Opaque Containee Implementation: Providing Docker “image” as an artifact
DockerDocker
RocketRocket…
PaaSModeling• 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.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 ComponentContainer
(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: < URI of Docker Image in Repo. > type: tosca.artifacts.impl.Docker.Image: repository: docker_repo
ContainerContainer
ContainerContainer
Opaque Containee Implementation: Providing Docker “image” as an artifact
DockerDocker
RocketRocket…
PaaSModeling• 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.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 ComponentContainer
(Docker Runtime Capability)
Container(Docker Runtime
Capability)
Containee(Docker Runtime
Requirement)
Containee(Docker Runtime
Requirement)
Requirements
Capabilities
ContainerContainer
ContainerContainer
Opaque Containee Implementation: Providing Docker “image” as an artifact
DockerDocker
RocketRocket…
PaaSModeling• 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 ComponentContainer
(Docker Runtime Capability)
Container(Docker Runtime
Capability)
Containee(Docker Runtime
Requirement)
Containee(Docker Runtime
Requirement)
Requirements
Capabilities
ContainerContainer
ContainerContainer
Opaque Containee Implementation: Providing Docker “image” as an artifact
DockerDocker
RocketRocket…
PaaSModeling• 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
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.