Replies: 1 comment
-
|
I like having the two variants of the images (with and without services). To me, the main question here would be whether the AiiDAlab team can take the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
New aiida docker stack based on a slim image
Background and problems description
Thanks to the fantastic work of @csadorf, we have
aiidalab-docker-stackheld for four image variants:base– A minimal image that comes with AiiDA pre-installed and an AiiDA profile set up.base-with-services– Likebase, but AiiDA services (PostgreSQL and RabbitMQ) are installed on the container and automatically launched on startup.lab– Likebase, but uses the AiiDAlab home app as the primary interface (the standard JupyterLab interface is also available).full-stack– Our most comprehensive image, likelab, but also comes with services pre-installed and launched.With this new way of maintaining aiida/aiidalab images, the
aiida-prerequisitesis not used anymore. We need to find a way to elegantly replace the old approach and make the new approach more automatic and easy to maintain.System user name can not be changed
A knew issue from using jupyter/minimal-notebook as the base image, the system user name default set to
jovyanand can only be changed by running container asroot. If the container starts as arootuser, it is hard to set start-up scripts to configure AiiDA for the system user of the container. Meanwhile, login to the container will end up with root user will bringing the complexity for vscode attach container setup.Not able to keep the latest aiida-core version
When the new
aiida-coreversion is released or the new fixes merge tomain, users may want to immediately use the image with newly added features. Now, it has to wait untilaiidalab-docker-stackbump the version of aiida-core, then builds and uploads the images.Confuse the organization name of docker hub
Although the docker hub namespaces
aiidateamandaiidalabare all managed by us, we still try to not confuse and mix up the images with these two different namespaces.Goals
Archive
aiidateam/aiida-prerequisitesand have all aiida only related docker image build files maintained inaiida-core.Two docker images,
aiidateam/baseandaiiidateam/base-with-servicesaiida-coreinstalled and can be started with rabbitmq & PostgreSQL services image by docker-compose.Images support both
linux/amd64andlinux/arm64, and include basic system tools:vim,git,conda/mambafor quick development environment buildup.The main purposes of these images included but were not limited to:
aiidalab-launchuser can quickly start a workable container with tools and aiida environment fully set up and start plugin or aiidalab app development immediately.Proposed enhancement
Using
mambaorg/micromambaas base imageActively maintained by the
mambateam (https://github.com/mamba-org/mamba#micromamba). Themambaorg/micromambaimage is a lightweight and fast image for fast building of small conda-based containers. It small but versatile image provides a flexible way to adjust the container as we want. The image supportslinux/amd64andlinux/arm64with running ubuntu as the base OS.The image allows running commands in
Dockerfilethrough root and system user under a specific conda environment by using a simple entrypoint script as the prefix. It makes configuring AiiDA environment as a system user running in a conda environment possible.I test this idea on aiidalab/aiidalab-docker-stack#319 and all works.
Move the
baseandbase-with-servicesstacks intoaiida-corerepoCreate docker files and build based on
mambaorg/micromamba, the images are built and upload toaiidateamdocker hub namespace. The docker files are maintained in theaiida-corerepository with github action used to build and upload the images.After having these images, the aiidalab docker stack can then build on them and reduce the duplication but focus on providing the jupyter tools.
Having self-hosted runner for arm64 CI test
GitHub does not provided free CI server for running CI workflows on architecture other than the
x86_64. But they allow users to easily build CI runner in a self-host way. Once there is a server running ARM64 architecture, the CI tests for build and test image can be run from the self-hosted runner.Beta Was this translation helpful? Give feedback.
All reactions