By using customizations such as those below, you can add and remove the features as needed for your ESS deployment.
Applying Your Customizations¶
In the reference deployment, you installed ESS
installer.sh -c install. As part of the operation, the script
calls the following:
kustomize build <some path>
This builds the Inrupt-provided customization for the reference deployment.
To customize your ESS deployment, you can use your own customization overlays.
Keep your own customizations in a safe place, such as source control.
Consider using automations to apply your own customization to your cluster.
Create a new directory for your overlay and navigate to it:
mkdir my-overlay cd my-overlay
Now you can refer to the deployment shipped by Inrupt and add the desired changes:
# kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - <path to ESS scripts>/kubernetes/overlays/minikube/ - labels.yaml
# labels.yaml apiVersion: builtin kind: LabelTransformer metadata: name: author labels: author: me
To verify your overlay, you can build the overlay and output to a file, such as
kustomized.yaml, for review:
kustomize build > kustomized.yaml
You may want to keep an old copy of the
kustomized.yamlfile for comparison with your new version.
In the example, notice that your labels are applied to a wide range of objects in the file.
To preview the changes that will be applied to your cluster, you can use
kubectl diff -f kustomized.yaml
When you are ready, you can apply the changes to your cluster:
kustomize apply -f kustomized.yaml
These techniques allow you to create a number of workflows, such as:
dev -> staging -> production
extra operational overlays
When designing your customizations, be aware that new features and services will arrive in updates to ESS. As such, consider the following when customizing:
- Be selective.
Try to focus the customization on the specific objects you want to change. For example, specify the deployment name when scaling to 20 replicas.
- Use labels to select things by their purpose.
A number of parts of the deployment have labels such as
role:loggingto help you choose things to customize.
replacebehaviors to control what you consume.
You can choose to extend an existing object, such as a
merge. If you want to fully replace the original content, you can use
- Use namespaces to separate distinct workloads
For instance, you may be adding logging or certificate management. Consider putting those in other namespaces if they are cluster-wide and serve other workloads, not just ESS.
However, if you are adding a new web server that will work in tandem with ESS, then using the same namespace as ESS may be preferable.