Great webinar today… there seemed to be particular interest in talking about a OOD in a container, and so I thought I’d start a thread about that.
My 2 cents… while having OOD in a container would ease install in some ways, there’s always the issue of customization of containers. And… one strength of OOD is its ability to be customized for each install location – from things as simple as colors / logo to more complex customization like installed apps, job templates, etc. If OOD was containerized, these customizations would not only need to be externalized, but the customization options would have to be well documented, which I find is often failing in downloaded containers.
One option I’ve seen for this that worked well was that the container expected a specific external mapping for customization data and then had a GUI for customization that saved all customization settings to that external mapping. This worked well, but from a container design perspective, it usually means that you have to map many customization save points(/logs, /etc, application save points, …) to that external mapping.
Many of the components used in OOD are already available in containers, so it’s just a matter of setting up the communication path and orchestrating the deployment. You could for example set up each container to mount a particular directory to contain OOD setup and configuration criteria.
We have a container orchestration platform, so it would be easy to deploy multiple instances of a given OOD service, appropriatelu configured to share setup information, do to things like scale or set up HA for the web front end, allow sequential updating of separate service components, etc. Our platform is Mesosphere but you could do the same in many other containerized data center automation setups, even just Ansible scripts or, for example, Kubernetes!
Note that it mentions that at first run, there’s a GUI “wizard” to configure the install, and then a sys admin can choose which of the mount points to include to save that data to the host.
I built a similar Singularity container for ownCloud from scratch, but instead of separating the critical writable information into 5 mount points, I combined them into one using softlinks in the container to remap directories. So, instead of having to mount 5 different volumes, I mount just one.
It works slick… especially mounting the config directory locally. One can change config parameters on their host and have those changes reflected in the container instantly (assuming one doesn’t need to restart the service to reflect those changes). Saves the step of having to login to the container to change the config and has the added bonus that the config is persistent between container restarts instead of having to rebuild the entire container to “save” the config changes.
In my opinion, the biggest weakness of containers is that they are often designed for generic vanilla installs and in the HPC world especially, what install is really “vanilla”? For core services like OOD, I usually end up downloading the container recipe, adding all the stuff I need to add for my environment, and rebuilding the container almost from a base OS image. So, I feel the more settings and configuration parameters you can expose via writable mounts and environment variables, the more useful the container will be.
We do provide containers, but only for proof of concept and developmental purposes. They are not production ready. But I 100% agree that we should move in that direction.
I’m not quite sure of all the hurdles we’d have to overcome to get there but here are a couple that I have thought of.
UID mappings within the container
We’d likely have to run the container as root (actual root, uid 0 on the host) so that we could fork users’ processes’ and maintain the UID. Not to mention invoking the scheduler with the actual users’ UID.
Directory mounts, similar to UID mapping above, we’d want all the $HOME directories mounted and users (whatever their internal UIDs are) to be able to read and write to them as appropriate
Apps and components, as containers I think is an amazing idea, it’s just very different from what we do now architecturally. It could be done, but I can’t tell if it is a good idea or if I just drank the container cool-aid and can’t see how much work it would be vs what we gain. I imagine it would be extremely challenging to support both architectures flexibly. That said, I’d +1 it.