text:
urn:lsid:ibm.com:blogs:entries-203cd156-7537-4b84-9c9d-77278729c8c1 A view from the clouds: Cloud computing for developers - Tags - configuration A view from the clouds: Cloud computing for developers 0 30 2 2013-12-06T05:09:12-05:00 IBM Connections - Blogs urn:lsid:ibm.com:blogs:entry-66b129d1-8845-45e0-afcd-4d0fb51e779c Choosing the right tool for the job DKA 0600026VJ2 active false Comment Entries Likes true 2011-05-18T15:22:37-04:00 2011-05-18T15:22:37-04:00

  WebSphere configuration management practices are common items of conversation that comes up when I am talking with users about IBM Workload Deployer (formerly WebSphere CloudBurst). This conversation can take on so many different avenues that it is hard to capture all of them in a short blog post. So, for the sake of this post, let's consider two facets of WebSphere configuration management. The first facet is addressing the need to consistently arrive at the same configuration across multiple deployments of a given WebSphere environment. The second facet involves managing the configuration of a deployed environment over time to protect against living drift. What is the best way to tackle these two challenges? Well, it comes down to picking the right tool for the job.

  When it comes to ensuring consistency of initial WebSphere configuration from deployment to deployment, there is really no better means than patterns-based deployments enabled by IBM Workload Deployer. Whether you are using a virtual system or virtual application pattern, the bottom line is that you are representing your middleware application environments as a single, directly deployable unit. When you need to stand that environment up, you simply deploy the pattern. The deployment encapsulates the installation, configuration, and integration of the environment, and your applications if you so choose. The benefit of this approach is that once you get your pattern nailed down, you can be extremely confident that the initial configuration of your environments is extremely consistent from deploy to deploy. Basically, no more bad deployments because someone forgot to run configuration step 33 out of 100!

  Because we talk about the benefits of consistency provided by our IBM Workload Deployer patterns, users often ask what IBM Workload Deployer does in terms of configuration governance for deployed environments. In other words, they ask how IBM Workload Deployer helps them to track configuration changes or compare the configuration of a deployed environment to a known good one. The honest answer is that this is a bit beyond the functional domain of the appliance. While IBM Workload Deployer does allow you to manage the deployed environment (apply fixes, update deployed applications, snapshot, etc.), it does not layer some of the common configuration governance concerns on top of that. However, there is a good reason why the appliance does not focus on that. It's because Rational Automation Framework for WebSphere does!

  If you find yourself wanting to actively track configuration changes, periodically (and automatically at specified intervals) compare configuration changes to a 'golden' baseline, import configurations of a known good environment, apply common configuration across a number of cells, then the capabilities of RAFW would likely be of interest to you. It can do all this and give you an incredible toolbox of out-of-the-box application deployment and configuration capabilities for WebSphere environments. In my mind, for those that spend a good deal of time dealing with WebSphere configuration, whether it be deploying applications, configuring containers, or debugging inadvertent changes, an examination of RAFW functionality is a must.

  Now it is time for a bit of disclaimer/clarification. I am not suggesting that you pick one or the other when it comes to IBM Workload Deployer and RAFW. In fact, there are many scenarios where 1+1=3 with these two solutions, and I have written about it many, many times (including this article). That said, I think it is important to highlight the relative strengths of each product, so that it is easier to map it back to your pain points. In honesty, many of the users I talk with have challenges in getting the initial configuration right AND managing it over time. That kind of problem beckons for the integrated IBM Workload Deployer/RAFW solution.

  Of course, technology only gets you so far when it comes to these kinds of problems. It would be disingenuous of me to suggest otherwise. It has always been and will continue to be important to establish clear and rigorous processes around the way you deploy, manage, and change environments. This just gives you an idea of some of the tools you can leverage to aid in the implementation of those processes.

  -- Dustin Amrhein

 WebSphere configuration management practices are common items of conversation that comes up when I am talking with users about IBM Workload Deployer (formerly WebSphere CloudBurst). This conversation can take on so many different avenues that it is hard to... 0 0 4165 urn:lsid:ibm.com:blogs:entries-203cd156-7537-4b84-9c9d-77278729c8c1 A view from the clouds: Cloud computing for developers 2013-12-06T05:09:12-05:00 urn:lsid:ibm.com:blogs:entry-d8110f28-a806-45bb-88e8-83ffc66385c7 Deploy-time variable resolution DKA 0600026VJ2 active false Comment Entries Likes true 2010-08-25T17:36:22-04:00 2010-08-25T17:36:22-04:00

  A while back, I talked about the new multi-image pattern capability introduced in WebSphere CloudBurst 2.0. This capability allows you to build patterns that include more than one product, or more than one version of the same product.

  The kind of pattern that is top of mind for me here, and the one I referenced in the previous post, is one that includes both WebSphere Application Server and DB2 components. In this regard, you can deploy the configured application and data containers as a single pattern deployment.

  In the pattern above, I include the WebSphere Application Server and DB2 components, along with configuration to create a data source and database. This makes setting all of this up completely automated and much simpler than traditional means. However, if you know something about configuring data sources in WebSphere Application Server, and you know a little bit about the deployment process for WebSphere CloudBurst, this may leave you scratching your head a bit!

  What do I mean? Well, when you configure a data source in WebSphere Application Server, you need to know the hostname for your backend database. That shouldn't be an issue, right? After all, I can simply declare parameters for my Create DB2 Data Source script package (which I have), one of them being the hostname, and pass those in during the deployment of the pattern. The catch is, since I'm deploying DB2 as part of this pattern, I will not know the hostname to pass in when configuring the parts for deployment. This is because WebSphere CloudBurst automatically assigns a unique hostname to each part during the deployment process. So, how do you deal with these kinds of issues?

  The answer is simple. You use the deploy-time variable substitution capabilities present in WebSphere CloudBurst 2.0. Specifically, when I'm deploying the pattern, I can pass a special variable to the hostname parameter defined by the Create DB2 Data Source. Before invoking the script package to create the DB2 data source, WebSphere CloudBurst automatically resolves the variable to the actual value, thus passing the correct hostname to my script.

  As you can partially see above, I passed in the value ${DB2DatabaseServer.hostname}.${DB2DatabaseServer.domain} as the hostname to my script to create the data source. As a result, during deployment WebSphere CloudBurst determines the hostname and domain name assigned to the DB2 part. The appliance passes this value into my script, and thus the script can correctly create the data source in the WebSphere Application Server instance as shown below.

  For more information on this variable substitution mechansim, check out the Information Center.

  -- Dustin Amrhein

 A while back, I talked about the new multi-image pattern capability introduced in WebSphere CloudBurst 2.0. This capability allows you to build patterns that include more than one product, or more than one version of the same product. The kind of pattern... 0 0 5045 urn:lsid:ibm.com:blogs:entries-203cd156-7537-4b84-9c9d-77278729c8c1 A view from the clouds: Cloud computing for developers 2013-12-06T05:09:12-05:00