Migrating from Pivotal tc Server on-prem to IBM Liberty in the cloud
- 1. © 2016 IBM Corporation Application migration to Bluemix for one of the world’s largest airlines Improving the mobile check-in experience
- 2. * Objective The purpose of this engagement was to create a new mobile check-in solution hosted on the cloud. Goals ▪Optimize the existing on-premise web service REST APIs by moving them to Bluemix “as is” ▪Connect this migrated application to other common services that were best left in the enterprise ▪Create a new cloud native application using the REST APIs to improve mobile check-in process Rationale The customer had many reasons for moving their mobile check-in process to the cloud. ▪Improve high availability. Through being able to host in multiple Bluemix data centers, this removes the necessity of having to maintain a costly disaster recovery center. ▪Exercise dynamic scalability – With mobile check-in loads being variable based on time of day, week or during high travel date, being able to scale based on load is very beneficial. ▪Support rapid development – Using bluemix garage methodologies for rapid development, Bluemix CloudFoundry based PaaS was the best solution to facilitate the process.
- 3. * Success Criteria Goals ▪Migrate existing REST API based web services from on premise TC Server as-is to Java buildpack hosted on Bluemix - Success ▪Connect migrated REST API based web services from Bluemix to on-premises resources that were best left within the corprorate firewall through the Secure Gateway - Success ▪Pass all functional and user acceptance tests - Success Stretch Goals ▪Migrate existing REST API best web services from on premise TC Server as-is to Liberty buildpack hosted on Bluemix - Success
- 4. * Tomcat vs Liberty considerations Initially the mandate was to move the existing mobile web services to the cloud as is. The customer was using TC Server (based on Tomcat) currently, and wanted to continue to use it in Bluemix. Bluemix does not support TC Server natively, however the Java buildpack on GitHub does contain an implementation of Tomcat. This was used for the initial PoC. Since, migrating to Liberty buildpack was low on the priority list. Once IBM completed the task of migrating the application to Bluemix using the Java buildpack, the backend resources were connected via the Bluemix Secure Gateway service, and all the developer test cases were executed successfully. As a side exercise IBM moved the application to run on Liberty buildpack in only one day! The executives in charge of the project were not interested in Liberty prior to this, as they thought it would distract from the development of the main project. Once they realized the simplicity of moving, and the benefits of Liberty vs Tomcat as far as support and performance considerations they were quick to change their perspective and are considering hosting their web services on Liberty buildpack within Bluemix.
- 5. * Overview of IBM Cloud Migration Process Understand WebSphere Migration Toolkits provide assistance in full cycle of cloud migration
- 6. * Overview of IBM Cloud Migration Tools A set of tools that help you: - Migrate from third-party application servers to WebSphere Application Server - Migrate between versions of WebSphere Application Server - Migrate to WebSphere Application Server on Cloud Migration discovery (WMDT) Binaries analysis Source migration (WAMT) Config migration (WCMT) On-line tool that helps you •Estimate the effort required to migrate your application to WebSphere Application Server from third-party application servers •Select the IBM cloud platform suited to host your application and estimate migration to that platform Command-line analysis of application binaries that provides • High level evaluation report showing the Java EE technologies your application uses • Detailed analysis for migration between versions of traditional WAS, Liberty, and Liberty Core • Cloud migration for instant runtimes differences • Cloud connectivity analysis Eclipse plugins that scans application source to provide • High level evaluation report • A line-by-line analysis of code changes required • Detailed analysis from third-party applications servers • Detailed analysis between versions of traditional WAS, Liberty, and Liberty Core. • Cloud migration for instant runtimes differences • Cloud connectivity analysis Eclipse plugin that helps migrate server configuration •From third-party application servers to WebSphere Application Server •Between versions of traditional WAS, Liberty, and Liberty Core
- 7. * Cloud Migration Tools Tool Name Location WebSphere Application Server Migration Discovery Tool http://ibm.biz/MigrationDiscovery Migration Toolkit for Application Binaries https://developer.ibm.com/wasdev/downloads/#asset/tools- Migration_Toolkit_for_Application_Binaries WebSphere Application Server Migration Toolkit https://developer.ibm.com/wasdev/downloads/#asset/tools- WebSphere_Application_Server_Migration_Toolkit WebSphere Configuration Migration Tool https://developer.ibm.com/wasdev/downloads/#asset/tools- WebSphere_Configuration_Migration_Tool
- 8. * Tomcat Configuration Migration ▪ Customized Java Buildpack from GitHub ▪ Added JVM Properties in java_opts.yml ▪ Added application-specific configuration to tomcat/conf ▪ Added application-specific libraries to tomcat/lib ▪ Set log4j.properties to console appender in tomcat/lib
- 9. * Customized Java Buildpack from GitHub ▪ There is no public domain TC Server Buildpack for Bluemix ▪ There is a Java Buildpack provided by CloudFoundry that includes Tomcat The CloudFoundry Java Buildpack exists here: https://github.com/cloudfoundry/java-Buildpack ▪ We created a fork of the Java Buildpack from GitHub to our personal GitHub account, and modified the BuildPack’s Tomcat configuration with functional changes that were made to the on premise TC Server configuration for running the application ▪ For instructions on keeping the forked Java Buildpack in sync with their upstream repository, see –https://help.github.com/articles/syncing-a-fork/
- 10. * Added JVM arguments to java_opts.yml Problem: Application sets JVM properties in Tomcat startup script; can’t do that on CloudFoundry Solution: We set the properties in the Buildpack properties config/java_opts.yml File Contents: from_environment: true java_opts: -Dnms.config.logs=${catalina.base}/logs -Dlog4j.debug=true
- 11. * Added application-specific configs to tomcat/conf Problem: Application specific configuration files need to be loaded from TCServer home, or classpath Solution: We added the application specific configuration files the following Java Buildpack folder resources/tomcat/conf The following are the configuration files that were added to the resources/tomcat/conf folder. Note that all of them may or may not be necessary for the PoC; however we discovered many were required so we moved them all catalina.policy catalina.properties context.xml cs.environment.properties ehcache.xml logging.properties server.xml tomcat-users.xml web.xml Z1019111.jks
- 12. * Added application specific libraries to tomcat/lib Problem: Application specific JAR files need to be loaded from TCServer home Solution: We added the application specific JAR files to the following Java Buildpack folder resources/tomcat/lib The following are the JAR files that were added to the resources/tomcat/lib folder. Note that all of them may or may not be necessary for the PoC; however we discovered many were required so we moved them all activation-1.1.jar geronimo-j2ee-management_1.0_spec-1.0.jar geronimo-jms_1.1_spec-1.1.1.jar jta.jar log4j-1.2.15.jar log4j.properties mail-1.4.1.jar ojdbc14 ojdbc14.jar ojdbc5.jar sqljdbc-1.0.jar
- 13. * Set log4j.properties to console appender in tomcat/lib Problem: Application Log files cannot be found in ${catalina.base} on CloudFoundry. Solution: There is not a logs folder in the ${catalina.base} on CloudFoundry; it is only there on TC Server. So we changed log4j.properties to use the console appender. Add a resources/tomcat/logs folder would have been an option, but console logging is the better practice for CloudFoundry based PaaS resources/tomcat/lib/log4j.properties ▪log4j.rootLogger=DEBUG, R ▪log4j.appender.R=org.apache.log4j.ConsoleAppender ▪#WWWCMTlog4j.appender.R.File=${catalina.base}/logs/tomcat.log ▪#log4j.appender.R.MaxFileSize=10MB ▪#log4j.appender.R.MaxBackupIndex=10 ▪log4j.appender.R.layout=org.apache.log4j.PatternLayout ▪log4j.appender.R.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
- 14. * Application Source Migration ▪ Loaded Properties from the Classpath ▪ Resolved File System Differences ▪ Resolved Network Connectivity Issues ▪ Loaded Static Content from the WAR ▪ Set Context Root
- 15. * Loaded properties from the classpath Problem: Cannot load properties files from outside the classpath. Solution: When we need to access files, we would include them in the WAR file directly. Also whenever reading a file, we had to change the code to access the resource via the classpath. Example: We moved threadpool.xml to the base of the WEB-INF/classes folder, and modified EnvironmentThreadPoolFactoryBean.java Before: ▪ApplicationContext context = new ClassPathXmlApplicationContext( ServiceMigrationDependencyLocator.getRelativePath() + "spring/threadPool.xml"); After: ▪ApplicationContext context = new ClassPathXmlApplicationContext("threadPool.xml");
- 16. * Resolved filesystem differences Problem: The context.xml specified a location to be searched on the TC Server’s file system that does not exist in CloudFoundry. You should not try to access a location within the container’s file system as it may be different that Buildpack locations. CloudFoundry does not push apps to the webapps folder. Solution: This file was not necessary as the Buildpack would ignore this, and it only caused problems Before: <?xml version="1.0"?> <Context> <Resources> <PostResources className="org.apache.catalina.webresources.DirResourceSet" base="${catalina.base}/webapps/<AppNAME>/" webAppMount="/WEB-INF/classes" /> </Resources> </Context>
- 17. * Resolved network connectivity issues Problem: All of the endpoints referenced in the application referred to hosts that are only available in within the customers intranet. Solution: We used secure gateways within Bluemix. These created a bridge to the endpoints within the customers network. Properties files needed to be modified to point to the cloud secure gateway host and port
- 18. * Served static content from the WAR Problem: Static content was being served from outside the WAR Solution: We moved the static content into the WAR Another option would have been moving static content into CloudFoundry Static Buildpack See: https://github.com/cloudfoundry/staticfile-buildpack
- 19. * Set the context root Problem: The /<Context Root> context root was not set for the application when install on Java Buildpack Solution: We used an environment variable to set the context root for Tomcat specifically.
- 20. * Java and Liberty Buildpack Comparison Comparison from migrating the application to Java and the Liberty Buildpack ▪Configuration ▪ Java Buildpack had to fork the Buildpack to configure Tomcat for running the application ▪ Liberty Buildpack did not have to Fork the Buildpack; instead the configuration was included in the server and the application was deployed to the server, and you push the entire server to Bluemix ▪Licensing ▪ Java Buildpack costs the same as Liberty Buildpack ▪Technical Support ▪ Java Buildpack does not include Tomcat support ▪ Liberty Buildpack does include Liberty support ▪Performance ▪ Liberty outperforms Tomcat ▪ Less Liberty instances run same workload.
Editor's Notes
- #6: Perform detailed workload analysis
- #7: WAS Application Migration Toolkit (WAMT) Migration Toolkit for Application Binaries WebSphere Configuration Migration Toolkit (WCMT) WAS Migration Discovery Tool
- #16: When dealing with application servers it is best to avoid using the default path as it changes easily. Either have a system property or equivalent that defines where the files will be searched for or, if you&apos;re shipping the file you want to read together with the application, put it inside the WAR and open it as a resource: YourClass.class.getResourceAsStream(&quot;/...&quot;); or YourClass.class.getResource(&quot;/...&quot;);