Modeling Deployment Content and Metadata Progressing towards a

  • Slides: 17
Download presentation
Modeling Deployment Content and Metadata

Modeling Deployment Content and Metadata

Progressing towards a complete example of a Sugar. CRM deployment 1. Sugar. CRM usecase

Progressing towards a complete example of a Sugar. CRM deployment 1. Sugar. CRM usecase – 2. Core, Basic, Custom Node Types and Relations – 3. Entities and relations required to represent the usecase Deployment content and metadata – 4. Topology, architecture and content of a basic 2 tier LAMP application Representation of Sugar. CRM deployment content and metadata Deployment Orchestration – Processing steps using the model to realize a physical deployment

Modeling Installed Content n n n Nodes are materialized from deployment content (the bits)

Modeling Installed Content n n n Nodes are materialized from deployment content (the bits) packaged as Deployment Artifacts The relevant information is described and does not imply any specific TOSCA encoding Installation Description – Describes how the Deployment Artifact contents are to be deployed for the Node Instance in the target – This content varies for each usage and hence cannot be stored as invariant information in the Deployment Artifact – Installation Descriptors can be reused n Deployment Artifact – – Describes the semantic details of the artifact Does not require the consumer to inspect the artifact contents Specifies the location of the bits and enough information for getting the bits Deployment Artifacts can be reused

Sugar. CRM Service Model Sugar. CRM Service Web. Server. Tier DBServer. Tier Port 80

Sugar. CRM Service Model Sugar. CRM Service Web. Server. Tier DBServer. Tier Port 80 HTTP End. Point Apache Web Server HTTP Client Document. Root: /Sugar. CRM HTTP Content End. Point Required End. Point Provided End. Point Sugar. CRM App PHP Module My. SQL Sugar. CRM DB Typed Connector Database Server End. Point propagates client credentials, DB Name, host and port client End. Point (Web Server)

Sugar. CRM Installation Content Apache Web Server Sugar. CRM App Apache. RPMInstallation /etc/httpd/conf. d/httpd.

Sugar. CRM Installation Content Apache Web Server Sugar. CRM App Apache. RPMInstallation /etc/httpd/conf. d/httpd. conf Sugar. CRMWeb. Application. Installation (sugar. CE-Full-6. 1. 5. tar. gz located at: /var/www/html/ Sugar. CE-Full-6. 1. 5). /config. php PHP Module PHPRPMInstallation /etc/php. ini /etc/httpd/conf. d/php. conf My. SQL Sugar. CRM DB My. SQLDatabase. RPMInstallation /etc/my. cnf My. SQLDatabase. Content. Installation (mysql-5. 0. 77_db_sugarcrm. tar. gz)

Apache/Sugar. CRM Installation Model TOSCA Deployment Artifacts Apache Web. Server Container RPM Installation TOSCA

Apache/Sugar. CRM Installation Model TOSCA Deployment Artifacts Apache Web. Server Container RPM Installation TOSCA Node Component Apache Web. Server Aggregated Installation (Containment relation) Nested installations of multiple levels are possible Entire Apache Web. Server Installation PHP Installation Base RPMs Ex RPMs PHP Module PHP Sugar CRM Web Application Installation Sugar. CRM Archive

Relating Components to their Installations Complete TOSCA Node Model Apache Web. Server Container RPM

Relating Components to their Installations Complete TOSCA Node Model Apache Web. Server Container RPM Installation Apache Web Server PHP Module PHP Installation Base RPMs Ex RPMs PHP Module PHP Sugar. CRM App TOSCA Node structure represents application structure TOSCA Deployment Artifacts Sugar CRM Web Application Installation Virtunomic Proprietary and Confidential Sugar. CRM Archive

Common Deployment Artifacts n n n n Disks/Volumes VM Images Packages Archives User Specific

Common Deployment Artifacts n n n n Disks/Volumes VM Images Packages Archives User Specific Archives Files Keys, Certs, Licenses, Account #, Passwords (defer)

Disks/Volumes Disk Installation OS: Mount location: /db, UID, GID, perms Device name: /dev/sdd 1

Disks/Volumes Disk Installation OS: Mount location: /db, UID, GID, perms Device name: /dev/sdd 1 Deployment of a disk requires configuration of the virtual infrastructure and the OS VM: Controller #, Unit # Deployment Artifact Disk Descriptor OS Descriptor Partition Descriptors URI to disk files Disk Part 1 Part N URIs: repo: /disks/disk 1 file: /disks/disk 2. img vsphere: !https/192. 168. 2. 155/sdk!<storage. Path>disk. vmdk E. g. . vmdk, . img, . vhd, EBS. May consist of one or more artifacts depending on format.

VM Images VM Installation Deployment of a VM Image requires a set of launch

VM Images VM Installation Deployment of a VM Image requires a set of launch parameters Launch params: Hypervisor params, key pairs, … Launch data: File or data available at launch Deployment Artifact VM Descriptor(s) OS Descriptor Device Descriptors URI to disk files Disk Part 1 Part N E. g. OVF, virt-image, AMI. Note OVFs may contain multiple VMImages Resource Descriptors URIs: s 3. amazomaws. com: /abc/images/centos-basic/centos/5/1. 0 -SNAPSHOT-2/x 86_64/centosbasic. ec 2. manifest. xml vsphere: !https/192. 168. 2. 155/sdk!<storage. Path><image. Name>

Packages Package Installation Specifies a set of packages to install by referencing one or

Packages Package Installation Specifies a set of packages to install by referencing one or more Deployment. Artifacts describing packages compatible with the target Packages from packagers such are RPM, MSI, DPKG are commonly deployed. The caveat is how dependencies are computed conflicts resolved. Often a few packages are specified and a package repository is used to find any additional required packages from the package repository. Deployment Artifact Package Descriptor 1 Package Descriptor n Package (s) Packages may be included in the deployment bundle (. rpm, . msi, …) If not they are loaded from a repo. Package descriptors may specify package location, or a package ID and the repository expected to provide the package. A repository may be packaged as part of the deployment bundle.

Archives Archive Installation Extract location: /opt/app, UID, GID, Perms File UID, GID mapping table

Archives Archive Installation Extract location: /opt/app, UID, GID, Perms File UID, GID mapping table Deployment Artifact Archive Descriptor Format: tar. gz Extraction method: tar –C /opt –xvf <archive> Metadata: UID/GID table Usage of archives requires extraction information and metadata for creating extraction folder. Since files are extracted, a mapping table maps UIDs/GIDs from thearchive to appropriate values in target OS Archive E. g. . tar, . zip, . gz, . bin, patch, installers, … URIs: repo: /archives/mydata. tar. gz file: /disks/database. Content. tar. gz vsphere: !https/192. 168. 2. 155/sdk!<inventory. Path>/My. VM!filesystem: /opt/data repo: /vms/myapp. ova!filesystem: /opt/data

User Archives User Archive Installation Extends Archive Installation with user account creation mapping original

User Archives User Archive Installation Extends Archive Installation with user account creation mapping original user account to account in target OS. Deployment Artifact User Archive Desc. Extends Archive Descriptor with source user account information. E. g. /etc/passwd data. Contains the data of a user in the operating system belonging to the sub-tree of the user’s account folder. E. g. /home/dbadmin Archive E. g. . tar, . zip, … URIs: repo: /archives/user_dbadmin. tar. gz file: /disks/user_dbadmin. zip vsphere: !https/192. 168. 2. 155/sdk!<inventory. Path>/My. VM!filesystem: /home/dbadmin

Files File Installation Extract location: /etc/top/app. cfg, UID, GID, Perms Deployment Artifact Archive Descriptor

Files File Installation Extract location: /etc/top/app. cfg, UID, GID, Perms Deployment Artifact Archive Descriptor Format: raw, compressed, … Extraction method Execution method Metadata: UID/GID table It may be necessary to deploy a specific file or to place a script in a specific location for execution File Any file. Usually not big. URIs: repo: /files/appinit. sh file: /files/appinit. sh vsphere: !https/192. 168. 2. 155/sdk!<inventory. Path>/My. VM!filesystem: /etc/rc. d/init. d/appx repo: /vms/myapp. ova!filesystem: /etc/rc. d/init. d/appx

Common DA metadata n Identity – Stronger than the artifact name n Version –

Common DA metadata n Identity – Stronger than the artifact name n Version – Scoped version ID n Origin information (Where did it come from? ) – URI of source, description, descriptor (any data) n n Expanded size Hash Signature Encryption

Packaging n An overall deployable TOSCA service is a collection of: – The TOSCA

Packaging n An overall deployable TOSCA service is a collection of: – The TOSCA XML file(s) describing the Service. Template, Node. Types, Relationship. Types, … – XSD files defining Node Type properties etc. – Plan model files (e. g. BPMN 2. 0 files) referenced from the Service Template – Deployment artifacts like archives, files, software installables, … n A self-contained packaging format as shipment vehicle for the above collection seems necessary – Self-contained archive file containing all the model files and artifacts, that can be deployed into a TOSCA environment n Proposal: define a packaging format for TOSCA services and their related artifacts similar to existing packaging formats (e. g. in JEE world)

Sketch of a Packaging Format /Meta-Inf Sugar. CRM Example /Service-Template /Types /Plans /. .

Sketch of a Packaging Format /Meta-Inf Sugar. CRM Example /Service-Template /Types /Plans /. . . /Archives /Scripts • Align with existing packaging formats (JAR, tar, EAR, …) • Define structure, content, and processing semantics /Meta-Inf MANIFEST. MF /Service-Template Sugar. CRM-Service. Template. xml /Types Sugar. CRM-Types. xsd /Archives sugar. CE-Full-6. 1. 5. tar. gz mysql-5. 0. 77_db_sugarcrm. tar. gz Note: larger artifacts (e. g. images) might be referenced instead of being packaged.