Add disconnected OpenShift installation page

Andrew Dunnrequested to merge
andunn/disconnected-openshift-docs into master

What does this MR do?

Adds a page for installing the GitLab Operator and a GitLab instance on a disconnected OpenShift cluster, as agreed in #860 (comment 4021843648). The page covers the manifest and Helm installation methods, redirects pulls with an ImageTagMirrorSet or with image values, links the chart's custom images page, and leaves OLM out of scope.

The charts pull images by tag, so an ImageDigestMirrorSet alone redirects none of the default pulls. The page says so and shows the tag-based set that oc-mirror generates.

flowchart LR
  N[Node pulls registry.gitlab.com/gitlab-org/...] --> S{ImageTagMirrorSet applied?}
  S -- yes --> M[Mirror registry in your network]
  S -- no --> X[Public registry, blocked]
  M --> OK[Pod starts]
  X --> F[ImagePullBackOff]

Test plan

Each step ran on OpenShift 4.22.14 with Operator 3.5.0, chart 10.5.0, and egress to the public registries blocked. The GitLab CR used external PostgreSQL and Redis and turned off Gateway API. Unless an item says otherwise, it also turned off TLS, the registry, KAS, and GitLab Exporter.

  1. No mirror set: the Operator pod stays in ImagePullBackOff.
  2. ImageTagMirrorSet with the manifest or Helm install: Running.
  3. Image values only: Running. With a self-signed certificate and Routes, /users/sign_in returns 200. global.image.registry alone leaves the shared-secrets pod in ErrImagePull.
  4. ImageDigestMirrorSet alone: ImagePullBackOff. With image.digest, it pulls from the mirror.
  5. Default components, with the registry, KAS, GitLab Exporter, a self-signed certificate, and S3: Running, with every pod image from the mirror.
  6. Mirror to disk, then from disk to the registry on the same host with egress blocked: Running.
  7. OpenShift Routes on the default-components install: with global.ingress.enabled: true, /users/sign_in returns 200 through the router.
  8. cert-manager images mirrored the same way: Available.

Related issues

Relates to #860

The page's entry in the global navigation comes in the companion MR gitlab-org/technical-writing/docs-gitlab-com!2758 (merged).

Author's checklist

If you are only adding documentation, do not add any of the following labels:

  • ~"feature"
  • ~"frontend"
  • ~"backend"
  • ~"bug"
  • ~"database"

These labels cause the MR to be added to code verification QA issues.

Review checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

  • As soon as you begin reviewing, select Start a review on your first comment so the MR shows Reviewer started review.
  • If the content requires it, ensure the information is reviewed by a subject matter expert.
  • Technical writer review items:
    • Ensure docs metadata is present and up-to-date.
    • Ensure the appropriate labels are added to this MR.
    • If relevant to this MR, ensure content topic type principles are in use, including:
      • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
      • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
      • Any task steps should be written as a numbered list.
      • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
  • Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
  • Ensure a release milestone is set.

An AI coding assistant wrote this change. The assistant also ran each described step on an OpenShift Local 4.22.14 cluster on a test VM, and ran vale, markdownlint-cli2, and lychee on the changed pages from the repository's lint configuration.

Edited by Andrew Dunn

Merge request reports