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
-
New aiida docker stack based on a slim image
Background and problems description
Thanks to the fantastic work of @csadorf, we have
aiidalab-docker-stack
held 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-prerequisites
is 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
jovyan
and can only be changed by running container asroot
. If the container starts as aroot
user, 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-core
version 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-stack
bump the version of aiida-core, then builds and uploads the images.Confuse the organization name of docker hub
Although the docker hub namespaces
aiidateam
andaiidalab
are all managed by us, we still try to not confuse and mix up the images with these two different namespaces.Goals
Archive
aiidateam/aiida-prerequisites
and have all aiida only related docker image build files maintained inaiida-core
.Two docker images,
aiidateam/base
andaiiidateam/base-with-services
aiida-core
installed and can be started with rabbitmq & PostgreSQL services image by docker-compose.Images support both
linux/amd64
andlinux/arm64
, and include basic system tools:vim
,git
,conda
/mamba
for quick development environment buildup.The main purposes of these images included but were not limited to:
aiidalab-launch
user 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/micromamba
as base imageActively maintained by the
mamba
team (https://github.com/mamba-org/mamba#micromamba). Themambaorg/micromamba
image 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/amd64
andlinux/arm64
with running ubuntu as the base OS.The image allows running commands in
Dockerfile
through 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
base
andbase-with-services
stacks intoaiida-core
repoCreate docker files and build based on
mambaorg/micromamba
, the images are built and upload toaiidateam
docker hub namespace. The docker files are maintained in theaiida-core
repository 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