I’m currently working on a huge project where I have to design a new platform to manage the traceability of products between raw materials and the consumer, complete path in a cross-country solution, between Europe and China. We chose to adopt Websphere as application server and I'd like to design it on Docker containers, over Ubuntu LTS, this is because the OS can follow us from X86 to zOS without problems. The problem is that when using Docker you can have a Standalone solution, or if you use the standard Docker Cluster (Swarm) you have many servers working together but they are stateless.

One of my ideas is to extend some features of Kubernet developing a new solution, that permit to deploy Docker Containers in a WebSphere Cluster Solution, with his full functionality.

I’m curious, how have others in this community have solved this problem? 

I assume that you talk about WAS Traditional and not about WebSphere Liberty.

For WAS Traditional there is a guide how to create a WAS ND cell in Docker, see

https://github.com/WASdev/ci.docker.websphere-traditional/tree/master/network-deployment

Maybe that helps you to set up a cell in Docker.

On the other hand you should really think about if you need a cell with a cluster or if a farm of  WAS Traditional standalone instances would fit as well. The latter would be a better fit for Docker as this would provide much more flexibility and would be loosely coupled.

Another possible solution is to use ICP - IBM Cloud Private. 

https://www.ibm.com/developerworks/community/blogs/fe25b4ef-ea6a-4d86-a629-6f87ccf4649e/entry/IBM_Cloud_Private_version_2_1_0_2_is_now_available_for_download?lang=en

I would recommend to use WebSphere Liberty Profile, containerize that and then orchestrate it using Kubernetes (Kubernetes provides a clustering functionality using services, deployments, replication controller, and pod elements).

If you want to stick with traditional WebSphere Application Server, stick with standalone - no cells, containerize it and then orchestrate it using Kubernetes.

The challenge with containerizing traditional WebSphere Application Server is when to run the configuration and deployment. Furthermore the hostname changes when a new container is instatiated (the IBM standard image deals with this, by running a changeHostname command on startup).

Liberty is much easier to handle, because all configuration is in a file, which can be easily replaced, e.g. by Kubernetes.

Technically you can put a  cell into containers, but... a cell is not a good fit to run in containers and is not recommended (see https://www.slideshare.net/davidcurrie/how-to-containerize-websphere-application-server-traditional-and-why-you-might-want-to). This is because members in a cell are tightly coupled to one another (remember the hostname change on new instantiations, difficult to handle).... and the container paradigm is to run single process in each container (so keep it small) and when you think of a node agent and a cluster member, those are already 2 processes - so no a great fit.

If you want to run a traditional WebSphere Application Server in a cell use a VM based approach (e.g. the Cloud Automation Manager that is provided by IBM).

Fully agree to Olivers recommendation. Clustering in a containerized environment is quite a challenge and imho is against the idea of lightweight containers.

I'd suggest to avoid clustering and design the application that it does not depend on a state but do the scaling via Kubernetes ( running in IBM Cloud private ).

Note that the ICP has a bundle with WAS Traditional included.

tWAS is meant to run on-prem in VM or BM even if you get it as part of ICP.  It is not meant to be installed in a Container... and yes, you will find documentation on how to Containerize it but this is "experimental". If you want to leverage the Container/k8s strategy, I strongly recommend to go with Liberty.

JF