Open jvsoest opened 1 year ago
Alternative technologies to consider: Podman, Singularity
Refactoring milestones:
There are multiple factors to consider to decide which one would be included first. One of these could be the existing Python libraries/clients for each technology API : https://pypi.org/project/podman-py/ , https://singularityhub.github.io/singularity-cli/
Another factor would be in which image-registry environments the images of these technologies could be managed, and their support to features like Notary or Cosign. For instance, as far I understand Harbor does't support podman images,
Good stuff! Just to add: I expect a large part of what is now the DockerManager
can be generalized into a ContainerManager
from which classes like DockerManager
and PodmanManager
would inherit, as all of these container technologies are based on containerd.
Hi all,
Based on the recent discussions around this feature, I'd to start this follow-up message by proposing to make it more precise (as two interrelated features), as follows:
In the past few weeks, I have been exploring alternatives for implementing these features, as a baseline for the discussion (your comments about them are appreciated!). I did this by (1) going through the containerized elements of vantage6 architecture (to understand them better), and (2) conducting experiments on multiple containerization platforms SDKs -along with Kubernetes- to see to what extent the containerization technology and format could be decoupled from the v6-node core.
To illustrate these alternatives, it is important to describe first how containers currently work on a vantage6 node (please let me know if I got something wrong). The left image illustrates a v6-node deployed directly on the server which, when needed, would run containerized algorithms through the docker daemon. These algorithms will eventually need to exchange data or perform requests to the v6-server through a 'proxy' http server (a server integrated on the node that encrypts and forward requests to the real one). In this configuration, the communication between the algorithm and the proxy is possible as a docker container has access to the host network by default.
On the configuration at the right -the one suggested in the v6 documentation-, the v6-node runs within a docker container. In this configuration data exchange between the algorithm and the proxy is also possible by linking both v6-node container and the algorithm container to the same virtual docker network.
The Container Runtime Interface (CRI) enables Kubernetes to handle a wide variety of container runtimes. Based on this, the v6-node architecture could be adapted as a single-node K8S architecture by:
This is an alternative for setting up v6-node on an HPC infrastructure where a conventional Kubernetes cluster is already in place. This could be done if the node architecture is redesigned as proposed in No. 3.
Hi @hcadavid, nice work! It's good to have this overview on paper with clarifying graphics. I think we should discuss this soon.
I have a few questions and comments:
Do you have any thoughts on how easy it would be to install each of the options locally in the node organizations? Do they have simple installation processes? What are IT/legal staff in institutions/hospitals are familiar with and likely to accept? In our experience it is very important that the local installation of the nodes should be as easy as possible for vantage6 to be a success. Also, updating the nodes should be easy.
Do you think flexibility to switch between alternatives would be feasible? I.e. if someone doesn’t want to install k8s they can go for podman. I guess this isn't easy but can you think of implementations that make this relatively easy?
In the intro you discuss the node running directly on the host as well as in a docker container. In practice we only run it dockerized nowadays.
Thank you @hcadavid for this research. Nice work indeed. I think @bartvanb raised some important questions for us. First of all I am most enthusiastic about the Kubernetes solution as it has a lot of pros:
DockerManager
to handle multiple container runtimesHowever the mayor downside is that Kubernetes becomes a dependency. This might not be ideal. However:
The alternative -as Bart suggest- is to support both cases. Which is less ideal but the only option if k8s requirement poses bigger problems than the Docker requirements.
I do have some open questions regarding the features of vantage6:
I think @bartvanb and I will investigate a bit if we can overcome the Kubernetes requirements.
As this is default for RHEL and some hospitals.
Links to #6