Unwrapping WebSphere CloudBurst script packages
I have written in this blog before about how using WebSphere CloudBurst, users can achieve fully customized WebSphere Application Server environments. Those customizations start at the operating system level by extending the shipped virtual images, modifying those images, and recapturing the custom image in the WebSphere CloudBurst catalog. On top of operating system level customizations are customizations made to the WebSphere Application Server middleware environment.
Customizations to the middleware environment are mainly achieved through what WebSphere CloudBurst calls script packages (click here for the script package section in the WebSphere CloudBurst Information Center). Very simply script packages are merely ZIP files that users uploaded into the WebSphere CloudBurst catalog and include in their custom WebSphere CloudBurst patterns as necessary.
The ZIP file that is stored in the catalog includes an executable script and optionally a set of artifacts used or needed by the script. In addition to uploading this ZIP file into the WebSphere CloudBurst catalog, users tell WebSphere CloudBurst how to invoke the script package and provide other information like environment variables that need to be present during script execution. WebSphere CloudBurst then uses this information to invoke the script packages upon completion of pattern deployment.
Script packages are very open-ended. As long as WebSphere CloudBurst can execute the script in the operating system environment, then it can be included in a pattern. So, users can create script packages that utilize the WebSphere Application Server wsadmin tool to install applications, set server trace settings, or otherwise alter the WebSphere Application Server configuration. Alternatively, users can supply operating system executables like shell scripts that otherwise configure the application environment. As long as a valid executable is supplied, then there are really no imposed limits on what a script package can do.
However, just because script packages can do just about anything doesn't mean they should! You can read this developerWorks article for a more complete discussion about WebSphere CloudBurst customizations and the use of script packages, but the bottom line is that script packages are best suited to deliver customizations that vary over application environments (like installing applications). For customizations that are needed in just about every application environment (required anti-virus software comes to mind), creating a custom virtual image is the way to go.
If you want to learn more about WebSphere CloudBurst script packages, I'd suggest you check out the WebSphere CloudBurst Information Center link and the developerWorks link above. As always, let us know if you have any questions by commenting here, sending us a tweet (@WebSphereClouds), or by sending an email to firstname.lastname@example.org.
-- Dustin Amrhein