HUBzero middleware has been based on OpenVZ container technology for a decade. This provided very powerful control and customization options with light resource utilization, ahead of alternatives at the time. However, OpenVZ 6 will reach end of life in November 2019. The next version, OpenVZ 7, is substantially different than its predecessors. Architecturally, OpenVZ 7 is becoming its own Linux distribution with limited support for the previous container management with "simfs". Adapting the HUBzero middleware to simfs under OpenVZ 7 resulted in a loss of quota management. HUBzero tool development under OpenVZ, as well as testing the entire HUBzero software stack, has been problematic because it required people to install a different kernel than the one provided by their distribution; under OpenVZ 7, having to install a specific distribution would make the problem even worse. The HUBzero middleware also required that all tools use the same tool template, so upgrades to the tool template necessitated synchronized upgrades and retesting of all tools.
Meanwhile, Docker emerged as a popular choice for creating, sharing and deploying containers. Docker isn't tied to a specific Linux distribution, and is easier to install and use than OpenVZ. Having the entire HUBzero software stack, not just the middleware, redeployed as Docker containers would ease testing, development, adoption and deployment. However, there were several challenges to doing so. One is that by default Docker heavily manages the host firewall, conflicting with the management performed by the HUBzero middleware, which also interacts extensively with the host firewall. That Docker functionality is optional, but enabled by default and normally expected to be functional. We didn't want to disable the Docker firewall functionality, as that may be surprising and cause compatibility issues. The second challenge was trying to separate the X11 server and related services, from the tools themselves, which used to all be located in the same OpenVZ container. Doing so creates flexibility and makes sense as newer tools tend to emit HTML directly and do not require an X11 server. It also makes tool containers smaller and more easily shared and managed. The third challenge is an ongoing one, which is to evaluate the security implications of using Docker instead of OpenVZ and develop better assurances based on gathered experience and evidence.
