Air-gapped GitOps with OCM & Flux
Introduction
In this guide, we will show you how the tools provided by OCM make it possible to automate your air-gapped deployments.
Air-gapped can mean different things depending on the context. For this guide, we’ll assume it means your deployment artifacts are stored in a private registry protected by the security controls at your organization. Your applications only have access to this private registry and little to no public internet access.
We’ll take the same podinfo
component that we deployed in the Deploy Applications with OCM & GitOps guide but this time we will use the OCM CLI to transfer the component to our own registry. The application will then be deployed from this “private” registry. This, of course, mimics a real-world air-gap scenario. In practice, there could be many layers of security between the two registries; however, the mechanics are ultimately the same.
Table of Contents
Requirements
Component Content
The podinfo
component contains three resources:
- a container image for podinfo
- a kubernetes deployment manifest for podinfo
- a configuration file read by the ocm-controller
We can list these resources using the ocm
CLI:
If we examine the config
file, we will see a section named localization
:
The localization
section contains a list of rules that describe the substitutions the ocm-controller
needs to perform to ensure that the Local copy of our image is deployed. OCM provides an identifier for each resource which can always be resolved to a specific storage location at which the resource can be accessed. This secret sauce makes it possible to automate air-gapped deployments using OCM.
We can examine the image resource to see precisely where the image can be accessed:
Component Transfer
We can use the ocm
CLI to transfer this public component into our “private” registry. Because we are simulating an air-gapped install, we instruct the ocm
CLI to copy the resources along with the component metadata:
It will take few moments to complete the transfer. Once it is complete we can view the component in the air-gapped registry:
Let’s examine the image resource on the component in our private registry:
We can see that the image reference now points to an image stored in our air-gapped registry.
GitOps & Localization
Now that our component has been successfully transferred, let’s deploy it using GitOps.
We assume you have completed the Deploy Applications with OCM & GitOps guide and will use that repository as the starting point for our air-gapped deployment.
Because our air-gapped OCM repository is private, we need to provide credentials. This will enable the ocm-controller
to retrieve components from the repository.
We can do this using a ServiceAccount
. First, create an Kubernetes Secret
to hold the credentials:
Then, create the ServiceAccount
:
Next, let’s modify the ComponentVersion
manifest so that it points to our air-gapped OCM repository and references the ServiceAccount
:
Now we need to tell the ocm-controller
to use the Localization rules we discussed earlier. To do this, we create a Localization
Custom Resource:
You can see that we have used the existing Resource
as the source for the Localization
and have provided the localization rules using the spec.configRef
field. The ocm-controller
enables us to freely chain resources together in order to perform a sequence of transformations upon an OCM resource.
Because the output we want to deploy is now generated by the Localization
CR rather than the Resource
CR, we need to update our FluxDeployer
:
Let’s commit, push, and reconcile these changes:
Verification
Flux should now be reconciling the Localized manifest with image references pointing to our private OCM repository.
We can easily verify this using kubectl:
To Be Continued
If we look closer, however, we will see that our application has not successfully rolled out:
If we filter the events we can see that Kubernetes cannot pull the image owing to missing credentials:
Check out our GitOps Driven Configuration of OCM Applications guide to see how we can use the ocm-controller
to configure our application at runtime and solve exactly this kind of problem!
Conclusion
In this tutorial we have shown how we can automate the process of delivering software to air-gapped environments using the Open Component Model and Flux.
We have shown how the process of Localization is enabled via OCM and combined with GitOps delivers a seamless application deployment model suitable for any environment.