TOSCA SugarCRM Deployment

technical detail discussionTOSCA Interop SC

2

SugarCRM Topology TemplateSugarCrmApp

[SugarCRMApplication]

SugarCrmDb

[SugarCRMDatabase]

PhpModule

[ApachePHPModule]

ApacheWebServer

[ApacheWebServer]

MySql

[MySQL]

connects to

hosted on

hosted on hosted on

hosted on

hosted on

depends on

VmApache

[Server]

VmMySql

[Server]

hosted on hosted on

OsApache

[OperatingSystem]

OsMySql

[OperatingSystem]

hosted on hosted on

WebTier

[Tier]

DbTier

[Tier]

3

Node and Relationship operations

NodeType“Database”

CNodeType

“Application” R

Lifecycle operations (create, configure, start, …) are used by an orchestrator to create

and manage components

Connector conceptRelationship Types declare what endpoints they can

connect, and which processing logic they inject to

establish a link at runtime

Base Relationship Types HostedOn, DependsOn and ConnectsTo define the base

semantics for processing topology models

RelationshipType“DBConnection”

NodeTemplate“MyDB”

CNodeTemplate“MyApp” R

is of type is of typeis of type

• Use defined lifecycle operations to deploy and manage each component• Use base relationship types to derive processing order

• Process a host before a hosted component (HostedOn)• Process a provider before a client (DependsOn, ConnectsTo)

• If a component is related to another component, see if relationship injects additional processing logic (e.g. pre-configure endpoint)

… a pretty mechanical process

4

Declarative processing of SugarCRM model• Use base relationship types to derive component

processing order– First process a host, then process hosted component– First process a component that another component

depends on, then process the dependent component– First process a component that another component

connects to, then process the connecting component

• For each component– Deploy its Deployment Artifacts– Invoke lifecycle operations in right sequence (create,

configure, start …); their can be no-ops

• If a relationship contributes logic, inject it into component operation invocations

Web 1

Web 2

Web 3

Web 4

Web 5

DB 1

DB 2

DB 3

DB 4

relationship injectslogic

DB 1

DB 2

DB 3

DB 4

Web 1

Web 2

Web 3

Web 4

create VM

perform base OS config

install and configure httpd

install and configure php runtime

create VM

perform base OS config

install and configure MySQL

create and configure SugarCRM database

Web 5 install and configure SugarCRM app,configure database endpoint properties

run in parallel

wait for step“DB 4” to complete

5

Artifacts and automation in TOSCA models

• Deployment Artifacts referenced in a TOSCA model represent the “deployable bits” that embody components of a deployment at runtime

– Examples: software installables, OS packages (rpm, deb, …), simple files, archives, images for VMs– Deployment Artifacts just get declared in the model and orchestrator implements logic to do

automatic deployment• For example, an archive artifact for a tarball might include metadata about target location as well as file path

permissions for target location, incl. user/group mappings orchestrator derives corresponding sequence of commands for full deployment flow

• Currently supported: File, Archive, User Archive, RPM List, RPM Group List

• Implementation Artifacts referenced in TOSCA model represent implementation of operations on components of the model

– Examples: scripts, chef automation, executable programs– Implementation Artifacts get executed in context of deployed environment; model parameters (e.g.

Node Template properties) and other context information (e.g. hostnames, IP addresses) passed as arguments

• Artifact definitions in TOSCA model have a pointer to the actual artifact– In current use cases, typically a relative URL to a file in the CSAR containing the TOSCA model, but

could be any URL accessible by the orchestration environment• Deployment Artifacts for a component get deployed before any Implementation Artifacts get

executed– Most basic scenarios could be done with Deployment Artifacts only (e.g. rpm based installation of

MySQL on a VM)

6

Example Deployment Artifact and Implementation Artifact usage

OperatingSystem

Server

WebServer

configureImplementationArtifact "webserver-configure"artifactType: ScriptArtifactscript: scripts/WebServer/configure.sh

DeploymentArtifact "webserver-packages "artifactType: OsPackageArtifactpackages: [httpd, php, php-cli, php-common, php-mysql, php-xml]

#!/bin/bash

# set listen port of httpdsed –i "s/Listen 80/Listen $httpport" $httpdconfig

# more stuff ...

<NodeTemplate id="WebServer" type="WebServer"> <Properties> <WebServerProperties> <httpport>8080</httpport> ... </WebServerProperties> </Properties></NodeTemplate>

<NodeType name="WebServer"> ...</NodeType>

<NodeTypeImplementation name="WebServer-rhel-x86_64“ nodeType="WebServer"> <RequiredContainerFeatures> <RequiredContainerFeature feature="os_type">linux</Req...> <RequiredContainerFeature feature="os_distro">rhel</Req...> </RequiredContainerFeatures> <ImplementationArtifacts> <ImplementationArtifact artifactRef="webserver-configure" artifactType="ScriptArtifact" interfaceName="http://.../lifecyle" operationName="configure"/> ... </ImplementationArtifacts> <DeploymentArtifacts> <DeploymentArtifact artifactRef="webserver-packages" artifactType="OsPackageArtifact"/> </DeploymentArtifacts></NodeTypeImplemenation>

<ArtifactTemplate id="webserver-packages" type="OsPackageArtifact"> <Properties> <OsPackageArtifactProperties packageType="rpm"> <PackageInformation packageName="httpd"/> <PackageInformation packageName="php"/> ... </OsPackageArtifactProperties> </Properties></ArtifactTemplate>

<ArtifactTemplate id="webserver-configure" type="ScriptArtifact"> ...</ArtifactTemplate>

In this example, configure.sh script is packaged in directory scripts/WebServer in the CSAR containing the TOSCA template definition.

One NodeType can have multiple implementations, e.g. for different operating systems. Orchestrator selects based on Required Container Features definitions.

$httpport accesses a property of the associated NodeTemplate.

7

Lifecycle operations and invocation context for Implementation Artifacts

• Default lifecycle operations for nodes:– install, configure, start, stop, delete – there may be no-ops (leave out operations)– Flow for deploy case: install, configure, start

• In case of chef automation, only install operation is used

• Default lifecycle operations for relations:– preConfigureEndpoint, postConfigureEndpoint for both source and target – there

may be no-ops• Each node operation gets as context all properties of the node (defined in

XSD)plus PublicIP, PrivateIP, HostName, FQDN of the VM where the node is hosted

• Each relationship operation gets as context all properties of the relationship (defined in XSD)– Plus properties, PublicIP, PrivateIP, HostName, FQDN of the VM where the source

node is hosted (prefixed with Source_)– Plus properties, PublicIP, PrivateIP, HostName, FQDN of the VM where the target

node is hosted (prefixed with Target_)

8

Example processing flow including node and relationship operations

• Node2.install• Node2.configure• Node2 postConfigureEndpoint• Node2.start• Node1.install• Node1.configure• Node1 postConfigureEndpoint• Node1.start

Node1

install

configure

start

Node2

install

configure

startpostConfigureEndpoint

postConfigureEndpoint