Skip to content

Commit 903e5f6

Browse files
adellapeadellape
committed
Add OLM disconnected config
1 parent e80b025 commit 903e5f6

File tree

3 files changed

+319
-0
lines changed

3 files changed

+319
-0
lines changed

‎_topic_map.yml‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -511,6 +511,9 @@ Topics:
511511
- Name: Creating policy for Operator installations and upgrades
512512
File: olm-creating-policy
513513
Distros: openshift-origin,openshift-enterprise
514+
- Name: Configuring OLM in disconnected mode
515+
File: olm-disconnected
516+
Distros: openshift-origin,openshift-enterprise
514517
- Name: Application life cycle management
515518
Dir: application-life-cycle-management
516519
Topics:

‎applications/operators/olm-disconnected.adoc‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
[id="olm-disconnected"]
2+
= Using Operator Lifecycle Manager on disconnected clusters
3+
include::modules/common-attributes.adoc[]
4+
:context: olm-disconnected
5+
6+
toc::[]
7+
8+
When {product-title} is installed as a disconnected cluster, Operator Lifecycle
9+
Manager (OLM) can no longer use the default OperatorHub sources as they require
10+
Internet connectivity. Cluster administrators can disable those default sources
11+
and create local mirrors so that OLM can install and manage Operators from the
12+
local sources instead.
13+
14+
////
15+
.Additional resources
16+
17+
* Link to section about disconnected cluster installations.
18+
////
19+
20+
include::modules/olm-disconnected-operatorhub-disconnected-mode.adoc[leveloffset=+1]
21+
.Additional resources
22+
23+
* For details on exposing your {product-title} cluster's internal registry to
24+
off-cluster access, see
25+
xref:../../registry/securing-exposing-registry.adoc#securing-exposing-registry[Exposing the registry].
26+
* For details on accessing the internal registry, see
27+
xref:../../registry/accessing-the-registry.adoc#accessing-the-registry[Accessing the registry].

‎modules/olm-disconnected-operatorhub-disconnected-mode.adoc‎

Lines changed: 289 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,289 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * applications/operators/olm-disconnected.adoc
4+
5+
[id="olm-disconnected-operatohub-disconnected-mode_{context}"]
6+
= Configuring OperatorHub in disconnected mode
7+
8+
Cluster administrators can configure OLM and OperatorHub to use local content in
9+
a disconnected mode.
10+
11+
.Prerequisites
12+
13+
* Cluster administrator access to a connected or disconnected {product-title} cluster and its internal registry.
14+
* Separate workstation with full Internet access.
15+
* If pushing images to the {product-title} cluster's internal registry, the registry must be exposed with a route.
16+
* `podman` version 1.5.1+
17+
18+
.Procedure
19+
20+
. **Disable the default OperatorSources.**
21+
+
22+
Add `disableAllDefaultSources: true` to the spec:
23+
+
24+
----
25+
$ oc patch OperatorHub cluster --type json \
26+
-p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
27+
----
28+
+
29+
This disables the default OperatorSources that are configured by default during
30+
a {product-title} installation.
31+
32+
. **Retrieve package lists.**
33+
+
34+
To get the list of packages that are available for the default OperatorSources,
35+
run the following `curl` commands from your workstation with Internet access:
36+
+
37+
----
38+
$ curl https://quay.io/cnr/api/v1/packages?namespace=redhat-operators > packages.txt
39+
$ curl https://quay.io/cnr/api/v1/packages?namespace=community-operators >> packages.txt
40+
$ curl https://quay.io/cnr/api/v1/packages?namespace=certified-operators >> packages.txt
41+
----
42+
+
43+
Each package in the new `packages.txt` is an Operator that you could add to your
44+
disconnected catalog. From this list, you could either pull every Operator or a
45+
subset that you would like to expose to users.
46+
47+
. **Pull Operator content.**
48+
+
49+
For a given Operator in the package list, you must pull its content:
50+
+
51+
----
52+
$ curl https://quay.io/cnr/api/v1/packages/<namespace>/<operator_name>/<release>
53+
----
54+
+
55+
This example uses the etcd Operator:
56+
57+
.. Retrieve the digest:
58+
+
59+
----
60+
$ curl https://quay.io/cnr/api/v1/packages/community-operators/etcd/0.0.12
61+
----
62+
63+
.. From that JSON, take the digest and use it to pull the gzipped archive:
64+
+
65+
----
66+
$ curl -XGET https://quay.io/cnr/api/v1/packages/community-operators/etcd/blobs/sha256/8108475ee5e83a0187d6d0a729451ef1ce6d34c44a868a200151c36f3232822b \
67+
-o etcd.tar.gz
68+
----
69+
70+
.. To pull the information out, you must untar the archive into a
71+
`manifests/<operator_name>/` directory with all the other Operators that you
72+
want. For example, to untar to an existing directory called `manifests/etcd/`:
73+
+
74+
----
75+
$ mkdir -p manifests/etcd/ <1>
76+
$ tar -xf etcd.tar.gz -C manifests/etcd/
77+
----
78+
<1> Create different subdirectories for each extracted archive so that files are not
79+
overwritten by subsequent extractions for other Operators.
80+
81+
. *Break apart `bundle.yaml` content, if necessary.*
82+
+
83+
In your new `manifests/<operator_name>` directory, the goal is to get your bundle in the following directory structure:
84+
+
85+
----
86+
manifests/
87+
└── etcd
88+
├── 0.0.12
89+
│   ├── clusterserviceversion.yaml
90+
│   └── customresourcedefinition.yaml
91+
└── package.yaml
92+
----
93+
+
94+
If you see files already in this structure, you can skip this step. However, if
95+
you instead see only a single file called `bundle.yaml`, you must first break
96+
this file up to conform to the required structure.
97+
+
98+
You must separate the CSV content under `data.clusterServiceVersion` (each file
99+
in the list), the CRD content under `data.customResourceDefinition` (each file
100+
in the list), and the package content under `data.Package` into their own files.
101+
102+
.. For the CSV file creation, find the following lines in the `bundle.yaml` file:
103+
+
104+
[source,yaml]
105+
----
106+
data:
107+
clusterServiceVersions: |
108+
----
109+
+
110+
Omit those lines, but save a new file consisting of the full CSV resource
111+
content beginning with the following lines, removing the prepended `-`
112+
character:
113+
+
114+
[source,yaml]
115+
.Example `clusterserviceversion.yaml` file snippet
116+
----
117+
apiVersion: operators.coreos.com/v1alpha1
118+
kind: ClusterServiceVersion
119+
[...]
120+
----
121+
122+
.. For the CRD file creation, find the following line in the `bundle.yaml` file:
123+
+
124+
[source,yaml]
125+
----
126+
customResourceDefinitions: |
127+
----
128+
+
129+
Omit this line, but save new files consisting of each, full CRD resource content
130+
beginning with the following lines, removing the prepended `-` character:
131+
+
132+
[source,yaml]
133+
.Example `customresourcedefinition.yaml` file snippet
134+
----
135+
apiVersion: apiextensions.k8s.io/v1beta1
136+
kind: CustomResourceDefinition
137+
[...]
138+
----
139+
+
140+
.. For the package file creation, find the following line in the `bundle.yaml`
141+
file:
142+
+
143+
[source,yaml]
144+
----
145+
packages: |
146+
----
147+
+
148+
Omit this line, but save a new file consisting of the package content beginning
149+
with the following lines, removing the prepended `-` character, and ending with
150+
a `packageName` entry:
151+
+
152+
[source,yaml]
153+
.Example `package.yaml` file
154+
----
155+
channels:
156+
- currentCSV: etcdoperator.v0.9.4
157+
name: singlenamespace-alpha
158+
- currentCSV: etcdoperator.v0.9.4-clusterwide
159+
name: clusterwide-alpha
160+
defaultChannel: singlenamespace-alpha
161+
packageName: etcd
162+
----
163+
164+
. **Create an Operator catalog image.**
165+
166+
.. Save the following to a Dockerfile, for example named
167+
`custom-registry.Dockerfile`:
168+
+
169+
[source,go]
170+
----
171+
FROM registry.redhat.io/openshift4/ose-operator-registry:v4.2 AS builder
172+
173+
COPY manifests manifests
174+
175+
RUN /bin/initializer -o ./bundles.db
176+
177+
FROM scratch
178+
179+
COPY --from=builder /build/bundles.db /bundles.db
180+
COPY --from=builder /build/bin/registry-server /registry-server
181+
COPY --from=builder /bin/grpc_health_probe /bin/grpc_health_probe
182+
183+
EXPOSE 50051
184+
185+
ENTRYPOINT ["/registry-server"]
186+
187+
CMD ["--database", "bundles.db"]
188+
----
189+
190+
.. Use the `podman` command to create and tag the container image from the
191+
Dockerfile:
192+
+
193+
----
194+
$ podman build -f custom-registry.Dockerfile \
195+
-t <internal_registry_route>/<namespace>/custom-registry <1>
196+
----
197+
<1> Tag the image for the internal registry of the disconnected {product-title}
198+
cluster and any namespace.
199+
200+
. **Push the Operator catalog image to a registry.**
201+
+
202+
Your new Operator catalog image must be pushed to a registry that the
203+
{product-title} can access. This can be the internal registry of the cluster
204+
itself or another registry that the disconnected cluster has network access to,
205+
such as an on-premise Quay Enterprise registry.
206+
+
207+
For this example, login and push the image to the internal registry of the
208+
disconnected {product-title} cluster
209+
+
210+
----
211+
$ podman push <internal_registry_route>/<namespace>/custom-registry
212+
----
213+
214+
. **Create a CatalogSource pointing to the new Operator catalog image.**
215+
216+
.. Save the following to a file, for example `my-operator-catalog.yaml`:
217+
+
218+
[source,yaml]
219+
----
220+
apiVersion: operators.coreos.com/v1alpha1
221+
kind: CatalogSource
222+
metadata:
223+
name: my-operator-catalog
224+
namespace: default
225+
spec:
226+
displayName: My Operator Catalog
227+
sourceType: grpc
228+
image: <internal_registry_route>/<namespace>/custom-registry:latest
229+
----
230+
231+
.. Create the CatalogSource resource:
232+
+
233+
----
234+
$ oc create -f my-operator-catalog.yaml
235+
----
236+
237+
.. Verify the CatalogSource and package manifest are created successfully:
238+
+
239+
----
240+
# oc get pods -n openshift-marketplace
241+
NAME READY STATUS RESTARTS AGE
242+
my-operator-catalog-6njx6 1/1 Running 0 28s
243+
marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
244+
245+
# oc get catalogsource -n openshift-marketplace
246+
NAME DISPLAY TYPE PUBLISHER AGE
247+
my-operator-catalog My Operator Catalog grpc 5s
248+
249+
# oc get packagemanifest -n openshift-marketplace
250+
NAME CATALOG AGE
251+
etcd My Operator Catalog 34s
252+
----
253+
+
254+
You should also be able to view them from the *OperatorHub* page in the web
255+
console.
256+
257+
. **Mirror the images required by the Operators you want to use.**
258+
259+
.. Determine the images defined by the Operator that you are expecting. This
260+
example uses the etcd Operator, requiring the `quay.io/coreos/etcd-operator`
261+
image.
262+
263+
.. To use mirrored images, you must first create an ImageContentSourcePolicy for
264+
each image to change the source location of the Operator catalog image. For
265+
example:
266+
+
267+
[source,yaml]
268+
----
269+
apiVersion: operator.openshift.io/v1alpha1
270+
kind: ImageContentSourcePolicy
271+
metadata:
272+
name: etcd-operator
273+
spec:
274+
repositoryDigestMirrors:
275+
- mirrors:
276+
- <internal_registry_route>:5000/coreos/etcd-operator
277+
source: quay.io/coreos/etcd-operator
278+
----
279+
280+
.. Use the `oc image mirror` command from your workstation with Internet access to
281+
pull the image from the source registry and push to the internal registry
282+
without being stored locally:
283+
+
284+
----
285+
$ oc image mirror quay.io/coreos/etcd-operator \
286+
<internal_registry_route>:5000/coreos/etcd-operator
287+
----
288+
289+
You can now install the Operator from the OperatorHub in disconnected mode.

0 commit comments

Comments
 (0)