EBcb seeks to standardize the construction of scientific software by encapsulating EasyBuild.
EBcb is a containerized build platform that utilizes EasyBuild for testing and constructing EasyConfigs. EBcb governs the build environment, while EasyBuild’s EasyConfigs dictate the build requirements of the scientific software.
EasyBuild employs toolchains, which are collections of build tools and libraries. EBcb containers are equipped with EasyBuild software. EBcb instances construct software without utilizing any native OS build tools. It is straightforward to construct the EBcb container, ensuring the use of the latest version of EasyBuild.
EBcb provides a cleanroom approach for software installation. The process of building software can contaminate the build environment by incorporating additional packages and leaving artifacts in the OS environment. EBcb at the Fred Hutch has provided a consistent, repeatable environment for constructing EasyConfigs by combining an EasyConfige with a tagged container.
fredhutch/ls2:eb-4.0.3-foss-2019b cfdd57f673ef
fredhutch/ls2:eb-4.5.4-foss-2020b d49b971f15bb
fredhutch/ls2:eb-4.6.0-foss-2021b 51fa37926564
Utilize the script build_EBcb.sh to generate an EBcb Docker container. The environment variables, EB_VER, LMOD_VER, EBUSER_UID, and EBUSER_GID, are employed to customize EBcb and tag the container. The EBcb runtime environment utilizes the account eb_user to execute EasyBuild. Map the software repository owner of your site to the account eb_user using the environment variables: EBUSER_UID and EBUSER_GID.
Create a local .env file to store the environment variables.
EBUSER_UID=65535
EBUSER_GID=6535
EB_VER=5.4.2
LMOD_VER=9.4.4
Utilize the script startEBcb “container name” to commence an instance of EBcb. Environment variables are utilized by startEBcb to select and execute an EBcb container.
The script startEBcb.sh employs container name to designate the image name.
Five bind mounts are required with EBcb.
- /app/software - Should be mapped to your target application directory.
ssoftwareis specific to an operating system and hardware architecture. - /app/modules
- /app/lmod
- /app/build - Bind to local SSD storage on Docker host
- /app/sources - Map to your software source repository of tarballs, shared by all OS and hardware architectures.
The EBcb container has a local volume named /eb. The /eb directory contains the subdirectories software, modules, and lmod. The /app/software/EasyBuild directory is the location of the local EasyBuild installation. The /eb directory is configured to be the first in the module search path.
ml avail EasyBuild
——————————————————————————— /eb/modules/all ———————————————————————————
EasyBuild/5.4.2 (L,D)
——————————————————————————— /app/modules/all ———————————————————————————
EasyBuild/4.9.4 EasyBuild/5.1.0 EasyBuild/5.2.0 EasyBuild/5.3.1
EasyBuild/5.0.0 EasyBuild/5.1.1 EasyBuild/5.2.1 EasyBuild/5.4.0
When the containers start, your username will be eb_user, which is mapped to the UID of the owner of your environment’s software. You will also be dropped into the /app/build directory, and the EasyBuild module will be loaded. You are now ready to type eb commands and start building software interactively.
The eb_user prompt displays [Mode, OS Name, Arch] as an example: [Prod noble-Zen4 build]. This indicates that you are building for Ubuntu Noble 24.02 on the Zen4 architecture in production mode.
The mode determines the environment and configuration for building software.
The eb_user can switch between Prod and Test environments.
The Prod mode is the default. eb build commands will write software and modules into the mapped /app production volume.
The Test mode is used for testing an EasyConfig. In test mode, installpath-software is set to /eb/software, and it will not write to the production volume. When your EasyConfig is ready to deploy, switch to the Prod mode.
A few pieces of software need to see the GPU to build software. startDBcb will query if a GPU is needed. If so the container will be run with docker run --gpus=1. The build host needs to have these additional Nvidia packages installed. Very your instance of EBcb has access to a GPU with nvidia-smi from the container.
- nvidia-container-toolkit
- nvidia-container-toolkit-base
Sometimes, you may need to manually seed source files for the Docker build stage one. Source files from the sources directory within the EBcb repository are copied to /build/sources, making the sources available to EasyBuild during container build time.
Note that the container has Lmod installed in /eb/lmod. Version parity is essential, so you will always want to keep your /app Lmod in sync with the EBcb Lmod. The LMOD_VER environment variable controls the version of LMOD at Docker Build time.
There are some software packages that depend on OS packages. The design of EBcb is to minimize exposure to OS packages, but they are sometimes necessary. Cuda expects to find an OS package for gcc. When additional packages are required, install manually as root after the container is started, before logging in as the eb_user.
-
EasyBuild is using
readelfto do sanity checks, which is part of binutils. Adding binutils would pull in a lot of OS packages to our clean room. When a package fails due to missingreadelf, just do the following. binutils is part of EasyBuild is built for every toolchain. Sometimes strip or as are used directly in software Makefiles. Again when an error occurs that they are missing, fix withcpcommand and not by adding binutils.sudo cp /app/software/binutils/[using GCCcore that matches the software]/bin/readelf /bin -
msodbcsql17 and unixodbc-dev modules are required to install the odbc driver in R