Application cloudification with liberty and urban code deploy - UCD
Download as PPTX, PDF0 likes293 views
The document details the migration of three bank applications from WebSphere Application Server (WAS) to Liberty, utilizing Urbancode Deploy (UCD) as the release automation tool. It outlines the phases of cloudification, objectives, completion status, and infrastructure set-up, as well as workshops conducted to address configuration management and rollback capabilities. The outcomes present enhanced deployment processes, integration with tools like Jenkins and CyberArk, and security management practices implemented within UCD.
Application cloudification with liberty and urban code deploy - UCD
- 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