10 Steps to Improving Your Deployment Process to Wildfly and Jboss EAP Whitepaper
Total Page:16
File Type:pdf, Size:1020Kb
10 steps to improving your deployment process to WildFly and JBoss EAP Whitepaper Table of contents Best practices for application deployments 3 Versioned artifacts together with application configuration 3 Versioned and templatized JBoss profile configuration 4 Best practices for deployments to IIS 4 Standard runtime control setup 4 Runtime control, insight, and deployment service 5 Automation 5 Automated application and configuration deployment 5 Automated JBoss middleware provisioning 5 Secure self-service 5 Integration 6 Consider components outside the Red Hat stack 6 Integrate with your development toolchain 6 Digital.ai | 10 steps to improving your deployment process to WildFly and JBoss EAP 2 Whitepaper At Digital.ai, we have decades of accumulated experience deploying to JBoss EAP and broader Red Hat middleware environments. Based on this Versioning knowledge, we have collected a list of practices and recommendations that can help you improve your 1. Versioned artifacts together with application deployment process to your JBoss- application configuration based middleware stack. 2. Versioned and templatized JBoss Many of the following practices, which we have profile configuration grouped into Versioning, Management, Automation, and Integration “tracks”, are applicable and valuable in other middleware environments too. Management The lightweight and flexible nature of JBoss1, the 3. Standard runtime control setup consequent wide variety of possible setups, and the relatively rapid pace of change of automation 4. Runtime control, insight, and interfaces, result in a number of JBoss-specific deployment service challenges too. Automation Versioning 5. Automated application and 1. Versioned artifacts together with application configuration deployment configuration 6. Automated JBoss middleware Real apps running on JBoss are more than just an EAR file. Keep information about your application provisioning configuration — the datasources, queues, topics, 7. Secure self-service etc. that are required only for this application and which you would also want to remove if the application were uninstalled — with the code so Integration you know what your application actually needs to 8. Consider components outside the run, even if you have to set it up in a brand new Red Hat stack environment. 9. Integrate with your development • Always delivering just “the new EAR file” toolchain and assuming that your target environment is correctly configured means that there is 10. no one place — no Definitive Software Library — you can point to that describes your full application • Applying configuration changes required for a new version to all your JBoss installations becomes as easy as deploying the new • It is important that your configuration application version to the next environment: definitions abstract away from the no waiting around for the middleware team implementation format, such as the XML to deal with a configuration request. Even file syntax for defining datasources in older better, backing those configuration changes JBoss versions, or specific CLI commands for out again is as simple as downgrading to WildFly and JBoss EAP 6. As this transition the old application version: no more JBoss installations with dozens or hundreds of possibly stale configuration resources about 1 Throughout this document, “JBoss” will be used when the comment which nobody can say whether they are used applies both to JBoss AS (now WildFly) and JBoss EAP. If the open source or commercial version specifically is meant, we will use “Wild- by any of the current applications or not Fly” and “JBoss EAP”, respectively. Digital.ai | 10 steps to improving your deployment process to WildFly and JBoss EAP 3 Whitepaper demonstrates, the implementation syntax can change dramatically. By specifying configuration in an abstract format, such Digital.ai Deploy, JBoss, & Red Hat changes can be accommodated without Middleware having to redefine all your application configuration Digital.ai Deploy, formerly XebiaLabs XL Deploy, is the only fully automated 2. Versioned and templatized JBoss profile Application Release Automation configuration solution on the market today. Digital.ai Even in a secured set up where developers Deploy was built from the ground up to don’t have access to the JBoss console and the support the best practices derived from underlying machine, ensuring a consistent server our extensive experience of deploying and profile configuration across environments, and preventing configuration drift, is a key to JBoss and working with Red Hat. challenge. Look for automation tooling to support Digital.ai Deploy offers unrivaled configuration drift analysis. Better still, prevent it from happening in the first place by provisioning support for the Red Hat middleware new JBoss environments based on versioned, family including JBoss EAP, as well as controlled configuration definitions! JBoss Web Server. Digital.ai Deploy can deploy most JBoss application and • Your “company standard” middleware environment configuration types out- configuration — profiles, JDBC drivers, and of-the-box, supports JBoss topology similar global resources — can be versioned and resource discovery, and provides a and controlled just as your application code and configuration should be consistent automation interface across (pre-)JBoss AS 6/JBoss EAP 5 and “new • Profile templates allow you to maintain one generation”, WildFly/JBoss EAP 6. versioned configuration definition while allowing port sets, credentials, etc. to vary With Digital.ai Deploy, organizations between environments can accelerate application time to • If your automation can deploy application market and eliminate manual tasks such configuration it should also be able to as scripting, while reducing cost and deploy your shared configuration, giving errors. you a consistent way of defining, managing, and applying all your JBoss configuration Learn more at: digital.ai/deploy settings Management 3. Standard runtime control setup in the background. Since the standard JBoss In an enterprise environment, JBoss needs to startup command returns before the server run as an unattended server process. Logging in is fully running, determine which additional interactively as a user, starting the process, and checks to use before the init.d script simply leaving the login session open is not a completes. Log parsing and checking for scalable approach. connectivity on a certain port are common • On Unix, create an init.d script that switches options; a simple application that provides to the JBoss service user and starts, stops, a dedicated “server up” response is another and restarts the server uninterruptedly and possible alternative Digital.ai | 10 steps to improving your deployment process to WildFly and JBoss EAP 4 Whitepaper • On Windows, install JBoss as a service using you dependent on a small set of individuals JBoss Native or one of the various Java for deployment service wrappers that are available • Release manuals are seldom stored or versioned alongside the applications they 4. Runtime control, insight, and deployment relate to: “oh, use the one from the last service time — it’s the same” Due to the relative simplicity and accessibility of the directory structure and deployment models • Ensure your automation allows for per- of pre-WildFly/JBoss EAP 6 versions, many JBoss application management of JBoss working setups handle deployment and maintenance directories! JBoss only offers “all-or-nothing” activities such as viewing log files through direct cleanup capabilities out of the box — either access to the JBoss directories and files. This can the working directories for all applications create unnecessarily complicated file permission are cleaned, potentially losing session state, structures when different groups of users require or no working directories are removed, different access rights (e.g. one group that deploys leaving stale files. In practice, working applications, another to manage configuration, a directory handling needs to be configurable third that can only start and stop the server). It also on a per-application basis ties these management activities very closely to the JBoss implementation which, as WildFly/JBoss EAP 6 6. Automated JBoss middleware provisioning demonstrates, can change significantly. • Many proven options exist to automatically • Expose the ability to start, stop, restart, provision a JBoss stack, from cloud etc. the server to view logs and to deploy management systems like VMware’s vSphere applications and configuration through a and vCloud and Red Hat’s Network Satellite, simple service layer. For start/stop/restart, to dedicated provisioning tools like JBoss appropriately controlled access to the JBoss Operations Network (JON), PuppetLabs’ init.d script or Windows service are already Puppet, and Opscode’s Chef sufficient • Clean environments greatly reduce the • For JBoss EAP 6, the new CLI already risk of stale settings, configuration, or file covers many aspects of a service layer. Until permission changes made for unrelated enterprises have entirely migrated to these applications in a previous test run from new versions, a thin wrapper that can expose interfering with your application and causing the same interface for both these and pre- a time-consuming “config bug hunt” WildFly/JBoss EAP 6 versions significantly simplifies application management and 7. Secure self-service reduces the migration effort Allow developers, testers, the QA team — anyone who needs access