Replicated is proud to announce the support of air-gapped Helm installations. While enabling air gap installations into self-hosted customer environments has been a cornerstone of the Replicated platform for quite some time, this new feature expands Replicated’s air gap support options and gives ISVs more flexibility in determining how to best support their customers’ air gap needs.
Traditionally, an air gap network meant something super specific: a network that was physically separated from other networks like the Internet. Today, air gap capabilities can be used for this scenario as well as environments that may have some temporary access to the global internet, but need heightened security and control measures. It is this scenario that we walk through today. See how Chuck D’Antonio, Director of Solutions Engineering, sets up air gap support within his Replicated enabled Helm charts in the video and walkthrough below. If you’re ready to jump right in, you can see our docs here.
First, Chuck logs into the Replicated download portal, which requires a customer-specific URL and password. He logs in as his customer Geeglo so they can install his sample application, SlackerNews.
He chooses “existing cluster with Helm” as the installation type. This gives him instructions to get all the images for the application into a local registry.
On his local workstation, he pulls all the images. He’s pulling all the images that the air-gap builder identified as being part of this application. This is going to be the complete list of images that your customer moves from the internet to either their air-gapped environment’s registry or, in this case, a tightly secured network that can only access the internal registry and be accessed from hosts within his network.
Once the images are pulled over, they are tagged by entering in the name of the local registry into the Replicated download portal. The name of the registry has been added into the copy/paste commands.
Chuck then pushes everything over to his local registry, which in this example is a Harbor registry.
Once the images appear in the registry, Chuck uses the subsequent commands on the Replicated portal to pull the Helm chart. For this, he pulls the value from the Helm chart and edits it to use within his environment.
Chuck utilizes a script he previously wrote (reach out to him at chuck@replicated.com if you’d like more information on what happens behind the scenes in this script). You can now see that all the registries are within Chuck’s values.yaml file.
Now, he utilizes the ‘run preflight checks’ command within the Replicated portal to run preflight checks against his cluster using the values in the values.yaml file. All of the checks pass.
Now, he’s ready to install his chart. He grabs the “Install the chart” command from the Replicated download portal. The containers are created, and when he runs a command to get the pods he can see that they’re running from his local registry in a fully secure environment.
You may be curious about using the Replicated SDK in this environment. It will continue to run as expected, since it has a copy of the license provided in its values. The SDK will also gather telemetry—including custom metrics—into Kubernetes secret that you’ll receive with every support bundle your customer sends.
That’s it! For more information on Replicated’s air gap support don’t hesitate to reach out to Chuck at chuck@replicated.com or book a demo.