This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
We’ve talked already about server topology. By that we meant which servers go on which systems in your environment, how many do you have per application, per system, etc. But what does configuration topology mean? Well, to be honest I just made that term up (ok, maybe somebody else already made it up – I didn’t search). What I’m talking about here is how the configuration for your various servers are located in your file system.
In a smaller environment where you might just have one server per system (or in a containerized environment where your server configurations are all isolated from each other anyway) this isn’t at all interesting. But in a single large system where you might have a lot of servers sharing the same file system, you’ll need to make some decisions about how you want to organize things.
By default if you just go to the ‘bin’ directory of your Liberty runtime and use the ‘server create’ command to conjure up a starting server configuration for a new server, where does the configuration go? Well, right next to that ‘bin’ directory is a ‘usr’ directory that will contain a ‘servers’ directory. If you create ‘server1’ this way, you’ll end up with a ‘server1’ directory in that ‘servers’ directory. Right there next to the runtime that you’re probably going to be updating with maintenance.
Depending on how you are managing the mounted file systems in your zFS setup, that might complicate things for you. You probably want to keep the configuration separate from the runtime.
But…would every server on this system (or the sysplex in a shared zFS environment) really belong in the same directory structure? There are all sorts of considerations to ponder as you try to sort out how you want that to lay out.
And what about included files? If you’re going to use included configuration files to put common things (like datasource definitions) in one spot to be included by different servers, should those all be together? Or maybe kept near the configuration for the servers that use them? Or should they be separate and owned by the folks that manage the datasource? If they change the port you use to access DB2, should they fix the Liberty config or should it be the people that own the servers?
All this will get tangled up in how you define your process to create a new production server. You’re going to end up with some rules about how this gets done so things end up in the right places and file permissions all work out properly. That feels like something you’re going to want to have some sort of automation to help with.
We’ll spend the next several weeks looking at different aspects of this whole topic. Hopefully this rough overview has at least given you some things to think about.