Containerize Bee?

[rstyd]

We're currently trying to decide whether or not we should containerize bee. This would put all of the BEE components, the GDB, nginx, redis, and any other elements we decide into a container which we would distribute to users.

We'll need to discuss the granularity of the image. Should there be one monolithic container for neo4j, nginx, redis, and BEE itself or should we have lean microcontainers for each piece?

I'll list some pros and cons. Feel free to add some.

Pros

• Eases packaging
  • If everything is in a container, users just need to download it, set it up, and they're good to go.
  • We wouldn't have to worry about pip and other python packaging issues which aren't great.
• Reproducible environment
  • We've run into a bunch of issues related to programming differences on different platforms and for individual developers.
  • Containerization will eliminate that issue.
• Limits juggling
  • Currently we're looking at using multiple containers to juggle all of the various components and external software we're using for BEE. One container would simplify this dramatically.

Cons

• How to distribute image?
  • We'll need to think about how to most efficiently distribute the image. Will it be a dockerfile users can build themselves or an image hosted on some repository.
  • Dockerhub has a limit on the number of pulls per hour which could be a problem for organizations like LANL.
• Updating pains
  • Updating BEE will (as far as I know) require redownloading the container. That's kind of onerous compared to a pip update and would be required for even small changes.
• Cross platform support
  • Will have to think carefully about how to provide cross platform support. We will need an image for each supported platform. We could provide a dockerfile so users can build an image themselves, but that still poses some issues as we ran into with power9.
• Container may be a bit unwieldy
  • Currently, we're looking at 3 different containers. One for neo4j, another for nginx, and another for redis. For this effort, we'd also need to include all of the BEE components into the image as well. The image would be around 350-450 mb by my estimation. Which isn't big, but also not necessarily something easy to just throw around to any resources want to run with BEE.

[pagrubel]

It does not have to be an all or nothing options why not distrubute BEE with pip and the container separate but have one container for all containerized dependencies. This way if we update BEE but the container doesn't change it's a simple update for the user.

[jtronge]

If we put everything in the container, how would BEE communicate with Slurm/LSF outside of the container? Would we need to bind-mount in specific binaries? I guess for slurm we could simply bind-in the socket location for slurmrestd, but this isn't possible for LSF as far as I know.