Continuous Delivery for Enterprise Java Applications

Mark van Holsteijn

How do you setup a environment that support the continuous deliver of enterprise Java applications? How do you manage the large number of machines that are involved? How do you enable self-service, continuous delivery of applications onto the platform?

In this blog post we will give a description of an open source Java Application Platform as a Service that we created for our customer, using VMware, Redhat Enterprise Linux, Apache WebServer, JBoss Enterprise Application Platform, JBoss Operations Network, Puppet, Deployit,  F5 Load Balancer and  a Layer7 SecureSpan gateway.

Data Center Quality Platform

The customer wanted a data center quality Java Application Platform with the following features:

  • Standard configuration
  • Standardized provisioning
  • Standardized deployment
  • Centralized monitoring
  • Centralized access control
  • Virtual environment
  • Proving technology

Current situation

As the current Java application platform was based on HP-UX on Itanium, the customer was facing high cost for hardware, software licenses and fading support from software vendors.  As all applications ran on a HP Superdome, it was very difficult to add resources to individual applications. In addition, development teams spend too much time taking their software through the development, test and acceptance environments, resulting in slow delivery of software into production. Finally, it was difficult to provide 24x7 availability because all applications are running on a single machine.

Java Application Platform

The following figure illustrate the solution architecture of the java application platform.

jap solution overview

In the following paragraphs we will describe the purpose of the most important components.

Dual Data Center – HP

Not shown in the figure, is the hardware setup of the platform. It consists of HP blades setup in two data centers on two different locations. This provides the basic infrastructure for 24x7 availability and fault tolerance.

VMware ESX

VMware ESX is deployed on top of the hardware in the dual data center. This provides us with the ability to create virtual machines and provide high availability in case of single server of single site failures. It also allows us the quickly scale up virtual machines and increase the resources assigned to individual virtual machines.

For all machines in the platform we use a single VMware template image. This image is installed with RedHat Enterprise Linux and a puppet client.

Puppet

vm-template

Puppet fully automates system management. It is used for the installation of software packages, conformity tests and day to day system administration tasks.  For every type of node, we have a puppet plan. When the machines boots, the puppet agent provisions the machine with all the necessary software and configuration according to the plan for that machine.

The use of Puppet completely automates and standardizes the configuration, ensures 100% reproducibility of the configuration and is fast. Provisioning of a new machine from the template to full operational mode is done in a matter of minutes.

JBoss EAP

JBoss Enterprise Application Platform is the Enterprise Java applications server for all java applications.  The installation and configuration is done by Puppet and uses the official RedHat RPMs.  Puppet configures JBoss to ensure that :

  • JBoss management applications authenticate users against Active Directory, providing a single point of authorization for operations.
  • A JBoss Oracle database schema is automatically provisioned for that specific instance of JBoss, providing persistence for the JBoss server system state.
  • All Business Applications can authenticate users using SAML against the Layer7 Identity provider, providing a single point of authentication and authorization for their customers.
  • The JBoss instance is added to the pool in the F5 Load balancer
  • The application server is added to the Deployit infrastructure inventory, providing the tenants of the platform with the ability to deploy applications to the server.

JBoss application servers are always deployed in multiples of two, where each server of a pair is assigned to a physically different data center location by VMware.

The use of puppet provides us with a fast and reproducible way of provisioning JBoss application servers, allowing for a fast and reliable scale out mechanism for the applications.

JBoss Operations Network

image

JBoss Operations Network (JON) is used for monitoring all the resources in the platform.   By default, Puppet installs a JON agent on every machine. This agent scans the inventory of the machine and reports it to the JON server.

JON has a very good support for high availability and fail over. By simply adding a JON server machine, agents will automatically distribute themselves across the servers and failover if necessary. Each JON server also runs a JON agent, making sure that unavailability of a JON server is also covered.

In JON we created a number of alert templates for different resource types (os, apache, jboss, jon, puppet, etc.)  that will monitor and report critical conditions on the system.  All error messages from the JBoss servers logs are reported as incidents.

All alerts and clearing conditions from JBoss Operations network are reported via SNMP to TNG Unicenter.

Through the  use of JBoss Operations Network all machines, servers and resources in the platform are automatically added to the centralize monitoring system.

Deployit

image

Deployit is used for the automated deployment of applications onto the platform. It automatically deploys all the application components in a stack to the appropriate containers.  Deployit :

  • deploys static content and proxy configuration to the apache webservers,
  • deploys enterprise java application components to all individual JBoss servers in the farm,
  • executes SQL scripts to the database,
  • configures the F5 loadbalancers to add or remove servers or applications to the pool,
  • applies environment specific changes to the application configuration.

The deployment plan for a specific application is prepared in close cooperation between the application developer and platform management staff. When the deployment plan is finished, developers can deploy new versions of the application themselves, directly from a build tool or manually.This ensures solving any installation or configuration problem isn't postponed until the application is installed for production use, but rather is solved at the early stage of any development.

The same deployment plan is used for all environments. Authorization can be configured per enviroment and per application. LDAP is used to authorize software developers to deploy and configure an application for development and testing purposes, while integration specialist can deploy the application in production.

The use of Deployit provides the platform with a fully automated and standardized deployment mechanism, improving the speed of deployment of applications through the development, test and acceptance environments while reducing the number of staff involved and lowering the number of configuration errors.

F5 Load Balancer

image

The F5 Load balancers is used to support scalability and fail over for the JBoss Application Server farm.

The pools are configured to use a sticky session protocol based upon the JSESSIONID session cookie. If the cookie is not present, round-robin load balancing of the HTTP requests is performed.

Puppet adds the JBoss servers to the  pool in the F5 Load Balancer.

When a server is scheduled for a restart, the server is taken out of the pool. This ensures that this server does not get any new request, but will still be servicing existing sessions. When the session count in JBoss drops to zero, the server is restarted and restored to the pool.

The use of the F5 Load Balancer provides us with the ability to increase and decrease the number of servers in the farm, provide load balancing, fail over and graceful decommissioning of servers in the farm.

Layer7 XML Gateway / Identity Provider

image

The Layer7 SecureSpan Gateway is used as centralized security policy enforcement point and SAML identity provider.

Layer7 supports multiple authentication methods, Kerberos, digital certificates, username+password and is able to use multiple identity stores.

Puppet configures all JBoss application servers with SAML support and configures Layer7 as the identity provider: JBoss receives authentication (identity) and authorization (roles) information as a SAML-token. The information contained in the token is translated to a standard JEE-principal user (using a tiny layer of custom code), so all JEE applications can access the authentication and authorization information in a standard way.  Whether the JEE application is a web application or provides webservices, from a security there's no distinction. All application designers have to do is declare the application security roles conform the JEE standard.

The use of Layer7 standardizes the authentication and authorization for all business applications and centralizes access control.

Conclusion

The customer wanted a modern data center quality Java Application Platform to ensure that java applications could be deployed with lower cost and with high availability and easy scalability.

VMware, the dual data center, Layer7, the F5 Load balancer and JBoss provide the infrastructure for a  high availability and scalability for any java application. The combination of VMware, Puppet and Deployit are the fabric to enable continuous delivery of enterprise java applications.

Through virtualization and automated provisioning and deployment it has become possible to add a completely new, correctly configured machine to a cluster in a matter of minutes, completely secure and under full monitoring.

Comments (5)

  1. MOUILLE - Reply

    January 16, 2012 at 9:57 am

    Hello,

    Can you detail the architecture upstream and downstream of the Apache Web Server?
    How do you ensure high availability and scalability of Web server?
    Do you use Apache "mod_cluster" or the F5?
    Do you have a Web server for each server EAP?

    Best Regards.
    Mr MOUILLE

    • Mark van Holsteijn - Reply

      January 16, 2012 at 11:29 am

      We use the F5 Load balancer directly communicating to the JBoss servers using HTTP. The F5 Load Balancer setup provides high availability and scalability across the data centers.

      The Apache Web Server acted as our http reverse proxy, before the F5 Load balance was in place. We used a Apache WebServer farm with mod_ajp, but this required a hardware load balancer in front of the Apache Webservers to deal with single server outages.

  2. [...] This is a syndicated post. Read the original at Xebia Blog 2011-12-14. [...]

  3. Chris - Reply

    February 1, 2012 at 2:15 am

    Mark – great post. Can you elaborate on why you’re not deploying your apps using Puppet? Why use another product? We’re currently looking at app deployment tools from XebiaLabs, Nolio and UC4, but using Puppet for the app layer seems to be a viable alternative.

    - Chris.

    Editor's note: comment copied from here.

    • Mark van Holsteijn - Reply

      February 6, 2012 at 10:53 pm

      Chris,

      We are using Puppet for automated provisioning of the operating system and all the middleware system software. We use Deployit so that we can provide self-service deployments to the software development teams: This means that we provide the infrastructure for the different environments (development, test, acceptance, production), while giving the development teams the freedom to deploy their system(s) any time they want as often as they want. The integration with hudson and maven also allows them to deploy to create fully automated build and deployment processes (continuous integration/delivery).

      So why not everything with Puppet? Our applications can be deployed across multiple layers and machines, so we needed to order the actions for the deployment. Puppet plans have a declarative nature, that does not work well with the order we need in a deployment process. Furthermore, the deployment processes of applications have more diversity and change more often than the provision of the operating system and systems software. Giving access to the puppet plans to the development teams meant that they would have full control over the operating system aswell as Puppet always run as root. Deployit's security subsystem we still retain control over the configuration of the operation system.

      If you have any other questions, please do not hesitate the contact me.

      Cheers,

      Mark

Add a Comment