HP Continuous Delivery Automation 1.00

Continuous Delivery Automation (CDA) 1.
x: How To POC, Series 300, Level 360

HP Continuous Delivery Automation 1.00
Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. This is an HP copyrighted work that may not be reproduced without the written permission of HP. You may not use these materials to deliver training to any person outside of your organization without the written permission of HP. Intel is a trademark of Intel Corporation in the U.S. and other countries. JavaTM and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Microsoft, Windows, Windows Vista, and Windows XP are U.S. registered trademarks of Microsoft Corporation. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. UNIX is a registered trademark of The Open Group. Printed in the USA Continuous Delivery Automation (CDA) 1.x: How to POC, Level 360 Presentation and Lab Guide August 2012 CDA1.xHowToPOC-Rev.0.9
Course Introduction
Preface
Audience
The target audiences for this course include:
Pre-Sales Technical Consultants
Professional Services Consulting Engineers Technical Support Engineers
Partners in a pre-sales, professional services, or technical support role

Other technical personnel interested in learning how to install, configure and integrate CDA in a typical POC or development test lab environment and perform simple and any available POC-specific use cases that are available within a POC environment
Goal
The main goal of this course is to:
Install and configure the CDA-specific software in a pre-installed lab environment, integrate CDA with the key CDA solution products already preinstalled, provision a platform, deploy a simple application, and integrate ALM 11.5 with CDA to demonstrate the main Lab Management Automation (LMA) use case being emphasized for CDA 1.00
Course Objectives
Upon successfully completing this course, you should be able to:
Prepare for a CDA POC by properly scoping the POC based on given customer requirements
TBD (not currently in the deck)
Install and configure the CDA-specific software in a pre-installed lab environment Integrate CDA with the key CDA solution products already installed Perform verification steps to validate the CDA installation and integration with the CDA solution products
Create an IO template using HP IO and build and provision a platform around that template within CDA Model a simple application and deployment topology and deploy the an application version on to the provisioned platform Repeat the model and deploy process for a slightly more complex application (Pet Clinic)
Perform the product feature configurations or customizations most commonly encountered in POCs for CDA
Integrate ALM with CDA and deploy the lab management automation use case with ALM
Implement the most common use cases scoped for a CDA POC
6 Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Curriculum Prerequisites
Before taking this curriculum, you should have the following prerequisites or equivalent experience:
Level Prerequisites (or equivalent experience) Grow Course ID 00273768 00271543 00271553 Pre-Sales Solutions Consultants Pre-Sales Technical Consultants Yes Yes PSO Consulting Engineer Yes Yes Yes Technical Support Engineer Yes Yes
300-400 300 400 400 400 400 300
HP Operations Orchestration (OO) 9.x: Essentials, Advanced Authoring, and Integration HP Server Automation (SA) 9.x: Essentials HP Server Automation (SA) 9.x: Installation
HP Server Automation (SA) 9.x: Administration and 00271561 Yes Hopefully the team can help define what they feel the prerequisites are Maintenance for each of their organizations after 00271584 attending the bootcamp. Please HP Server Automation (SA) 9.x: OS Provisioning Yes feedback to the FE team! HP Server Automation (SA) 9.x: provide Application Deployment 00271590 Yes Manager Sitescope 11.0 Essentials and Advanced 6 months+ field experience with OO and SA 00296961 Yes Yes
Employee link: http://grow.hp.com/Saba/loginAsUser.jsp?deepLinkName=CourseDetail&deepLinkParams=courseId=<Course ID> Partner link: http://h20507.www2.hp.com/Saba/loginAsUser.jsp?deepLinkName=CourseDetail&deepLinkParams=courseId=<Course ID>
Recommended Course PATH (1.0)

The suggested course path for CDA 1.0 all technical audiences:
Level Course Title Grow Course ID 00309286 00374030 00377187 00323161 Pre-Sales Solutions Consultant 1 2 Pre-Sales Technical Consultant 1 2 3 4 (optional) PSO Consulting Engineer 1 2 3 4 (optional) Technical Support Engineer 1 2 (optional) 3 (optional) 5
200 200 400 500
CDA 1.0: Technical Awareness Webinar (TAW) CDA 1.0: Introduction to CDA CDA 1.0x: SWAT Bootcamp (beta) + CDA 1.0: Support Webinar
+ Workshop based on CDA 2.0: No longer offered on CDA 2.0, should take the Continuous Delivery Automation (CDA) 2.x: SWAT Bootcamp instead (Grow ID: 00390660)
Curriculum paths still TBD

The suggested course path for CDA 1.00 all technical audiences:
Level Course Title Grow ID Pre-Sales Pre-Sales Solutions Technical Consultant Consultant 1 2 1 2 3 4 PSO Consulting Engineer 1 2 3 4 Technical Support Engineer 1 (optional) 2 3 4 (optional)
200 200 400 400
CDA 1.00: Introduction to CDA CDA 1.00: Technical Awareness Webinar (TAW) CDA 1.00: Delta Technical Deployment Webinar + CDA 1.00: Technical Deployment Webinar 1
400
400 400 500
CDA 1.x: SWAT Bootcamp (VILT)

CDA 1.00: Technical Deployment Webinar 2 5* CDA 1.x: Service Design Workshop (VILT) TBD TBD
5 (optional)
6 (optional) 7
6 (optional) 6
Curriculum paths CDA 1.00: Delta Technical Support Webinar 00383157
still TBD 8 (optional)
8 (optional) 8
+ Recommended only if you have already been working with CDA 2.0 (skip CDA 1.00: Technical Deployment Webinar 1)
* Series of 5 webinars in the planning stages for September and October (Webinar 1 is open for registration)
Course References
References for this course to help you learn more:
Documentation:
CDA 1.00 Release Notes CDA 1.00 Support Matrix CDA 1.00 Concept Guide CDA 1.00 Install & Configuration Guide CDA 1.00 User Guide CDA 1.00 Troubleshooting Guide
Other
R&D and Product Marketing CDA Wiki:
http://rndwiki.atlanta.hp.com/confluence/display/hybridcloud/BTO+Hybrid+Cloud
https://connections.houston.hp.com/docs/DOC-12072 https://connections.houston.hp.com/docs/DOC-19291
CDA FAQ:
Pre-Sales SharePoint (internal)
CDA Forum (internal) (TBD) Please share if you have other links that you find helpful
10
Conventions
The following text conventions are used throughout the materials:
Courier text, courier text bold
Normal represents screen output, a file, or command Bold represents screen input to type
Courier italics text, courier italics text bold

Normal represents a variable to substitute Bold represents a variable to substitute and then input
11
Lesson 1: Installing and Configuring Continuous Delivery Automation

Continuous Delivery Automation (CDA) 1.x: How to POC
Lesson Goal
The main goal of this lesson is to:
Install and configure the CDA-specific software in a pre-installed lab environment
13
Lesson Objectives
Upon successfully completing this lesson, you should be able to:
List the CDA components and CDA roles
Describe the overall process for successfully installing CDA Access the lab environment
Explore the user interface of an existing CDA instance

Install the CDA software in a pre-installed lab environment Perform the post-installer integration configuration steps for CDA
Perform the post-install domain configuration steps for CDA
14
Lesson References
References for this lesson to help you learn more:
Documentation:
CDA 1.00 Release Notes CDA 1.00 Support Matrix CDA 1.00 Concepts Guide CDA 1.00 Installation & Configuration Guide CDA 1.00 Troubleshooting Guide
15
Overview of the CDA Components and Roles
Dev Sees

Operations Sees
More urgent, date-driven projects put into the queue Even more fragile code (less secure) put into production More releases have increasingly turbulent installs Release cycles lengthen to amortize cost of deployments Failing bigger deployments more difficult to diagnose Most senior and constrained IT ops resources have less time to fix underlying process problems Ever increasing backlog of work that could help the business win Ever increasing amount of tension between IT Ops, Development, Design
Fragile applications are prone to failure
Long time required to figure out which bit got flipped

Detective control is a salesperson Too much time required to restore service Too much firefighting and unplanned work Urgent security rework and remediation
Planned project work cannot complete

Frustrated customers leave Market share goes down Business misses Wall Street commitments Business makes even larger promises to Wall Street
17
Source: Gene Kim (www.realgenekim.me)
CDA functional architecture

Dev DevOps
SEM/SRC SAL SCM
Ops
ITSM Perf Mgmt
ARM
ALM AAL
AWM
MAL
BSM: SiS, Diag, EUM, TV, OM
Fault/ Health Mgmt
DSL Build repo
RTSM Add. tools
Build
RAL/CAL + provisioners/deployers IaaS Controller

HP Systems
CI Controller
Rich Infrastructure Services
Converged Infrastructure
Multi-site, Multi-tenant
Non HP Systems & Cloud Environments
18
HP Management restricted Infrastructure
CDA INTERNAL ARCHITECTURE:

EXECUTION ENGINES MODELS
ARM
Eclipse (future) ALM
A A L
Provision mgr Provision factory RAL provisioner Deployment manager Deployer factory Chef (*) deployer
APIs
MAL
MAL Event Listener MAL Internal API Monitor config Event receiver
Correlation/ Rules engine
monitoring
AWM
event pipeline
JPBM process engine Quartz scheduler
SiteScope
Diagnostics
Lab management automation
DSL
Application designer UI Infrastructure designer UI Application model Infrastructure model
RTSM
Nagios
Realized target instances
SW artifact pointers
IDeployer Internal API
IProvisioner Internal API
Chef
Server Automation
OO DMA HyperV
MOE
HP cloud
vCenter EC2 Provisioning (IaaSC)
deployment
19
call-outs, customizations
HP restricted
Initial CDA personas

Application architects (model)
Infrastructure/platform architects (model)
Developer, tester (operations)
CDA administration
20 Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein HP is subject to change without notice. restricted
CDA personae
Application developer Application builder Application tester Application release mgr Application ops mgr
Dev Requirements, Dev Code, Unit-Test, Dev Env Setup, Checkin; develops requirements for IT service designer; resolves defects from tester Build Artifacts, Src code repository Mgmt, Models; interfaces with Application release mgr & tester for releasing artifacts to DSL Test Dev Requirements, Test Code, Unit-Test, Test Lab Setup, System Test, Perf Test, Reliability Test; defines release readiness, tracks test/CHO metrics Release Planning for Releases: From Test to Staging. From Staging to Production; interfaces with Application tester for sign off on release readiness Production SLAs (uptime, performance, scaling, security) for applications in production; provides app monitoring requirements
IT platform designer
IT operations IT service manager CDA admin
Develops Templates & Pools for Dev, QA, Staging, Production; interfaces with Application developer for template requirements
Administers configurations and installations of packaged applications, OS, network, DB for QA, Staging, Production IT environments Production SLAs (uptime, performance, scaling, security) for production IT infrastructure; capacity planning; HW acquisition Manage CDA installation; provider eco-system/plugins; Systinet domains
Involved persona Primary persona

HP restricted
Not involved persona
CDA: model driven

deployed application
application version model layer operation component end point
topology stored config mapping
platform deployment provider
external software IaaS template

server group
policy binding
LB group
external service
policy provisioned platform monitor monitor provider provisioned server group
deployed monitor policy

22 Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein HP is subject to change without notice. restricted
Overview of the Installation Process
Public cloud: EC2, HP, Savvis
Conceptual CDA ecosystem
vm images Custom automation RBA server RBA server
Run book flows
Build environ. artifacts
vm images
Deploy monitoring
Deploy server Monitor server
CDA server
Provision, deploy orchestration Models: app, platform, infra, monitor policy Artifacts: platforms, deployments
Private hypervisors: VMWare Microsoft
Monitor templates Deploy server Deploy server Deploy app
Provider plugins
IaaS server
Infra service mgmt

Provision infra
VPN, firewall
Infra templates
24
CDA Installation Process Overview

Pre-Installation
database Install and configure Oracle or SQL server DB for CDA; supply drivers MOE 7.1 Install and configure MOE as IaaS layer Install: install and configure CDA HP CDA install wizard Deployer Install and configure Chef and/or Server Automation
Installation
PostInstallation
MOE service config: setup connection to MOE HP CDA Console Plugin config: create plugin configurations to other integrated tools HP CDA Console Tags: Define your orgs env tags for platforms, apps HP CDA Console Lifecycle: Define your orgs release lifecycle stages HP CDA Console
Monitoring (optional) Install and configure SiteScope, Diagnostics, Nagios
Content (optional) Install and configure OO, Chef recipes, DMA flows
CDA Installation Process

Read the Release Notes
Look for anything that might break the installation
Pre-Installation
Read the Install & Configuration Guide

Review the installation process and all the steps necessary to install the CDA solution
Check the support matrix documentation for details on the hardware and software requirements for CDA Prepare the target servers for installation
Operating systems, networking, storage, access to software installers, and so on Setup DNS and NTP on the servers,
Install pre-requisite tools

Database MOE 7.1 Deployer Monitoring (optional) Content (optional)
CDA 1.0 support matrix:

http://teams9.sharepoint.hp.com/teams/sepub/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fteams%2fs 26 Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. epub%2fShared%20Documents%2fARMCC%20and%20Abstraction%2fRelease%20Criteria

Launch Continuous Delivery Automation JAR file
Installation
Unpack install JAR to installation directory

Database setup Encryption options CDA endpoint configuration LWSSO configuration (auto install of Jboss 7.1) Reference: CDA 1.00 Install and Configuration Guide
Part of lab
27

Test embedded Jboss server
http://[install-server]:8080 should give Jboss hello page
PostInstallation
Launch CDA web UI Configure MOE server plugin

Can configure more than 1 (Note: default connection/receive timeouts usually increased in the lab) Test server connection
Create plugin configurations

Need at least 1 plugin for deployer (Chef and SA; can have multiple of each) Optional monitoring: SiteScope, Diagnostics, Nagios Optional content: SA/DMA, OO, Chef recipes
Define organizational tags in CDA

Tags are tree/taxonomy configured in CDA Used by IaaS templates, platforms, and applications
Define organizational lifecycle

Can have more that 1 lifecycle
28
Accessing the Lab Environment
30
There is an individual student environment assigned to each student by the Instructor.
31
There is the shared resource network environment that will be accessible by ALL students via their student environment.
Each student environment is identical, so only outbound connections are allowed to the Internet and the shared resource network.
33
This is the RD Web URL that you will use to access the Fort Collins lab environments for this class.
34
This is the web server that you will initially log in to using your assigned student-xxx account and password provided by the Instructor.
35
Lab Assignments Handout

Student Name Web / RDP Session Login Web / RDP Session Password RDP Session (AccessVM) IP Address
name name
name name name name name name name name name name name
ovsc\student-xxx ovsc\student-xxx
ovsc\student-xxx ovsc\student-xxx ovsc\student-xxx ovsc\student-xxx ovsc\student-xxx sovsc\tudent-xxx ovsc\student-xxx
Password Password
Password Password Password Password Password Password Password
10.0.42.xxx 10.0.42.xxx
10.0.42.xxx 10.0.42.xxx 10.0.42.xxx 10.0.42.xxx 10.0.42.xxx 10.0.42.xxx 10.0.42.xxx
The first page of the LabAssignments.pdf file contains studentxxx Password 10.0.42.xxx your assigned studentxxx account and password for the student-xxx Password 10.0.42.xxx duration of the class. This account is only for accessing the student-xxx Password 10.0.42.xxx Fort Collins lab. The PDF should be in the Virtual Room student-xxx Password 10.0.42.xxx handouts.
36

Exercise Tasks
1. Download and open the LabAssignments.pdf document from the Virtual Room.
https://www.rooms.hp.com/attend/default.aspx?key=RPNEWNMDJ2 Note that there is a generic Sandbox Student Login Process.pdf document in case you are having problems.
2. Write down or print your assigned student account, password and the IP address of your AccessVM from the document.
3. Use Internet Explorer to access the RD Web URL:
https://sandboxtraining.ovsc.adapps.hp.com/RDWeb
4. Log in using the OVSC domain account and password assigned to you. 5. Establish an RDP session to your assigned student environment. 6. Setup student environment Approximate time for exercise: 30 minutes
1. Download the Lab Assignments

https://www.rooms.hp.com/attend/default.aspx?key=RPNEWNMDJ2
38
2. Write Down your sandbox credentials & IP
39
3. Use Internet Explorer to Access the RD Web URL

https://sandboxtraining.ovsc.adapps.hp.com/RDWeb
Enter your assigned student account and password, see LabAssignments.pdf for details.
40
4. Log in Using Your Assigned OVSC Domain Account
You should now see a link to the AccessVM in the student environment that has been assigned to you by your Instructor.
41
From the web server there is a link to your assigned student environment, which will establish a RDP session (eventually) to the Access VM of your assigned student environment.
42
From the Access VMs Windows desktop, you will be able to use the tools on the Access VM to access the VMs in your assigned student environment and the shared resource network environment. For example, RDP or PuTTY to another server within the lab environment.
43
5. Establish an RDP session

Steps:
A. Select the link provided in the RD Web page. This link will take you through a process to establish an RDP session between your Windows client and the AccessVM.
B. Enter your assigned OVSC account and password when asked in the process. C. Enter the IP address of the assigned AccessVM when prompted. D. Verify you are now logged in to the AccessVM by viewing the Windows desktop.
44
5. Establish an RDP session

Eventually you should see the desktop of the AccessVM. From here, you can access the VMs in the lab environment using IP addresses and the standard usernames and passwords found in the lab assignments hand-out.
45
The sqldb-student server is a RedHat Linux server hosting Oracle (installed using the SA bits). It will be used as the CDA database backend.
The adam-student server is a Windows server and will be used to practice installing CDA.
47
The alm-student server is a Windows server hosting HP Application Lifecycle Management (ALM). This server will be used in a later lab.
The servers in the shared resource network, behind the VMR, are a complete CDA solution set that includes vCenter and ESX servers so that students can provision CDA platforms and deploy applications.
49
Lab vCenter Assignment and Passwords
The second page of the LabAssignments.pdf file contains your assigned vcenter-yy account and passwords for all the accounts within the lab environment. These will be used for integration. For now, just use the Administrator user.
vCenter and Managed Hosts in the Lab Environment
51

vCenter manages the ESX servers in the shared resource network for CDA. The Private_Net1 network is the same network where all the other shared resource network VMs are attached. So everything is on one network in the shared resource network.
52
VM templates are used for creating IO templates, which are used for creating CDA platforms, which are used for deploying applications on top of, and so on.
53
Lab vCenter Assignment and Passwords
The remaining pages of the LabAssignments.pdf file contains the various username and passwords you will need in both the student and shared environments.
54
6. Setup student environment

Steps:
A. Create a mapped network drive to the CDA lab files.
B. Import a custom hosts file to the AccessVM to be able to access the VMs in the student and shared resource network. C. From the AccessVM, open an RDP session to the adam-student server:
Remember, after you have logged in to the AccessVM, you no longer use the OVSC domain account. Instead, use the accounts and passwords provided by your Instructor for the CDA lab environment(s).
D. Ping each of the servers in the student environment to verify connectivity.
55
Create a mapped network drive to \\10.0.44.101\training for easy access to the lab files for this course.
56

c:\Windows\system32\drivers\etc\hosts
Copy the contents of the hosts_file.txt file found on the media server to the Windows hosts file.
10.0.44.83
cda-io1.ovsc.adapps.hp.com cda-io1 io1.syslab.adam.qa.hp.com io1
Note the late edition to the file for another IO (io1) server that you will use in labs instead of the older IO (io) server.
Make sure you use the local administrator account and password (which is VC_SL_DC001)
58

c:\Windows\system32\drivers\etc\hosts
Update the existing hosts file for the late edition IO server.
10.0.44.83
cda-io1.ovsc.adapps.hp.com cda-io1 io1.syslab.adam.qa.hp.com io1
Note the late edition to the file for another IO (io1) server that you will use in labs instead of the older IO (io) server.
Verify connectivity to: adam-student sqldb-student io-student & 172.16.253.1 (AccessVM GW address) io1 chef0106
60

Exercise Review
Were you able to log into your assigned Student Environment

If yes, then let your instructor know by chatting in the Virtual Room
Or, update the survey in the Virtual Room, if available Use the Question Manager if you have questions about the exercise or product questions
If no, then let your instructor know by chatting in the Virtual Room
Please do not hesitate to let your instructor know if you are having any problems in the exercises
Also check the Question Manager for possible answers to your from past classes
Were you able to RDP to the adam-student server?

If yes, great, you are on track and ready to move on!
If no, let your instructor know
61
Exploring an Existing CDA Instance
63
The current adam-student server already has CDA installed. All you have to do is start it up and log in!
64
The adam-student installed CDA instance is already integrated with the IO and Chef servers in the shared resource network.
65
Before installing CDA, start the existing CDA instance, log in and explore the CDA user interface.
66
Exploring an existing CDA instance

Exercise Tasks
1. Verify Oracle is running and listening for services 2. Verify connectivity from adam-student 3. Start the CDA installation 4. Log in to CDA
5. Explore the CDA user interface

Approximate time for exercise and break: 30 minutes
67
1. Verify Oracle is running and listening
Open a PuTTY session to sqldb-student and log in as root / VC_SL_DC001.

Most important is that Oracle is running and listening for services!
68
2. Verify connectivity from adam-student
Verify connectivity to: sqldb-student (CDAs database server) io & chef0106 (CDAs integration to the shared resource network, notice the NATd addresses)
69
3. Start CDA
Change to the CDA bin directory and run the serverstart.bat script. This window will be your CDA console.
3. Start CDA (continued)
Take a break, you deserve it! It will take about 5 minutes to start. After you see the hp-adam.ear message, press enter within the window and THEN you should be able to log in to CDA using a browser.
71
4. Log in to CDA (set proxy first, if necessary)

If you have any issues connecting to CDA, verify *.syslab.adam .qa.hp.com is ignored in the proxy settings of the browser.
72
4. Log in to CDA
admin / changeit
73
4. Log in to CDA
Make sure you are pointing to adam-student and not the shared CDA server.
74
5. Explore the CDA user interface

Steps (time permitting in the lab):
A. Walk through the CDA UI tabs and links to familiarize yourself with the interface
B. Look at the example configurations in the Administration tab C. Look at the example platforms and templates in the Platforms tab D. Look at the example applications in the Applications tab E. Just dont try to deploy anything just yet
This short lab simply shows you what to expect after you install CDA
75
Installing the CDA Software
Installing the CDA software

Exercise Tasks
1. Review the CDA Installation and Configuration Guide
A copy of the CDA documentation set is available on: \\10.0.44.101\training\CDA1.0\CDA1.00_Docs
2. Shutdown the running CDA instance and delete

Control-C in the Command or Power Shell window where CDA was started. Remove the CDA folder contents in:
C:\Program Files\Hewlett-Packard\
3. Run the CDA Installer

Change to the root of the C:\ folder, where the CDA bits are already downloaded, and run the installer:
C:\ java jar HP-0.11.0*.jar
Use next series of slides for the values to use in the Installer wizard.
4. Start the CDA instance

Use the serverstart.bat script from a Command or Power Shell window to start CDA:
cd C:\Program Files\Hewlett-Packard\CDA\1.00\bin serverstart.bat
The Command or Power Shell window must remain open and displays all CDA console messages
5. Verify CDA is operational

77
1. Review the CDA Installation and Configuration Guide

Steps:
A. Open the CDA Installation and Configuration Guide
A copy of the CDA documentation set is available on: \\10.0.44.101\training\CDA1.0\CDA1.00_Docs
B. Review Chapter 1, Installation and Configuration Overview

This chapter provides an overview of the installation requirements and installation process.
C. Review Chapter 3, Installing and Configuring HP CDA

Use Chapter 3 as a reference for the steps provided in this lab. This lab guide will specify the values you should use for the given student lab environment.
78
2. Shutdown the Running CDA Instance

A. Ctl-C to start the shutdown
B. Y to terminate the batch job.
79
2. and delete the existing CDA instance

Change to the c:\Program Files\HewlettPackard folder and delete the CDA folder.
80
3. Run the CDA installer
The CDA build is already downloaded to the adam-student server.

Read the Welcome and click Next to continue.
82
Accept the License Agreement.
83
Accept the default installation folder.
84
7. Run the Installer
Select the Default installation scenario.
85
There are no updates at this time.
86
Select Disable for the lab.
87
Select Oracle 11g as the database.
88
Select Create schema.
89
Use the sqldb-student server for the database server and VC_SL_DC001 as the database password. Warning: Be sure to use sqldb-student and NOT the sqldb server in the shared lab environment.
C:\JODBC\ojdbc6-11.2.0.2.0.jar
Locate the OJDBC driver in the C:\JODBC folder.
91
Ignore the Warning message and click OK to continue.
92
Newer builds will ask for the data file folder. Accept the default for this lab.
93
Select Initial Import. Note that after you click Next you should see status messages while validation steps are performed.
94
Enter the adam-student server for the hostname and cda as the Web Context.
95
Use the Built-in HP Lightweight SSO Integration.
96
Select Basic.
97
FE_Passphrase#1 FE_Passphrase#1
Enter the domain and pass-phrase for LWSSO. Use FE_Passphrase#1 for the pass-phrase. This pass-phrase needs to be consistent with other LWSSO-enabled products such as ALM.
98
Enter any value for the email since there is no email (SMTP) server in the lab. Note that the default password is: changeit
99
Nothing to do here, please move along ;-)
Select the 60 day evaluation license.
Almost done!
It will take about 20 minutes to install.
Done installing.
Read and you are done installing!

4. Start CDA instance
Change to the bin directory and start the server from a Command or Power Shell window.
4. Start the CDA instance
It should take about 2-5 minutes to fully start CDA. You should be able to log in after you see the hp-adam.ear file deployed in the console window. Note that the console (server) log, and other logs, can be found in the c:\Program Files\Hewlett-Packard\CDA\1.00\jb710\standalone\log folder.

Steps:
A. Log in to CDA using a browser:
CDA URL:
http://adam-student.syslab.adam.qa.hp.com:8080/cda IE already has a link on the Favorites bar
Note that the browser should be set to NOT proxy URLs from *.syslab.adam.qa.hp.com
IE is already set
Might need to fix if using Firefox
Log in to the CDA server using:

admin / changeit
B. Verify the CDA GUI Displays
Log in to CDA on the adam-student server and explore the interface after a clean installation.
Installing the CDA software

Exercise Review
Were you able to install the CDA software?

Did you verify CDA is operational?

If yes, great, you are on track and ready to move on!
Performing the Post-Installer Integration Configuration

Exercise Tasks
1. Set up HP IO integration
2. Set up Chef Server integration

3. Set up HP Server Automation integration 4. Set up HP DMA integration
5. Set up HP OO integration
6. Set up Jenkins build server integration 7. Run a Check Connections test from CDA and verify a connection is established for each provider Approximate time for exercise and break: 30 minutes
Open a browser window and verify you can connect to the HP IO URL needed for the CDA-IO integration: https://io.syslab.adam.qa.hp.com:51443/hpio
Verify you can log in to HP IO using the CDA-IO integration account and credentials: administrator / IO_001
Leave the Domain blank for this environment
Please note that you are using the IO server in the shared resource network that is being used by ALL students. Please be careful in the shared environment and follow the guidelines in the lab guide when using IO and creating content. Be sure to PREFIX content with SXXX, where XXX is your student assigned ID. This will make it easier to identify your work.
Return to the CDA interface and add a new IO server from the Administration tab and Servers option.
Enter the following values:
Name: Shared IO Server
Description: IO server in the shared resource network. MOE User name: administrator Password: IO_001 MOE Server: https://io.syslab.adam.qa.hp.com: 51443/hpio Connection Timeout: 90
Receive Timeout: 120
Test the connection Save when successful

Verify if any existing IO templates show up in CDA
A. Select the Platforms tab and navigate to the Infrastructure Templates page
B. Select the IO server that you just finished setting up the connection information for
C. Verify if any IO templates show up on the page as Not Synchronized Yet
Note that if the IO server has any IO templates, these templates should show up in the CDA interface and validate the communications with IO. It is possible that there are not any existing IO templates and you will need to create them either before or after the integration with CDA. For example:
2. Set up Chef integration
Verify you can ping the Chef server and/or connect to the Chef server using a browser.

Go to Plugins in the Administration tab, locate the Chef Deployer Plugin line and then scroll the window to click on the Add configuration option.

Steps:
A. Configure the Parameter Values for the Chef server
Name: Shared Chef Server
Description: This is the Chef server in the shared resource network used by ALL students. Chef Server hostname: chef0106.syslab.adam.qa.hp.com Chef Server user: root
Chef Server password: VC_SL_DC001

Chef Server SSH port: 22 Chef Server SSH timeout (seconds): 10 Chef Server cookbooks directory: /etc/chef/cookbooks Chef Server bootstrap script: Chef Server bootstrap retries number: 10 Chef Server bootstrap retries wait (seconds): 120 Chef Server Knife retries number: 10 Chef Server Knife retries wait (seconds): 120 Chef Server SSH key directory: /root/.ssh
B. C.
Perform an Test Connection to verify CDA can communication with Chef Save the settings
3. Set up HP Server Automation integration

Steps:
A. Select the Administration tab and navigate to the Plugins page
B. Locate the SA Deployer Plugin option and Select Add configuration C. Configure the Create Provider parameters for the SA Deployer Plugin:
Name: Shared SA Core
Description: Connection to the SA core in the shared lab environment used by ALL students.
SA Host: sa.syslab.adam.qa.hp.com
SA User: administrator SA Password: Aut0mat10n!
D. Test the connection and save when successful
4. Set up HP DMA integration

Steps:
B. Locate the DMA Deployer Plugin option and Select Add configuration C. Configure the Create Provider parameters for the DMA Deployer Plugin:
Name: Shared SA Core
Description: Connection to the SA core in the shared lab environment used by ALL students. Note that DMA is integrated with SA. DMA Server Host: sa.syslab.adam.qa.hp.com DMA user name: administrator DMA password: Aut0mat10n!
5. Set up HP OO integration
Steps:
B. Locate the OO Deployer Plugin option and Select Add configuration C. Configure the Create Provider parameters for the OO Deployer Plugin:
Name: Shared OO Server
Description: Connection to the OO server in the shared lab environment used by ALL students.
OO Host: oo.syslab.adam.qa.hp.com
OO Port: 8443 OO Protocol: https OO Central Certificate Autotrust: yes OO Basic Auth User Name: admin OO Basic Auth password: Aut0mat10n!
6. Set up Jenkins build server integration

Steps:
A. Open a new browser tab and verify you can connect to the shared Jenkins server
http://diagjenkins.syslab.adam.qa.hp.com:8080/ No user name or password is required for the Jenkins server
B. Return to the CDA user interface and select the Administration tab and navigate to the Servers page C. Select the Add Jenkins Server link
D. Configure the Jenkins Server parameters as follows:

Name: Shared Jenkins Server Description: Connection to the Jenkins build server in the shared resource network used by ALL students. userName: leave blank password: leave blank
serverUrl:
7. Run a Check Connections test
Verify each server or provider shows up in the list and the communications test is successful.

Exercise Review
Were you able to complete the post-installer integration configuration?

Please do not hesitate to let your instructor know if you are having any problems in the exercises Also check the Question Manager for possible answers to your from past classes
Performing the Post-Installer Domain Configuration
Overview of CDA Domains

Introduce CDA domains in context with the different user roles
Default v.s. System domains
Why create additional domains
Performing the Post-Installer Domain Configuration

Exercise Tasks
1. Create a new CDA Domain as the CDA Administrator (admin)
2. Create a CDA Domain Administrator

3. Create a CDA non-Domain Administrator for testing in the new domain
4. Log in as the new CDA Domain Administrator

5. Log in as the new CDA non-Domain Administrator
1. Create a new CDA Domain
Create a new CDA Domain. Use your assigned student ID as a prefix for the domain to make it easier to identify.
1. Create a new CDA Domain
Review each of the sub-tabs before making further changes (for comparison later).
2. Create a new CDA Domain Administrator

Create a new CDA user. This user will be assigned to manage the newly created domain as the Domain Administrator.
Use your assigned student ID as a prefix.
Change the Default Domain of the user to the newly created CDA Domain.
Change the users Role Membership for the newly created CDA Domain. Add all roles to the new user.
View the Roles for the newly created CDA Domain and verify the new user is now a member of the Domain Administrator role within that domain.
3. Create a new CDA non-Domain Administrator

Create a new CDA user. This user will be assigned as a non-Domain Administrator in the newly created domain.
Use your assigned student ID as a prefix.
Change the Default Domain of the user to the newly created CDA Domain.
Change the Role Membership of the non-Domain Administrator user. Assign all roles except for the Domain Administrator.
View the newly created CDA Domain. Verify the non-Domain Administrator user is a member of all roles, except the Domain Administrator role, for the domain.
Log out of the existing session and restart the browser. Note that you might experience page and JavaScript errors if you do not restart the browser.
Log in as the newly created Domain Administrator.
View the options on the Administration tab. Notice the user has limited permissions

Verify the new user is in the newly created CDA Domain.
Verify the user cannot to switch domains from the Settings tab.

Log in as the newly created non-Domain Administrator.
Notice that this user does not have the Administration tab.
Verify that the user is in the newly created CDA Domain.

Select Settings and verify the user is only assigned to the newly created CDA Domain. The user cannot switch domains.
Installing a CDA Patch
Installing a CDA Patch

Exercise Tasks
1. Download the CDA patch

Note that the patch is already downloaded to the lab environment for your convenience.
2. Read the patch updates and installation instructions

Note that the patch document is already downloaded to the lab environment for your convenience.
3. Install the CDA patch 4. Start the CDA server instance 5. Verify the CDA patch is installed
1. Download the CDA patch

Downloading the patch requires a HP Passport account. Note that the patch is already downloaded to the lab in the \\10.0.44.101\trai ning\CDA1.0 folder as the CDA_00001.zip file. Continue to the next slide.
2. Read the patch updates and installation
Open and review the patch document already downloaded on the \\10.0.44.101 server as: CDA_00001_Doc.htm
3. Install the CDA patch

Steps:
A. Extract the patch (already done in the lab environment for you).
Note that the CDA_00001.zip file was not recognized as valid in Windows file in the lab environment, therefore the zip file was extracted for you on Linux and the extracted contents are currently in the folder: \\10.0.44.101\training\CDA1.0\CDA1.00.0001_Patch
B. Copy the CDA1.00.001_Patch folder to the C:\ drive of the adamstudent server.
Do this step now.
C. Shutdown the existing CDA instance from the CDA console window (CTL-C).
Do this step now.
D. Install the patch.

Use the next several slides as a guide.
E. Start the CDA server instance

F. Log in to the CDA instance and verify the patch is applied
Run the setup.bat script. This will launch the CDA setup wizard.
Click Next to continue.
Locate and add the updatetoolpatchCDA_00001.jar file to the list of updates.
Click Finish to close the CDA setup wizard.
Run the setup.bat script again.
Locate and add the CDA_00001.jar file to the list of updates.
The update should take about 20 minutes to complete. When done, click Next to continue.
Click Finish to close the CDA setup wizard.
4. Start the CDA server instance
Start the CDA server instance.
4. Start the CDA server instance
Wait until you see the hp-adam.ear message before trying to log in to the CDA server instance.
5. Verify the CDA patch is installed

Log in as the admin user (changeit).
Scroll to the bottom of the page and select the About Continuous Delivery Automation link.
Verify the patch is 1.00.0001 build 18th July 2012.
Lesson Summary
After completion of this lesson, you should now be able to :
List the CDA components and CDA roles
Describe the overall process for successfully installing CDA Access the lab environment
Explore the user interface of an existing CDA instance

Install the CDA software in a pre-installed lab environment Perform the post-installer integration configuration steps for CDA
Perform the post-install domain configuration steps for CDA
Lesson 2: Provisioning a CDA Platform

Lesson Goal
Provision a single Ubuntu CDA platform to verify provisioning is working correctly between CDA, IO and vCenter
Lesson Objectives
Create a single Ubuntu server IO template from HP IO
Create a CDA platform based on the single Ubuntu server IO template Provision the single Ubuntu CDA platform from CDA
Verify the single Ubuntu server CDA platform is fully provisioned between CDA, IO, vCenter
Lesson References
Documentation:
CDA 1.00 Release Notes CDA 1.00 Concepts Guide CDA 1.00 User Guide HP MOE Docs
BladeSystem Matrix 6.x Demonstrations, http://mslweb.vse.adapps.hp.com/vseatc/demos/
Bursting with HP CloudSystem, http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA36847ENW&cc=us&lc=en.

Matrix OE Product Documentation, http://h18004.www1.hp.com/products/solutions/insightdynamics/infolibrary.html
Other
vSphere Virtual Machine Administration Guide
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_vm_admin_guide.pdf
Chapter 4, Working with Templates and Clones
Creating a Single Ubuntu Server IO Template from HP IO
Overview of HP IO templates
Create an overview that explains what an HP IO template is and how it is used in context with CDA
Describe the user roles that will be responsible for creating these HP IO templates
Their relationship with those creating VM templates and those creating CDA platforms from the IO templates
Provide example scenarios in relation to the main Dev/Test use case being promoted with CDA 1.0
What else would you like to see in this section as far as an overview?
Overall process for creating IO templates for use with CDA

Done via the HP MOE Infrastructure Orchestration Designer
MOE templates are specifically synchronized into CDA

Part of CDA Platform design area in UI
MOE templates encapsulate the network, storage & compute complexity of the IaaS
Templates define virtualization source (i.e. VMware, EC2) Templates can be hybrid of public and private
Server groups can define future capacity (i.e. starting number of servers in the group to provision, max number to allow scaling up to)
New in MOE 7.1 is also support for load balancers and firewalls
Creating a single Ubuntu server IO template

Exercise Tasks
1. Log in to the HP IO portal and launch the IO designer
2. Drag, drop and connect the components for the IO template

3. Configure the Network settings 4. Configure the Server Group settings
5. Publish and save the IO template

6. Verify the published template in IO 7. Create a new service in IO from the IO template 8. Delete the new service from IO Approximate time for exercise and break: 30 minutes
1. Log in to the HP IO portal
Connect to: https://io.syslab.adam.qa.hp.com:51443/hpio
Log in to the IO portal as: administrator / IO_001
1. and launch the IO template designer

Select Templates and then New to launch the designer window.
Note that there is a sample IO template created by student-000 (S000) for reference.
2. Drag, drop and connect the components
Double-click allows you to edit the settings of each component.

3. Configure the Network
Select Private_Net1 for this lab environment. Click OK when done.
4. Configure the Server Group
Double-click the SvrGrp1 icon to edit the Server Group for the new template.
Update the settings for the Config, Networks and Software tabs before saving. Be sure to use your assigned student ID as a prefix to uniquely identify your template in the shared IO server.
Be sure to use your student prefix to create unique hostnames for your provisioned servers. and select DHCP for the network.
Select DHCP for the network.
Select the cda-ubuntu VM template that already exists on the ESX server.
Read and click OK to continue.

5. Publish and save the IO template
Be sure to use your student prefix to uniquely identify your IO template.
6. Verify the published template in IO
Return to the IO portal and verify your template shows up in the IO portal. Note that you will likely see many other student IO templates.
7. Create a New Service from IO
Select your IO template and create a new service to provision and verify your template works from IO
Enter a unique service name and hostname for your new service and then select Options (NOT Submit). Please use a short prefix to identify your service from other students.
Note that Service Name and hostname uniqueness is VERY important in a shared environment. Also, CDA limits the hostname completion to 2 characters, while HP IO allows more characters.
Before submitting the request, verify you are using the CDA Pool for provisioning.
View the request in IO.
Verify vCenter is cloning and setting up the VM for your service. Switch back-and-forth between IO and vCenter to watch the progress. Note that you should see several tasks related to your service (clone, reconfigure, customize, power on).
Verify the VM has an IP address and hostname.
Note that you will not be able to directly ping or access the VM from your student environment.
S000Ubt1
.36
The new VM is cloned on one of the ESX servers from the VM template and then reconfigured by IO with a hostname and put on the network. The VM boots and then gets a DHCP IP address from the DHCP server . The DHCP client then requests a dynamic update of DNS, and so on.
8. Delete the New Service from IO

Delete the service and verify the service is deleted from vCenter and IO.
IMPORTANT: Please delete your VM to conserve shared resources or the entire class will have problems later.
Create a single Ubuntu server IO template

Exercise Review
Were you able to complete the lab?

Also check the Question Manager for possible answers to your question from past classes
Creating a CDA Platform based on the Single Ubuntu Server IO Template
Overview of a CDA Platform

What is a CDA Platform?
A CDA platform is a wrapper around an MOE template; it is where Provisioning happens
Object is versioned within CDA Assigned to lifecycle stage(s) to indicate its use/scope Can model extensions on top of the core IaaS template Included persona: Infrastructure designer
Note: CDA platforms do NOT model any specific aspects of the application that comes later!
An MOE template re-usable across applications and lifecycle stages

app A dev platform
app A test platform app B dev platform
MOE template
Different CDA platforms can use the same underlying MOE template, but deliver different platform capabilities
app A dev platform app B dev platform
Jboss install via CDA SW library
MySQL install via CDA SW library
WebLogic install via CDA SW library
SQL server install via CDA SW library
MOE template
MOE template
OS only
OS only
OS only
OS only
Platform models takes advantage of MOE 7.1 server customers existing templates & content
IaaS templates
storage NW
compute
NW
storage load balance
compute
Existing Image Sources (VMW, HypV, EC2, HP)
CDA platform model Server groups Infrastructure template
Additional Software
The CDA model for platform captures the IaaS template capabilities For platform stack completion: CDA can maintain a library of external SW Sources: OO, DMA, Chef Creates standardized platform provisioning
OO flow Chef recipe DMA flow
OO server Chef server DMA server
flows
recipes
flows
Overall Process for Creating a CDA Platform

Synchronize MOE templates in CDA
Note that any changes made to the IO templates made from MOE require resync in CDA
Create new Platform object

Select MOE template
Define Lifecycle Choose Deployer tool
From Platform Designer

Tag (as needed) for underlying Templates capabilities Add (as required) add-on SW components from CDA Platform SW library
Provision & Deprovision from Platform UI area of CDA

Can view inventory of provisioned servers
Pick a Deployer for the platform

Each CDA platform model defines the specific deployer tool it will use for all SW deployments
For platform SW deployment (during provisioning) For application deployment
This allows the platform provisioning process to setup the right deployment tool right away
Bootstrapping will setup the targets agents
Does mean that customers that use different deploy tools across their org may end up with some duplicate platforms (differing only on deployment tool)
For example, could have different SA server for Staging vs. Production
Would need different platform definitions for the 2 environments
Create a simple single Ubuntu server IO template

Exercise Tasks
1. Import the IO template in to CDA
2. Identify (tag) pre-installed software for the template

3. Create a new platform 4. Set the deployer credentials Approximate time for exercise and break: 15 minutes
1. Import the IO template into CDA

Log in to the CDA server instance as the Domain Administrator for your newly created CDA Domain.
1. Import the IO template into CDA
From your adam-student server, import your IO template into CDA and synchronize.
2. Identify pre-installed software
Select the imported IO template. Note the first time you do this, you might need to re-enter the CDA username and password.
Credentials are required to show the IO template illustration.
Select the imported IO template and click on the Server Group in the illustration.
Add MySQL 5.1 and Tomcat 6 to the list of software already provisioned on the template. Save the changes.
3. Create a New Platform

Create a new platform based on your imported IO template.
Select deployer
3. Create a New Platform
Verify your IO template is selected for the platform.
4. Set the Deployer Credentials
Go to the Designer tab for the platform and edit the properties of the Server Group to set the deployer username and password to: root / ubuntu
Provisioning a Single Ubuntu Server CDA Platform
Overview of a CDA Platform Provisioning

CDA provisioning is all done via its IaaS layer (which is the Matrix MOE 7.1 software)
Matrix users will understand this as IO services and service requests A single request from CDA to MOE will provision all of the servers, storage, and networking defined in the MOE template
CDA exposes some specific fields from the MOE integration

Need to define the service name that will be used by MOE (8 char max) Need to define the substitution string that MOE will append to hostnames (2 char max)
Post-MOE provisioning
CDA will bootstrap the deployment agent (Chef, in the lab examples) CDA will install any assigned platform SW
CDA also exposes a command line tool to essentially import externally provisioned platforms into CDA
Well cover the cdaexec tool later in the class
Overall Process for creating a CDA Platform

Setup provision jobs parameters
Parameters at the platform level
Allows you to store parameters for later use
Start provisioning job

MOE creates service as defined by the template
Deployment agent bootstrapped External SW deployed (optional)
Provisioning a single Ubuntu server CDA platform

Exercise Tasks
1. Provision a CDA platform
2. Verify the platform is provisioning in IO

3. Verify the platform is provisioning in vCenter 4. Verify provisioning activity in the CDA Console
5. Verify provisioning completes in CDA

1. Provision a CDA Platform
Return to the Overview tab of the platform and scroll the page to the right and select Provision to provision the platform.
Enter unique values for the provisioned platform name.
Enter unique values for the hostname and service name. Note that the hostname can only be 2 characters at this time.
Save the parameters for this Provisioned Platform using the Service Name (makes it easier to identify later).
Click OK to start the provisioning.
Select the link to See report for more details.
You should see your platform being provisioned with no errors.
2. Verify the platform is provisioning in IO
Verify your platform is being provisioned in IO.
3. Verify the platform is provisioning in vCenter
Verify your platform is being provisioned in vCenter. Switch backand-forth between vCenter, IO and CDA to watch the progress.
4. Verify provisioning activity in the CDA Console
Note that while provisioning, near the end of the provisioning, CDA (without the .0001 patch) will tell the Chef Server to bootstrap the node. You can switch to the CDA console window and should be able to see various messages related to the Chef Server and bootstrapping. Note that bootstrapping in the .0001 patch has moved to application deployment.
When provisioning is complete, you should see successful messages on the reports page. The platform is now ready for application deployment.

Note that in CDA 1.00 (without patch 0001) the server should also successfully register with the Chef Server during provisioning. With the patch, the node is registered later during application deployment. Note also that in this lab environment, the DNS record for the newly provisioned host is automatically added to the DNS server, allowing the Chef Server to find and bootstrap the newly provisioned server. In other environments, you might need to come up with an alternate solution. For example, run an OO Flow to update DNS.
View All Provisioned Platforms and verify your platform shows up in the list as PROVISIONED.
Provisioning a single Ubuntu server CDA platform

Exercise Review

Also check the Question Manager for possible answers to your question from past classes
Lesson Summary
Create a single Ubuntu server IO template from HP IO
Create a CDA platform based on the single Ubuntu server IO template Provision the single Ubuntu server CDA platform from CDA Verify the CDA platform is fully provisioned between CDA, IO and vCenter
Lesson 3: Model and Deploy an Application in CDA

Lesson Goal
Model and deploy a multi-tiered application in CDA on an already provisioned CDA platform
Lesson Objectives
Model and deploy a simple application on a single Ubuntu server CDA platform
Model and deploy the Pet Clinic application on a single Ubuntu server CDA platform
Lesson References
Documentation:
CDA Release Notes CDA Concepts Guide CDA User Guide
Other
Optionally, Opscode (Chef) wiki: http://wiki.opscode.com
Modeling and Deploying a Simple Application on an already provisioned CDA Platform
Overview of CDA Modeling

Describe basic CDA concepts related to modeling and deployment
Quickly model and deploy a very simple application (if you can even call it that) to test whether you can deploy using the Chef deployer
Discuss modeling and layers in relation to application layers and tiers
Perhaps discuss how to model a complex multi-tiered application such as the Online Banking Application
Rumors that it will be used at Discover?
Model a little more complex application like the Pet Clinic to make a pass at a more real application
Perhaps that is as far as we go for the SWAT Bootcamp?
Modeling a Simple Application

Exercise Tasks
1. Create a new application and version
2. Create an application model

3. Add layers 4. Define actions
5. Create a deployment topology

6. Map layers 7. Deploy the application 8. Verify deployment 9. Undeploy the application 10.Approximate time for exercise and break: 30 minutes

Log in to the CDA server instance as the non-Domain Administrator user that you created earlier.
Create a new application using a unique name and description.

Create a version for your application.
2. Create an Application Model
Select Create Application Model to model the application or select Application Models and then Create.
Provide a unique name and description for the application model.
Select Application Models to define your application layers and model the deployment of those layers.

Note Note: thatwell we will come come back back to SW to SW artifacts artifacts & builds & builds later later
Select the application model you created earlier. Note that an application version can have more than one application model. Why you might ask? Stay tuned
3. Add Layers to the Application Model
Select Layers to define the layers of the application.

3. Add Layers to the Application Model
Add a new layer to the application called Base Configuration.
4. Define Actions for the Application Layers
Expand the Deploy actions and add an Executed Script to your layer to be used during the Deploy phase.
Add a very simple script to validate a simple deployment.

Add a very simple script to validate a simple undeployment.

5. Create a Deployment Topology
Create a Deployment Topology for the application model.
5. Create a Deployment Topology
Select an appropriate platform for the deployment topology.

1. 5. Create a Deployment Topology
Skip defining a monitoring policy for the deployment topology and select Finish.
6. Map Layers to Server Groups
You would map the application layers to the Server Groups if you had multiple layers and groups. For this case, the 2 layers are automapped to 1 server.
7. Deploy the Application on to a Deployment Topology

A. Return to the Overview tab for the application model. B. Scroll to the right and select the Deploy option.
Use your application model, topology and previously provisioned platform to deploy.
Save the parameters and then click Finish to deploy.
See reports for details!
Drill down on successful messages for more information.

8. Verify Deployment (and Explore)
From the AccessVM you can open a PuTTY window to the Chef Server to get inside the shared resource network.

Steps:
A. Log in to the shared Chef Server:
root / VC_SL_DC001 Careful as ALL students have root access. Just look, no touching!
B. Run the knife command to view your chef node:

knife client list knife node list
C. Change to the /etc/chef/cookbooks and look for your generated cookbooks (for example, s000) D. Open an ssh connection to your chef node E. Change to the /etc/chef directory, on the node, to see what a properly bootstrapped client looks like F. Run chef-client on the node to validate client/server communications
G. List the /tmp directory and look for your deployment file
Return to CDA and view All Deployments from the Applications tab. Select your application.
Review the deployed application information in CDA.
9. Undeploy the Application
Scroll right and Undeploy the application.
Review the report.

Steps:
A. Return to the All Deployments view and verify the application deployment has been removed.
B. Verify the CDA Platform is till provisioned from the Platforms tab (view All Provisioned Platforms). C. Verify the Undeploy file was created on the chef client (optional).
Importing and Deploying the Pet Clinic Application on an already provisioned Ubuntu server CDA platform
Model the Pet Clinic application on a single Ubuntu platform

Exercise Tasks
1. Import the Pet Clinic application archive into CDA as the Domain Administrator. 2. Update the application model layers. 3. Define a new deployment topology.
4. Map Layers to Server Groups (create connections).

5. Deploy the Pet Clinic application version. 6. Verify (instructor) 7. Approximate time for exercise and break: 30 minutes
1. Import the Pet Clinic application archive

Log in to the CDA server instance as the Domain Administrator for your newly created CDA Domain.
From the Model Archive option, locate the petclinic-chef-ubuntu0.11.0.3.zip file on the shared drive and then select Advanced Options.
Review the import options and then click Import to import the zip file.

The import should finish with warning messages since some of the existing artifacts in the archive were from the System domain which requires CDA administrator permissions. You imported as the Domain Administrator to reduce the risk of importing and overwriting existing artifacts in the System domain (where the original Pet Clinic was created and exported).

Additional Steps:
A. Review all of the imported content (artifacts) message pages:
You should see several warnings or errors which you should be able to ignore for this lab.
B. Return to the Applications, Platforms and Administration tabs and view what content is imported from a CDA perspective:
Application tab
Pet Clinic Application and version, including all related artifacts are imported
These came from a previous export of the repository from another lab environment, therefore, there needs to be some editing of the model before you can use the imported content
While on the Administration tab, review all of the Pet Clinic Application related links and tabs to help become familiar with the various screens All Platforms > Pet Clinic Logical Platform definition
Platforms tab

275
Infrastructure templates (notice a new IO server artifact and IO template was imported) Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
2. Update the Application Model layers

Log in to the CDA server instance as the non-Domain Administrator user that you created earlier.

Delete the reference to the http://arm-collective... artifact that was imported. It is not used in this lab and will cause the deployment to fail.
Drill down until you locate the Layers of the Pet Clinic application model.
Expand the DB Layer and view the mysql config deployment step.
Drill down until you can actually view the contents of this artifact. Note that you might need to provide credentials to view.
Notice that this configuration file has been parameterized to allow you to set the port value at deployment time. You should find one more parameterized value in this file. Close the file when done viewing and navigate back to the Layers page for the application model.
The values in the my.cnf configuration file are set at the Layer level.
The default values are set using Reference Variables that are picked up from the defined Endpoints for the Layer.
Click the pencil icon to open the parameter for editing.
Edit (view) the mysql.bindaddress default value to point to the ipaddress endpoint. Click OK and then Save to update the Default Value.
Edit the mysql.port default value to point to the port endpoint. Click OK and then Save to update the Default Value.
Save your work BEFORE you move on to the next deployment step.

Additional steps:
A. Walk through each deployment step for both the DB Layer and App Server Layer
B. Where you see a Reference Variable, edit that variable to pick up the correct syntax (make sure you Save before moving between deployment steps) C. You should find reference variable for the following actions:
mysql config (in the DB Layer)
mysql.bindaddress
mysql.port mysql.dbname (maps to path endpoint) mysql.localuser.name (maps to application layer) mysql.localuser.password (maps to application layer) mysql.remoteuser.name (maps to application model)
configure mysql (in the DB Layer)

mysql.remoteuser.password (maps to application model)
The imported model points to a nonexistent server in our lab environment, so you will need to update the location of the petclinic.war file. See next slide.
Change the source to use an image from the DSL. You can upload the petclinic.war file to the DSL from the shared media server in the lab.
Make sure to Save you changes BEFORE moving to the next deployment step.
3. Define a New Deployment Topology
The imported deployment topology model points to a platform that does NOT exist in the environment. You can delete or ignore this topology for now.
Add (create) a new deployment topology based on your provisioned platform.
Select your single Ubuntu platform as part of the topology.
Skip Monitoring for now.
4. Map Layers to Server Groups (connections)

Select your deployment topology and then map the layers on to the appropriate server groups (the next logical step; however, no need here because everything is on one server).
5. Deploy the Pet Clinic Application Version
Return to the Overview, then scroll right and deploy the application.
Select a unique deployment name and appropriate Application and Model and Platform to deploy to.
Review parameter values for the corrected syntax.

Save the previous parameters for later use in ALM.
There is no monitoring policy set at this time, so Finish to start the deployment.
6. Monitor the Deployment
Deployment should start and you should be able to click See report for more details.
Eventually all steps should execute successfully.
Drill down on execution steps to see more details.

7. Start the Application

You can start the entire application or individual components.
7. Review the report for details

Verify the startup of the application.
8. Verify the Pet Clinic URL

Note that you cannot directly access the provisioned VM from the student environment. You must first RDP to a VM within the shared resource network and then use a browser to connect to the Pet Clinic application.
Yippy!
Note that the student environments will not be able to directly access the newly provisioned platforms because they are in a NATd environment. Ask your instructor to try your URL from within the shared environment. [Need to get a Windows jump server in the shared env.]
Model the Pet Clinic application on a single Ubuntu platform

Exercise Review

Lesson Summary
Describe the process and the infrastructure requirements for creating VMware templates for use with CDA
Create a VMware template for Linux and Windows Create a VMware customization specification for Linux and Windows
Lets briefly go back and discuss builds

CDA has the concept of Software artifacts and builds for deployments
SW artifacts are all of the applications files/scripts/etc
This is whats built by the Continuous Integration system (i.e. subversion/maven/hudson) CDA can reference via external URL, link into jenkins server, load directly into CDA DSL Artifacts can come from different locations, so can define multiple configurations for locations
A CDA build is a specific set of packaged app artifacts

Can be created at the time of deployment
Can be created separately (i.e. ahead of time) Are based on a artifact configuration Can be used over and over in deployments Are moved through the CDA lifecycle
1. Managing build configs
Different configs for different artifact locations; these are from CDA DSL
1. Managing build configs
These are from a Nexus staging server
1. Application builds
This is a CDA packaging from the default config can now be deployed over & over
1. Lifecycle processing
Manage the lifecycle of the app here in the app build area
Quick next step link to move along lifecycle
1. Lifecycle processing
Lifecycle management
Can have more than 1 lifecycle defined for the CDA install
Can have multi paths thru a lifecycle

Attributes of a lifecycle stage
Tasks can define what tasks the owners of the stage need to check off prior to moving on; an ad hoc list Policies additional reusable list of to-dos per stage Approvers organizational decision makers to check off
If lifecycle stage has no approvers, then CDA users can directly click in Builds to promote (otherwise promotion blocked until all authenticators sign off)
1. Lifecycle configuration
Lesson 4: Integrating ALM with CDA and Deploying the Lab Management Automation Use Case
Continuous Delivery Automation (CDA) 1.x: How to POC, Level 360
Lesson Goal
Integrate ALM 11.5 in to the CDA solution and successfully implement the lab management automation use case.
Lesson Objectives
Describe the ALM to CDA Lab Management Automation use case and user story
Install ALM 11.5 for CDA integration
Note that I thought it would be helpful for BSA Pre-Sales to see how to install ALM in a minimum configuration to support ALM-CDA integration and the LMA use case Experienced LMA users should at least have a set of parameters that they need for installation so they dont have to go through all of the slides
Possibly create a second ALM instance that is already installed. Students can then power on the ALM they wish to use. Create a hyperlink in PPT that takes them to the next exercise.
Integrate CDA with an existing ALM 11.5 installation Implement and demonstrate a simple Lab Management Automation (LMA) use case example between ALM and CDA using the Pet Clinic application
Lesson References
CDA documentation:
CDA 1.00 User Guide
Chapter 2, HP CDA General Information and Tasks, see the section on Parameters and Parameterization Chapter 3, Troubleshooting Integration Issues with Other HP Applications
CDA 1.00 Troubleshooting Guide
ALM documentation:
A
B
Other:
Pointers to Pre-Sales collateral for Presentation and Demonstration of LMA Pointers to ALM related enablement
ALM Integration Overview
Overview of Integration CDA ALM Integration

Provide an overview of the ALM-CDA integration:
Support for the Lab Management Automation use case
How much overview is needed to explain LMA?
List the requirements for a successful integration

Roles Authentication Passphrases
Architecture
Connectivity between CDA-ALM Roles/Authentication API What a real world deployment looks like
Overall Process
1. Install
2. Integrate
3. Configure 4. Import
5. Provision
6. Deploy 7. Undeploy 8. Deprovision Note that the start actions will need to be added to the Deploy workflow since an ALM user has no way to select which actions are performed.
Integrating ALM 11.5 into a CDA Environment
Integrating ALM 11.5

Exercise Tasks
1. Install the ALM 11.5 software for use with CDA
2. Install the ALM Add-ins necessary to connect to ALM and integrate with CDA
3. Configure ALM for CDA integration as the ALM Site Administrator
4. Configure Lab Management for CDA integration as the ALM Site Administrator
5. Configure Lab Management for CDA integration as the ALM User Approximate time for exercise and break: 60 minutes
1. Install the ALM 11.5 software

Instructions for those already familiar with, or wish to skip, installing ALM and adding the ALM Add-ins:
A. Use the vSphere client and your student login credentials to log in to the sscvtc vCenter server. B. Power-down the cda-alm-student-notinstalled VM and power-up the cda-alm-student-installed VM. C. Skip to Task 3 of this exercise to continue with the configuration of ALM as the ALM Site Administrator.
All others will need to complete Tasks 1 and 2:

A. Continue to the next slide.
Note that the above steps have not yet been implemented in the current lab environment. You will need to perform Tasks 1 and 2.
Before starting the installation, edit the Windows hosts file and uncomment the localhost entry.
Locate and run the ALM installer.
Read and click Next to continue.
Read and accept the license agreement.

Enter appropriate customer information.
Accept the default location.
Confirm the installation.
Progress is shown as the installation proceeds. It should take approximately 5 minutes to copy the files and start the server configuration wizard.
Click Finish to complete the installer portion.
The ALM server configuration wizard should automatically launch to allow you to configure ALM.
Locate and insert the license key file for ALM.
Enter the Database Server configuration parameters. Use VC_SL_DC001 as the DB admin password.
Accept the defaults.
Enter FE_Passphrase#1 in each text box for this lab.
Be sure to use Administrator with a capitol A. The password should be: VC_SL_DC001
Accept the default.
Leave blank for this lab.
Enable the Install Mercury Tours check box if you wish to view the tutorials.
Select None for this lab environment since there is no SMTP server available.
alm-student.syslab.adam.qa.hp.com
Verify the configuration parameters and select Next to continue.
The configuration wizard should now update the configuration. The configuration should take about 10 minutes to complete.
Ensure the option to start the ALM server is selected.
Click Finish to end the installer and start ALM.
It might take up to 5 minutes to start the ALM server. Note that a browser window should open and display the top page of ALM when started (next slide).
View the ALM icon in the System Tray and verify the server is started.
2. Install the ALM Add-ins

Steps:
A. Install the HP ALM Connectivity add-in
B. Install the HP ALM Lab Service add-in C. Install the HP ALM Client Registration add-in
2. Install the ALM 11.5 Add-ins
Select the Add-Ins Page link to set up various add-ins required by ALM.
Select the HP ALM Connectivity link.
Note that for the ALM/CDA integration Lab Management use case, you will nee to install several add-ins.
Download and install the add-in. Return to the previous screen when done.
Select the HP ALM Lab Service link.
Download and run the installer.
Use the default settings for the installer wizard. Use the values for the HP ALM Lab Service Settings found on the next slide.
Enter the following values: ALM server url: http://localhost:8080 /qcbin
Host user name: Administrator
Click Register Host.
Click OK to continue. There is no approval that you need to do for the lab.
Click OK to continue.
Start the host service.
Close the installer wizard.
Verify the ALM Lab Service is running in the System Tray. Return to the previous add-ins screen when done.
Select the HP ALM Client Registration. Note that there are two add-ins that you need to install.
Scroll to the bottom of the page to find two links for the Client Registration add-ins.
Select Register HP ALM link.
Install the ALMPlatform-Loader.
Note that a new browser window should open to indicate that you will need to download and install some additional Windows software.
Read the note. Notice that you need to download and install the 32 bit version of the Windows software.
Download and install the 32 bit version.
Click Yes to install the Windows software.
Return to the previous browser window and refresh the page to start the add-ins installer.
It should take a few minutes to install the add-in.
You should get a message to close the browser window if the add-in was installed successfully.
Return to the previous add-ins screen. Install and register the HP ALM Site Administration add-in.
It should take a few minutes to install the add-in.
Verify the registration completes successfully and close the browser window. Return to the top server page for the ALM server: http://localhost:8080/qcbin
Select Site Administration and verify you can log in to ALM as the ALM Site Administrator.
Note that add-ins are downloaded and installed per user and host.
Verify you can log in as the ALM Site Administrator.
Administrator / VC_SL_DC001
ALM installation and basic configuration is now complete and you are now ready to configure the ALM/CDA integration for the Lab Management use case.
3. Configure ALM as the Site Administrator

Steps:
A. Create a new site project for CDA
B. Create a new ALM user for running the ALM/CDA integration tests C. Add the ALM user to the new CDA project as Project Administrator
D. Add the ALM user to the Lab Management as Project Administrator
Create a new empty project.
Enter a project name.
Accept the defaults for the new project.
Click OK to continue.
Add the Administrator as a Project Administrator for the new project.
Select the ALM Lab Extension option for this new project.
Review and create the new project. It will take several minutes to create.
Select No to not complete the Lab Management project settings. You do this later in the lab.
Review the results.
Create a new ALM user.
Add the new project to the list of user projects assigned to this new user.
Add the new user to the new project and assign the new user as a Project Administrator to the new project.
Add the new alm-user as a project manager for Lab Management.
4. Configure Lab Management as the Site Admin

Steps:
A. Log in to the Lab Management user interface as the ALM Site Administrator
B. Verify connectivity to the CDA server C. Create a new CDA Server configuration D. Update the CDA project for the new CDA server E. Define the CDA domain for the CDA project F. Add a new testing host to run VAPI-XP scripts
Select Lab Management.
Log in as: Administrator / VC_SL_DC001
Open a second browser tab and verify connectivity to the student CDA server.
Create a new CDA Server to the student CDA server in the lab.
If you get an error trying to configure the CDA server, more than likely the LWSSO passphrases for both ALM and CDA are different.
Note that the next 2 slides show you how to update the passphrase value in ALM, if necessary.
Log in to CDA as the admin user and view the passphrase value in the System Settings. Use that value to reconfigure ALM, if necessary. Note that changing the value in CDA does not appear to work at this time.
You can edit the passphrase value in ALM as the Site Administrator. Note that you will need to restart ALM after the change.
The goal is to add the student CDA server to the list of CDA servers in ALM Lab Management.
Note that ALM only supports one CDA server at this time.
Update the Project Settings for the CDA_DEMO_PROJECT. Add the CDA Server and then set the CDA Domain to point to the student CDA server and the student created CDA domain (created in CDA).
Add a new testing host to run the VAPI-XP scripts. Not that the name must match the host name set in the HP ALM Lab Service Settings.
Notice that the host status should be Unavailable and Not registered at this time.
A. Open the ALM Lab Service Settings from the System Tray.
B. Register the host.
Refresh the list of testing hosts and verify the new host is now Operational and Registered.

Run Check Host on the testing host and verify the check finishes successfully.
Configure Lab Management as the ALM User

Steps:
A. Create a new AUT Environment for the CDA application
Create a new AUT Environment for the Pet Clinic application Configure the link to CDA Create AUT Parameters
B. Create a Test
Create a Test Plan and Script
Create a VAPI-XP test Select test
Create a Test Set (Test Lab)
Create a new Build Verification Suite for the Pet Clinic
C. Run the Build Verification Suite

Run a test using a deployed platform Run a test and deprovision Run a test and provision and deploy
5. Configure Lab Management as the ALM User
Select the Application Lifecycle Management link to log in as an ALM user.
Authenticate and log in as the alm-user. Note that there is no password set for this user (at this time).
Verify the testing host is listed. Note that you cannot make changes from this interface.
Create a new AUT Environment for the current Pet Clinic version under test.
Create a new AUT Environment Configuration for the Pet Clinic AUT Environment.
Create a set of parameters for the Pet Clinic application environment with default values for ALM.
Set the new parameter values based on values returned from CDA.
Create a new folder to hold Pet Clinic related tests.
Create a new VAPI-XP test.
Click Next on the wizard screens to accept the defaults.

Click Next on the wizard screens to accept the defaults.

Click Finish to accept the defaults.

Replace the current contents with those from the file: Z:\CDA1.0\vapi-pc-script-simple.txt
Create a new test set folder for the Pet Clinic test sets.
Create a new Functional test set.
Add the new test to the test set.
Define the testing host for the test set.
Create a new folder to hold Pet Clinic related build verification suites.
A. Create a new Pet Clinic build verification suite. B. Add the Pet Clinic test set to the Pet Clinic build verification suite.
Note that the test set is a Functional test set. It is easy to create a test set without setting the type earlier.
Run the Pet Clinic build verification suite and use the already deployed Pet Clinic environment.
Look for a pop-up window to display the parameters.

The window should display the values for the parameters passed from CDA to ALM. Close the window to finish the test.

View the Execution Report and close when done. The test should complete successfully.
Run the build verification suite again and this time deprovision when done.
Configure Lab Management as the ALM User

Additional steps:
A. Verify the Pet Clinic application is undeployed
Note that you will need to log in as the admin user to CDA to show all events and see the undeploy and deprovision events. The Internal Administrator is used between ALM and CDA.
B. Verify the CDA Platform is deprovisioned C. Verify the VM is deleted in vCenter D. Run BSV again and this time provision and deploy, while leaving the application deployed when the testing is done. E. Verify the VM is provisioned F. Verify the CDA Platform is provisioned G. Verify the Pet Clinic application is deloyed H. View the results of the BSV test I. Verify the Pet Clinic application remains deployed and the CDA Platform remains provisioned.
Lesson Summary
Describe the ALM to CDA Lab Management Automation use case and user story
Install ALM 11.5 for CDA integration Integrate CDA with an existing ALM 11.5 installation
Implement and demonstrate a simple Lab Management Automation (LMA) use case example between ALM and CDA using the Pet Clinic application
Lesson 5: Integrating HP SiteScope with CDA and Deploying Monitoring

Lesson Goal
Integrate HP SiteScope 11.20 in to the CDA solution and show how to configure a new monitoring provider:
Import SiteScope (SiS) templates Understand CDA monitor policy Deploy monitoring with an app
Lesson Objectives
Describe the CDA SiS monitoring use case and user story
Integrate CDA with an existing HP SiteScope 11.2 installation Implement and demonstrate a simple monitoring deployment use case example between SiS and CDA
Lesson References
CDA documentation:
CDA Release Notes
Deployment of the same HP SiteScope template to the same target directory on two or more HP SiteScope systems is not supported Requires HP SiteScope 11.20
CDA Support Matrix
CDA User Guide
Chapter 5, Monitoring Administration

Chapter 5, Troubleshooting Monitoring
CDA Troubleshooting Guide
Other
HP SiteScope 11.0 documentation set
Integrating HP SiteScope with CDA
Concepts to Cover
Notes:
CDA includes monitoring deployment in conjunction with application deployment A monitoring policy is attached to a deployment topology during deployment The monitoring policy defines the monitor server and monitor templates to use CDA currently supports HP SiteScope, HP Diagnostic and Nagios (open source) monitoring tools Monitoring tools allow you to monitor application availability and performance Monitoring is deployed and undeployed with the application via CDA Monitoring tool events are reported back to CDA and monitoring status is displayed in the CDA user interface Monitoring details are displayed in the appropriate monitoring tool CDA allows monitor policy changes and re-deployment to existing deployments
Concepts to Cover
Notes (continued):
Process overview
Identify monitoring tools in the environment

CDA supports HP SiteScope, HP Diagnostics and Nagios (open source) monitoring tools Other monitoring tools require custom integration Also need to configure the monitoring tool to send monitoring events to CDA (not part of lab because ALL students are sharing the one HP SiteScope server in the shared lab environment) HP SiteScope monitors are created in CDA by importing HP SiteScope templates HP Diagnostics and Nagios monitors are manually configured
Create a Monitor Server in CDA for each monitoring tool identified
Define Monitors

Define Monitoring Policies Assign Monitoring Policies to Deployment Topologies Deploy the application (and monitoring) Review the state of the monitored application Modify the Monitor Policies and Re-Deploy Undeploy the application (and monitoring)
CDA monitoring functions
Lifecycle Monitoring Abstraction Actionable events
Aligns monitoring lifecycle with the deployment and provisioning lifecycles
Rich set of monitoring tool integrations including Sitescope, Diagnostics and BSM stack, Nagios ( see earlier slides on phased approach ) Extensible to other monitoring systems via abstraction layer Policy management Configurable rules Actionable Application & Infrastructure events generated based on policy and rules configured.
High level architecture

BSM: SiteScope, Diagnostics RUM, BPM, OM IAAS 3rd party, Monitor
Definitive Software Library (DSL)
Retrieve, Store
Application Release Manageme nt (ARM)

Provision, Deploy
Scale, Control
Application Workload Management (AWM)
Events
Monitoring Abstraction Layer (MAL)
Actions
IaaS Controller or Resource Abstraction Layer (RAL), Deployers, Configuration Abstraction Layer (CAL)
High level architecture
Monitoring Tool
Monitor Config API
MAL (embedded in ARM/AWM)

Monitor Configuration (CRUD)
Context
ARM/AWM
Monitors
Create/Delete Instance
Threshold Engine
Event API
Model Info
Event Receiver Correlate events to actionable events (Rule Engine)
Actionable Event
Integrating HP SiteScope with CDA

Exercise Tasks
1. Create a HP SiteScope monitor server
2. Define the monitors by importing the HP SiteScope templates into CDA

3. Define a monitoring policy for the Pet Clinic application
4. Add HP SiteScope templates to the monitoring policy

Create the monitor server

The CDA monitoring is configured under the Monitor tab
CDA 1.0 ships OOTB with provider template for Diagnostics and SIS
A. Create a new monitor server configuration in CDA for all monitor tools across the release environment B. For a given server configuration, import its monitor templates

Log in to the CDA server instance as the CDA administrator.
Select Monitor Servers from the Monitoring tab.
Create a new Monitor Server from the Monitoring tab.
Provide a name and description and then select a monitor provider definition (before clicking Next).
Add the SiteScope monitoring server type as the monitor provider definition.
Verify SiteScope is added as a monitor provider definition and click Next to continue.
Open a new browser window and connect to the shared SiS server in the lab: http://sis.syslab.adam.qa.hp.com:8080/SiteScope
Verify the authentication credentials needed by CDA: admin / VC_SL_DC001
Click Finish to continue to complete the wizard.

The HP SiteScope monitor server is now available, but only to the System domain. Does not show up in other domains.
2. Import the HP SiteScope templates into CDA

A. Scroll the Shared HP SiteScope Monitor Server window to the right and select Import Templates.
B. Import the SiteScope Deployer templates.

B. View the report for details.
A. It will take about 5 minutes to import all of the templates.
Verify the templates were imported successfully.
View the imported SiteScope templates.
3. Create a monitoring policy
Create a new monitoring policy.
Provide a unique name and description.
Add a couple of imported SiteScope templates to the monitoring policy.


Search and add the URL Latency template.

Search and add the Unix HP basic template.
Click Finish to complete the monitoring policy.

The new monitoring policy is now ready to use.
Deploying an application with a monitoring policy

Exercise Tasks
1. Associate a monitoring policy with a CDA deployment topology
2. Deploy an application with a monitoring policy

3. Set monitoring parameters during deployment 4. Verify monitoring from HP SiteScope
Drill down to the Pet Clinic application model and view the current Deployments. First, you will need to undeploy the existing deployment.
Undeploy the current deployment. Verify the undeploy is successful and then return to the Pet Clinic application model.
Add a new deployment topology to the existing application model.

Provide a unique name and description for the new topology.
Associate the topology with a matching platform.
Add a monitoring policy to the App Server Layer.
Select and add the SiS monitoring policy that you created earlier.
Add the SiteScope monitor server that you created earlier as the monitor server for this topology.
Select the SiteScope monitor server that you created earlier and add it to the topology.
Click Finish to complete the wizard.

View the new topology with the SiteScope monitoring policy. Verify the policy shows up on the App Server Layer.
Provide a unique name and select the deployment topology that includes monitoring.
Review the application parameters and click Next to continue.
Enter appropriate values for the monitoring parameters. Be sure to use a unique sis_destinatio n_path because the HP SiteScope server is shared by ALL students.
Save the parameters for later use and then click Finish to deploy.
3. Verify monitoring
Review the deployment report and verify the monitoring deployment was successful.
Start the Pet Clinic application. Verify the Pet Clinic application starts successfully.
View SiteScope monitoring. Note that the Cpu and Memory monitors might not work because the template uses Telnet for communications, which is not enabled on the Ubuntu server.
Additional steps:
A. Undeploy the application and verify the monitoring is also undeployed
Verify monitoring is also undeployed in CDA.
Verify monitoring is also undeployed in SiteScope. Note that the HP SiteScope server is shared by ALL students, so your specific monitors should not show up.
Associate policy with a topo

Monitor policies are model separately so they can be portable across application topologies The policies are translated real-time into configuration updates to the monitoring tools during application deployment Policies can add parameters to the deployment job Policies are associated with layers within the application model An application can have more than 1 policy
New monitor parameters
Newly provisioned server
ubuntu
Lesson 6: Integrating with HP Server Automation and HP Database Middleware Automation

Lesson Goal
Integrate CDA with the HP Server Automation (SA) and HP Database and Middleware Automation (DMA) service providers and demonstrate a simple integration use case for deploying a SA Policy and DMA Flow through CDA.
Lesson Objectives
Describe the CDA to SA/DMA integration and use case scenarios
Integrate CDA with an existing SA 9.12 installation Implement and demonstrate a simple deployment use case example using a SA Policy Implement and demonstrate a simple DMA flow execution
Lesson References
Documentation:
CDA Release Notes
Check for any known issues related to SA and DMA
CDA Support Matrix
Make sure your SA core is supported
CDA Installation and Configuration Guide
Provides information on configuring the SA and DMA plugin configurations
Other
Server Automation and DMA User Guide documentation
[testing integration]
Exercise Tasks
Appendix A: Preparing VMware Templates for use with CDA

Lesson Goal
Learn best practices for creating VMware templates for use with CDA and optionally create a Linux template that works with both SA and the Chef deployer
Lesson Objectives
Create a VMware template for Linux and Windows
Create a VMware customization specification for Linux and Windows
Lesson References
Documentation:
CDA Installation and Configuration Guide
Appendix B, Opscode Chef Best Practices
Other
vSphere Virtual Machine Administration Guide
Chapter 4, Working with Templates and Clones
Overview of Creating VMware Templates for CDA
Overview of VMware Templates in CDA

CDA via IO (MOE) uses VM templates to create VMs during provisioning
Assuming you are using vCenter for provisioning
VM templates are simply a master copy of a VM that can be used to create many clones (other VMs from the template)

Standard VMware definition For example, the VM name, computer name, network settings, and so on Known as guest operating system customization in VMware Uses a wizard or customization specification and optional scripts VMware Tools must be installed on the VM template Guest operating system customization must be supported by VMware for the given OS
Refer to the VMware vSphere Compatibility Matrixes documentation for other details
VMware includes tools to customize the clone during the deployment
IO uses Sysprep file for Windows for configuration

Need to have a Sysprep (like unattend.txt) file in IO install to use in IO template definition On your IO server, in C:\Program Files\HP\Matrix infrastructure orchestration\conf\sysprep\, make a copy of Sysprep_sample. Open the copy in Notepad and search for the line that contains AdminPassword = "changeme". Remove the hash at the front of the line and change the password to be something you use. Then specify that sysprep as the sysprep file in your HPIO template Windows server groups.
VM templates used in CDA should include:

Networking
The NIC configured for DHCP
When using SA as a deployer

A sanitized SA Agent so the VM can be managed by SA after deployment
The VMware Network should be set to the same VM network as SA
When using Chef as a deployer

Optionally, you might want to include the chef-client installer on the VM template for environments where the client does not have Internet access (cannot be bootstrapped over the network) Bootstrapping code on the Chef server will need to be modified to bootstrap from a local install
Other software
VM template can contain base software that will be used by all platforms
Overall Process for Creating VM Templates for use with CDA

1. Create a VM, within the vCenter accessed by CDA, with the appropriate operating system image for the desired CDA platform offering(s)
Ensure VMware Tools is installed on the VM The VM might contain additional content if the content is needed for all CDA platform offerings that use the VM template Specific offerings can then use a Deployer to apply additional content (for example, through the Software Management features of SA) Use whatever method is appropriate for creating the VM (for example, cloning from within vCenter or using SA to provision the OS)
2. Deploy the SA Agent to the VM and bring it under management of SA (if the VM was not provisioned through SA) 3. Sanitize the SA Agent on the VM and shutdown the VM 4. Deactivate and delete the managed server from SA 5. Convert the VM to a VM template
6. Create a guest customization specification in VMware, if necessary
Create VMware Templates
Creating VMware VM Templates

Exercise Tasks
1. Create a VM with the appropriate Operating System image
2. Deploy the SA Agent to the VM

3. Sanitize the SA Agent 4. Deactivate and Delete the target VM managed server from SA
5. Convert the VM to a Template

6. Create a VMware Customization Specification In VMWARE 7. Test the VM template from vCenter Approximate time for exercise and break: 30 minutes

Steps
A. Launch the vSphere Client from the AccessVM and log in to the shared vCenter Server for the lab:
IP address: User name: vcenter-YY, where YY is a unique number assigned to each student by the instructor
This allows you to monitor the vSphere Client Recent Tasks for messages related to your assigned vCenter user
Password: VC_SL_DC001 View the VMs and Templates that are already managed by vCenter

Steps (continued)
B. Deploy the rhel53x64-Master template to a new VM called: StudentXXX-rhel53x64-template StudentXXX-rhel53x64-template
Where XXX is your assigned student account number, be sure to put the target VM in the Students Templates folder WAIT until the VM is completely deployed before editing the VM settings, do not edit the settings from the Deploy Template wizard
C. After the VM is deployed, then edit the VM settings and set the Network adapter to: 10.0.44.0 Network (the same network the shared SA core is on), also make sure the adapter is connected
Create a VM with the appropriate Operating System image

Steps (continued)
D. Power on the VM
E. Record the IP address obtained from the DHCP server (SA)
See the Summary tab of the new VM Write down the VM IP address (NOT the Host IP address of the ESX server)
If you do not get an IP address, recheck your VM network settings and make sure the adapter is connected
Create a VM with the appropriate Operating System image

Steps (continued)
F. Install VMware Tools on the target VM
Select your VM in the vSphere Client and launch the Install/Upgrade VMware Tools option
Note that this version of vCenter will automatically install or upgrade VMware Tools on Linux and should take about 5 minutes
Note that previous versions of vCenter require you to mount the CD-ROM, install the VMware Tools RPM, and run the VMware configuration tool
2.Deploy the SA Agent to the VM

Steps
A. Launch the SA Client and log in to the SA core (10.0.44.115) as: CDA_admin / VC_SL_DC001
You might need to install the BSA Launcher on the Windows client Turn off proxies on the SA Client before logging in to the SA core
B. Deploy the SA Agent to your target VM You should see your Select Manage Server and deploy the Agent to the server, use root / VM based on the IP opsware for the credentials address you C. Verify the target VM is now under management of SA recorded earlier. Please note that SA and vCenter are shared resources with other students.
Go to Unmanaged Servers and scan for the IP address of your specific target VM
3.Sanitize the SA Agent

Steps
A. Record the SA Object ID of the target VM server
Open the Device Explorer of the target VM server and view the server Properties Record the Object ID value (use the copy command so you can paste it later) Close the Device Explorer

Steps (continued)
B. Run the BRDC HPSA agent sanitizer Program APX from the SA Library
Look under Extensions and Program in the Library
Locate the program, right-click and select Run

Steps (continued)
C. Return to the Enter the Object ID of the target VM server in the Options step of the APX
Wait for the job to complete before shutting down the target VM
D.Shutdown the VM (do NOT reboot or start)

Return to the vSphere Client and shutdown your target VM
4.Convert the VM to a Template

Steps
A. Return to the vSphere Client B. Select your target VM C. Right-click and select Template and then Convert to Template D. Your VM template is now ready to use within CDA
5.Create a VMware Customization Specification In VMWARE

Steps
A. Read Chapter 4, Working with Templates and Clones of the vSphere Virtual Machine Administration Guide, if you need more information
B. Launch the vSphere Client and log in to the shared vCenter Server for the lab
IP address: 10.0.44.42 User name: vcenter-YY, where YY is a unique number assigned to each student by the instructor Password: VC_SL_DC001
C. Go to the Customization Specifications Manager interface D. Review the existing useVmName_Linux and useVmName_Windows customization specifications
These were already defined in the shared environment and are used by the shared CDA installation
E. (Optional) Create your own Linux and Windows customization
6. Deactivate and Delete the target VM managed server from SA

Steps
A. Return to the SA Client
B. Right-click your target VM server and select Deactivate Server (make sure you select your target VM that matches the IP address recorded earlier) C. Right-click your target VM server and select Delete Server (this removes the record of the VM from SAs database) First, Deactivate the server Then, Delete to remove the server record completely
7.Test the VM Template from vCenter (Optional)

Steps
A. Deploy a Virtual Machine from your template
Name the test VM as: Student-XXX-rhel53x64-test and put it in the Student Test VMs folder Select your customization template during deployment, if you have one, or use the existing useVmName_Linux customization template
B. Power on your test VM

Verify the VM gets an IP address from the DHCP server (SA)
Record the IP address to so you can identify your VM later
C. Return to the SA Client and verify the server is now managed D. Deactivate and Delete the server record from SA
E. Return to the vSphere Client and shutdown your VM and then delete the VM from disk
Note that you do NOT want to delete your VM template because you will use that template later in the sample service designs of CDA
Creating VMware VM Templates

Exercise Review
1. Were you able to complete the lab?

Lesson Summary
Create a VMware template for Linux and Windows
Create a VMware customization specification for Linux and Windows
Appendix B: Installing and Configuring MOE 7.1 for CDA 1.00

Lesson Goal
Install the HP Insight Orchestration (IO), also known as Matrix Operating Environment (MOE) 7.1 (build 38) software and integrate MOE with vCenter to allow CDA to provision platforms through MOE
Lesson Objectives
Install MOE 7.1 build 38
Integrate MOE with vCenter Create and provision an IO template to verify operations
Lesson References
Documentation:
CDA 1.00 Release Notes CDA 1.00 Support Matrix CDA 1.00 Concepts Guide CDA 1.00 Installation & Configuration Guide CDA 1.00 Troubleshooting Guide
Install MOE 7.1 Build 38
Create a mapped network drive to the training files at \\10.0.44.101\training.

Locate the ISOs for MOE and then mount the MOE ISO(s) to the VM DVD drive(s).
Mount the MOE ISOs and start the autorun application, if needed.
Accept the License Agreement.
Run the Integrated Installer.
Select all of the options and then Customize to configure the appropriate options.
Recommended Course PATH (1.00) HP Version Control Repository Manager

De-select the following:
HP Insight Control server deployment (install locally or reuse remote installation) HP Insight Control Server deployment SIM Integration module HP Insight Control server deployment Quiesce SIM Plugin HP Insight Control server migration HP Matrix recovery management
Select the appropriate option for your environment.
Review the server prerequisites. Note that the installer will install MS SQL if not installed already.
Use the default installation directory.
Enter the password for the logged on (Administrator) user. Include the domain, if appropriate for your installation.
Install Microsoft SQL Server. This will take several minutes.
Accept the default to enable automatic sign-in.
Enter the HTTP proxy server settings for the environment.
Use the default port.
Accept the default.
Accept the default.


Read and continue.
Review the installation summary and install.

Read and continue.

The installation can take up to 3 hours to complete in the Fort Collins lab environment. Monitor on occasion.
At about 16 percent or 20 minutes the system will reboot. You will be asked to enter the location of the second DVD (ISO) if you are using only one mounted DVD.
Verify the installation completes successfully.
Review the Next Steps. Perform the first and third high-level bullets for the Fort Collins lab.
Run the Advisor and view the output. You should get only one Major notification, which you can ignore.
Review the log file and look (search) for any obvious errors.
Access the Systems Insight Manager. Log in as the Administrator user and IO_001 password.
Enter or ignore license key, that is the question?

Go to All Systems and verify the IO server shows up in the list of systems.
Return to the Insight Management Installer and close the window. Reboot the server and then relaunch Insight manager.
Integrating IO with vCenter
Start the License Manager in order to load the keys file.
Select Add Licenses.

Select the option to specify a file name and path to the key file.
Locate the key file for HP IO and open.

Process the key file into HP IO.

Verify you now have available licenses to manage the vCenter managed hosts.
Discover the eSX Managed Hosts
Verify the task is running. The task should discover the listed ESX managed hosts and any VMs on those managed hosts. Note that esx2 was not connected at the time of the discovery.
Select the Task ID to drill down deeper into the task details.
Select the ESX server Target and scroll down to see the target details.
View the target details and look for any Major failures, for example, credential issues.
Return to All Systems and view the results of the discovery task.
License the Managed ESX Hosts
Verify the ESX server is now licensed.

Discover the vCenter Server
Create a Discovery task for the vCenter server.

Verify the task is running.
View the task target details and verify there are no Major errors.
Verify the vCenter server shows up in the list of All Systems.

From the vCenter servers properties page, select Options, Credentials, and System Credentials.
Verify the Access Type is set to both WBEM/WMI and Sign-in. Select one of them and then Edit system credentials.
Select the link to show advanced protocol credentials.
Select the VME tab and set the VME credentials for the vcenter protocol.
Verify the task completes successfully.
After a few minutes, launch the Infrastructure orchestration tool.
Select Refresh and verify the ESX server shows up in the Unassigned server pool.
Create a new pool for the ESX servers that will be used for provisioning through CDA.
Create a new pool and assign the newly discovered ESX server to the new pool. Save the changes when done.
Verify the ESX server is now in the newly created server pool.
Go to the Software tab and verify any existing VM templates show up in the list of available software.
Go to the Network tab and edit the Private_Net1 network settings.
Go to the DNS sub-tab and edit the DNS settings.
Go to the Windows sub-tab and edit the Windows domain settings. Save the changes when done.
Verify the network is now available.
Read and click OK to acknowledge the message.
Save the template.
Save the template. Use a unique name if multiple students are performing the lab.
Return to the Infrastructure orchestration window and verify the IO template now shows up under the Templates tab.
Creating a new service from an IO template
Create a new service from the IO template to verify operations.
Make sure you use a unique service name and hostname to identify your service because the IO server is shared by ALL students.
3. Creating a new service from an IO template

Additional steps:
A. Verify the service is provisioned from vCenter.
B. Verify the service is provisioned from IO. C. Deprovision the service from IO to conserve VM resources
Thank you

HP Continuous Delivery Automation 1.00

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HP Continuous Delivery Automation 1.00

Transféré par

Droits d'auteur :

Formats disponibles

Continuous Delivery Automation (CDA) 1.

x: How To POC, Series 300, Level 360

Partners in a pre-sales, professional services, or technical support role

300-400 300 400 400 400 400 300

Employee link: http://grow.hp.com/Saba/loginAsUser.jsp?deepLinkName=CourseDetail&deepLinkParams=courseId=<Course ID> Partner link: http://h20507.www2.hp.com/Saba/loginAsUser.jsp?deepLinkName=CourseDetail&deepLinkParams=courseId=<Course ID>

Recommended Course PATH (1.0)

200 200 400 500

Curriculum paths still TBD

Employee link: http://grow.hp.com/Saba/loginAsUser.jsp?deepLinkName=CourseDetail&deepLinkParams=courseId=<Course ID> Partner link: http://h20507.www2.hp.com/Saba/loginAsUser.jsp?deepLinkName=CourseDetail&deepLinkParams=courseId=<Course ID>

Recommended Course PATH (1.00)

200 200 400 400

CDA 1.x: SWAT Bootcamp (VILT)

Curriculum paths CDA 1.00: Delta Technical Support Webinar 00383157

still TBD 8 (optional)

Pre-Sales SharePoint (internal)

Courier italics text, courier italics text bold

Lesson 1: Installing and Configuring Continuous Delivery Automation

Explore the user interface of an existing CDA instance

Perform the post-install domain configuration steps for CDA

Overview of the CDA Components and Roles

Fragile applications are prone to failure

Long time required to figure out which bit got flipped

Planned project work cannot complete

Source: Gene Kim (www.realgenekim.me)

CDA functional architecture

BSM: SiS, Diag, EUM, TV, OM

Fault/ Health Mgmt

DSL Build repo

RTSM Add. tools

RAL/CAL + provisioners/deployers IaaS Controller

Non HP Systems & Cloud Environments

HP Management restricted Infrastructure

CDA INTERNAL ARCHITECTURE:

Lab management automation

Realized target instances

IDeployer Internal API

IProvisioner Internal API

Initial CDA personas

Infrastructure/platform architects (model)

Developer, tester (operations)

Involved persona Primary persona

Not involved persona

CDA: model driven

application version model layer operation component end point

topology stored config mapping

platform deployment provider

external software IaaS template

policy provisioned platform monitor monitor provider provisioned server group

deployed monitor policy

Overview of the Installation Process

Public cloud: EC2, HP, Savvis

Conceptual CDA ecosystem

vm images Custom automation RBA server RBA server

Run book flows

Build environ. artifacts

Deploy server Monitor server

Private hypervisors: VMWare Microsoft

Monitor templates Deploy server Deploy server Deploy app

Infra service mgmt

CDA Installation Process Overview

Monitoring (optional) Install and configure SiteScope, Diagnostics, Nagios

CDA Installation Process

Read the Install & Configuration Guide

Install pre-requisite tools