Summary
oss-crs and all of its associated modules currently require network access at every lifecycle step — prepare clones CRS repos from GitHub and pulls/builds Docker images, build-target builds target images and creates snapshots that install packages from PyPI and apt inside containers, and run builds infrastructure sidecars from Docker Hub base images. In an air-gapped environment where all images are pre-built on a networked machine and transferred as tar files, only build-target and run should need to execute — but the framework has method to assign locally hosted registries support at all.
This issue covers the changes needed to enable a pre-built image workflow: build online, export, transfer, load offline, then run build-target and run without any public internet access.
Envisioned Use Case
Deploy oss-crs in an air-gapped environment (e.g. competition environment with no internet, restricted corporate network, etc). CRS module images, infrastructure sidecar images, and LLM database images are built on a networked machine and transferred as tar files. The air-gapped machine loads these images and runs build-target (compiling the target project against offline base images) and run.
The tricky step is build-target: it must still compile the target project, which requires Docker base images to be available offline, and snapshot creation must not reach out to the network for package installs. We acknowledge it is a strict requirement that to use OSS-CRS application developers must be able to at least build their target application in the target offline environment and they must find their own methods to do so. The Git issue would cover for only simpler ways to export and import OSS-CRS and its modules' dependencies.
A high-level envisioned workflow is as follows:
- (Online) Run prepare but export full images, base images (libCRS, maybe libFuzzer at this stage, etc), other dependencies to run selected CRS module to location importable by Offline machine
- Transfer exported artifacts to Offline machine
- (Offline) Prepare step just references images and other dependencies
- (Offline) Build-target builds the target repository referencing needed base images and dependencies packaged in transferred importable locations
- (Offline) Run
Summary
oss-crs and all of its associated modules currently require network access at every lifecycle step — prepare clones CRS repos from GitHub and pulls/builds Docker images, build-target builds target images and creates snapshots that install packages from PyPI and apt inside containers, and run builds infrastructure sidecars from Docker Hub base images. In an air-gapped environment where all images are pre-built on a networked machine and transferred as tar files, only build-target and run should need to execute — but the framework has method to assign locally hosted registries support at all.
This issue covers the changes needed to enable a pre-built image workflow: build online, export, transfer, load offline, then run build-target and run without any public internet access.
Envisioned Use Case
Deploy oss-crs in an air-gapped environment (e.g. competition environment with no internet, restricted corporate network, etc). CRS module images, infrastructure sidecar images, and LLM database images are built on a networked machine and transferred as tar files. The air-gapped machine loads these images and runs build-target (compiling the target project against offline base images) and run.
The tricky step is build-target: it must still compile the target project, which requires Docker base images to be available offline, and snapshot creation must not reach out to the network for package installs. We acknowledge it is a strict requirement that to use OSS-CRS application developers must be able to at least build their target application in the target offline environment and they must find their own methods to do so. The Git issue would cover for only simpler ways to export and import OSS-CRS and its modules' dependencies.
A high-level envisioned workflow is as follows: