oc-mirror assists with lifecycle management of mirror registries that support OpenShift environments by performing differential update operations and synchronizations.
- Differential Synchronization of OpenShift Release Images
- Differential Synchronization of Operator images
- Synchronization of OpenShift cincinnati graph data image
- Synchronization of OpenShift Release images by version or channel latest
- Synchronization of Operator Images by full catalog and full catalog at latest (HEAD) operator versions. Also, allows for synchronization of individual operators by version to each channels' HEAD.
- Synchronization of helm charts
- Synchronization of additional images
- Remote state backends
- Base image filtering (planned)
- (multi) Cluster resource management
- Registry maintenance with image pruning
- Deterministic - Each application phase’s results are the same regardless of where the application is executed from within each phase’s environment. This allows for oc-mirror to underpin a website, run in CI, reconcile as an operator, or run from the CLI as a standalone binary or as an oc plugin.
- Stateful - Differential operations require tracking downloaded versions and calculating upgrade paths based on previous application runs. State must persist between execution environments.
- One-way synchronization - Some internet-disconnected environments are considered confidential and cannot tolerate data spillage from the disconnected environment to any internet connected networks. oc-mirror only synchronizes differential state from internet-connected environments to internet-disconnected environments. oc-mirror assumes that no data can traverse from an internet-disconnected environment to an internet-connected environment at any time.
- User Workloads - oc-mirror synchronizes helm charts and arbitrary images to streamline the importation of user workloads into their OpenShift deployments.
- Internet Connected Experience - Operator Lifecycle Manager, OpenShift Update Service, Advanced Cluster Management, and oc-mirror; in concert, can facilitate user experience parity with that of internet-connected environments. This ux is achieved by updating cluster resources during the publishing phase of oc-mirror (planned).
- Artifact Size - oc-mirror attempts to reduce the size of artifacts passed from the internet-connected environment to the internet-disconnected environment. These efficiencies are addressed at two levels: Differential version updates and Differential image layer updates. These artifacts can be further subdivided into user-defined file sizes. During each phase of operation, every effort has been made to reduce duplication of content on disk while contents traverse between image registries and imagesets. Due to image validation requirements, network utilization remains the most inefficient aspect of oc-mirror.
- Wide Applicability - oc-mirror provides a means to synchronize container image content for limited connectivity deployments of containerized edge, IoT, and AI/ML offerings.
- Metadata - Complete record of all content synchronization
- UUID - Ensures synchronized content integrity
- Sequence - Ensures differential content integrity
- Workspace - Environment used to create and publish content
- Backends - Location of metadata
- Imageset - Medium for transferring content and metadata between environments.
oc-mirror has two main phases of operation:
- Create
- Publish
And two modes of operation:
- Full
- Diff
During the “create full” phase, the following operations are performed:
- Read declarative configuration file
- Create new workspace
- Generate new UUID
- Assign sequence number 1
- Download/Archive content
- Write metadata to imageset
- Write metadata to backend
During the “publish full” phase:
- Metadata is read from imageset
- UUID/Sequence number checking with backend metadata
- Upload content to mirror
- Output k8s manifests
- Optionally update (multi) cluster ICSPs / Catalog Source / OpenShift Update service
- Update backend metadata
During the “create diff” phase for differential updates:
- Read declarative configuration file
- Check UUID of workspace
- Assign sequence number n+1
- Differentially download / archive content (download diff and throw away previously synchronized image layers)
- Write metadata to imageset
- Write metadata to backend
During the “publish diff” phase for differential updates:
- Metadata is read from imageset
- UUID/Sequence number checking with backend metadata (must be next in sequence)
- Merge differential operator upgrade graph into the existing catalog index image
- Upload content to mirror (reconstitute images from new layers and previously uploaded layers)
- Output cluster ICSPs / Catalog Source / Cincinnati
- Optionally update (multi) cluster ICSPs / Catalog Source / Cincinnati
- Update backend metadata
The imageset configuration is intended to reflect the current state of the registry mirroring. Any content types or images that are added to the
configuration will be added to the mirror and this is also applies to content types that are removed from the imageset configuration. Image pruning is done on a best-effort basis. oc-mirror will attempt image deletion and if a registry does not allow for this type of request,oc-mirror will return an error. the --continue-on-error flag can be used if desired to ignore pruning errors if the registry does not allow DELETE operations. If you are using the heads-only workflow option, oc-mirror will store starting versions from the initial run in the metadata and using this to maintain ranges.
More information on the oc-mirror imageset configuration can be found here.
More information on oc-mirror workflows can be found here.