Kubernetes
Gluesync Kubernetes support comes with a manifest configuration file and a kustomize-based archive file that we provide to eligible customers that have purchased the Enterprise license pack.
Pre-flight checks
To ensure a smooth experience in running Gluesync as a Kubernetes service, please walk through the following checklist to ensure your environment is ready.
-
The environment is able to host the Gluesync pod as per the recommended specification, either because a node with enough free resources is available or you have provided for some form of auto-scaling.
-
The environment is able to reach the Internet, with particular requirements for the MOLO17 container registry at https://registry.hub.docker.com and sub-paths.
-
You have received the Access Tokens to the MOLO17 container registry.
-
The environment is able to reach both source and destination databases on the relevant ports/protocols.
-
You have received the Kustomize-based archive and have uncompressed it on a workstation that has the Kustomize tool available - either as a stand-alone tool or the one integrated in kubectl.
Running
To successfully run the service you should just prepare the configuration inside the config.json file, build the manifest via the Kustomize tool, and apply that to your cluster.
Inside the provided archive, a dockerconfigjson file has already been prepared for you to use your Access Tokens to login to the container registry. Also, a logback.xml file has been pre-configured.
[from the directory containing the main kustomization.yaml file]
$ kustomize build . > manifest.yaml
$ kubectl apply -f manifest.yamlCustom registry
Should you need to use a custom registry, e.g. because your environment cannot reach MOLO17’s container registry, please contact us to arrange a specific setup. You can use the provided Access Tokens to locally mirror the container, but the software will have to be able to contact gluesync.com to perform license key validation.
In this case, please edit accordingly the Kustomize-based service templates to ensure the correct registry is used, and the related access credentials are persisted in the dockerconfigjson resource (or, if applicable, a different imagePullSecret is used).