Pivotal is happy to announce that Oracle WebLogic Server applications can now be deployed to Cloud Foundry by downloading the new WebLogic Buildpack from Github.
Until now, users running Java applications requiring an application server typically relied on Apache Tomcat as the default container in the Cloud Foundry Java Buildpack. Tomcat is a great light-weight option for many Java web applications supporting the Servlet specification, but there are also many applications that use some Java EE features like EAR packaging, JMS, Data Sources, and other application server specific features that are not deployable on Tomcat. This WebLogic buildpack along with the recently announced JBoss buildpack, now enables new types of Java applications to run natively on Cloud Foundry.
Here is a short 3 minute video of the buildpack.
There is also a 20 minute video that goes into the details of the buildpack.
The easiest way to get started is with bosh-lite with v164+ versions of cf-release with the client_max_body_size configuration set to a minimum of 768MB and follow the README instructions. Pivotal CF 1.2 will have the large file support that is required to more easily use the WebLogic Buildpack. Additionally, there are two sample applications (WAR and EAR) with pre-built configurations bundled within the buildpack (under resources/wls) repository that should be good for a test drive against a local bosh-lite environment.
Features of the Buildpack
- During application staging the buildpack will download and install Oracle WebLogic and JDK binaries from a user-configured location.
- Configures a single server default WebLogic Domain. Configuration of the domain and subsystems would be determined by the configuration bundled with the application or the buildpack.
- JVM settings like memory, heap, gc logging can be configured on a per app basis without modifying the buildpack.
- JDBC Datasources and JMS services are supported with domain configuration options.
- WebLogic Server can be configured to run in limited footprint mode (no support for EJB, JMS, known as WLX mode) or in full mode.
- Standard domain configurations are supported and able to be overridden by the application or the buildpack.
- Scale the application as needed using ‘cf scale’. The number of WebLogic Server instances running an application can be scaled up or down using the ‘cf scale’ command without reconfiguring the domain.
- The Application can be a single WAR (Web Archive) or EAR (multiple war/jar modules bundled within one Enterprise Archive).
- Its possible to expose the WebLogic Admin Console as another application all within the context of the CF application endpoint (like testapps.xip.io)
- JDBC Datasources are dynamically created based on Cloud Foundry Service definitions bound to the application.
- Option to bundle patches, drivers, dependencies into the server classpath as needed.
- CF machinery will monitor and automatically take care of restarts as needed, rather than relying on WebLogic Node Manager.
- Its possible to bundle different configurations (like heap, or jdbc pool sizes, etc.) for various deployment environments and have complete control over the configuration that goes into the domain and or recreate the same domain every time.
- Integration with Cloud Foundry’s Loggregator, which brings a unified log stream from all application instances streamed back to clients like the “tail” function in *nix systems using ‘cf log’ CLI command.
- Supports Blue-Green deployments by using the ‘cf route’ option to switch the routing logic between deployments during upgrades or maintenance.
- The Java and WebLogic binaries should be made available for download from an accessible location by the buildpack.
- CF release version should be equal or greater than v158 to allow overriding the client_max_body_size for droplets (the default is 256MB which is too small for WebLogic droplets).
- Only HTTP inbound traffic is allowed. No inbound RMI communication is allowed. There cannot be any peer-to-peer communication between WebLogic Server instances.
- There is no support for multiple servers or clusters within the domain. An admin server would be running with the application(s) deployed to it. In-memory session replication or high-availability is not supported.
- Only stateless applications are supported. The server will start with a brand new image (on an entirely different VM possibly) on restarts and hence it cannot rely on state of previous runs. The file system is ephemeral and will be reset after a restart of the server instance. This means Transaction recovery is not supported after restarts. This also includes no support for messaging using persistent file stores. WebLogic LLR for saving transaction logs on database and JDBC JMS store options are both not possible as the identify of the server would be unique and different on each run.
- Changes made via the WebLogic Admin Console will not persist across restarts for the same reasons mentioned previously, domain customizations should be made at staging time using the buildpack configuration options.
- Server logs are transient and are not available across restarts on the container file system, however can have Cloud Foundry loggregator send logs to a syslog drain endpoint like Splunk.
- The buildpack does not handle security aspects (Authentication or Authorization). It only uses the embedded ldap server for creating and using the single WebLogic Admin user. Its possible to extend apply security policies by tweaking the domain creation.
- Only base WebLogic domains are currently supported. There is no support for other layered products like SOA Suite, WebCenter or IDM in the buildpack.
Please give the WebLogic Buildpack a try, and let us know your feedback by submitting an issue on the Github repository.
About the Author
BiographyMore Content by Sabha Parameswaran