How to Build CSARs. Tim Waizenegger. University of Stuttgart Universitätsstr Stuttgart Germany.

Transcription

1 How to Build CSARs for OpenTOSCA University of Stuttgart Universitätsstr Stuttgart Germany Tim Waizenegger Gefördert durch: Förderschwerpunkt: Projektträger:

2 Preface 2

3 Purpose of this Document This How-To will explain the general steps involved in creating a cloud service model in TOSCA and providing it as a packaged CSAR file for OpenTOSCA University of Stuttgart 3

4 Prerequisites A running instance of the Winery modeling tool See Installation Guide Existing NodeTypes See Winery Quick Start Knowledge about the OpenTOSCA principles and imperative provisioning See OpenTOSCA Presentation University of Stuttgart 4

5 Basics 5

6 TOSCA in one Slide TOSCA conceptually consists of two parts: Application Topologies Management Plans Application Topology Management Plans Node X Relationship Node Management Operation calls University of Stuttgart 6

7 Contents of a CSAR file Type X Properties Interfaces Topology (Templates) Types Management Plans Deployment Artifacts Implementation Artifacts Images Services Installables Scripts Deployment Artifacts Implementation Artifacts Cloud Service Archive (CSAR) University of Stuttgart 7

8 Steps to create a CSAR 8

9 Process overview 1. Sketch the topology and orchestration 2. Decide on appropriate NodeTypes for your topology 3. Create a new ServiceTemplate in Winery 4. Model your previously sketched topology in winery using your NodeTypes as building blocks 5. Supply the necessary parameters to the NodeTemplates 6. Model and then import your complete Plan-Package 7. Supply the input/output message format of your plan 8. Define your default plan input message and further selfservice information 9. Export your finished ServiceTemplate as CSAR file University of Stuttgart 9

10 1. Sketch the topology and orchestration For the purpose of this guide, we will model a cloud service offering a MySQL Database We will use the amazon public cloud for hosting a virtual machine Which should run a linux operating system On which we then run the MySQL database system Our provisioning logic therefore needs to: Request a virtual machine with the appropriate operating system Install the MySQL database And finally configure the MySQL instance University of Stuttgart 10

11 2. Decide on appropriate NodeTypes for your topology Database ( MySQL ) I A Configure instance Operating System ( Ubuntu ) I A Install MySQL VM ( VirtualMachine ) Provision VM and OS Amazon EC2 Public Cloud ( AmazonEC2 ) I A University of Stuttgart 11

12 3. Create a new ServiceTemplate in Winery University of Stuttgart 12

13 4. Model your topology University of Stuttgart 13

14 4. Model your topology University of Stuttgart 14

15 5. Supply parameters to the node templates University of Stuttgart 15

16 6. Model & Import your plan package Since OpenTOSCA is an imperative container, you need to provide the topology AND orchestration logic OpenTOSCA currently supports orchestration logic in the form of BPEL workflows You can use any BPEL modeling tool (e.g. to develop your orchestration plan An example plan can be found in the example CSAR referenced on the very last slide of this document As the next step, import the finished plan package into Winery University of Stuttgart 16

17 6. Model & Import your plan package University of Stuttgart 17

18 6. Model & Import your plan package University of Stuttgart 18

19 7. Supply plan input and output parameters The plan I/O parameters you supply to Winery will be written to the TOSCA service template definition They have to match the input/output message definition from the plan itself It is good practice to copy the message definition from the plan s WSDL to the TOSCA definition University of Stuttgart 19

20 8. Provide Self-Service Information The OpenTOSCA ecosystem provides a Self-Service Portal which Shows all CSARS available in the container with a description Allows starting the Build Plan execution by a single click by passing a predefined (default) plan input message to the plan Receives the callback from the plan to show the plan result to the user To use this feature, you have to supply the following as part of the CSAR: Service description/icon BuildPlan reference and default input message University of Stuttgart 20

21 8. Provide Self-Service Information University of Stuttgart 21

22 9. Export finished CSAR file Now the finished CSAR can be exported from Winery It can be re-imported to different Winery instances A CSAR file is a ZIP file, it can be extracted, edited by hand and re-packaged University of Stuttgart 22

23 9. Export finished CSAR file University of Stuttgart 23

24 Further Information 24

25 A simple example CSAR file An example CSAR file can be found at: It contains a small topology consiting only of an OpenStack virtual machine node and a linux operating system node The OpenStack node has an attached implementation artifact for calling the OpenStack API from within a build plan The linux node has an attached implementation artifact that allows sending SSH-commands to the linux-vm from within a plan It contains an executable BPEL build plan which will provision a single virtual machine running linux, and then execute a single command on that machine via SSH It contains self-service data and can be used from the selfservice portal Vinothek It contains an ANT script for re-packaging the CSAR file after manual extraction/modification University of Stuttgart 25