This topic provides an overview of the components and resources you need to install VMware Tanzu Operations Manager in air-gapped environments, including the typical corresponding automation resources.

Offline components

To run offline, you must obtain resources from the internet and move them into offline components that store and use them. The method you use to move a resource from the Broadcom Support portal or GitHub into an offline environment can vary from setting up a designated proxy to burning a DVD.

The following image displays types of resources, and the components you must move them to, in your offline environment. It also includes a jumpbox. The jumpbox is a Linux host for running commands such as bosh, uaac, and fly. You can use the Tanzu Operations Manager VM for this purpose.

Blocks shown in this configuration are:

  • Tanzu Operations Manager Network Resources, feeding into:
    • S3
    • Artifact Store
  • Automation Resources, feeding into:

    • Artifact Store
    • Docker Registry
    • Git
    • Concourse

      Operations Manager block diagram

The following table provides more detail about resources and the component you must move them to:

Resource Move to...
Broadcom Support portal products such as tiles, stemcells, BOSH releases, and Tanzu Operations Manager S3 and artifact store
Pipelines and scripts Git
Configuration Git
Container images Docker Registry, S3, or artifact store
Third-party resources such as NSX-T and OSS BOSH releases Artifact store
Backup artifacts S3

Architectural patterns

The following sections describe three architectural patterns for running in air-gapped environments. The pattern you use depends on how your environment is set up.

Pattern One: Artifact store with internet access

It is common for organizations to deploy an artifact store such as Artifactory or Nexus as a gateway to the Internet. In this configuration, the artifact store is typically configured as a Docker mirror.

This pattern includes an S3 component that is used only for backups of the installation. Blocks in this configuration are:

  • Jumpbox
  • S3
  • Git
  • Runway / Concourse, feeding into:
    • Tanzu Operations Manager Network Resources
    • Artifact Store
  • Automation Resources, feeding into:
    • Artifact Store

Ops Manager block diagram with S3

The following table provides an example of how you might handle resources in this scenario:

Resource Component
VMware Tanzu products such as tiles, stemcells, BOSH releases, and Tanzu Operations Manager This architectural pattern presents the challenge of getting Broadcom Support portal resources from the Internet into the artifact store. For example, Artifactory and Nexus cannot interact directly with Broadcom Support portal. You could place Broadcom Support portal resources in an artifact store through a remote Concourse worker with access to the internet, or by downloading them from the internet and placing them in the artifact store manually, for example.
Pipelines and scripts Store in Git. Use manual clone and push. Modify pipelines to use registry_mirror.
Configuration Store in Git. Use manual clone and push.
Container images Store in the artifact store that you configured as a mirror.
Third-party resources such as NSX-T and OSS BOSH releases Store in a generic artifact store repository.
Backup artifacts Store in a S3 blobstore.

Pattern Two: Completely offline

In completely offline environments, you must bring in all resources manually and store them in the available local components. Blocks shown in this configuration are:

  • Jumpbox
  • Tanzu Operations Manager Network Resources, feeding into:
    • Operator and media
  • Automation Resources, feeding into:
    • Operator and media
  • Operator and media, feeding into:
    • S3
    • Artifact Store
    • Docker Registry
    • Git
    • Concourse

Ops Manager block diagram - completely offline

In this architectural pattern, you must configure pipelines to watch components for changes and manually apply updates when they are available. The following table provides an example of how you might handle resources in this scenario:

Resource Component
VMware Tanzu products such as tiles, stemcells, BOSH releases, and Tanzu Operations Manager Manually upload to Nexus.
Pipelines and scripts Modify pipelines to use a local Harbor Docker registry. Manually clone an online environment, bring it to the offline environment on DVD, and push it to offline Git.
Configuration Store in your offline Git.
Container Images Get from the Internet, transfer to USB, and push to offline Harbor.
Third-party resources such as NSX-T and OSS BOSH releases Store in a generic artifact store repository.
Backup artifacts Store in a S3 blobstore.

Pattern Three: TLS intercepting proxy

This pattern allows Internet access, but only through a proxy that decrypts and rewrites TLS certificates. In general, this resembles an online install, however it requires that you add your corporate certificate to all BOSH-deployed VMs. Blocks shown in this configuration are:

  • Jumpbox
  • Tanzu Operations Manager Network Resources block and Automation Resources block, feed (through a proxy) into:
    • S3
    • Artifact Store
    • Docker Registry
    • Git
    • Concourse

Ops Manager block diagram - TLS intercepting proxy.

Some of the challenges in this pattern include the following:

  • Any automation that calls to the Internet will fail if it does not have the corporate certificate in its trust store.
  • Concourse tasks that do not use resources do not receive updated BOSH root certificates. This means you must configure tasks to ignore TLS errors or update the root certificates as part of the tasks.
check-circle-line exclamation-circle-line close-line
Scroll to top icon