kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v2alpha1
mirror:
platform:
graph: true
channels:
- name: stable-4.16
type: ocp
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.16
packages:
- name: lvms-operator
- name: advanced-cluster-management
channels:
- name: release-2.11
- name: multicluster-engine
channels:
- name: stable-2.6
- name: openshift-gitops-operator
channels:
- name: gitops-1.13
- catalog: registry.redhat.io/redhat/community-operator-index:v4.16
packages:
- name: patterns-operator
additionalImages:
- name: registry.redhat.io/ubi9/ubi-minimal:latest
- name: registry.connect.redhat.com/hashicorp/vault:1.17.6-ubi
- name: registry.access.redhat.com/ubi8/httpd-24:1-226
- name: ghcr.io/external-secrets/external-secrets:v0.10.2-ubi
- name: registry.redhat.io/ansible-automation-platform-24/ee-supported-rhel9:latest
# VP charts
- name: quay.io/hybridcloudpatterns/acm:0.1.3
- name: quay.io/hybridcloudpatterns/clustergroup:0.9.5
- name: quay.io/hybridcloudpatterns/gitea:0.0.2
- name: quay.io/hybridcloudpatterns/golang-external-secrets:0.1.3
- name: quay.io/hybridcloudpatterns/hashicorp-vault:0.1.3
- name: quay.io/hybridcloudpatterns/utility-container:latest
- name: quay.io/hybridcloudpatterns/imperative-container:v1
- name: quay.io/hybridcloudpatterns/pattern-install:0.0.3
- name: docker.io/gitea/gitea:1.21.11-rootlessValidated Patterns in a disconnected Network
by Michele Baldessari
October 12, 2024
patterns
how-to
Preamble
This document provides a comprehensive guide on how to deploy a Validated Pattern, specifically the Multicloud GitOps solution on OpenShift 4.16, onto an OpenShift cluster that has been set up in a disconnected network environment. A disconnected network, in this context, refers to an infrastructure that is isolated from external internet access, which adds additional complexity to the deployment process.
By following this guide, you will learn the necessary steps, best practices, and specific configurations required to successfully deploy Multicloud GitOps in such an environment. We will cover the prerequisite setup, key components involved, and how to manage the constraints posed by the lack of direct connectivity to external repositories and services. This ensures that even in a restricted, air-gapped network, the deployment of this validated pattern can be performed smoothly and securely.
Requirements
One or more openshift clusters deployed in a disconnected network
An OCI-compliant registry that is accessible from the disconnected network (referred to as
registry.internal.disconnected.netin this article)A Git Repository that is accessible from the disconnected network
(Optional) A VM in the disconnected network where we run our commands
We won’t cover here how to deploy openshift in a disconnected network, as there is more detailed documentation that can be found here
Mirroring
The first step needed to deploy a pattern is mirroring all the needed images. In most cases this is a very pattern-dependent process, so the exact list of needed images will depend on the pattern, on the openshift version and on the needed operators.
In this example we use the tool oc mirror --v2 (note: it is currently in tech
preview, but the experience is superior compared to the previous release). Here
is an example of such a configuration file imageset-config.yaml:
We can use this imageset-config.yaml file to mirror the needed images on our
registry. We assume we have a folder (/var/cache/oc-mirror) where the tool can
locally cache the downloaded images before pushing them to the internal
registry. We copied the imageset-config.yaml in that folder:
oc mirror --config=/var/cache/oc-mirror/imageset-config.yaml \
--workspace file:///var/cache/oc-mirror/workspace \
docker://registry.internal.disconnected.net --v2Once this command completes the registry.internal.disconnected OCI registry
will contain the mirrored images. The oc mirror command will generate a few
yaml files that can be found under /var/cache/oc-mirror/workspace/working-dir/cluster-resources.
We need to apply them to our cluster:
cd /var/cache/oc-mirror/workspace/working-dir/cluster-resources
oc apply -f cs-community-operator-index-v4-16.yaml \
cs-redhat-operator-index-v4-16.yaml idms-oc-mirror.yaml \
itms-oc-mirror.yamlOnce these are applied the cluster will be able to fetch the images from the internal disconnected registry.
Git repository changes
Note that we assume here that the git folder you are working on has the
origin remote pointing to the disconnected git server where you will be
cloning the pattern from. To verify to which git server a remote is pointing to
you can run the git remote -v command.
We will need to tweak a couple of things so that the pattern is aware of which
catalog sources in openshift contain the different images. Those names were
defined in the previous mirroring step in the yaml files under
/var/cache/oc-mirror/workspace/working-dir/cluster-resources.
values-global.yaml:
main:
multiSourceConfig:
enabled: true
clusterGroupChartVersion: "0.9.*"
helmRepoUrl: registry.internal.disconnected.net/hybridcloudpatterns
patternsOperator:
source: cs-community-operator-index-v4-16
gitops:
operatorSource: cs-redhat-operator-index-v4-16values-hub.yaml:
acm:
mce_operator:
source: cs-redhat-operator-index-v4-16
clusterGroup:
subscriptions:
acm:
name: advanced-cluster-management
namespace: open-cluster-management
channel: release-2.11
source: cs-redhat-operator-index-v4-16Deploy the pattern
At this point we can clone Multicloud Gitops on to a VM that lives in the disconnected network and deploy the pattern. The only thing we need to do first is to point the installation script to the mirrored helm chart inside the disconnected registry.
# Points to the mirrored VP install chart
export PATTERN_DISCONNECTED_HOME=registry.internal.disconnected.net/hybridcloudpatterns
./pattern.sh make installAfter a while the cluster will converge to its desired final state and the MultiCloud Gitops pattern will be installed successfully.
