Container Base images

In order to meet the security recommendations and in specific aim to have zero critical vulnerabilities, SKAO provides build images for development and base images for applications.

The list of the images provided are shown below:

Note

The build image tools is a work in progress as the required tools are identified and support is expanded! The aim is to have one container that can be used as a build image for all SKAO software

  • ska-base: CIS hardened Ubuntu 22.04 base image

  • ska-build: DEPRECATED

  • ska-build-python: Ubuntu 22.04 based build image for Python applications with Python 3.10

  • ska-python: Ubuntu 22.04 based base image for Python applications with Python 3.10

  • ska-build-node: Ubuntu 22.04 based built and test image for Javascript applications with Node 22 and Cypress 14.2.0

  • ska-node: Ubuntu 22.04 based base image for Javascript applications with Node 22

  • ska-webserver: Ubuntu 22.04 based base image for serving static websites and proxying calls to backend APIs with Nginx 1.27.3 and Python 3.10

  • ska-cuda: NVIDIA provided Ubuntu 22.04 based base image for running CUDA applications with CUDA 12.14.x and Python 3.10.x.

  • ska-build-cuda: NVIDIA provided Ubuntu 22.04 based base image for building CUDA applications with CUDA 12.14.x and Python 3.10.x.

For easier traceability, security and management purposes, The following metadata are present in the images (in the file /etc/skao.metadata) and as labels: * int.skao.image.created: creation date: ISO 8601 format date and time the image was built * int.skao.image.version: image version * int.skao.image.tags * int.skao.image.team * int.skao.image.url: URL to find more information on the image, i.e. docs url * int.skao.image.source: source code url * int.skao.image.baseImage

Rationale

  • The build image is needed in order to automate the construction of an image both locally and in a Gitlab pipeline (using the cicd infrastructure) transparently. Without it, every time the image has to be built an new environment should be created. The image is advised to be used when building applications

  • In order to have a secure software supply chain, the base image must be well known and must include the security patches and every required upgrade. By giving to the SKAO developers a secure image, vulnerabilities would be only in the image they are working on since SKAO infrastructure would try to minimise many vulnerabilities from the start.

Example Dockerfile

Below it is possible to see an example of a Dockerfile which install a virtual environment with poetry in the build image and that copy it to the runtime using multi-stage builds.

FROM artefact.skao.int/ska-build-python:0.5.0 as build

WORKDIR /src

COPY pyproject.toml poetry.lock* ./

ENV POETRY_NO_INTERACTION=1
ENV POETRY_VIRTUALENVS_IN_PROJECT=1
ENV POETRY_VIRTUALENVS_CREATE=1

#no-root is required because in the build
#step we only want to install dependencies
#not the code under development
RUN poetry install --no-root

FROM artefact.skao.int/ska-python:0.1.2

WORKDIR /src

#Adding the virtualenv binaries
#to the PATH so there is no need
#to activate the venv
ENV VIRTUAL_ENV=/src/.venv
ENV PATH="$VIRTUAL_ENV/bin:$PATH"

COPY --from=build ${VIRTUAL_ENV} ${VIRTUAL_ENV}

COPY ./src/my_project ./my_project

#Add source code to the PYTHONPATH
#so python is able to find our package
#when we use it on imports
ENV PYTHONPATH=${PYTHONPATH}:/src/
 ...

Example Dockerfile (uv)

Repositories that have migrated to uv (see Poetry to UV(+ Ruff) Migration) should use the following pattern as standard. It installs uv in the build stage, resolves dependencies from the committed lockfile with uv sync, and copies the resulting virtual environment into the runtime image.

FROM artefact.skao.int/ska-build-python:0.5.0 AS requirements

WORKDIR /src

COPY uv.lock pyproject.toml ./

RUN uv sync --frozen --no-dev --no-install-project

FROM artefact.skao.int/ska-python:0.2.5

WORKDIR /src
ENV VIRTUAL_ENV=/src/.venv
ENV PATH="$VIRTUAL_ENV/bin:$PATH"

COPY --from=requirements ${VIRTUAL_ENV} ${VIRTUAL_ENV}
COPY ./src/my_project ./my_project

#Add source code to the PYTHONPATH
#so python is able to find our package
#when we use it on imports
ENV PYTHONPATH=${PYTHONPATH}:/src/
 ...

Key flags:

  • --frozen installs exactly what the lockfile says

  • --no-dev excludes development dependencies from runtime images

  • --no-install-project installs only dependencies when that matches the image design