Skip to content

Commit 9eff972

Browse files
committed
Add blog post
1 parent 169d379 commit 9eff972

File tree

1 file changed

+183
-0
lines changed

1 file changed

+183
-0
lines changed
Lines changed: 183 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,183 @@
1+
---
2+
date: 2024-10-12
3+
title: Validated Patterns in a disconnected Network
4+
summary: Install a Validated Pattern on a disconnected network
5+
author: Michele Baldessari
6+
blog_tags:
7+
- patterns
8+
- how-to
9+
---
10+
:toc:
11+
12+
== Preamble
13+
14+
This document provides a comprehensive guide on how to deploy a Validated
15+
Pattern, specifically the Multicloud GitOps solution on OpenShift 4.16, onto an
16+
OpenShift cluster that has been set up in a disconnected network environment. A
17+
disconnected network, in this context, refers to an infrastructure that is
18+
isolated from external internet access, which adds additional complexity to the
19+
deployment process.
20+
21+
By following this guide, you will learn the necessary steps, best practices,
22+
and specific configurations required to successfully deploy Multicloud GitOps
23+
in such an environment. We will cover the prerequisite setup, key components
24+
involved, and how to manage the constraints posed by the lack of direct
25+
connectivity to external repositories and services. This ensures that even in a
26+
restricted, air-gapped network, the deployment of this validated pattern can be
27+
performed smoothly and securely.
28+
29+
30+
== Requirements
31+
32+
* One or more openshift clusters deployed in a disconnected network
33+
* An OCI-compliant registry that is accessible from the disconnected network
34+
(referred to as `registry.internal.disconnected.net` in this article)
35+
* A Git Repository that is accessible from the disconnected network
36+
* (Optional) A VM in the disconnected network where we run our commands
37+
38+
We won’t cover here how to deploy openshift in a disconnected network, as there
39+
is more detailed documentation that can be found
40+
https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/disconnected_environments/index#about-installing-oc-mirror-v2[here]
41+
42+
== Mirroring
43+
44+
The first step needed to deploy a pattern is mirroring all the needed images.
45+
In most cases this is a very pattern-dependent process, so the exact list of
46+
needed images will depend on the pattern, on the openshift version and on the
47+
needed operators.
48+
49+
In this example we use the tool `oc mirror --v2` (note: it is currently in tech
50+
preview, but the experience is superior compared to the previous release). Here
51+
is an example of such a configuration file `imageset-config.yaml`:
52+
53+
[source,yaml]
54+
----
55+
kind: ImageSetConfiguration
56+
apiVersion: mirror.openshift.io/v2alpha1
57+
mirror:
58+
platform:
59+
graph: true
60+
channels:
61+
- name: stable-4.16
62+
type: ocp
63+
operators:
64+
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.16
65+
packages:
66+
- name: lvms-operator
67+
- name: advanced-cluster-management
68+
channels:
69+
- name: release-2.11
70+
- name: multicluster-engine
71+
channels:
72+
- name: stable-2.6
73+
- name: openshift-gitops-operator
74+
channels:
75+
- name: gitops-1.13
76+
- catalog: registry.redhat.io/redhat/community-operator-index:v4.16
77+
packages:
78+
- name: patterns-operator
79+
additionalImages:
80+
- name: registry.redhat.io/ubi9/ubi-minimal:latest
81+
- name: registry.connect.redhat.com/hashicorp/vault:1.17.6-ubi
82+
- name: registry.access.redhat.com/ubi8/httpd-24:1-226
83+
- name: ghcr.io/external-secrets/external-secrets:v0.10.2-ubi
84+
- name: registry.redhat.io/ansible-automation-platform-24/ee-supported-rhel9:latest
85+
# VP charts
86+
- name: quay.io/hybridcloudpatterns/acm:0.1.3
87+
- name: quay.io/hybridcloudpatterns/clustergroup:0.9.5
88+
- name: quay.io/hybridcloudpatterns/gitea:0.0.2
89+
- name: quay.io/hybridcloudpatterns/golang-external-secrets:0.1.3
90+
- name: quay.io/hybridcloudpatterns/hashicorp-vault:0.1.3
91+
- name: quay.io/hybridcloudpatterns/utility-container:latest
92+
- name: quay.io/hybridcloudpatterns/imperative-container:v1
93+
- name: quay.io/hybridcloudpatterns/pattern-install:0.0.3
94+
- name: docker.io/gitea/gitea:1.21.11-rootless
95+
----
96+
97+
We can use this `imageset-config.yaml` file to mirror the needed images on our
98+
registry. We assume we have a folder (`/var/cache/oc-mirror`) where the tool can
99+
locally cache the downloaded images before pushing them to the internal
100+
registry. We copied the imageset-config.yaml in that folder:
101+
102+
[source,sh]
103+
----
104+
oc mirror --config=/var/cache/oc-mirror/imageset-config.yaml \
105+
--workspace file:///var/cache/oc-mirror/workspace \
106+
docker://registry.internal.disconnected.net --v2
107+
----
108+
109+
Once this command completes the `registry.internal.disconnected` OCI registry
110+
will contain the mirrored images. The oc mirror command will generate a few
111+
yaml files that can be found under `/var/cache/oc-mirror/workspace/working-dir/cluster-resources`.
112+
113+
We need to apply them to our cluster:
114+
115+
[source,sh]
116+
----
117+
cd /var/cache/oc-mirror/workspace/working-dir/cluster-resources
118+
oc apply -f cs-community-operator-index-v4-16.yaml \
119+
cs-redhat-operator-index-v4-16.yaml idms-oc-mirror.yaml \
120+
itms-oc-mirror.yaml
121+
----
122+
123+
Once these are applied the cluster will be able to fetch the images from the
124+
internal disconnected registry.
125+
126+
== Git repository changes
127+
128+
Note that we assume here that the git folder you are working on has the
129+
`origin` remote pointing to the disconnected git server where you will be
130+
cloning the pattern from. To verify to which git server a remote is pointing to
131+
you can run the `git remote -v` command.
132+
133+
We will need to tweak a couple of things so that the pattern is aware of which
134+
catalog sources in openshift contain the different images. Those names were
135+
defined in the previous mirroring step in the yaml files under
136+
`/var/cache/oc-mirror/workspace/working-dir/cluster-resources`.
137+
138+
`values-global.yaml`:
139+
[source,yaml]
140+
----
141+
main:
142+
multiSourceConfig:
143+
enabled: true
144+
clusterGroupChartVersion: "0.9.*"
145+
helmRepoUrl: registry.internal.disconnected.net/hybridcloudpatterns
146+
patternsOperator:
147+
source: cs-community-operator-index-v4-16
148+
gitops:
149+
operatorSource: cs-redhat-operator-index-v4-16
150+
----
151+
152+
`values-hub.yaml`:
153+
[source,yaml]
154+
----
155+
acm:
156+
mce_operator:
157+
source: cs-redhat-operator-index-v4-16
158+
159+
clusterGroup:
160+
subscriptions:
161+
acm:
162+
name: advanced-cluster-management
163+
namespace: open-cluster-management
164+
channel: release-2.11
165+
source: cs-redhat-operator-index-v4-16
166+
----
167+
168+
== Deploy the pattern
169+
170+
At this point we can clone Multicloud Gitops on to a VM that lives in the
171+
disconnected network and deploy the pattern. The only thing we need to do first
172+
is to point the installation script to the mirrored helm chart inside the
173+
disconnected registry.
174+
175+
[source,sh]
176+
----
177+
# Points to the mirrored VP install chart
178+
export PATTERN_DISCONNECTED_HOME=registry.internal.disconnected.net/hybridcloudpatterns
179+
./pattern.sh make install
180+
----
181+
182+
After a while the cluster will converge to its desired final state and the
183+
MultiCloud Gitops pattern will be installed successfully.

0 commit comments

Comments
 (0)