1 / 8

TOSCA SugarCRM Deployment

TOSCA SugarCRM Deployment. technical detail discussion TOSCA Interop SC. SugarCRM Topology Template. connects to. depends on. SugarCrmApp [ SugarCRMApplication ]. SugarCrmDb [ SugarCRMDatabase ]. hosted on. hosted on. PhpModule [ ApachePHPModule ]. hosted on. hosted on. hosted on.

malana
Download Presentation

TOSCA SugarCRM Deployment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TOSCA SugarCRM Deployment technical detail discussionTOSCA Interop SC

  2. SugarCRM Topology Template connects to depends on SugarCrmApp [SugarCRMApplication] SugarCrmDb [SugarCRMDatabase] hosted on hosted on PhpModule [ApachePHPModule] hosted on hosted on hosted on MySql [MySQL] ApacheWebServer [ApacheWebServer] OsApache [OperatingSystem] OsMySql [OperatingSystem] hosted on hosted on VmMySql [Server] VmApache [Server] hosted on hosted on WebTier [Tier] DbTier [Tier]

  3. Node and Relationship operations RelationshipType“DBConnection” Lifecycle operations (create, configure, start, …) are used by an orchestrator to create and manage components is of type is of type is of type Connector concept Relationship 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 • 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 NodeTemplate “MyApp” NodeType“Application” NodeTemplate “MyDB” NodeType“Database” C C R R

  4. Declarative processing of SugarCRM model relationship injectslogic • 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 5 DB 4 Web 4 Web 3 DB 3 Web 2 DB 2 Web 1 DB 1 Web 1 DB 1 create VM create VM Web 2 DB 2 perform base OS config perform base OS config run in parallel install and configure httpd install and configure MySQL Web 3 DB 3 install and configure php runtime create and configure SugarCRM database Web 4 DB 4 install and configure SugarCRM app, configure database endpoint properties Web 5 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 <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> <ImplementationArtifactartifactRef="webserver-configure" artifactType="ScriptArtifact" interfaceName="http://.../lifecyle" operationName="configure"/> ... </ImplementationArtifacts> <DeploymentArtifacts> <DeploymentArtifactartifactRef="webserver-packages" artifactType="OsPackageArtifact"/> </DeploymentArtifacts> </NodeTypeImplemenation> <ArtifactTemplate id="webserver-packages" type="OsPackageArtifact"> <Properties> <OsPackageArtifactPropertiespackageType="rpm"> <PackageInformationpackageName="httpd"/> <PackageInformationpackageName="php"/> ... </OsPackageArtifactProperties> </Properties> </ArtifactTemplate> <ArtifactTemplate id="webserver-configure" type="ScriptArtifact"> ... </ArtifactTemplate> One NodeType can have multiple implementations, e.g. for different operating systems. Orchestrator selects based on Required Container Features definitions. DeploymentArtifact"webserver-packages " artifactType: OsPackageArtifact packages: [httpd, php, php-cli, php-common, php-mysql, php-xml] WebServer configure ImplementationArtifact "webserver-configure" artifactType: ScriptArtifact script: scripts/WebServer/configure.sh OperatingSystem #!/bin/bash # set listen port of httpd sed –i "s/Listen 80/Listen $httpport" $httpdconfig # more stuff ... Server $httpport accesses a property of the associated NodeTemplate. In this example, configure.sh script is packaged in directory scripts/WebServer in the CSAR containing the TOSCA template definition.

  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 Node1 Node2 install install postConfigureEndpoint configure configure start postConfigureEndpoint start • Node2.install • Node2.configure • Node2  postConfigureEndpoint • Node2.start • Node1.install • Node1.configure • Node1  postConfigureEndpoint • Node1.start

More Related