[SUGGESTION]: Use docker-compose for web application portion of nextPYP

[jpellman]

Hello again nextPYP Developers,

I just wanted to leave another quick suggestion for how nextPYP is set up. From an operational perspective, it would likely be a lot easier to deal with the web app portion of nextPYP if it were containerized using Docker instead of Singularity. My reasoning on this point is that Docker is much better suited for web applications due to its support for network namespacing and its ability to manipulate iptables rules. Singularity, in contrast, looks to be much more oriented towards batch computing and non-interactive applications.

Additionally, Docker has a deployment/testing mechanism (docker-compose) that is a bit more intuitive and reproducible when deploying web applications. docker-compose codifies port mappings, storage volumes, etc using a YAML file and allows you to reliably bring up an application without needing to deal with an installer script, systemd units or the underlying container runtime.

I've seen docker-compose used with some success in SmartScope and I believe that it would work well here too.

--John

[cuchaz]

Hi there. Thanks for the feedback! Sorry it took so long for us to get back to you, but for some reason, issue notifications weren't turned on for this repo, so we're just now seeing this issue.

We're somewhat familiar with Docker and some of the tools in that ecosystem. If I recall correctly, a veeeeery early prototype of nextPYP used Docker, but we learned very quickly that Docker doesn't work in many shared cluster environments due to security policy, so we switched to Apptainer (then Singularity) for the rest of our development.

From what I understand, SmartScope had the opposite problem. A requirement of running in a Windows environment meant that Apptainer wasn't a good option for them and Docker worked better for that case, mostly because Docker went to incredible lengths to bring a very Linux-only feature (kernel namespaces) to Windows by automating the creation and management of VMs.

So this is a long-winded way of saying that we could potentially support Docker deployments for the website component of our software, but it would be a totally independent effort from maintaining our existing Apptainer-based process, since we don't have the option of switching away from Apptainer entirely.

Is there something you'd like to do with the website component of nextPYP that isn't currently supported? We've tried to include a lot of configuration options in our config file system, but probably we didn't think of everything. Building and maintaining a completely separate Docker system is probably more work than we'd like to do at the moment, but more specific feature requests might be more easily handled by tweaking the existing system a bit.

[jpellman]

Hi @cuchaz ,

The motivation for this issue is that web app portion of nextpyp is a bit difficult and unwieldy to maintain from an operational perspective, primarily because apptainer is ill-suited to deploying web applications (because that's not its main use case). The combination of systemd + apptainer is a bit awkward, and also reduces the flexibility we have for deploying the web application. For instance, if the web app were more Docker-centric, it would take much less effort to convert a docker compose config file to a set of Kubernetes manifests or to deploy the web application using a managed cloud service like AWS Fargate or GCP Cloud Run.

The batch/computation portion of the application is fine as-is and almost certainly should stay as an apptainer container (a potential improvement would be to support another SLURM-supported container runtime like podman, enroot, udocker).

Also, on a more pedantic note (not really relevant), it is not true that namespacing is a Linux-only feature. Windows containers can make use of namespacing as well (see here if interested). Docker has done a particularly good job at making it so that Linux containers can run on top of Windows (which wouldn't normally be possible) using HyperV virtualization and I suspect that's the main advantage that the Smartscope folks were interested in.

[cuchaz]

Ah, yes. If you're trying to deploy the website component on a Kubernetes system or a cloud, that's a use case we definitely haven't designed for. That tech ecosystem isn't something we use ourselves, so we haven't done anything to make usage easier there.

And yes, I keep forgetting Windows eventually implemented something like namespaces too and they have their own support for native containers now. We don't use much Windows around here either, so my Windows knowledge is probably waaaay out of date. =)