1 / 17

Modeling Deployment Content and Metadata

Modeling Deployment Content and Metadata. Progressing towards a complete example of a SugarCRM deployment. SugarCRM usecase Topology, architecture and content of a basic 2 tier LAMP application Core, Basic, Custom Node Types and Relations

watson
Download Presentation

Modeling Deployment Content and Metadata

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. Modeling Deployment Content and Metadata

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

  3. Modeling Installed Content • 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 • 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

  4. SugarCRM Service Model SugarCRM Service WebServerTier DBServerTier Port 80 HTTP EndPoint Apache Web Server MySQL Required EndPoint Provided EndPoint HTTP Client SugarCRM App SugarCRM DB Typed Connector PHP Module DocumentRoot:/SugarCRM HTTP Content EndPoint Database Server EndPoint propagates client credentials, DB Name, host and port client EndPoint (Web Server) Zone1

  5. SugarCRM Installation Content Apache Web Server ApacheRPMInstallation /etc/httpd/conf.d/httpd.conf SugarCRM App SugarCRMWebApplicationInstallation (sugarCE-Full-6.1.5.tar.gz located at: /var/www/html/ SugarCE-Full-6.1.5) ./config.php PHP Module PHPRPMInstallation /etc/php.ini /etc/httpd/conf.d/php.conf MySQL MySQLDatabaseRPMInstallation /etc/my.cnf SugarCRM DB MySQLDatabaseContentInstallation (mysql-5.0.77_db_sugarcrm.tar.gz)

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

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

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

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

  10. 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 E.g. OVF, virt-image, AMI. Note OVFs may contain multiple VMImages Disk VM Descriptor(s) Part 1 OS Descriptor URI to disk files Part N Device Descriptors Resource Descriptors URIs: s3.amazomaws.com:/abc/images/centos-basic/centos/5/1.0-SNAPSHOT-2/x86_64/centos-basic.ec2.manifest.xml vsphere:!https/192.168.2.155/sdk!<storagePath><imageName>

  11. Packages 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. Package Installation Specifies a set of packages to install by referencing one or more DeploymentArtifacts describing packages compatible with the target Deployment Artifact Packages may be included in the deployment bundle (.rpm, .msi, …) If not they are loaded from a repo. Package (s) Package Descriptor 1 Package Descriptor n 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.

  12. Archives Archive Installation 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 Extract location: /opt/app, UID, GID, Perms File UID, GID mapping table Deployment Artifact Archive Archive Descriptor E.g. .tar, .zip, .gz, .bin, patch, installers, … Format: tar.gz Extraction method: tar –C /opt –xvf <archive> Metadata: UID/GID table URIs: repo:/archives/mydata.tar.gz file:/disks/databaseContent.tar.gz vsphere:!https/192.168.2.155/sdk!<inventoryPath>/MyVM!filesystem:/opt/data repo:/vms/myapp.ova!filesystem:/opt/data

  13. User Archives User Archive Installation 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 Extends Archive Installation with user account creation mapping original user account to account in target OS. Deployment Artifact Archive User Archive Desc. E.g. .tar, .zip, … Extends Archive Descriptor with source user account information. E.g. /etc/passwd data. URIs: repo:/archives/user_dbadmin.tar.gz file:/disks/user_dbadmin.zip vsphere:!https/192.168.2.155/sdk!<inventoryPath>/MyVM!filesystem:/home/dbadmin

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

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

  16. Packaging • An overall deployable TOSCA service is a collection of: • The TOSCA XML file(s) describing the ServiceTemplate, NodeTypes, RelationshipTypes, … • 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, … • 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 • Proposal: define a packaging format for TOSCA services and their related artifacts similar to existing packaging formats (e.g. in JEE world)

  17. Sketch of a Packaging Format /Meta-Inf SugarCRM Example /Service-Template /Types /Meta-Inf MANIFEST.MF /Plans /... /Service-Template /Archives SugarCRM-ServiceTemplate.xml /Scripts /Types SugarCRM-Types.xsd • Align with existing packaging formats (JAR, tar, EAR, …) • Define structure, content, and processing semantics /Archives sugarCE-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.

More Related