The goal of this task is to investigate potential impact of a restricted networking environment ("air gapped") on CRW 2.0 (based in Che 7)

Use cases

Installation

A customer willing to deploy CRW in an airgap environment or restricted environment still need the ability to deploy CRW.

There are different aspects of the installation which must be handled. From the deployment of the CRW images, but also all the required components used by each of the devfile and plugins.

The installation procedure should be simplified for the customer:

• We should automate the flow of pulling the images into an internal registry.
• The operator would then be configurable to use the images from that internal registry.
• The plugin binaries should be available (probably with the plugin registry) and the plugin registry should be configured to point to the right place
• The devfiles should be pointing to the images on the internal registries

Update

Once an installed CRW has been deployed in an airgap environment, there will be needed to manage the upgrades to newer version.

A customer, will need solutions in order to:

• Update the devfile registry
• Update the plugin registry (and the plugins themselves)
• Update the CRW components

Use

As a developer working with CRW and using the different default stacks packaged, the stacks should be configurable so that they are pointing we are to internal dependencies management tools (like artifactory or other).
It should be easy enough to the customer and automated, to configure the stacks (and the associated devfile) so that they are rely on different dep management tools.

Details

CRW images

`CRW` images: operator, server, postgres, RH-SSO. It is already possible to override those with local images before the installation. The operator takes care of it.

TODO: Make sure JWT proxy image (used as auth gateway) is configurable in CR spec. Currently not supported in chectl. https://github.com/redhat-developer/codeready-workspaces/blob/master/devdoc/building/che7-custom-resource-airgap.yaml - see chectl + cr.yaml should be able to overriding ALL images deployed via operator #14088

Plugin registry

Plugin registry. In an offline environment a customer will need to deploy a local plugin registry. As of Che 7, this is handled by the Operator at deploy-time. See https://github.com/redhat-developer/codeready-workspaces/blob/master/devdoc/building/che7-custom-resource-airgap.adoc

TODO: Build a UBI image with plugin registry + required vsix and icons. WIP in https://github.com/eclipse/che-plugin-registry/pull/195

Plugin Broker

Workspace config has attributes with plugin IDs. Plugins are being searched in plugin registry, and plugin broker downloads binaries.

Plugin broker image is defined as a workspace master property.

TODO: Make sure it is possible to override plugin broker image in CR spec. Currently not supported in chectl. https://github.com/redhat-developer/codeready-workspaces/blob/master/devdoc/building/che7-custom-resource-airgap.yaml - see chectl + cr.yaml should be able to overriding ALL images deployed via operator #14088

Sidecar plugin binaries

Some plugin binaries are downloaded from VS Code marketplace, others are available in GH releases. In any case, when in an offline environment, neither of them will be available.

Potential solution:

• Pull all images for CRW 2.0
• Pull all the images needed for the default stacks (as referenced by the default devfiles)
• Pull all the images for the plugins
• Push all those images into a custom container registry
• Update the devfiles to point to the custom container registry, instead of marketplace or GH
  • https://github.com/eclipse/che-plugin-registry/blob/master/plugins/ms-vscode.go/0.9.2/meta.yaml#L14
  • https://github.com/eclipse/che-plugin-registry/blob/master/plugins/ms-vscode.typescript/1.30.2/meta.yaml#L8
• Make customized devfiles available to users so they can create workspaces

Sidecar images

Remote vscode plugins are started in sidecars. Each plugin has its own image that inherits Theia runtime base image with nodejs installed + plugin and language dependencies.

Potential solution:

• pull images, tag and push to a local registry
• build and deploy a custom plugin registry, replace links to DockerHub with images coming from a local registry.

Running Workspace

Java/Maven/Gradle

It will be necessary to point build tools to local registries (maven's settings.xml, ~/.gradle/gradle.properties).
Often, local maven repos artifactories are using self signed certificates, so a customer will either have to create a keystore and add it to default java cacerts or define keystore in build commands (-DpropName=)

NodeJS

npm should be configured to be using a local registry (npm set registry? env var passed to)
If npm registry uses self signed certs, crt should be added to root ca in a container (rebuild an image) or npm should be aware of ca (npm config set ca ""?)

Other stacks

Similarly, other stacks like PHP or .NET may need such fine tuning to work with local registries/artifactories etc.