Migration of 3 real applications from WAS to Liberty in a a bank, adopting UrbanCode Deploy as release automation tool

1. 1
Application Cloudification with Liberty and
UrbanCode Deploy - UCD)
Migration of 3 real applications from WAS to Liberty in a a bank, adopting UrbanCode
Deploy as release automation tool
January 2020
Davide Veronese
davide.veronese@it.ibm.com
https://davideveronese.wordpress.com/
https://www.linkedin.com/in/davide-veronese-b8b08b28/

2. 2
Agenda
 Activity Overview scope
 Objectives
 Completion status
 Infrastructure env
 Teams set-up
 Timeline
 Workshops outcomes
 References for questions and discussed points

3. 3
Cloud evolution – Status update
Bank apps
Liberty
3 - Containerize 4 - Operate
1 – Libertize
2 – Automation with LMI
1. Libertize – Deploy the application code on the Java
Liberty
2. Automation – (Build and) Deploy the applications on
Liberty with a LMI tool
Phase 1
3. Containerize – Move Bank apps with Liberty on
Containers with LMI tool
4. Operate – Run the Containers on CaaS (OCP) or
other platform
Phase 2
• IT topology simplification with adoption of a
Lightweight and Open source App Srv
• Optimize migration impacts: high portability
from WAS to Liberty
• 100% compatibility with Kubernetes for
Containers cluster implementation
• Enabler for an application architecture
simplification
• Accelerate DevOps adoption
• Strong rollback and recovery
capabilities
Value Proposition
Object of this presentation

4. 4
Bank app evolution PoC - objectives
Topics included in the PoC
• install selected Bank apps applications on WAS Liberty environment
• test and verify:
• Conflicts between Bank apps and Liberty libraries
• Resource access
• Security and SSO
• configuration management: based on master XML configuration file and an include XML config. test
and verify Liberty product as for future CTS candidate
• support Customer to identify gaps and processes to be implemented related to the new platform
• Analysis and implementation of the deployment process that will cover single and multiple J2EE
application on Liberty
• Implementation of the use case for installation rollback in the following two scenarios:
• Rollback caused by a fault/error in one of the installation steps
• Rollback driven by the user after a successful installation
• UCD native API exposure

5. 5
PoC activities – Completion status
Activity Status Notes to complete
Install selected Bank apps on WAS Liberty environment VMs available, Liberty+UCD installed and running. XFrame2 apps
installed correctly
Test and verify:
1. Conflicts between XFrame2 and Liberty libraries
2. Resource access
3. Security and SSO
1. intercommunication between different applications deployed working
correctly
2. Backend access ok, reading property files from an application to be
evaluated
3. Bank Security involved to identify potential solutions. No issue identified
Configuration management: based on master XML configuration file
and an include XML config. Test and verify Liberty product as for
future CTS candidate
Config mgnt addressed during the workshops. To be finalized after PoC
competition involving other Bank orgs (Security). No open items.
Integration with CyberArk analysed, integration with Jenkins demo done.
Support Customer to identify gaps and processes to be
implemented related to the new platform
Process and organizations topics jointly discussed, no criticality identified.
The impacts and gaps finalization is depending by the target Bank
solution timeline. Integration with MLX and other Bank tools discussed, to
be further analysed
Analysis and implementation of the deployment process that will
cover single and multiple J2EE application on Liberty*
Implemented 3 deployment processes using a common template. Bank
hands-on session on UCD done to review what done in previous
workshops,
Implementation of the use case for installation rollback in the
following two scenarios*:
• Rollback caused by a fault/error in one of the installation steps
• Rollback driven by the user after a successful installation
Rollback included into the deployment processes for the 3 Bank apps.
Deeper understanding of rollback mechanism completed
UCD native API exposure* API exposed by UCD and documented. API not tested in this phase.
Further analysis API overview, classification and how they can be invoked
scheduled by Jan 27th workshop

6. 6
Bank apps evolution PoC – Infrastructure env
The environment provided in this proposal is composed by:
• 3x2 instances of Liberty product, one for each application in scope
• 1 instance of IHS product
• 1 instance of UCD
• 1 Oracle schema for UCD and 10GB of SAN storage
The following schema provides an architectural view of the environment already provisioned with a Private
Cloud
App1
App2
App3
App1 App2 App3

7. 7
Workshops activities
Activities Done:
 PoC env set-up according to the defined topology (slide 4) + Oracle DB
 (in progress) Firewall requests for UCD integration with Nexus and CyberArk)
 Bank applications manually installed on Liberty servers
 Configuration management for Liberty, and related role mapping in UCD
• Analysis of requirements from Bank and IT supplier
• Definition of a potential target solution in the PoC
• (in progress) Definition of a final solution to be further analysed after the PoC
 Bank apps Deploy processes implemented with UCD
• App1: completed first version with rollback
• App2: completed first version with rollback
• App3: completed first version with rollback
 userID creation for Bank access to UCD console

8. 8
Config Management, high level solution (1/2)
High level view solution:
 Environment property management: usage of env property to customize the configuration, adoption of
tokens in the conf files which can be easily adopted. IT supplier proposition to adopt a token structure
similar to WebSpere for variables ( ${property} )
 Easy mgnt of mainframe resources: Bank asked to identify a solution to reduce the effort for
application teams to connect to mainframe envs. For DB2, MQ, CTG e IMS the «ambito» usually identify
hostname and port to be used for the connection factory in the server.xml. 3 options have been
discussed (“C” is currently implemented in UCD)

9. 9
Config Management, high level solution (2/2)
High level view solution:
 Config ownership and responsibility: the Liberty conf model provides high level freedom to the
application teams. This means also more responsibility and impact on SLAs when configuring shared
resources (e.g. DB2). 3 options have been evaluated to reduce the responsibility for application teams
(“A” is currently partially implemented in UCD):
• A) Configuration Override at application server level
• B) XML schema validator
• C) manual approval
• Config mgnt at app level: the team discussed the option to have one single config component
(managed by app team) for each UCD application. Considering the deploy env shared by more EARs,
and more subsystem for the same AAM code, this solution will prevent duplication and overwriting. This
solution is under discussion. The alternative to have more than one config component for each
application can be applied, but a review of potential conflicts is required

10. 10
Main outcomes
Value added capabilities introduced with UCD (Workshop1):
• process templates for ear and wlp config to provide reuse and standardization
• rollout deployment to primary and secondary resources to provide business continuity
• installation rollback feature provided by the product
• added "operational process" to start and stop servers that could be used by developers
in test envs
• environment properties used to replace token and to have configuration files
customized in each env
• call external API during deployment process to check application liveness
• possibility to define human tasks con human interactions
• possibility to define approval process for specific environment before start deployment

11. 11
Main outcomes
Value added capabilities introduced with UCD (workshop2):
• UCD APIs overview
https://www.ibm.com/support/knowledgecenter/it/SS4GSP_7.0.4/com.ibm.udeploy.reference.doc/topics/rest_api_ref_overview.html
• Integration with Change Management system to push standard Bank roles into UCD for each
application, and to align UCD components with Change Management subsystems
• Quality gate: implementation of a basic quality gate related to component status (e.g.: Validated or
Deprecated)
• New application onboarding process on UCD as
• IT supplier will define Resources, Resource groups and Resource tree in Urbancode (maybe done manually or in case of
Cloud an image could already be available with UCD agent)
• application owner creates the Components, then the Application and he/she maps components to resource tree
• using the application template concept creation of all the components and the related resource tree
• agent protyping can also be used to create a full fledged environment (IT supplier still needs to provision actual servers
and map them to agent prototypes)

12. 12
Workshop3 outcomes (1/2)
1. Bank hands-on session on UCD to review what done in previous workshops:
• Creation of 2 new UCD components using the template for both ear file and config file
• Clarification about Bank/IT supplier responsibility
• Possibility to create components from Shared-Library
• Creation of an application from the template
• UCD Environment deep dive as set of target resources with related configurations, used as destination of application
deployment.
• Review of Primary and Secondary Server categories for Environment set-up
• Review of deployment processes already implemented
• Overview of how UCD can be triggered by the availability of a new app baseline released into the source code versioning
system
2. API overview, classification and how they can be invoked:
• Overview of API documentation
(https://www.ibm.com/support/knowledgecenter/it/SS4GSP_7.0.4/com.ibm.udeploy.reference.doc/topics/rest_api_ref_over
view.html)
• Focus on UCD “teamsecurity” APIs group
• Demo of UCD APIs adoption in a Groovy script to integrate Jenkins with UCD
• Adoption of UCD APIs as CLI utility commands for authentication

13. 13
Workshop3 outcomes (2/2)
3. Overview of gaps between current deployment process on WAS, and deployment
processes implemented with UCD in PoC for Liberty
• Open discussion and review of the processes already implemented. No specific issues identified
4. Deeper understanding of rollback mechanism
• Review of the Rollback capabilities implemented into the UCD processes implemented for the Bank apps
• Discussion about how this solution can be enriched to address further fault scenarios
5. Other discussed topics
• UCD and Jenkins integration: demo of “Jenkins Publisher” UCD plugin to integrate a Jenkins pipeline with UCD, creation
of a new UCD component driven by Jenkins
• UCD and CyberArk integration: overview of the available plug-in. Discussion about potential usage of UCD plug-in with
Liberty apps. Bank Security team have to be involved for further evaluations
• SSO options for Liberty (Bank Security involved), discussion of potential solution with JWT. The final closure of this topic
is out of the UCD/Liberty perimeter, and it will be finalised with Bank Security team.

14. 14
UrbanCode Deploy objects mapping
This meta model represents all UrbanCode Deploy object types and their relationships:

15. 15
UrbanCode Deploy: Extending product functions
The functions and integration capabilities of UrbanCode Deploy could be extended using:
• Plug-ins
UrbanCode Deploy plug-ins provide tools for creating component processes and integrations. UrbanCode
Deploy provides plug-ins for several common deployment processes, and others are available to integrate
with a wide variety of tools, such as middleware tools, databases, and servers. Ref.:
https://www.ibm.com/support/knowledgecenter/SS4GSP_7.0.4/com.ibm.udeploy.reference.doc/topics/plugin
_ch.html
• Rest API
The UrbanCode Deploy server have a separate REST interface. You can use these REST interfaces to
automate tasks on those servers. Ref.:
https://www.ibm.com/support/knowledgecenter/SS4GSP_7.0.4/com.ibm.udeploy.reference.doc/topics/rest_a
pi_ref_overview.html
• Command line interface
CLI is a command-line interface that provides access to the UrbanCode Deploy server. It can be used to
find or set properties and to run numerous functions. Ref.:
https://www.ibm.com/support/knowledgecenter/SS4GSP_7.0.4/com.ibm.udeploy.reference.doc/topics/cli_ch
.html

16. 16
UrbanCode Deploy: Managing security
UrbanCode Deploy uses a flexible team-based and role-based security model that maps to your organizational
structure.
From a high level, the security system for the server consists of an authentication realm, authorization realm,
roles, and teams. The authentication realm verifies the identity of the user or system that is trying to log on to
the UrbanCode Deploy server. The authorization realm manages user groups.
The available authentication and authorization realms are as follows:
• Internal Storage
Uses internal role management. The default authorization realm (Internal Security) is of this type.
• LDAP or Active Directory
Uses external LDAP role management.
• SSO
Provides single sign-on authorization.
Further informations on UrbanCode Deploy security concepts could be found at:
https://www.ibm.com/support/knowledgecenter/SS4GSP_7.0.4/com.ibm.udeploy.admin.doc/topics/security_ch.ht
ml
The next slide show the security model implemented in UrbanCode Deploy.

17. 17
UrbanCode Deploy: Security Model

18. 18
UrbanCode Deploy: Integrating security with external system
UrbanCode Deploy provides both cli command or Rest API to manage teams, user/group assignment and
resource/team associations.
The integration implementation depends on the security model implemented in the external system.
A general suggestion is to define a group for each team/role and add the group with that role in the team:
• T1
• R1  T1R1 (group)
• R2  T1R2 (group)
• Rn  T1Rn (group)
With this configuration the sync with an external system could be done just synchronizing group members using
Rest API or cli commands: addUserToGroup / removeUserFromGroup.
If the authorization realms is LDAP/AD or SSO the sync is not necessary.

19. 19
UrbanCode Deploy: Jenkins integration
UrbanCode Deploy provides the “Jenkins Pipeline” plug-in: https://developer.ibm.com/urbancode/plugin/jenkins-
2-0/
This plug-in is installed into the Jenkins server and includes functions to interact with IBM UrbanCode Deploy
components and deployments. With this plug-in, you can complete the following tasks:
• Create components
• Publish artifacts to a version
• Start component version imports
• Deploy snapshots or component versions
• Run operational processes
• Run the step multiple times within a single job
• Accomplish all of the above with pipeline script syntax
Useful links:
• Jenkins Pipeline Plug-in Tutorial: Component Version Import and Snapshot Deployment:
https://developer.ibm.com/urbancode/2017/07/11/jenkins-pipeline-tutorial/
• https://github.com/UrbanCode/jenkins-pipeline-ucd-plugin

20. 20
UrbanCode Deploy: CyberArk integration
CyberArk has implemented and released a plug-in for UrbanCode Deploy:
https://developer.ibm.com/urbancode/plugin/cyberark/
This plugin allows UrbanCode Deploy to get credentials from EPV via AIM, and to get secrets from Conjur for
setting up a CI/CD workflow.
The CyberArk plug-in provides the process steps:
• Authenticate Conjur
• Get Password from CCP (Web Service)
• Get Password from CP (CLI Utility)
• Get Variable from Conjur
The CyberArk plugin password retrieval steps generate secure process request properties accessible only by
the currently running process. In subsequent steps you may access these properties using the syntax
${p:CyberArk/password}, ${p:CyberArk/username}, and ${p:CyberArk/address}.
Useful links:
• https://github.com/cyberark/urbancode-conjur-aim