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.
---------------
Last week we talked about the need to keep server configuration away from the actual runtime code for the server. That gets done by setting the WLP_USER_DIR environment variable to point to the directory where you want configurations kept for all the servers using that same value for that variable.
Well, that means that you could, if you want, have all your servers set that variable to point to the same directory and then all your server configurations for your various servers would be in one place. That might be really handy and easy to manage if you’ve only got a couple of servers. But if your environment is more complicated, and it probably is, then you might want to think about this a little bit.
It seems likely that you’d want to group servers together that have something in common. File permissions are going to play a role here. It would make things easier if you could grant access to all the servers in a common directory to the people that need to manage those servers. So you might want to group your server configurations together based on whatever organizational alignments you have. Servers managed by group A are together and servers managed by group B are in another directory. They could share a common root, if you like, but be different down a layer or two.
Of course, one group might manage servers that are for completely unrelated things and you might want to keep those separate. Remember also that each ‘user dir’ comes with a directory to put common configuration elements that can be easily used by all the servers in that group. So maybe the production servers are in one group and the test servers are in another, each including the same data source definition from their separate shared config directory. The production one points to the production database and the test one to the test database. The server configurations are the same and only the location of the configuration controls what database they access. That’s pretty cool, but it requires a little thinking ahead to make it work.
You do probably want to keep server configurations for different purposes (even within the same group) separate, mostly because of file permissions. Dev/Test/Prod servers have different access requirements and should probably be kept separate because access requirements are different.
And organization within your enterprise will matter too. Servers used by commercial banking probably have to be separate from servers for consumer banking. Maybe they are managed by different groups, or maybe not.
A lot of things to consider. Politics, of course, but also need to for different types of access, ease of configuration management, sharing of common configuration. You really need to consider not only what you currently need (the one server to run that phone directory application) but also what your environment might eventually look like. You don’t have to fully deploy a massive structure right away, but try not to box yourself into something that will be a pain down the road.
I know…if you could predict the future that well, you’d be placing stock market orders from your yacht in the Caribbean.